Hi, * Frans Pop ([EMAIL PROTECTED]) [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". Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
