[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian Installer] General release plan for RC1

Frans Pop wrote:
=== D-I STRING FREEZE: Thu 12 Okt, 00:00 UTC - Sun 22 Okt, 00:00 UTC ===

Hi folks,

This mail really should have gone out at least two and probably three weeks earlier. Blame goes to the discussions on d-{private,vote,wherever} which resulted in a serious drop in my motivation in recent weeks and in me dragging my heels on preparing the release.
My apologies for letting you all down.

The most important work planned for RC1 has been done and the installer in general works well, although some finishing touches and testing are still planned in the run up to Release Candidate 1 of the installer.

I don't have a hard planned release date yet, but it will probably be first week of November. Detailed planning and updates will be sent to d-boot and d-release lists.
General status and preparations for Etch RC1 can be found on [1].

As it looks now RC1 will be released with kernel 2.6.17, unless 2.6.18 is ready to migrate to testing in time for us to make the switch before the release. If not, we plan to switch to 2.6.18 ASAP after RC1 and release RC2 ASAP after 2.6.18 does migrate to testing.

How can you help?
If you have some time, please help us by testing the installer. We need testing especially for the non-mainstream architectures and new features recently introduced in the installer (e.g. encrypted partitioning).

Especially welcome is also specific testing by e.g. maintainers of packages/functionality used in the installer: RAID/LVM support, PCMCIA, filesystems (JFS, XFS, ...), bootloaders, etc.
Please check if the bits *you* care about are supported well!

Watch out for calls for testing on d-d-a!

The graphical installer now, for the first time, uses udebs built from official GTK library packages (2.8.x), which means we will be able to drop the various unofficial packages we have been using up to Beta 3. Thanks to Dave Beckett, Loïc Minier and Josselin Mouette for helping us get this far!

The GNOME maintainers have decided to stay with 2.14 and GTK 2.8.x for Etch. This means that g-i will also stay with the current 2.8.x libs, so until the release we need to focus on that and leave work on 2.10.x for post-Etch.
There is one RC issue that will need to be resolved before RC1: #390683.

Just today mike emmel fixed the "boom" bug, it should technically possible switching to GTK+ 2.10.x. Moreover, after some debugging from my side yesterday mike possibly found where to look to fix #390683. If mike manages to fix #390683, we should be able to backport the fix into our patch tarball for GTK 2.8.20, unless (i guess) the fix is located in that huge block of code added in july to corrctly implement painters, which our tarball currently does not include because it's dated May 2006. In the latter case, we should perform a from scratch backport of the gtkdfb backend found in current GTK 2.10 CVS to 2.8.20. In the case a clean backport should be overcomplicated (i failed in this some weeks ago), would this be a valid reason to switch to a clean GTK 2.10.x set of libs for the d-i only?



Reply to: