Je jette pas la pierre aux autres devs, remonter un patch, ç'est pas aussi simple qu'on le croit.
Déja, faut que le patch soit utile à remonter. Les patchs de personnalisations ( genre mettre debian dans la banniére ssh ), ça rentre pas dans cette catégorie. Les patchs d'applications d'une policy refusé upstream ( je pense par exemple à perl ), pareil.
Ensuite, faut que le patch soit propre dans sa forme ( un fichier correct et pas un amoncellement de patch dans tout les sens comme le paquet cron ), que la patch soit claire lisible et pas trop porc( genre un gros coup de code commenté ).
Et la, faut ensuite que le dev réponde à son email ( et faut le trouver encore ), ou que le projet posséde un gestionnaire de bug, qui lui même nécessite souvent un login ( un jour, on aura surement un systéme d'authentification distribué, mais c'est pas encore le cas ), et la, tu peut commencer à envisager l'envoyer.
J'ai passer une bonne semaine à corriger des problémes gcc4 sur divers softs c++ libre, au cours d'un stage ( quasiment sur mon temps libre ).
Et pour la remonté des patchs, entre les "ah mais c'est pas sur la version cvs on prends pas", les "envoyez le patch sur la liste de diffusion", et le silence radio,il ne reste plus grand chose. Et encore, je passe sur le fait qu'il mets parfois~ 1 an à être appliqué, ton patch.
Surtout que la moitié des patchs était assez simple, et je pense que j'ai perdu plus de temps à remonter le patch, et l'auteur à le relire et à l'appliquer que de nous laisser bosser tout les deux dans un coin à corriger les erreurs g++.
J'essaye de remonter les patchs, mais je vais pas commencer à harceler les auteurs pour intégrer mon patch, ou pour prendre un bugzilla.
Et c'est vrai, il y a aussi des docs dupliqués de partout, certaines de basses qualités. Sans doute parce que c'est simplement plus facile à faire, il y a pas d'histoire de gloriole ou quoi que ce soit. Pour faire un howto pour le tldp, il faut apprendre docbook, pour faire ce que tu veut sur ton blog/site web, tu fait ce que tu veut comme tu le veut.
Cherche pas plus loin, il y a pas que les electrons qui suivent le chemin de moindre résistance.
[^] # Re: Qu'en pensez-vous ?
Posté par Misc (site web personnel) . En réponse au journal De l'utilité des développements Libres. Évalué à 10.
Entre un document et la pratique, il y a une différence.
On pourrait citer de la même maniére canonical face à debian, et voir que curieusement, même si canonical fait son possible, tout ne remonte pas :
http://kitenet.net/~joey/blog/entry/a_bad_taste_in_the_mouth(...)
Je jette pas la pierre aux autres devs, remonter un patch, ç'est pas aussi simple qu'on le croit.
Déja, faut que le patch soit utile à remonter. Les patchs de personnalisations ( genre mettre debian dans la banniére ssh ), ça rentre pas dans cette catégorie. Les patchs d'applications d'une policy refusé upstream ( je pense par exemple à perl ), pareil.
Ensuite, faut que le patch soit propre dans sa forme ( un fichier correct et pas un amoncellement de patch dans tout les sens comme le paquet cron ), que la patch soit claire lisible et pas trop porc( genre un gros coup de code commenté ).
Et la, faut ensuite que le dev réponde à son email ( et faut le trouver encore ), ou que le projet posséde un gestionnaire de bug, qui lui même nécessite souvent un login ( un jour, on aura surement un systéme d'authentification distribué, mais c'est pas encore le cas ), et la, tu peut commencer à envisager l'envoyer.
J'ai passer une bonne semaine à corriger des problémes gcc4 sur divers softs c++ libre, au cours d'un stage ( quasiment sur mon temps libre ).
Et pour la remonté des patchs, entre les "ah mais c'est pas sur la version cvs on prends pas", les "envoyez le patch sur la liste de diffusion", et le silence radio,il ne reste plus grand chose. Et encore, je passe sur le fait qu'il mets parfois~ 1 an à être appliqué, ton patch.
Surtout que la moitié des patchs était assez simple, et je pense que j'ai perdu plus de temps à remonter le patch, et l'auteur à le relire et à l'appliquer que de nous laisser bosser tout les deux dans un coin à corriger les erreurs g++.
J'essaye de remonter les patchs, mais je vais pas commencer à harceler les auteurs pour intégrer mon patch, ou pour prendre un bugzilla.
Et c'est vrai, il y a aussi des docs dupliqués de partout, certaines de basses qualités. Sans doute parce que c'est simplement plus facile à faire, il y a pas d'histoire de gloriole ou quoi que ce soit. Pour faire un howto pour le tldp, il faut apprendre docbook, pour faire ce que tu veut sur ton blog/site web, tu fait ce que tu veut comme tu le veut.
Cherche pas plus loin, il y a pas que les electrons qui suivent le chemin de moindre résistance.