On Sun, Aug 16, 2009 at 02:41:36PM +0200, Marc Brockschmidt wrote: > Heya, Hi,
> As announced on dda [RT1], we want to get an impression when releasing > Squeeze is feasible. We have proposed a (quite ambitious) freeze in December > 2009, and some developers have noted that their planned changes wouldn't be > possible in this time frame. So, to find out when releasing would work for > most people, it would be great if you could answer the following questions: > > * Which major upstream releases of eglibc are expected in the next two > years? Which of those are material for Debian stable, which might be a bit > flaky? Upstream glibc is released twice a year, in May and November (that can be late in the month), and eglibc the same day, or a few days after. For squeeze it would be nice to have eglibc 2.11. > * How much time do you usually need from a new upstream release of eglibc > to a stable Debian package in unstable? While getting a new upstream version of eglibc in a good shape for unstable takes usually a few weeks for main architecture, it can take up to one to two months for other architectures, depending on the porters and upstream support in solving issues. Usually non-i386/amd64 architectures comes with regressions in the testsuite... We can probably anticipate that by uploading snapshots to experimental a few weeks before the release, but some manpower is needs for that, which may be already used for other tasks (see below). > * How many "big" transitions will the upcoming changes cause? When should > those > happen? Can we do something to make them easier? > This should not trigger any transition, but it may block package in unstable until the eglibc package is moved to testing, though with symbols support it concerns less packages. This means we should upload eglibc to unstable when it is really ready, and possibly synchronised with the release team so that it does not come in the middle of a big transition. Apart from that we also need some time to - Do the multiarch transition. Work is currently in progress (libc6 and libc6-dev has been splitted already), the remaining big part is to install the glibc in the multiarch paths. This may delay work on other tasks. (This is a release goal) - Switch glibc to use the default compiler, as it usually trigger regressions in the testsuite on some architectures. For squeeze (gcc-4.4 seems to be the default compiler for squeeze), this work has already been done for some architectures, but some regression have been found on at least armel and mips that needs investigation and debugging. (This is a release goal) - Rework the locales* package to avoid either compiling the locales or installing a pre-compiled version of all of them. This will mainly benefit embedded systems. This will require some time, especially to ensure a transition path from the current packages. Cheers, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
