[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: which kernel version for etch


* Frans Pop (elendil@planet.nl) [060724 00:34]:
> On Sunday 16 July 2006 17:48, Andreas Barth wrote:
> > Actually, I think it's way more important that we make sure we have
> > infrastructure ready on each and every day to update the kernel, than
> > to try to delay this point in time for a few hours or days. Because we
> > will need that not only before release, but also after release, and if
> > I look at the amount of kernel root exploits, we will need it quite
> > fast.
> Agreed, but mostly we do. The infrastructure for point releases needs to 
> be improved though.

Point releases are one part of the game, more updates via
testing-proposed-updates (or proposed-updates after release) and
security updates via security.debian.org another. I think we need to
think from what point in time on we need that, and speak with the
security team.

> What happened during the Sarge release was that we were aiming all the 
> time to release ASAP. If you do that, you cannot really relax your freeze 
> selectively.

Well, we're definitly not aiming to release all the time. :)

That's one of the reasons why we wrote December - to be able to plan
with it now, and have enough time for changes/adjustments/.... The only
other reasons I have for holding back changes to the the kernel (except
"do not break it", of course) is the installer. Other than that, I don't
mind (as long as we are sure enough that there aren't any regressions,
of course).

At the current state, I think any expectation is just a guess, based on
some experiences in the past.

> Maybe the release team should instead say: "OK, we are not going to make 
> the current planned date and looking at the issues it will take at least 
> 3 weeks to fix if all goes well; so let's postpone the release by 2+ 
> months which will allow us switch to a newer kernel".
> This needs thorough discussion though.

Well, I think we should discuss that when we are there. I personally
don't mind to release etch with an kernel that already had an security
update on security.debian.org, as I know that we will have an
security-bug-fixed kernel there anyways for the full etch lifecycle,
minus a few days maybe. Other people might have a different opinion on
that, though. But we really should decide soon "which point in time is
the last one to stop release of etch for "normal" security issues".


Reply to: