Mouais, le noyau n'est pas vraiment à date fixe, c'est plutôt un mix des deux approches.
Le noyau a une période de 2 semaines en début de cycle pour accepter toutes les modifications pertinentes et à priori plutôt testées. Ensuite on entre dans une période de 6 à 8 semaines de stabilisation des changements acceptés au début. Il est plutôt rare qu'un changement accepté en début de cycle soit viré avant la fin. Car il faut une certaine maturité de ce travail pour entrer dans ce processus ce qui évitent d'y ajouter des trucs à moitié finie.
Mais cela n'est possible que parce qu'il y a énormément de développeurs noyau qui maintiennent des branches de développement dédiés (au réseau, à la mémoire, à certains pilotes, etc.) pour faire un premier tri et améliorer le résultat avant de ne proposer à la branche officielle que les travaux déjà validés.
[^] # Re: "mais c'est mon vice de la perfection que je paye."
Posté par Renault (site web personnel) . En réponse à la dépêche Changement de version et améliorations du Micro Music Player (mmp-2.1). Évalué à 3.
Mouais, le noyau n'est pas vraiment à date fixe, c'est plutôt un mix des deux approches.
Le noyau a une période de 2 semaines en début de cycle pour accepter toutes les modifications pertinentes et à priori plutôt testées. Ensuite on entre dans une période de 6 à 8 semaines de stabilisation des changements acceptés au début. Il est plutôt rare qu'un changement accepté en début de cycle soit viré avant la fin. Car il faut une certaine maturité de ce travail pour entrer dans ce processus ce qui évitent d'y ajouter des trucs à moitié finie.
Mais cela n'est possible que parce qu'il y a énormément de développeurs noyau qui maintiennent des branches de développement dédiés (au réseau, à la mémoire, à certains pilotes, etc.) pour faire un premier tri et améliorer le résultat avant de ne proposer à la branche officielle que les travaux déjà validés.