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

Re: glibc plans for the lenny cycle

Marc 'HE' Brockschmidt a écrit :
> Heya,

> The release team is currently working on a schedule for the lenny
> release cycle. For that, we want to gather some data from the bigger
> software packaging teams in Debian first.
> We would like to know which major upstream versions of glibc are
> expected to be released in the next 24 months and how much time you
> expect them to need to get stable enough for a Debian stable release.

First of all the team of made no plans yet. However all agree a long
time (since the Etch toolchain freeze), that we will have to work on
glibc 2.5, the current upstream version. This version has stayed a lot
of time in experimental, and is currently being integrated into
unstable, so I (and very probably "we") expect it to be stable enough in
Lenny in the next 6 months (and even less given that the first upload
looks not so bad).

A new upstream version 2.6 is expected a few weeks before the release of
Fedora core 7, so probably in the beginning of may. The next version is
expected about 6 months later for Fedora core 8 and so on.

It's difficult to say now how long it will take to integrate a further
version, without testing it on a few architectures, and without knowing
the list of architectures that will be supported for Lenny.

Also for hppa and glibc 2.6, if we are not able to build it linuxthreads
+ TLS support, we will have to switch to NPTL, and that *may* mean a
libc transition. We are still waiting for more information from the
upstream hppa porters.

Basically I would say that glibc 2.7 looks unrealistic for lenny, glibc
2.6 would be the goal, and glibc 2.5 the backup solution.

> Our current, very rough plans would mean a release in 18 months with some
> padding in both directions, which would lead to a lenny release around 
> October 2008. We expect to shuffle this a bit around to fit everyone's 
> needs, so please tell us if this date works for you.

Basically it looks ok. What about the freeze period for the toolchain? I
think we usually suffer for a too early freeze of the glibc (it has been
frozen in July for Etch, even if it has been unblocked a lot of time
after). In my opinion, it would be better to freeze the upstream version
at that time and allow minor update until the main freeze.


  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Reply to: