On 7/9/06, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
[Gustavo Franco] > Since Carlos' work is going well and considering that SELinux support > is still a "pet release goal"[0] and i don't think it will make the > release, we've a chance to push LSB-compliant init-scripts as a > release goal now. I'm not sure what SELinux got to do with this, but will chip in a few comments. It would be nice if all init.d scripts have LSB-compliant headers in time for Etch, but it is not required to handle dependency based reordering of the scripts, thanks to the way insserv handle override files (it include dependency info for the init.d scripts missing those internally). And it is unlikely that we manage to implement an update-rc.d which uses this dependency info in time for Etch, and thus I believe it is better to introduce the dependency info without any hard deadline. When Carlos get lintian to report missing headers, developers will slowly fix the init.d scripts by themselves, and I hope all packages will be fixed in time for etch+1.
In pratical terms, insserv won't be added in none of our tasks, so the user, admin, whatever will need to install it after installing Etch. Better than nothing, but not that better than we've now. The update-rc.d is a issue right, but you answer below why we should at least try this even without a new update-rc.d. I really disagree with your last point. This "slowly" approach is what makes us (almost) totally non release focused. If we've a great work being done and can make our release in 4, 5 months why wait (and add stuff slowly) 22, 23 months (Etch+1) ? If nobody steps in to really focus on release and its details you will be writing the same thing for somebody else in 17, 18 months. Take note.
There are other changes to the boot which will improve the boot times much more than parallelization, and I recommend we focus on those for Etch instead.
The "hotspots". Well, there's the discarded "sh->bash" thing, "depmod" already implemented and what we've more that will improve the boot times much more than parallelization ? Maybe i missed something, but these two cited won't.
This is not to say that we should stop reporting bugs about missing headers, nor that we should not ask the release team on their opinion. After all, adding such headers introduces a very low risk to the packages, and make it a lot easier to detect errors in the boot sequence. And such errors in the boot sequence should be fixed before Etch. :)
That's my point Petter. :)
As for how we are on schedule for releasing Etch, I believe we are on track and will make the release in November/December this year, but there is a lot of hard work left to do, and we should do our best to reduce the amount of remaining work. Adding new release goals is perhaps not the best way to do it, but on the other hand we need to verify the boot order before Etch freezes.
Exactly why i mentioned one release goal: SELinux support, that i think won't make the release so we could ask for a replacement. Closing, i can't do all this by myself so if you (Petter) and Carlos don't want to go this way, i'll move on. regards, -- stratus _______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
