The next release of d-i should not be a beta. It should be something that we feel is suitable to be used in a real Debian release. This means that we can't afford to put out a release with significant known bugs of the kind documented in the errata, if fixes are known for the bugs. In trying to construct a timeline for such a release, things are complicated by DebConf4. While our target date for this release is the end of the month, and it would be great to be able to put out the release during DebConf, this is not the most important thing we'll do at DebConf. The most important thing will be getting together, sharing problems, visions, and goals, doing longer-term planning, buying drinks, getting other DD's hooked on d-i development[1], working on some of our hard problems, etc. We have shown that we can put out beta-quality releases without a DebConf, so it's important to use DebConf not only for making a better release, but for doing the things that come so much more easily in person and have larger effects in d-i later on. This timeline tries to balance these needs. The basic plan is to continue the process of getting fixed udebs into testing using the criteria I mentioned previously, and soon after the beginning of DebConf4 produce a test candidate build. Then we begin a period of intense and wide-ranging testing of this build. We can take advantage of some d-i developers being at a conference with lab rats^W^Wwilling volenteers to do some real-life usability testing, while filling out the remainder of the arches that need testing with d-i folk who did not make the conference, and with some minor advertising for testing. After several days of testing, we will have the information to decide whether this test candidate is good enough to release. If not, we can add appropriate fixes to testing, and repeat the cycle in a week. 20 may sarge_d-i cds become the default for testing branch for rc1 string freeze begins 21-24 may testing and fixes, udeb propagation to testing 25 may string freeze ends translated udebs uploaded to archive 26 may debconf4 begins translated udebs (with no code changes) put in testing initrd builds begin 27 may initrd builds finish, CD builds done, test candidate available begin testing 28 may testing continues.. 29 may testing continues.. 30 go/no-go day - is it good enough to release? 31 release day if go, else add fixes to testing and repeat 02 june end of debconf4 Note that the 21-24 may time period is more important than it appears. This is where we build our release and make possibly the last code changes, and we should expect to come out of it with something very close to release quality. It will be important to get quite a lot of testing done in that time period. When we're checking out the test candidate, it's essential that we cover all arches and as many installation methods as we can. An important question is whether too many of our key testers -- folk like Bdale and Jeff Bailey -- will be at the conference and so away from their arch farms at home. Also we need to know what hardware will be at the conference -- i386 will no no problem, but what other arches will be covered there? I want to have people lined up ahead of time for each architecture who will be available to do some testing during both time periods. So please make a commitment now if you can. (I myself can promise that I will test i386 installs from: usb key (on real hardware) and on CD, floppy + network, and floppy + cd (vmware). Also 32 mb installs from floppy and from CD. Oh, and 2.6 installs from usb key and from CD. I will be unable to test netboot at least during the 21-24 may period, and also won't be able to check wireless stuff, or obscure i386 hardware. With a total of 7 installs in vmware, it will take me approximatly 2 days to do this testing.) -- see shy jo [1] Hey, it happened to me at the last DebConf..
Attachment:
signature.asc
Description: Digital signature