[arch-dev-public] [PATCH] initscripts: Add a splash support

[Dan McGee]

On Nov 4, 2007 11:57 AM, Damir Perisa <damir.perisa at 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