Am Don, den 15.01.2004 schrieb Joey Hess um 04:33: > 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.) > OK, beta2 is out now. So I suppose powermac test are no longer needed.
> 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. Sorry I did not have much spare time to spend on d-i since christmas. Unfortunately this is not going to change soon. I will try to do my best. > > 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) I request you to make an exception for discover as the next upload should have no impact on d-i and fixes quite important bugs in the deb. We might delay the next discover-data upload some day as this is more or less cosmetic and the really important fixes are in the archive. > > - 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. This is already in the archive. But I jus discovered it did not build on the autobuilders due to a problem with the build depends: discover2 depends on kernel-headers-2.4.20-386 | kernel-headers which yields "E: Couldn't find package kernel-headers-2.4.20-386". How can I best solve this? Should I include the relevant kernel headers in the package or build-depend on a kernel-headers package for every arch? If I can't build-depend on a virtual package this is going to cause headaches as these headers change their package name with every new kernel released. > - 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. How is this connected to discover2? Someone simply has to come up with a discover-data list for 2.6. I think we should not put to much energy in 2.6 support as I hope most/all hardware will be supported by 2.4 for some time. So changing to a 2.6 kernel can be done after the installation. > - 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. I'm looking forward to this. > - 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. This would be a good idea. > - better wireless support > I think that a wireless-tools udeb just went in, but a frontend > to that is needed. yes, the wireless-tools udeb is available now. The first step would be to include it on the netboot images. wireless-tools-udeb should probably be priority standard so anna pulls it in by default. Gaudenz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
