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

Re: Questions for candidate Walther



Le Mardi 8 Mars 2005 13:26, Matthew Garrett a écrit :
> Jonathan Walther <krooger@debian.org> 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

Attachment: pgpcyeOZiuWDI.pgp
Description: PGP signature


Reply to: