Un noyau en version unstable est beaucoup plus risqué qu'une intégration d'un logiciel non testé dans une distrib
un kernel dit stable qui est instable c'est pas pire qu'un kernel dit unstable qui est instable ?
D'autre part, sur une Debian, la version stable s'avère très bien sur des serveurs, mais pour une utilisation domestique, on aprécis d'avoir des logiciels plus récents
Debian unstable c'est pas fait pour les chiens.
alors que le kernel stable intègre tout ce dont l'immense majorité des utilisateurs ont besoin.
le kernel dit stable doit etre AVANT TOUT stable avant d'intégrer quoique ce soit.
Là on est d'accord, dans un version stable l'intégration de nouveau code ne devrait pas avoir sa place.
En pratique ce n'est pourtant jamais le cas. En conséquence il me semble essentiel d'ouvrir la branche impaire au plutot.
Et je te garantie que s'ils intégraient moins rapidement les nouveautés dans la branche stable, il y aurait plus de gens pour tester la branche instable
exemple tu laisses trainer un peu le support usb en unstable, ou une autre "carotte".
Ca me semble pourtant limpide à comprendre comme résonnement.
Mais là c'est pas moi qui décide de la politique d'intégration
La politique est peut etre de laisser des distributions avoir une longueur d'avance sur certaines feature des kernels officiels, genre ext3 depuis la Red Hat 7.2 .. Je dis ça mais j'ai rien dis, hein.
[^] # Re: Aie...
Posté par Frederic Logier . En réponse à la dépêche Kernel 2.4.15/2.5.0 buggé. Attention !. Évalué à 1.
un kernel dit stable qui est instable c'est pas pire qu'un kernel dit unstable qui est instable ?
D'autre part, sur une Debian, la version stable s'avère très bien sur des serveurs, mais pour une utilisation domestique, on aprécis d'avoir des logiciels plus récents
Debian unstable c'est pas fait pour les chiens.
alors que le kernel stable intègre tout ce dont l'immense majorité des utilisateurs ont besoin.
le kernel dit stable doit etre AVANT TOUT stable avant d'intégrer quoique ce soit.
Là on est d'accord, dans un version stable l'intégration de nouveau code ne devrait pas avoir sa place.
En pratique ce n'est pourtant jamais le cas. En conséquence il me semble essentiel d'ouvrir la branche impaire au plutot.
Et je te garantie que s'ils intégraient moins rapidement les nouveautés dans la branche stable, il y aurait plus de gens pour tester la branche instable
exemple tu laisses trainer un peu le support usb en unstable, ou une autre "carotte".
Ca me semble pourtant limpide à comprendre comme résonnement.
Mais là c'est pas moi qui décide de la politique d'intégration
La politique est peut etre de laisser des distributions avoir une longueur d'avance sur certaines feature des kernels officiels, genre ext3 depuis la Red Hat 7.2 .. Je dis ça mais j'ai rien dis, hein.