Re: glibc plans for the lenny cycle
Marc 'HE' Brockschmidt a écrit :
> Heya,
Hi
> 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.
Cheers,
Aurelien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: