C'est le prix à payer lorsqu'on développe un projet pour le noyau sans travailler avec le reste de la communauté. Certes peut être qu'ils n'acceptaient pas de bosser sur une base bancale. Alors en ce cas il fallait envoyer des patchs pour virer ces mauvaises bases et les tourner petit à petit vers ce qu'ils voulaient tout en apportant régulièrement l'argumentation qui va avec.
C'est déjà parfois difficile de faire avaler aux mainteneurs un petit jeu de 10 petits patchs qui développe une idée travaillée de manière isolée sans en parler à la communauté. A moins d'avoir de la chance ou beaucoup d'expérience.
En règle générale, soit l'idée est carrément refusée, soit on applique les révisions des rélecteurs de patchs et on renvoie une nouvelle version de son jeu de patch, et on itère comme ça jusqu'à ce que ça plaise à tout le monde. On voit régulièrement passer, sur la mailing list de Linux, des patchs qui en sont à leur 5ème, 10 ème version. Enfin heureusement ce n'est pas toujours comme ça. Au delà de 5 itérations c'est quand même plus rare. Mais ça peut être comme ça au lancement d'un projet pour le kernel et après la suite du développement est souvent plus simple et plus fluide, une fois qu'on a compris comment accorder ses propres désirs avec la direction que veut prendre la communauté, on parvient à balancer des patchs qui sont inclus sans trop de besoin de correction.
Bref, je parlais là d'un petit jeu de 10 petits patchs. Mais leur truc est un pavé.
C'est difficile d'inclure un pavé dans le noyau, l'idéal étant d'inclure chaque fonctionnalité d'un projet petit à petit, en restant toujours très proche de la liste de diffusion. Si un changement nécessite d'un coup un gros patch, il faut toujours parler de son idée avant et voir l'avis des autres, au risque d'être frustré après avoir balancé un patch de plusieurs semaines de boulot sans en en avoir parlé avant.
# Le prix du développement out-of-tree
Posté par fweisbec . En réponse à la dépêche La fin de Grsecurity ?. Évalué à 10.
C'est déjà parfois difficile de faire avaler aux mainteneurs un petit jeu de 10 petits patchs qui développe une idée travaillée de manière isolée sans en parler à la communauté. A moins d'avoir de la chance ou beaucoup d'expérience.
En règle générale, soit l'idée est carrément refusée, soit on applique les révisions des rélecteurs de patchs et on renvoie une nouvelle version de son jeu de patch, et on itère comme ça jusqu'à ce que ça plaise à tout le monde. On voit régulièrement passer, sur la mailing list de Linux, des patchs qui en sont à leur 5ème, 10 ème version. Enfin heureusement ce n'est pas toujours comme ça. Au delà de 5 itérations c'est quand même plus rare. Mais ça peut être comme ça au lancement d'un projet pour le kernel et après la suite du développement est souvent plus simple et plus fluide, une fois qu'on a compris comment accorder ses propres désirs avec la direction que veut prendre la communauté, on parvient à balancer des patchs qui sont inclus sans trop de besoin de correction.
Bref, je parlais là d'un petit jeu de 10 petits patchs. Mais leur truc est un pavé.
C'est difficile d'inclure un pavé dans le noyau, l'idéal étant d'inclure chaque fonctionnalité d'un projet petit à petit, en restant toujours très proche de la liste de diffusion. Si un changement nécessite d'un coup un gros patch, il faut toujours parler de son idée avant et voir l'avis des autres, au risque d'être frustré après avoir balancé un patch de plusieurs semaines de boulot sans en en avoir parlé avant.