j'aimerai qu'on m'explique, parce que je comprend pas comment 2 (juste 2) dev vont pouvoir automagiquement régler plus de 300 bugs bloquant pour la release ? j'aimerai bien qu'on m'explique la méthode parce que ça pourrait intéresser beaucoup de monde. Je trouve que Dunc-Tank manque de transparence sur ce point.
Ben disons que le travail des mainteneurs ne change pas beaucoup pendant le passage de testing à stable. Je cite une courte phrase du livre de Raphaël Hertzog (j'espère que je vais pas aller en prison pour ça) : Le Release Manager aura préalablement prononcé une période de freeze (gel), où il devra approuver chaque mise à jour de testing. Le but est d'empêcher toute nouvelle version (et ses nouveaux bogues) et de n'approuver que des mises à jours correctives.
Puis il explique que le release manager est le seul à pouvoir modifier les paquets.
Avec le nombre de paquets dans Debian, ça représente quand même du boulot.
[^] # Re: quand la bureaucratie recontre le libre
Posté par ciol . En réponse à la dépêche Destitution du Debian Project Leader ?. Évalué à 0.
Ben disons que le travail des mainteneurs ne change pas beaucoup pendant le passage de testing à stable. Je cite une courte phrase du livre de Raphaël Hertzog (j'espère que je vais pas aller en prison pour ça) :
Le Release Manager aura préalablement prononcé une période de freeze (gel), où il devra approuver chaque mise à jour de testing. Le but est d'empêcher toute nouvelle version (et ses nouveaux bogues) et de n'approuver que des mises à jours correctives.
Puis il explique que le release manager est le seul à pouvoir modifier les paquets.
Avec le nombre de paquets dans Debian, ça représente quand même du boulot.