On Fri, Mar 02, 2007, Steve Langasek wrote: > To state it plainly: the blocker for the etch release for the past 2 months > or so has been the kernel. This was known, and it was stated. > > I don't remember seeing anyone from outside the kernel team step forward to > tackle any of the kernel's RC bugs. This is pretty understandable -- we > already have a large kernel team, and the package is not exactly readily > NMUable, so trying to focus the whole project's attention on the kernel > sounds like a classic mythical-man-month recipe for disaster, in addition to > being a pretty huge time investment for any outside developer because of the > kernel package's high learning curve. So what do you think should have been > done differently in terms of release management that would have helped keep > the release target? Has going back to a 2.6.17 kernel been considered? There were probably reasons to accept 2.6.18 only four days before base was frozen, but that seems all the more questionable now that the new release itself didn't seem to fix any bugs, yet introduced new ones (such as #410497). At least now we know the kernel may have to be frozen sooner. -- Sam.
Attachment:
signature.asc
Description: Digital signature