Et si Debian Testing devenait constamment utilisable ? Le projet CUT

Suivez-moi aussi sur Identi.ca ou sur Twitter.

CUT pour Constantly Usable Testing. Oui, vous avez bien lu.

L’idée a été proposée par Joey Hess sur son blog, le programmeur de la suite des outils Debhelpers qui facilitent grandement la réalisation de paquets Debian. Le manifeste du projet est disponible ici.

Ce vieux routier de Debian a constaté que les temps ayant changés, le rôle du projet Debian n’était plus de fournir seulement des versions fixées à un moment et évoluant peu par la suite – nous parlons ici des fameuses versions stables – mais que dorénavant le projet avait les moyens de fournir une version en constante évolution, constamment en phase avec les dernières sorties.

Cela pourrait se faire assez simplement, à l’aide d’une équipe chargée de maintenir en permanence différents critères de qualité pour la version aujourd’hui appelée “en test” (testing) :

  • La version en test devrait pouvoir être installée constamment.
  • Les bugs dont la gravité est supérieure ou égale au niveau “sérieux” devront être corrigés rapidement et les logiciels inutilisables devront être rejetés de la version en test.
  • Les failles de sécurité devront être corrigées le plus vite possible ou annoncées afin que les utilisateurs puissent s’en occuper eux-mêmes.
  • Mettre à jour depuis une plus vieille version de testing doit toujours être possible.
  • Des instantanées devront être disponibles de manière régulière, afin que les utilisateurs nécessitant une base solide pour leur déploiement en ait une. Elles seront numérotées et chacune sera une image de la version en test quand elle aura été estimée en bonne condition.

La page du projet est accessible ici.

En un mot, si ce projet qui a remporté une large adhésion du public lorsqu’il a été présenté à DebConf10, le rassemblement annuel des développeurs Debian cette années à New-York, se met en place et atteint ses objectifs, c’est tout simplement le visage de Debian tel qu’on le connaît jusqu’à aujourd’hui qui va se modifier. Quels seront les effets de ce changement sur l’organisation de Debian à long terme, nul ne peut aujourd’hui le prédire alors que CUT n’est pas encore en place. Mais c’est en tout cas une excellente idée qui risque de provoquer un large afflux de personnes intéressées.

29 thoughts on “Et si Debian Testing devenait constamment utilisable ? Le projet CUT

  1. Le terme technique pour decrire une distribution qui evolue tout le temps (sans attendre un point livraison) est ‘rolling release’.

    CUT est sur le modele de Mint Debian. Mais, je pense que si CUT prend bien, il vaut mieux avoir ce genre de chose a la source.

    On peut aussi se referer a ce qu’est arch par rapport a slackware, pour analyser la relation CUT/Debian.

    Je suis assez impatient de voir ce que ca donne.

    G.

    • Carl,

      Quelle est ta définition d’une rolling release ? Est-ce que tu sous entend que la version CUT serait fixe ? et qu’il faudrait changer quelque chose dans le sources.list pour passer à la “snapshot” suivante ?

      Si ce n’est pas le cas, c’est tout à fait similaire à Arch, car la version stable de arch est qualifiée de rolling et Arch possède une version de test (sid chez debian). Peut-etre que tu ne veux pas utiliser le terme rolling testing comme CUT ne sont pas qualifié de stable au sens debian (ie très strict 😉 )

      A terme CUT est-il destiné à remplacer testing ?

      Merci d’avance 🙂

    • FredBezies : pour qu’il n’y ait aucune ambiguïté sur le sujet, le projet CUT (qui s’incarnera précisément par la création d’une nouvelle équipe) est interne à Debian, il ne s’agira pas de créer une nouvelle dérivée de Debian. Il s’agit d’une évolution de la version en test que tous les utilisateurs de Debian connaissent bien.

  2. il ne manque qu’à ajouter des release à dates fixes et on aura un quasi-Ubuntu;)

    je pense que c’est le voeux de bcp d’utilisateurs qui sont déçus des versions des logiciels sous Debian (vivement python 2.7 sous testing…)

    super idée en tous cas

  3. C’est une très bonne idée je trouve.
    Pour ma part, je tourne sur un dérivé de Debian testing (CrunchBang 10) et c’est déjà assez stable.

    Le fait d’avoir des versions d’outils et de logiciels assez récent peut être un bon argument pour tous ceux qui disent “Debian, c’est stable mais il n’y a que des vieilles versions des softs.”

  4. Oh wow ! J’espère que « CUT » ne restera pas juste une idée. « CUT » m’apparaît comme un point majeur pour l’avenir de Debian.

    Je ne voudrais pas paraître centré sur ma personne mais certains logiciels libres évoluent rapidement. Mes besoins, par rapport à mes connaissances et le temps que je peux allouer à l’OS et sa compréhension, requièrent « stable » mais par rapport à mon utilisation pour la photographie, c’est clairement « testing » pour les logiciels plus récents.

    Malgré que Squeeze ne soit pas encore sortie, elle distribue au moins deux logiciels importants pour moi mais dont les versions sont déjà obsolètes (et d’autres suivront peut-être dès cet automne). L’un de ces logiciel me permet d’utiliser un instrument de mesure.

    Au milieu de cette semaine, était annoncée une nouvelle version, attendue, d’un logiciel. Le même jour celui-ci était déjà disponible pour Debian (Bravo et merci Roland Mas) mais malheureusement dans « experimental » en conséquence de l’état actuel du développement de Debian.
    Si je suis « stable », le produit final par Debian, je pourrai l’utiliser dans quoi ? Trois ans ?

    Suivre « testing » et vivre avec ses éventuels problèmes est une solution pour rester avec Debian mais, tout comme les histoires de « apt-pinning », cela est trop complexe.

    Debian se revendique « le système d’exploitation universel ». Ce serait formidable qu’il le soit aussi pour un maximum d’utilisateurs sans qu’il y ait un trop gros compromis à faire sur certaines qualités techniques premières.

    Si « CUT » devait arriver que restera-t’il a certaines autres « distros » ?

  5. Il me semble que c’est une excellente idée !

    Je pense que si le projet abouti ça signifieras que les périodes de gels deviendront plus courtes (on pars d’une base plus stable), mais des durées entre une nouvelle version et le gel plus long (les nouveautés mettraient plus de temps à descendre en testing).
    Je pense que ça influenceras la qualité de la version stable car le travail de correction de bug se ferras au plus tôt.

  6. Je ne comprends pas tout à fait l’intérêt du projet. Depuis 5 ans que j’utilise Debian au quotidien, mon choix s’est toujours porté sur la version sid ou testing pour avoir des logiciels à jour. C’est très très très (j’insiste :p) rarement arrivé qu’il y ait un bug réellement bloquant… Testing est déjà une distribution “stable” à part entière à mes yeux. Je comprends pourquoi un sysadmin voudra profiter de la stable pour son parc et ses serveurs, mais dans l’état actuel des choses, je ne vois pas pourquoi un utilisateur normal ne choisirait pas la testing (mis à part le nom qui peut effrayer).
    J’ai l’impression que testing a déja cette vocation et qu’elle existe pour ça. L’utilisateur qui se plaint de Debian pour les vieilles versions des packages qu’elle contient n’ont jamais du comprendre que le choix ne se résume pas qu’à la debian stable. Pour moi, c’est le choix entre les 3 distrib de debian qui en font sa force.

    Les utilisateurs de arch se vantent de la “récenteté” de leurs packages, alors que debian propose non seulement des paquets presque aussi récents (voir plus récents parfois) dans sa version unstable/experimental, mais propose aussi en plus une version stable d’une stabilité presque inégalée.

    Je ne pense pas que CUT changera la donne, ce n’est qu’un effort en plus fourni pour stabiliser testing, ce qui est déjà un objectif de debian testing en soi il me semble…
    Par contre j’ai peur que la tentative n’aboutisse à un ralentissement de l’évolution des versions dans testing 🙁 Ça serait vraiment une mauvaise chose de mon point de vue, ça ne ferait que diminuer l’évantail des choix offerts par debian.

  7. Mais, en fait, CUT existe déjà, en pratique. Moi, ça fait des années que je suis en testing, bien qu’on me répête souvent que c’est pas bien.

    Les utilisateurs n’ont pas attendu CUT pour le faire 😉

  8. Utilisateur régulier des versions testing de Debian, je pense que cela contribuera à améliorer encore cette version de Debian avec laquelle il m’est quand même arriver de connaître quelques soucis nécessitant de mettre les mains bien dans le cambouis 🙂 .Certes, c’est formateur, mais bon c’est souvent quand on a pas le temps ou plus urgent à faire !
    Avec l’intégration officielle des dépôts backports et cette annonce, je trouve que Debian est en train de prendre une bonne orientation vis à vis des utilisateurs plus novices des systèmes GNU/Linux en leur offrant des logiciels plus “frais” tout en gardant cette préoccupation de la stabilité et de la sécurité.

  9. Je trouve l’idée très bonne. Je suis en Debian stable sur mes machines de bureau et je suis parfois un peu frustré des versions de mes packages malgré l’existence des backports.
    Merci pour cet info !

    • anatolem : je ne suis pas sûr de comprendre en quoi le fait qu’une équipe interne chargée de maintenir Debian testing dans un état qui fasse qu’elle soit toujours utilisable doit “rester un choix personnel pour l’utilisateur”.

  10. Désolé si je déterre cet article mais il y a quelque chose qui me chiffonne à propos de CUT. Bien que le projet soit très intéressant, je le trouve néanmoins dispensable.

    Le principal objectif de CUT est de faire une sorte de rolling release via la version Testing pour qu’elle soit utilisable/installable tout le monde.

    Pour ma part, CUT = Sid car même si ce dernier est la branche unstable de Debian, elle est quand même vraiment stable. En 1 an d’utilisation, je n’ai pas eu de problème. Il suffit d’avoir le paquet magique = apt-listbugs et tout roule.

    Cette branche pourrait être intéressante si les paquets qui proviennent d’experimental passent plus rapidement en unstable. (style Iceweasel/Icedove ou encore VLC)

    • Berillions : Il n’y a que 10 jours entre l’arrivée d’un paquet en Sid et sa migration automatique vers Debian testing. Par contre si le paquet reste bloqué en Sid, c’est qu’il y a une bonne raison. Le paquet peut par exemple ne pas se créer correctement pour certaines architectures un peu exotiques. Le barrage Sid->Testing est donc une étape importante au niveau de l’assurance qualité du projet Debian et les paquets qui arrivent en Testing ont donc déjà franchi une sérieuse étape de stabilité.

      Tout ça pour dire que baser la CUT sur Sid pourrait induire de graves problèmes sur un nombre important de paquets. Et là je ne parle même pas des problèmes importants qui peuvent parfois survenir sur un ensemble de paquets présents dans Sid.

  11. Je me demande si le terme de rolling release n’est pas utilisée un peu trop abusivement.

    Ok, si les paquets arrivés dans Sid en bon état sont migrés sur testing en 10 jours, nous avons en effet un système très à jour. Seulement ce qui n’est pas pris en comte ici, c’est que la testing est freezée périodiquement, pendant un ou deux ans le temps de bien la stabiliser.

    Du coup, lorsque le gel a commencé, ne s’éloigne donc pas de plus en plus de la notion de rolling release que tout le monde semble vouloir adopter?

    • Je me suis trompé, le gel semble ne durer que quelques mois.

      En tout cas le principe de CUT pourrait éviter les rares cas où l’installation de la release hebdomadaire testing serait cassée, ce que apt-listbugs ne serait éviter.

  12. Bonjour le blog !
    Je vais très souvent découvrir vos publications et la je me suis décider à poster un petit message.
    Je juge que les billets sont très bien rédigés et enrichissants, c’est un bonheur de vous relire.
    Continuez comme cela le plus longtemps encore !
    Une bonne année !

  13. Hello à tous,

    excellente initiative qui permettra peut-être à la distribution de se relancer sur le poste de travail, éventuellement sur les serveurs pour des besoins spécifiques (car en général la stabilité prévaut).
    Adepte de Debian depuis longtemps, j’ai toujours regretté que ses instances dirigeantes n’aient pas davantage pris en compte la diffusion sur le poste de travail … pourtant les communautés libres sont actives et les logiciels sont en développement continu !

    Par contre, je n’ai pas compris le warning sous les liens de téléchargement sur le site du projet : pourquoi n’y a-t-il pas d’update de sécurité pour les packages ? Est-ce que CUT ne prend pas en compte la sécurité, ou est-ce un manque temporaire de ressources permettant d’assurer cette fonction ?

    Merci en tout cas … je comprends que la communauté Debian ait particulièrement apprécié l’arrivée de ce projet.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *