[arch-dev-public] [PATCH] initscripts: Add a splash support
Hi! This patch finishes the work done by dtw and iphitus for bringing an optional splash support to default initscripts. It eliminates the need for separate initscripts-splash package which provides/conflicts=('initscripts'). User has to install splashy or fbsplash which provide required mikinitcpio hooks and ${SPLASH}_wrapper script, and then use e.g. SPLASH="splashy" in rc.conf to enable it. -- Roman Kyrylych (Роман Кирилич)
Am Sat, 3 Nov 2007 16:48:05 +0200 schrieb "Roman Kyrylych" <roman.kyrylych@gmail.com>:
Hi!
This patch finishes the work done by dtw and iphitus for bringing an optional splash support to default initscripts. It eliminates the need for separate initscripts-splash package which provides/conflicts=('initscripts').
User has to install splashy or fbsplash which provide required mikinitcpio hooks and ${SPLASH}_wrapper script, and then use e.g. SPLASH="splashy" in rc.conf to enable it.
-1 from me We are not focussed to be an eyecandy distribution. There's already a usable solution. I dislike to have another possible breaker in core. Andy
Saturday 03 November 2007, Andreas Radke wrote: | Am Sat, 3 Nov 2007 16:48:05 +0200 | | schrieb "Roman Kyrylych" <roman.kyrylych@gmail.com>: | > Hi! | > | > This patch finishes the work done by dtw and iphitus for | > bringing an optional splash support to default initscripts. | > It eliminates the need for separate initscripts-splash package | > which provides/conflicts=('initscripts'). | > | > User has to install splashy or fbsplash which provide required | > mikinitcpio hooks and ${SPLASH}_wrapper script, and then use | > e.g. SPLASH="splashy" in rc.conf to enable it. | | -1 from me | | We are not focussed to be an eyecandy distribution. There's | already a usable solution. I dislike to have another possible | breaker in core. -1 from me too why is a separate initscripts-splash pkg a bad thing? for those who want to play with it, let them, but do not make the initscripts more complex as it should be. - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Am Samstag, 3. November 2007 schrieb Damir Perisa:
Saturday 03 November 2007, Andreas Radke wrote: | Am Sat, 3 Nov 2007 16:48:05 +0200 | | schrieb "Roman Kyrylych" <roman.kyrylych@gmail.com>: | > Hi! | > | > This patch finishes the work done by dtw and iphitus for | > bringing an optional splash support to default initscripts. | > It eliminates the need for separate initscripts-splash package | > which provides/conflicts=('initscripts'). | > | > User has to install splashy or fbsplash which provide required | > mikinitcpio hooks and ${SPLASH}_wrapper script, and then use | > e.g. SPLASH="splashy" in rc.conf to enable it. | | -1 from me | | We are not focussed to be an eyecandy distribution. There's | already a usable solution. I dislike to have another possible | breaker in core.
-1 from me too
why is a separate initscripts-splash pkg a bad thing? for those who want to play with it, let them, but do not make the initscripts more complex as it should be.
- D
-1 from me too, eye candy for having more trouble is not worth for. and also it makes it more complex greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sat, 3 Nov 2007 17:59:21 +0100 Tobias Powalowski <t.powa@gmx.de> wrote:
Am Samstag, 3. November 2007 schrieb Damir Perisa:
Saturday 03 November 2007, Andreas Radke wrote: | Am Sat, 3 Nov 2007 16:48:05 +0200 | | schrieb "Roman Kyrylych" <roman.kyrylych@gmail.com>: | > Hi! | > | > This patch finishes the work done by dtw and iphitus for | > bringing an optional splash support to default initscripts. | > It eliminates the need for separate initscripts-splash package | > which provides/conflicts=('initscripts'). | > | > User has to install splashy or fbsplash which provide required | > mikinitcpio hooks and ${SPLASH}_wrapper script, and then use | > e.g. SPLASH="splashy" in rc.conf to enable it. | | -1 from me | | We are not focussed to be an eyecandy distribution. There's | already a usable solution. I dislike to have another possible | breaker in core.
-1 from me too
why is a separate initscripts-splash pkg a bad thing? for those who want to play with it, let them, but do not make the initscripts more complex as it should be.
- D
-1 from me too, eye candy for having more trouble is not worth for. and also it makes it more complex
greetings tpowa
-1 from me, too. I dislike the idea to make it more complex just for eyecandy. Daniel
I agree. I have never myself been very big on bootsplash screens and such. I actually want to see what is happening when i boot my machine..or i click the power button and go get myself some coffee or tea. yay me! I wouldn't think we need to add complexity to our initscripts just for this. I think documenting how people can do it themselves and providing the companion packages (fbsplash,etc), is the way to go.
I want to summarize the arguments for adding the patch again and provide you with the patch that I would consider a good idea, if it works for the splash implementations that exist: 1) The patch is unintrusive, there is no way it could harm anyone who has splash disabled. 2) Maintaining two sets of initscripts (one with, one without splash) will result in inconsistencies between the two and in _more_ bugreports. 3) We'd make lots of users happy, because they will use splash anyway, but right now will break their systems in doing so. The ones of you against using this could summarize their arguments as well. The only thing I remember was "I don't use splash, so I see no reason to support it in any way", which I don't accept as a real argument. This is the link to the diff as it is in the splash branch now: http://projects.archlinux.org/git/?p=initscripts.git;a=commitdiff;h=ad804da1...
thank you Thomas for the thesis - here the antithesis of your points from my point of view. lets see if we can find a synthesis :) Sunday 04 November 2007, Thomas Bächler wrote: | 1) The patch is unintrusive, there is no way it could harm anyone | who has splash disabled. is the implementation so that initscripts is untouched if the thing is disabled? if it gets enabled by chance (in rc.conf, right?) then will the code check for all needed things before trying to do fancy things? what happens if e.g. kernel framebuffer driver breaks during a kernel update? will the machine still have unbroken initscripts? this are my concerns on your point. | 2) Maintaining two sets of initscripts (one with, one without | splash) will result in inconsistencies between the two and in | _more_ bugreports. the inconsistencies will not happen, if the fork pkg takes initscript pkg as template and just apply the patch, right? but i see thta it is more work to maintain two pkgs. who is the main coder / responsible of initscripts at the moment? i want the opinion the person who maintains this code if he wants to include the patch or not. | 3) We'd make lots of users happy, because they | will use splash anyway, but right now will break their systems in | doing so. i'm not against having the option to make somebody happy. life is making people happy after all. but it should not be risking to break an essential part just to have an eye-candy. adding niceties is not KISS and also a modification of philosophy of arch. i'm not against it in a strict sense, but i'm for letting it happen with zero compromises. | The ones of you against using this could summarize their arguments | as well. The only thing I remember was "I don't use splash, so I | see no reason to support it in any way", which I don't accept as a | real argument. not at all here - so let me try a synthesis: if the coder(s) who are in charge for initscripts decide to take the burden to add this eye-candy to maintain and if the code is failsafe in testing for broken elements (fb driver, missing required pkgs, ...) and falling back to "plain behaviour" in case of any problem and the eye-candy is per default disabled and easily configurable then i'm for adding it. feel free to add any antithesis to my synthesis or finish the discussion :) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On Nov 4, 2007 11:57 AM, Damir Perisa <damir.perisa@solnet.ch> wrote:
thank you Thomas for the thesis - here the antithesis of your points from my point of view. lets see if we can find a synthesis :)
Sunday 04 November 2007, Thomas Bächler wrote: | 1) The patch is unintrusive, there is no way it could harm anyone | who has splash disabled.
is the implementation so that initscripts is untouched if the thing is disabled? if it gets enabled by chance (in rc.conf, right?) then will the code check for all needed things before trying to do fancy things? what happens if e.g. kernel framebuffer driver breaks during a kernel update? will the machine still have unbroken initscripts? this are my concerns on your point.
| 2) Maintaining two sets of initscripts (one with, one without | splash) will result in inconsistencies between the two and in | _more_ bugreports.
the inconsistencies will not happen, if the fork pkg takes initscript pkg as template and just apply the patch, right? but i see thta it is more work to maintain two pkgs. who is the main coder / responsible of initscripts at the moment? i want the opinion the person who maintains this code if he wants to include the patch or not.
Do people really not read the whole email thread before responding? I thought this was quite clear: Thomas:
Maintaining a separate initscripts package (official or unofficial) will result in the scripts being out of sync, and we will get bug reports for already fixed bugs. As mentioned above, the patch is unintrusive and (apart from some small details) fine.
Thomas:
That said, the only ones that have seriously been working on initscripts are tpowa and me, with an occasional patch from Roman and Dan. So, despite the fact that I am willing to listen to the concerns of others, the final decision lies with me and tpowa.
He is both willing to maintain it and handle the bug reports (which will be far less because the packages will not be out of sync). Obviously the code may not be perfect yet, so why don't we focus our efforts on improving the code so it won't break our systems instead of flat-out "NO" answers. I guess it just bugs me when we have so many nay-sayers and no doers in our developer group. Roman and Thomas are making an effort here to improve something and a lot of people are just coming out and saying a lot without doing anything, and it really gets to those of us that try to get things done around here. -Dan
Damir Perisa schrieb:
Sunday 04 November 2007, Thomas Bächler wrote: | 1) The patch is unintrusive, there is no way it could harm anyone | who has splash disabled.
is the implementation so that initscripts is untouched if the thing is disabled? if it gets enabled by chance (in rc.conf, right?) then will the code check for all needed things before trying to do fancy things? what happens if e.g. kernel framebuffer driver breaks during a kernel update? will the machine still have unbroken initscripts? this are my concerns on your point.
My concerns about breaking and not breaking things were so far only limited to the case where SPLASH is disabled: If SPLASH is disabled, or /sbin/${SPLASH}_wrapper is not found, then the splash_wrapper function does nothing. Thus nothing will change for you. What happens if the framebuffer breaks is completely up to the specific splash implementation, which may of course be buggy. But those bug reports will concern only whoever maintains splashy or gensplash (which I heard already exist as working packages), and these bugs will only affect those who have splash enabled. I guess that the splash_wrapper cannot initialize itself and will ignore all further commands, thus resulting in our "normal" boot screen. Quoting from your other mail:
actually would break a lot of my private scripts when enabled splash, because i am using stat_XX() functions from functions of arch that i use in xterm.
what would happen if you would use the splash_wrapper on a not-framebuffer capable device? i do not know what is actually the /sbin/${SPLASH}_wrapper doing, but will it fall back to the splash_wrapper() { : } behaviour if it detects that it cannot use any framebuffer device?
The splash_wrapper apparently must have a function that initializes it and one that de-initializes it. Thus, if you call a stat_* function after the splash has exited, splash_wrapper ignores the call. Again, it depends on the splash wrapper implementation, which I don't know or maintain.
this is of course a detail and i'm not mentioning it because i use this functions but in general. is there an option on what happens when "/sbin/${SPLASH}_wrapper $@" fails?
Nothing. The splash screen is not initialized/updated/closed.
| 2) Maintaining two sets of initscripts (one with, one without | splash) will result in inconsistencies between the two and in | _more_ bugreports.
the inconsistencies will not happen, if the fork pkg takes initscript pkg as template and just apply the patch, right? but i see thta it is more work to maintain two pkgs.
It will simply duplicate work. And as I will not maintain a separate set of initscripts, someone else will, and there will be a time delay. It is simply a bad thing to replace such an essential part of the system with a "3rd party" replacement.
| 3) We'd make lots of users happy, because they | will use splash anyway, but right now will break their systems in | doing so.
i'm not against having the option to make somebody happy. life is making people happy after all. but it should not be risking to break an essential part just to have an eye-candy. adding niceties is not KISS and also a modification of philosophy of arch. i'm not against it in a strict sense, but i'm for letting it happen with zero compromises.
The patch adds a very KISS way to provide optional splash support. It simply adds a few hooks that can be passed to an external program (not necessarily a splash implenetation), or ignored.
| The ones of you against using this could summarize their arguments | as well. The only thing I remember was "I don't use splash, so I | see no reason to support it in any way", which I don't accept as a | real argument.
not at all here - so let me try a synthesis:
if the coder(s) who are in charge for initscripts decide to take the burden to add this eye-candy to maintain
As is already apparent from what I said before, all I am willing to maintain is the skeleton that others can and will use to provide splash support. The patch moves this task out of initscripts, so we can keep them clean and don't need several versions of essentially the same code. The actual splash implementations must provide a wrapper that acts according to the commands that we pass to them. From what Roman said, such wrappers already exist for splashy and gensplash.
if the code is failsafe in testing for broken elements (fb driver, missing required pkgs, ...) and falling back to "plain behaviour" in case of any problem
Again, the behaviour of the wrapper is up to whomever maintains it. If it is missing or fails, the scripts behave as if splash is disabled.
Sunday 04 November 2007, Thomas Bächler wrote: | [...] | Again, the behaviour of the wrapper is up to whomever maintains | it. If it is missing or fails, the scripts behave as if splash is | disabled. ok, thanx +1 for your part from my side - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On Sun, 4 Nov 2007, Thomas Bächler wrote:
I want to summarize the arguments for adding the patch again and provide you with the patch that I would consider a good idea, if it works for the splash implementations that exist:
1) The patch is unintrusive, there is no way it could harm anyone who has splash disabled. 2) Maintaining two sets of initscripts (one with, one without splash) will result in inconsistencies between the two and in _more_ bugreports. 3) We'd make lots of users happy, because they will use splash anyway, but right now will break their systems in doing so.
The ones of you against using this could summarize their arguments as well. The only thing I remember was "I don't use splash, so I see no reason to support it in any way", which I don't accept as a real argument.
This is the link to the diff as it is in the splash branch now: http://projects.archlinux.org/git/?p=initscripts.git;a=commitdiff;h=ad804da1...
+1 for adding a patch for splash support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Sat, Nov 03, 2007 at 04:48:05PM +0200, Roman Kyrylych wrote:
Hi!
This patch finishes the work done by dtw and iphitus for bringing an optional splash support to default initscripts. It eliminates the need for separate initscripts-splash package which provides/conflicts=('initscripts').
User has to install splashy or fbsplash which provide required mikinitcpio hooks and ${SPLASH}_wrapper script, and then use e.g. SPLASH="splashy" in rc.conf to enable it.
+1 from me. We either do the work here (and it doesn't break anything for the users who don't change a thing) or we have to fight with it later in a different package that's nearly exactly the same as initscripts with only a few changes. Jason
Jason Chu schrieb:
User has to install splashy or fbsplash which provide required mikinitcpio hooks and ${SPLASH}_wrapper script, and then use e.g. SPLASH="splashy" in rc.conf to enable it.
+1 from me. We either do the work here (and it doesn't break anything for the users who don't change a thing) or we have to fight with it later in a different package that's nearly exactly the same as initscripts with only a few changes.
I don't like certain details about the patch, but we should create a branch in the initscripts git to finalize it all and then apply it. +1 from here.
On Sun, November 4, 2007 04:25, Thomas Bächler wrote:
Jason Chu schrieb:
User has to install splashy or fbsplash which provide required mikinitcpio hooks and ${SPLASH}_wrapper script, and then use e.g. SPLASH="splashy" in rc.conf to enable it.
+1 from me. We either do the work here (and it doesn't break anything for the users who don't change a thing) or we have to fight with it later in a different package that's nearly exactly the same as initscripts with only a few changes.
I don't like certain details about the patch, but we should create a branch in the initscripts git to finalize it all and then apply it.
+1 from here.
+1 from me. Last I saw the patch was unintrustive and wasn't complicated at all. The support is not activated by default, a user still needs to install splashy/fbsplash, etc. I see no practical reason this patch should not be included. It has no negative side effects, offers more, and is not complicated. Jamese
James Rayner wrote:
On Sun, November 4, 2007 04:25, Thomas Bächler wrote:
Jason Chu schrieb:
User has to install splashy or fbsplash which provide required mikinitcpio hooks and ${SPLASH}_wrapper script, and then use e.g. SPLASH="splashy" in rc.conf to enable it.
+1 from me. We either do the work here (and it doesn't break anything for the users who don't change a thing) or we have to fight with it later in a different package that's nearly exactly the same as initscripts with only a few changes.
I don't like certain details about the patch, but we should create a branch in the initscripts git to finalize it all and then apply it.
+1 from here.
+1 from me. Last I saw the patch was unintrustive and wasn't complicated at all.
The support is not activated by default, a user still needs to install splashy/fbsplash, etc.
I see no practical reason this patch should not be included. It has no negative side effects, offers more, and is not complicated.
Jamese
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
+1 from me too. I agree with James. I want a nice splash once I know my system is running ok, and I don't want to have to struggle to get it. I remember trying splash from community/Aur once long time ago, and since it borked my system, I never wanted to get back to it. If we provide some kind of official support, I'm assuming a good number of users would be interested. So +1 for NOT activating support by default, but making it easy to get if required. Varun
Sunday 04 November 2007, Varun Acharya wrote: | James Rayner wrote: | > On Sun, November 4, 2007 04:25, Thomas Bächler wrote: | >> Jason Chu schrieb: | >>>> User has to install splashy or fbsplash which provide | >>>> required mikinitcpio hooks and ${SPLASH}_wrapper script, and | >>>> then use e.g. SPLASH="splashy" in rc.conf to enable it. | >>> | >>> +1 from me. We either do the work here (and it doesn't break | >>> anything for | >>> the users who don't change a thing) or we have to fight with | >>> it later in a | >>> different package that's nearly exactly the same as | >>> initscripts with only a | >>> few changes. | >> | >> I don't like certain details about the patch, but we should | >> create a branch in the initscripts git to finalize it all and | >> then apply it. | >> | >> +1 from here. | > | > +1 from me. Last I saw the patch was unintrustive and wasn't | > complicated at all. | > | > The support is not activated by default, a user still needs to | > install splashy/fbsplash, etc. | > | > I see no practical reason this patch should not be included. It | > has no negative side effects, offers more, and is not | > complicated. | > | > Jamese | > | > | > _______________________________________________ | > arch-dev-public mailing list | > arch-dev-public@archlinux.org | > http://archlinux.org/mailman/listinfo/arch-dev-public | | +1 from me too. I agree with James. I want a nice splash once I | know my system is running ok, and I don't want to have to struggle | to get it. I remember trying splash from community/Aur once long | time ago, and since it borked my system, I never wanted to get | back to it. i wonder why ;) | If we provide some kind of official support, I'm | assuming a good number of users would be interested. So +1 for NOT | activating support by default, but making it easy to get if | required. seems we have a polarisation here... some are against it, some are for it. can you guys who think we should add this patch please tell me the reason why it cannot be a fork-package of initscripts but has to be integrated? - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On Sun, 2007-11-04 at 12:02 +0100, Damir Perisa wrote:
seems we have a polarisation here... some are against it, some are for it.
can you guys who think we should add this patch please tell me the reason why it cannot be a fork-package of initscripts but has to be integrated?
Initscripts is an important package. Making users install an unofficial initscripts package will give us extra bugreports. I've seen it with all those pesky "XDG_DATA_DIRS is not set" bugreports because Alex decided to move xorg.sh from xproto to libx11 while many users didn't use the official libx11, but a libx11-xcb package.
Sunday 04 November 2007, Jan de Groot wrote: | On Sun, 2007-11-04 at 12:02 +0100, Damir Perisa wrote: | > seems we have a polarisation here... some are against it, some | > are for it. | > | > can you guys who think we should add this patch please tell me | > the reason why it cannot be a fork-package of initscripts but | > has to be integrated? | | Initscripts is an important package. Making users install an | unofficial initscripts package will give us extra bugreports. I've | seen it with all those pesky "XDG_DATA_DIRS is not set" bugreports | because Alex decided to move xorg.sh from xproto to libx11 while | many users didn't use the official libx11, but a libx11-xcb | package. i mean having an official initscripts-flash. one that would take the initscripts as source, apply the patch and be the one used. provided by a dev who likes flash :) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Damir Perisa schrieb:
i mean having an official initscripts-flash. one that would take the initscripts as source, apply the patch and be the one used. provided by a dev who likes flash :)
Maintaining a separate initscripts package (official or unofficial) will result in the scripts being out of sync, and we will get bug reports for already fixed bugs. As mentioned above, the patch is unintrusive and (apart from some small details) fine.
Thomas Bächler schrieb:
Damir Perisa schrieb:
i mean having an official initscripts-flash. one that would take the initscripts as source, apply the patch and be the one used. provided by a dev who likes flash :)
Maintaining a separate initscripts package (official or unofficial) will result in the scripts being out of sync, and we will get bug reports for already fixed bugs. As mentioned above, the patch is unintrusive and (apart from some small details) fine.
I added a splash branch to initscripts and applied the patch. We can merge that once the patch is finalized: http://projects.archlinux.org/git/?p=initscripts.git;a=shortlog;h=splash
On Sun, 04 Nov 2007 13:16:28 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
I added a splash branch to initscripts and applied the patch. We can merge that once the patch is finalized: http://projects.archlinux.org/git/?p=initscripts.git;a=shortlog;h=splash
Why did you open a branch? That sounds to me, that it is decided that we will include the patch to initscripts. There are several devs, who are against this patch!! And you open just a branch to merge it later with official initscripts. For me, that's like I and the other devs were just ignored with the concerns to this patch!!!
Daniel Isenmann schrieb:
Why did you open a branch? That sounds to me, that it is decided that we will include the patch to initscripts. There are several devs, who are against this patch!! And you open just a branch to merge it later with official initscripts.
For me, that's like I and the other devs were just ignored with the concerns to this patch!!!
I only said that we CAN merge the branch later, I didn't say we will. The whole reason I didn't apply the patch to the master branch is that we have not yet decided what to do with it, and I myself am not sure yet. A branch can be easily deleted or ignored for eternity. That said, the only ones that have seriously been working on initscripts are tpowa and me, with an occasional patch from Roman and Dan. So, despite the fact that I am willing to listen to the concerns of others, the final decision lies with me and tpowa.
On Sun, 04 Nov 2007 13:37:26 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
So, despite the fact that I am willing to listen to the concerns of others, the final decision lies with me and tpowa.
Then the whole discussion is senseless. It's like we have concerns about it, but you do what you want, because you are maintaining it. You are doing a great job on initscripts, that's clear. But the behaviour isn't ok! Just opening a branch that CAN be merged later despite the concerns of others isn't right. I know, you can delete this branch, if it isn't merged later, but I think we are a team and have discuss and decide several things together. Sorry for my words, if they sounds a little bit aggressive....
Daniel Isenmann schrieb:
Then the whole discussion is senseless. It's like we have concerns about it, but you do what you want, because you are maintaining it.
As I said, I will listen to concerns, but right now, I haven't seen any real arguments, just things like "Supporting things I don't like/use/want is stupid". I don't use or like splash, in fact, I find it annoying and stupid. But Arch is about choice. If we can give users a choice to use splash by adding a few simple hooks to a few scripts that don't hurt anyone, then why not do it? Right now, users have to break their systems if they want splash, is that the proper solution for you?
Just opening a branch that CAN be merged later despite the concerns of others isn't right. I know, you can delete this branch, if it isn't merged later, but I think we are a team and have discuss and decide several things together.
So, you suggest we should post one patch after the other to the list, making the review a pain in the ass. Adding a branch is just a convenient way to collect the work that has been done and show results to others, so they can actually view what is being suggested (which I assume most of you haven't done).
On Nov 4, 2007 7:43 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Daniel Isenmann schrieb:
Just opening a branch that CAN be merged later despite the concerns of others isn't right. I know, you can delete this branch, if it isn't merged later, but I think we are a team and have discuss and decide several things together.
So, you suggest we should post one patch after the other to the list, making the review a pain in the ass. Adding a branch is just a convenient way to collect the work that has been done and show results to others, so they can actually view what is being suggested (which I assume most of you haven't done).
Daniel- I suggest you read up on GIT before you blow Thomas away with invalid accusations. Branches aren't a big deal in GIT, so calm down. Creating a branch doesn't mean anything is getting done anywhere else. Creating a branch is not a "team" decision at all- that is just retarded and would prevent any progress at all on anything we do. NOT creating a branch would be the stupid thing to do here- people get unmotivated to ever submit patches like this again if they just end up in the black hole of politics and bickering. -Dan
On Sun, Nov 04, 2007 at 02:10:28PM +0100, Daniel Isenmann wrote:
On Sun, 04 Nov 2007 13:37:26 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
So, despite the fact that I am willing to listen to the concerns of others, the final decision lies with me and tpowa.
Then the whole discussion is senseless. It's like we have concerns about it, but you do what you want, because you are maintaining it.
You are doing a great job on initscripts, that's clear. But the behaviour isn't ok! Just opening a branch that CAN be merged later despite the concerns of others isn't right. I know, you can delete this branch, if it isn't merged later, but I think we are a team and have discuss and decide several things together.
Sorry for my words, if they sounds a little bit aggressive....
I'm going to jump on this bandwagon for a minute... I just read your concern and it was "I dislike the idea to make it more complex just for eyecandy". Do you or have you ever maintained initscripts? Have you ever submitted a patch or fixed a bug to do with them? If not, then why does it matter how complex something gets if it just works for what you need it to do? The people who do maintain it and fix the bugs *do* want the patch. Who are you to say whether it's too complex for them or not? Why not say, "thank you for writing the patch, I'm sure that lots of people will be very happy that things have become easier for them"? Jason
On Sun, 4 Nov 2007 12:48:35 -0800 Jason Chu <jason@archlinux.org> wrote:
I'm going to jump on this bandwagon for a minute...
I just read your concern and it was "I dislike the idea to make it more complex just for eyecandy". Do you or have you ever maintained initscripts? Have you ever submitted a patch or fixed a bug to do with them? If not, then why does it matter how complex something gets if it just works for what you need it to do?
The people who do maintain it and fix the bugs *do* want the patch. Who are you to say whether it's too complex for them or not? Why not say, "thank you for writing the patch, I'm sure that lots of people will be very happy that things have become easier for them"?
Jason
No, I have never maintain or send bugfixes to initscripts. You are right, it's not my problem, because other must maintain it. In my opinion it isn't worth to add it anyway, because it is just eyecandy. But if Thomas or anybody else getting it done without any side effects for users who don't have activate splash, go on and add splash support in initscripts. Or in your words: "thank you for writing the patch, I'm sure that lots of people will be very happy that things have become easier for them" ;) +1 from me (IF everything is running fine for users without activated splash, because that's the default of booting archlinux (and I hope it will be the default option in the future)). Daniel
Sunday 04 November 2007, Jason Chu wrote: | The people who do maintain it and fix the bugs *do* want the | patch. i think knowing this in front of this discussion would have saved us much time. and energy... :) ... and i do not mean that one of these who maintain it just put a "+1" but rather a "i maintain initscritps and will include this, please have a x-check of this patch". it should have been announced on this list from Роман but rather from one of this people who maintain it. or is Роман the new initscripts maintainer? - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Man, there was a lot to read through there. Whew! Let me summarize exactly what's happening here. We have a divide between the "what we have now is good enough" crew, and the "lets try some more experimental features" crew. Both sides have valid points. But, sadly, I need to side with one of them. Having splash support in our initscripts is a good thing. We're not forcing anyone to use a bootsplash. In fact, we're doing just the opposite. We're facilitating it. We're saying "if you want to, go ahead". For those of you who DON'T use bootsplash, I humbly suggest you take a peek at rc.sysinit and look at all the stuff we support an no one uses. There's a lot of it. We support quite a lot of stuff in there because, frankly, there's no better place for it. Now here's the thing. This *could* be modular. We *could* do this in a separate dir of scripts that are executed way in the beginning of rc.sysinit. In fact, we could even get crazy and name that dir "/etc/rc0.d" or something. /me smirks. We maintain a very simplistic init style. This is a good thing. The problem with doing so is here - for some features, we need to put support in our scripts. We can't have the support in external files or directories, or anything like that - that's the kind of initsystem we explicitly DON'T have. So here's my suggestion for the naysayers - rewrite our initscripts to support a SysV init style. Do that and I will gladly maintain a second initscripts package. However, right now all you're doing is fighting against the "curse of Arch" - talking real work to death, and killing motivation. In summary: I'm for it.
2007/11/5, Damir Perisa <damir.perisa@solnet.ch>:
Sunday 04 November 2007, Jason Chu wrote: | The people who do maintain it and fix the bugs *do* want the | patch.
i think knowing this in front of this discussion would have saved us much time. and energy... :) ... and i do not mean that one of these who maintain it just put a "+1" but rather a "i maintain initscritps and will include this, please have a x-check of this patch".
it should have been announced on this list from Роман but rather from one of this people who maintain it. or is Роман the new initscripts maintainer?
Wow, I had alot to read this morning. I'm not a maintainer for initscripts, but I carefully watch all functionality and bugs related to i18n and time issues. Heh, I was forced to do this because of many bugs that were in those areas in the past. (Even my first 2 patches for Arch back in times when I was only starting to use it in VMware and which I sent directly do Judd was about fixing non-latin font support for non-UTF8 locales). I sent this patch to Thomas and a copy here at the same time for review. Thus I couldn't include "Our initscripts maintainers do like this patch" in the message. It this would be the case - I or Thomas would sent a message like "There is a new branch in initscripts git with added _OPTIONAL_ splash support via simple _hooks_. blah-blah-blah-etc-comes-here". I thank to Thomas who patiently explained what this patch does and changes. -- Roman Kyrylych (Роман Кирилич)
Sunday 04 November 2007, Thomas Bächler wrote: | I added a splash branch to initscripts and applied the patch. We | can merge that once the patch is finalized: | http://projects.archlinux.org/git/?p=initscripts.git;a=shortlog;h= |splash http://projects.archlinux.org/git/?p=initscripts.git;a=commitdiff;h=ad804da1... +if [ -n "${SPLASH}" -a -x "/sbin/${SPLASH}_wrapper" ]; then + source /etc/$SPLASH.conf + source /etc/rc.d/$SPLASH-functions + splash_wrapper() { + /sbin/${SPLASH}_wrapper $@ + } +else + splash_wrapper() { + : + } +fi and then using it in stat_fail() stat_done() ... actually would break a lot of my private scripts when enabled splash, because i am using stat_XX() functions from functions of arch that i use in xterm. what would happen if you would use the splash_wrapper on a not-framebuffer capable device? i do not know what is actually the /sbin/${SPLASH}_wrapper doing, but will it fall back to the splash_wrapper() { : } behaviour if it detects that it cannot use any framebuffer device? this is of course a detail and i'm not mentioning it because i use this functions but in general. is there an option on what happens when "/sbin/${SPLASH}_wrapper $@" fails? maybe something like: "/sbin/${SPLASH}_wrapper $@ || echo 'splash failed - status: $@'" (this is a wild guess - no idea if it may work; i'm not familiar with all the code, just had a look at some diffs) by the way: thanx for the branch. more convincing if oyu can browse git and have a look in a unproblematic way :) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
participants (14)
-
Aaron Griffin
-
Andreas Radke
-
Damir Perisa
-
Dan McGee
-
Daniel Isenmann
-
eliott
-
Eric Belanger
-
James Rayner
-
Jan de Groot
-
Jason Chu
-
Roman Kyrylych
-
Thomas Bächler
-
Tobias Powalowski
-
Varun Acharya