Steve Langasek wrote: > 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?
Hmm, it's probably possible to not let the test candidate block rc2's
scheduling. This would probably involve starting a string freeze right
after Oldenburg, and beginning preparation of the test candidate at the
same time. Which kinda works because we won't want to be changing lots
of strings right in the middle of preparing the test candidate anyway.
Then the test candidate is releaed near the beginning of October, we
have a week of user testing and feedback (still in the string freeze),
and rc2 preparation begins.
This does give us only a week to get user feedback on the test candidate
and do bug fixes, and it preculdes fixing many strings based on user
feedback. And it may delay rc2 by a week, since otherwise we could begin
rc2 prep right after the 1 week string freeze. On the other hand, our
translators may appreciate a longer string freeze for this final release
for sarge.
> 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?
We could go either way. I'm not especially worried about preserving the
usability of rc1 at this point, since it's highly unlikly we'll actually
release with it. So we could do a full udeb sync at this point, which
would aid testing of the test candidate. Or we could only provide CD and
usb images and no netboot or floppy images and not touch the udebs in
testing.
I'm also unsure of whether we would build the images for a test
candidate on the autobuilders, or use our daily builds for it. The
autobuilders do not prioritise d-i builds highly, and until that's
fixed[1] or unless the autobuilders are much less loaded than last time,
it could take 2+ weeks to do a build there -- which is part of the
reason I'm projecting so uch tie to get rc2 released.
--
see shy jo
[1] Technically the problem is that the autobuilders consider the
debian-installer package to be of extra priority, and so permanatly at
the bottom of the build queue, even though it also builds the very
standard priority initrds used by the installer.
signature.asc
Description: Digital signature
