Le Mardi 8 Mars 2005 13:26, Matthew Garrett a ÃcritÂ: > Jonathan Walther <[EMAIL PROTECTED]> wrote: > > I committed to working toward a six-month cycle. As DPL, I have no > > desire to act unilaterally. Once a sufficient number of us are > > inspired with the right vision, things will just happen. As DPL, > > my job is to inspire-with-vision. And that is something I am good > > at. > > A 6 month release cycle would not go down well with many users unless > we have a much longer support cycle. How have you ensured that the > security team will be able to support 3 or 4 releases simultaneously?
Instead of full releases, we could imagine a perfect world where non
vital parts (with vital I mean : kernels, compilers, libc, d-i) are not
touched, but big softwares updated (gnome, kde, apache, ...)
IMHO there is two *technical* major problems wrt long release cycle :
* security issues, take KDE e.g. [1], upstream does not support old
branches, since they fix security issues in HEAD and backport it
*only* in the current stable branch. so when current branch is x.y.z
and the one in debian, x.y.* or x.(y-1).*, it can already be painful,
but possible to do the backport ourselves
but when stable version is (x-1).(y-4).* ... let's be honnest ... we
don't do any security updates. we even not know if we are vulnerable
or not. and if we are .. nobody has time to fix it
* developper : upstream rarely support straight upgrade path from a 3
years old release to the new one. And this gives a lot of work to the
developpers. Currently, in the debian-qt-kde team, we have the
problem to upgrade kdm (the kde login manager) from the 2.2 version
to the 3.4 one, and configuration tools now don't manage 2.2 config
files well enough to allow it smoothly. Since kdm has changed a lot,
users would certainly have to configure the new bits anyway, but it's
possible that they actually loose all their current settings ...
Why wouldn't we have some short term releases that are not major
releases with all rethought (from d-i, to the kernel and compiler and
perl version), but with only :
* straight upgrades
* only a few more important changes , decided by the release team, and
only by them. e.g. with next sub-release :
- we will upgrade perl since current one is really too old, or
- we will upgrade apt, since we want gpg sig checks available or
- we will upgrade gnome since it has not been done since 2 releases
...
Our main problem is, after release, everyone is quite free/allowed to
break anything. wich happens since pple have been stuck in their
progress by last release. and then we need 2 years to recover.
In fact, maybe the problem is not with the release cycle ... but with
what a release is.
btw, for the security team, I think it's fair to ask users to upgrade
their distribution. If we don't assume that, then why don't we support
debian 1.0 anymore ???
6 month may be short, but between 6 month and 3 years there is some
place.
[1] I'm member of the debian-qt-kde team, so the example is natural for
me, but the same can be said for quite a lot of big pieces of
software in debian, so please don't flame
--
ÂOÂ Pierre Habouzit
ÂÂO
OOO http://www.madism.org
pgpGkaNj2uQUC.pgp
Description: PGP signature
