LSB-compliant init-scripts as release goal.

[Gustavo Franco]

On 7/9/06, Petter Reinholdtsen <pere at hungry.com> 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