I've gone ahead and started the beta 2 release process. CD images are in place and I will send out the release announcement once the web site has updated. (Some install media won't appear in sarge until tomorrow's dinstall.) I have to say that this release took longer to get done than I'd hoped. We started out strong, the compromise was unavoidable and was handled as well as can be expected, the string freeze went well, the holiday slowdown was worse than I expected, and then it felt to me as if things trailed off at the end instead of us making a big push to finish the release. I'm going to think about this and try to figure out things that went wrong and how to avoid them, and I'd appreciate any insights anyone might have. Anyway with luck we now have a firm release, available in the sarge distribution, for three architectures, which is an important step along the way to sarge releasing with d-i. In a sense we're not done with beta2 yet, since we have between 1 and 2.5 architectures that are still in positions to possibly be added to the beta in a week or two. At the same time, I am eager to open unstable back up to continued development especially with so many improvements already waiting to go in. The conflict here is that if a package is destablised in unstable, and then the beta2 "backport" needs to get a minor fix to that package into sarge to make it work on a pending architecture, I won't be able to get that fix into sarge; it will be blocked by the changes in unstable. So starting after tomorrow's dinstall (just in case something goes wrong), unstable is reopened for uploads of: I. NEW udebs (partman, etc), that are not present in sarge. II. Any changes necessary for mips, alpha, and powerpc subarches, targeted at beta 2. III. udebs that are only for architectures that do not plan to release with beta 2 (such as boot loader installers for unreleased architectures) IV. udebs that are only for architectures that have already released for beta 2 But is still closed to uploads of: X. Developmental changes of udebs that are in beta2. (busybox, build/, base-installer, main-menu, anna, etc, etc) Porters who want to keep working on beta2 will need to use the CD images that don't include unstable udebs for testing, and as they fix problems, tell me what udebs include the fix so I[1] can push them into sarge. This may make things a little bit harder for you, which is why I've added the extra week. We can make another announcement once more ports are ready for beta2. There are many things I'm looking forward to seeing in the next release of d-i. Here is my wishlist: - security fixed, 2.4.23 kernel (with SATA support) This should be relatively easy to roll out, I intend to update linux-kernel-di for i386 soon, adding the 2.4.23 kernel while keeping 2.4.22, and transition over to it. This will go into unstable as it meets requirements I. and III. above. - discover 2 I guess all the hard work has been done. IIRC the plan is to upload it with a different name, so we can test installs using it before swtiching overything away from discover 1. If this does not involve renaming the existing discover udeb, it will meet requirement I., and can be uploaded to unstable soon. - partman Likewise, the plan here is to get it into the installer but with a menu item that makes it non-default (like autopartkit) until we're comfortable with it. Since it meets requirement I., it can go in soon. - grub Fairly early in this cycle we need to swtich to grub as the default boot loader on i386, so we can be confident it works before the next release. It might be nice if a few of grub-installer's worst bugs were fixed first though. - XFS Could happen a number of ways, either as an alternate boot on the CDs, or by XFS finally being added to stock 2.4.25/6, or by d-i getting support for 2.6. I'm sure that Steve will come up with something. - 2.6 kernel For some arches at least, possibly not as the default but available as an alternate boot on the CDs. Blocked by discover 2. - better i18n in the second stage We need to work out something in base-config that works as well as d-i does for all our supported languages. Kensi has some ideas, but they are not firm. - improved languagechooser Possibly with country selection split out, but we need to try it that way and see if we like it enough to add the extra question. Christian can upload the new countrychooser when he's happy with it (I.), but will have to wait to change languagechooser in unstable (X.). - improved image names The floppy and initrd images need to be renamed using clearer names and a deeper tree structure used to hold them on the ftp site. The disruption should be mild, but we will have to coordinate with debian-cd and get docs updated too. - udebs and debs with same namea Some key changes in base-config are being blocked because we cannot add debs of choose-mirror, etc to the archive. At the same time, there is some uglyness in the initrd builds that could be avoided if we could have a udeb named libc6. This seems doable, but will require the assistance of the ftp-master and has the potential to cause unanticipated problems. - switch to subversion It would be good to reorganise the tree, and some things are waiting on that being done. Since this has the potential to disrupt everything else during the transition, we'll have to be very cautious. - better wireless support I think that a wireless-tools udeb just went in, but a frontend to that is needed. - better pcmcia support Something that works more than 40% of the time would be good. - a manual Seems to be making progress, but needs to make more progress. - a graphical boot screen Besides looking polished, one advantage is that this can avoid confronting non-English speakers with a page of English in syslinux. Technically this should be both easy and reasonably safe to do on i386. Artistically, it's a limited medium and I'm not up to it, and I don't know if anyone reading this is. I have been mulling over the idea of a contest of some sort. - three more ports Bringing the total released architectures to 7 or 8. alpha, hppa, mipsel, and sparc seem like contenders. Please add to this list, though goodness knows, it's long enough already. -- see shy jo [1] Or rather, the ftp-master behind the curtain.
Attachment:
signature.asc
Description: Digital signature