Je ne sais pas d’où tu sors ces 10 jours. Mais j’imagine que c’est une moyenne au doigt mouillé.
Pas du tout, ça vient de la Référence du Développeur Debian. Hors période de gel, les paquets envoyés dans unstable y restent un certain temps, qui dépend de la priorité définie par leur mainteneur pour cette mise à jour (10 jours pour un priorité faible, 5 pour une priorité moyenne, 2 pour une priorité élevée).
Ça fait des années que j’utilise Debian et il est évident que ce qui s’apparente le plus à une rolling release c’est unstable. Testing est une sorte de version béta de la prochaine stable (qui remplacera victorieusement son illustre prédécétrice) à destination de ceux qui testent sérieusement.
En ce qui me concerne, ça fait des années que je suis Développeur Debian, et si je suis loin de tout savoir à ce sujet, je suis à peu près au fait du fonctionnement des différentes version (en interne, on parle de distributions, à ne pas confondre avec différentes distributions GNU/Linux...).
Testing est techniquement une distribution à intégration continue différée, hors des périodes de gel. En période de gel, c'est figé en effet.
Unstable est une distribution à intégration continue immédiate, et elle est tout également concernée par le gel, de façon plus subtile : lorsque la testing est gelée, c'est toujours principalement la unstable qui sert recevoir les mises à jour, à ceci près qu'il ne s'agit plus de nouvelles versions mais seulement de corrections de bugs. Par conséquent, on évite d'envoyer de nouvelles versions dans unstable, qui ne seraient en aucun cas acceptées dans testing, et qui bloqueraient les envois de corrections pour des versions antérieures présentes dans testing.
Concrètement, supposons qu'en période de gel, testing contienne autojump 23-2. Arrive autojump version 24, et disons que je l'empaquette pour envoyer un autojump 24-1 dans unstable. On se retrouve alors avec, dans testing, autojump 23-2, et dans unstable, autojump 24-1. Là-dessus, quelqu'un découvre un bug critique sur autojump 23-2, et je prépare un paquet autojump 23-3 corrigeant cela. Problème, je ne peux pas l'envoyer dans unstable, qui contient autojump 24-1 qui est une version supérieure. Ce n'est pas dramatique, je dois alors l'envoyer dans testing-proposed-updates qui est faite pour cela, mais comme c'est un peu agaçant, en pratique on évite ce genre de cas, et, en période de gel, on évite d'envoyer des nouvelles versions dans unstable, préférant utiliser pour cela experimental.
Tout ça pour dire que si unstable est effectivement ce qui s'apparente le plus à une distribution à intégration continue, il ne faut pas non plus s'attendre à ce qu'elle soit toujours mise à jour au même rythme : en période de gel de la testing, son évolution sera également partiellement figée !
[^] # Re: Daubian toasting
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Utilisation de debian testing. Évalué à 6. Dernière modification le 10 juin 2016 à 15:40.
Pas du tout, ça vient de la Référence du Développeur Debian. Hors période de gel, les paquets envoyés dans unstable y restent un certain temps, qui dépend de la priorité définie par leur mainteneur pour cette mise à jour (10 jours pour un priorité faible, 5 pour une priorité moyenne, 2 pour une priorité élevée).
En ce qui me concerne, ça fait des années que je suis Développeur Debian, et si je suis loin de tout savoir à ce sujet, je suis à peu près au fait du fonctionnement des différentes version (en interne, on parle de distributions, à ne pas confondre avec différentes distributions GNU/Linux...).
Testing est techniquement une distribution à intégration continue différée, hors des périodes de gel. En période de gel, c'est figé en effet.
Unstable est une distribution à intégration continue immédiate, et elle est tout également concernée par le gel, de façon plus subtile : lorsque la testing est gelée, c'est toujours principalement la unstable qui sert recevoir les mises à jour, à ceci près qu'il ne s'agit plus de nouvelles versions mais seulement de corrections de bugs. Par conséquent, on évite d'envoyer de nouvelles versions dans unstable, qui ne seraient en aucun cas acceptées dans testing, et qui bloqueraient les envois de corrections pour des versions antérieures présentes dans testing.
Concrètement, supposons qu'en période de gel, testing contienne autojump 23-2. Arrive autojump version 24, et disons que je l'empaquette pour envoyer un autojump 24-1 dans unstable. On se retrouve alors avec, dans testing, autojump 23-2, et dans unstable, autojump 24-1. Là-dessus, quelqu'un découvre un bug critique sur autojump 23-2, et je prépare un paquet autojump 23-3 corrigeant cela. Problème, je ne peux pas l'envoyer dans unstable, qui contient autojump 24-1 qui est une version supérieure. Ce n'est pas dramatique, je dois alors l'envoyer dans testing-proposed-updates qui est faite pour cela, mais comme c'est un peu agaçant, en pratique on évite ce genre de cas, et, en période de gel, on évite d'envoyer des nouvelles versions dans unstable, préférant utiliser pour cela experimental.
Tout ça pour dire que si unstable est effectivement ce qui s'apparente le plus à une distribution à intégration continue, il ne faut pas non plus s'attendre à ce qu'elle soit toujours mise à jour au même rythme : en période de gel de la testing, son évolution sera également partiellement figée !