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

Re: Méthode de stabilisation des release Debian en question...



Bonjour,

Question est motivée par le constat suivant :
Aujourd'hui, la branche "experimental" joue le rôle de l'"unstable" dans un cas hors freezing et donc une partie des developpeur/mainteneur sont focalisés sur les nouveaux programmes plutôt que sur les versions en cours de stabilisation...

Par ailleurs, la pertinence de conserver des vieux navigateurs internet (le choix du 10.0 alors que le 16.0ESR est sorti !) ou bien de vieilles suites bureautiques est extrêmement critiquable...

D'où ma réflexion sur un coeur "à la débian" stabilisé jusqu'à 0 bug RC et le reste de la distribution en "rolling release" puisque même hors période de freeze ça fonctionne plutôt bien...

A déterminer la limite de ce coeur (outils, noyaux, service, version de LSB...).

Les avantages :
 - Avoir une distribution stable pour les serveurs et la production en général,
 - Avoir une distribution "à jour" pour les usage domestiques (Desktop, mobile...)
- Pourvoir faire de cycles de freeze plus court (moins de paquets à stabiliser), plus cohérents et éventuellement plus rapprochés...

Limites
 - Quid de ce qui est dans le coeur et ce qui ne l'est pas,
- Une distribution à plusieurs vitesse qui nécessite d'avoir en permanence un mélange stable/rolling release et donc plus de travail pour l'équipe securité...

Mes 2cents

Mourad


Le 09/03/2013 11:23, Mourad Jaber a écrit :
Bonjour,

C'est une question qui me taraude depuis quelques temps déjà...
Ne serions-nous pas arrivé à la limite du process de livraison des version stable de Debian ?

Nous allons entamer le 10éme mois de freezing et il reste encore + de 150 bugs Release Critical...

Au rythme actuel de résolution (1.1 bugs par jour), la debian Stable sera livrée dans + de 6 mois !

Ma question est précisement serait-il à votre avis intéressant de découper la distribution en plusieurs projets (core, server, desktop...) qui pourrait avoir des cycle de vie différents ? ou bien de limiter l'évolution de la stable en rentrant en freezing tous les 6 mois / 1 an après la release?

Je pense que cela aurait un impact positif sur les temps de release (par exemple conserver les mêmes règles pour core et server (0 bugs RC) et les assouplir pour les environements graphiques)...

Qu'en pensez-vous ?

++

Mourad



Reply to: