> À proprement parler, Alan Cox n'a jamais vraiment prétendu que "'2.6.x' est tellement buggé que bah, il faut que je m'y colle"...
Oui. Mais le 2.6 n'est pas géré comme le 2.4 ou le 2.2.
D'ailleurs il faut voir comme la branche 2.7 "traine" à arriver et le rythme "infernal" des modifs de 2.6 qui ne sont pas toujours très "catholiques" au premier abord pour une branche stable.
> qu'il a toujours fait ça sur les versions 'stables' du kernel.
Oui mais là ce n'est pas la même chose. Les anciens -ac étaient du débug et de l'expérimental. Un peu comme la branche -mm. Quoique la branche -mm soit plus aventureuse (suffit de comparer la taille des patchs...). La branche actuelle est à 98 % du débug uniquement.
Alan faisait toujours de l'avance de phase avec sa branche -ac. Lorsqu'on voit le changelog de l'actuellement branche -ac, la volontée est clairement le débug et vérifier que tout est remonté en upstream (branche Linus).
Alan étant aussi un développeur Red Hat, son travail dépend aussi des besoins de Red Hat. Possible qu'il donne actuellement un coup de main pour RHEL4 et que les prochains -ac soient plus risqués.
[^] # Re: Rectifications...
Posté par itstimetogo . En réponse au journal Branche Linux 2.6 stable. Évalué à 3.
Oui. Mais le 2.6 n'est pas géré comme le 2.4 ou le 2.2.
D'ailleurs il faut voir comme la branche 2.7 "traine" à arriver et le rythme "infernal" des modifs de 2.6 qui ne sont pas toujours très "catholiques" au premier abord pour une branche stable.
> qu'il a toujours fait ça sur les versions 'stables' du kernel.
Oui mais là ce n'est pas la même chose. Les anciens -ac étaient du débug et de l'expérimental. Un peu comme la branche -mm. Quoique la branche -mm soit plus aventureuse (suffit de comparer la taille des patchs...). La branche actuelle est à 98 % du débug uniquement.
Alan faisait toujours de l'avance de phase avec sa branche -ac. Lorsqu'on voit le changelog de l'actuellement branche -ac, la volontée est clairement le débug et vérifier que tout est remonté en upstream (branche Linus).
Alan étant aussi un développeur Red Hat, son travail dépend aussi des besoins de Red Hat. Possible qu'il donne actuellement un coup de main pour RHEL4 et que les prochains -ac soient plus risqués.