On Fri, Sep 17, 2004 at 08:07:32PM -0400, Joey Hess wrote: > We seem to be in relatively good shape for another release at the > moment; as far as I know there's little significant new breakage. We > seem to have a lot of patches piling up in the BTS, and we should > perhaps try to go over those and work out which are worth applying > before a release. We also need to think about scheduling a string freeze > for the next release. > We've been tracking issues at the top of TODO, though most of them lately > have not been problems with d-i, but with the second stage install. I'll > trim it to the d-i issues: > Things we really should fix before rc2: > - finish 2.6.8 and 2.4.27 kernel upgrades, all applicable arches > - fix syslinux parameter bug #269424 > Things that would be nice for rc2, but can't block it: > - pcmcia-cs resource range detection > (untested patch from per) > - vmelilo-installer needs to remove no_bootloader > from /target/etc/kernel-img.conf > - support for root on raid > Since a string freeze takes at least a week, and getting all the images > built and tested for release took two weeks last time, we're still some > time from a rc2 release. The Oldenburg meeting is coming up next week, > and I dislike trying to do releases at such meetings. Still, we've > probably now reached the point where installation reports from rc1 are > less useful, and where we want users to be trying the latest version of > the installer. > So I propose that we do a release that is not a release candidate. We > could call this a test candidate (but users seemed to find that > confusing before), or a technology preview release. Some of the nice new > features would include - > - root on LVM (done) > - preseeding automatic installs (nearly done) > - new kernels (nearly done) > - whatever else has been done that I've forgotten about > - whatever else we do at Oldenburg > This release would not rc1 involve a string freeze and a full set of > updated translations. It might even be broken on some architectures, if > some arches are currently broken. It would simply be a consistent > snapshot of what we have accomplished in the 2 months since rc1. It > would probably still take about a week to get it built and released; the > release building could begin right after Oldenburg for a release near > the beginning of next month. The rc2 release would then probably not > happen until the end of next month. > Alternatively, we could skip this and go ahead with getting rc2 out > immediatly after Oldenburg. That would mean probably a string freeze the > last week of this month, and a rc2 release near the middle of next month. > Which alternative is better, I leave up to you -- and the timetables of > the release managers. I'd like to be able to commit to a release date sooner than the end of next month, but that just doesn't seem feasible at this time. If we make some forward progress on the current blockers, how much pain would it be to drop the test candidate midstream and go straight for RC2? Also, would the test candidate be seen as superseding RC1 on the website, etc? Will this be considered enough of a "release" that we could set about cleaning up the old kernel udebs, etc. currently in testing? -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature