Passer Testing comme une distro rolling-release, l'idée n'est pas nouvelle avec le programme:
C'est l'idée de la Constantly Usable Testing (Debian CUT).
Mais quand on va sur la page, c'est désespérant tellement on a l'impression que ça ne change rien au schmilblick:
Le dernier snapshot est d'août 2012, et en gras en haut de la page, on peut lire:
"Paused until Debian Wheezy is released."
Citons l'exemple d'une appli qui, si elle n'est pas une appli phare, n'en est pas moins plutôt populaire: le navigateur rekonq.
Testing 0.9.2-1
Experimental 1.1-1
Liste des versions amont depuis la 1.1:
Version Date de sortie
1.1 08/2012
2.0alpha 11/2012
2.0stable 12/2012
2.1 01/2013
2.2 02/2013
Et on ne peut pas blâmer les mainteneurs: ils ont les 2 mains prises dans Wheezy.
Questions:
-Pourquoi les outils pour créer les paquets ne seraient pas assez simples et puissants pour que l'amont puisse créer un paquet "vanilla" sans difficulté? Au lieu de créer le paquet, les mainteneurs ajusteraient une fois un fichier de config qui dit quelles modifs sont à faire. Pas les patches sur le code, mais des trucs cons genre emplacement des fichiers, suffixes du nom de paquet, etc.
Comme ça, à chaque nouvelle version qui n'apporte pas une révolution, les développeurs n'auraient qu'un bouton à presser pour mettre à jour un dépôt experimental à eux.
-Je n'ai aucun doute sur l'excellence du niveau du contrôle qualité de Debian, mais pourquoi est-ce qu'il doit prendre autant de temps?
À un moment, il va falloir accepter de tailler dans le lard: un paquet trop long à être corrigé doit se faire jeter, point barre. Si ça choque des utilisateurs, ils peuvent rémunérer des développeurs Debian pour y consacrer leur temps.
Debian sort quand elle est prête: surtout ne pas changer ce crédo. Mais: ne pas l'appliquer aux correctifs de paquets!
Existe-t-il une date limite aux corrections de bugs critiques spécifique en période de gel? Si non, il faut l'instaurer. Après quoi, si le délai est dû à un manque d'attention, le paquet est déclaré orphelin. En période de gel, le délai devrait être 1 semaine sans activité significative, voire moins! L'équipe en charge de la version se charge de traquer les retardataires et de prendre les décisions difficiles (ex:retirer un paquet à son développeur jusqu'à la sortie de la stable).
Pour parer aux problème que cela inclue, il faudrait peut-être une nouvelle catégorie de paquets en plus de main, contrib, non-free, pour tous ces paquets qui sont arrivés trop tard mais qui "auraient pu le faire", un "noQAcert", qui devra être aussi stable que les stables et pour lequel une fenêtre de quelques mois sera ouverte après la sortie officielle d'une version.
Voilà! C'étaient mes 2 balles en tant qu'utilisateur.
[^] # Re: Demandez le programme !
Posté par Maclag . En réponse au journal Nouveau Debian Project Leader. Évalué à 5.
Passer Testing comme une distro rolling-release, l'idée n'est pas nouvelle avec le programme:
C'est l'idée de la Constantly Usable Testing (Debian CUT).
Mais quand on va sur la page, c'est désespérant tellement on a l'impression que ça ne change rien au schmilblick:
Le dernier snapshot est d'août 2012, et en gras en haut de la page, on peut lire:
"Paused until Debian Wheezy is released."
Citons l'exemple d'une appli qui, si elle n'est pas une appli phare, n'en est pas moins plutôt populaire: le navigateur rekonq.
Testing 0.9.2-1
Experimental 1.1-1
Liste des versions amont depuis la 1.1:
Version Date de sortie
1.1 08/2012
2.0alpha 11/2012
2.0stable 12/2012
2.1 01/2013
2.2 02/2013
Et on ne peut pas blâmer les mainteneurs: ils ont les 2 mains prises dans Wheezy.
Questions:
-Pourquoi les outils pour créer les paquets ne seraient pas assez simples et puissants pour que l'amont puisse créer un paquet "vanilla" sans difficulté? Au lieu de créer le paquet, les mainteneurs ajusteraient une fois un fichier de config qui dit quelles modifs sont à faire. Pas les patches sur le code, mais des trucs cons genre emplacement des fichiers, suffixes du nom de paquet, etc.
Comme ça, à chaque nouvelle version qui n'apporte pas une révolution, les développeurs n'auraient qu'un bouton à presser pour mettre à jour un dépôt experimental à eux.
-Je n'ai aucun doute sur l'excellence du niveau du contrôle qualité de Debian, mais pourquoi est-ce qu'il doit prendre autant de temps?
À un moment, il va falloir accepter de tailler dans le lard: un paquet trop long à être corrigé doit se faire jeter, point barre. Si ça choque des utilisateurs, ils peuvent rémunérer des développeurs Debian pour y consacrer leur temps.
Debian sort quand elle est prête: surtout ne pas changer ce crédo. Mais: ne pas l'appliquer aux correctifs de paquets!
Existe-t-il une date limite aux corrections de bugs critiques spécifique en période de gel? Si non, il faut l'instaurer. Après quoi, si le délai est dû à un manque d'attention, le paquet est déclaré orphelin. En période de gel, le délai devrait être 1 semaine sans activité significative, voire moins! L'équipe en charge de la version se charge de traquer les retardataires et de prendre les décisions difficiles (ex:retirer un paquet à son développeur jusqu'à la sortie de la stable).
Pour parer aux problème que cela inclue, il faudrait peut-être une nouvelle catégorie de paquets en plus de main, contrib, non-free, pour tous ces paquets qui sont arrivés trop tard mais qui "auraient pu le faire", un "noQAcert", qui devra être aussi stable que les stables et pour lequel une fenêtre de quelques mois sera ouverte après la sortie officielle d'une version.
Voilà! C'étaient mes 2 balles en tant qu'utilisateur.