C'est vrai, mais quand je commence a contribuer a un soft, généralement, c'est parce qu'il y a un aspect qui me gêne, le plus souvent, des dysfonctionnements ou des problèmes de performance.
Contribuer du code, dans ce type de cas (surtout les perfs), c'est passer plusieurs heures à comprendre d'où viens le problème, qui sera variable selon le hardware, puis trouver sa racine, patcher, adapter son patch au style de codage, puis passer par ce que je considère être une pure galère: faut faire un fork, puis pull, puis push, puis faire une push request, attendre la réponse pendant N jours... et même si le patch en question touche juste une fonction de 20 lignes, on te diras de l'éditer toi-même jusqu'a ce qu'il colle a des trucs listés nulle part.
Je vais être franc: je trouve ce modèle bien trop bureaucrate, il nécessite bien trop de ressources matérielles (lancer un brouteur web, c'est mini 2Gio de RAM et un ponçage de disque dur gratos pendant 20s mini sur disque mécanique), et nécessite un polling humain.
En face de ça, il existe un modèle ancestral, certes, moins sexy, certes, basé sur: j'ai un truc qui me soule sur un soft, je me fais un patch perso, je j'envoie a la mailing list du projet, qui disent soit "oui", soit "non", soit "oui mais on va patcher ton patch", éventuellement avec des discussions qui ne nécessiterons pas l'usage de ces usines à segfaults et fuites d'infos que sont les navigateurs webs, chacun pouvant utiliser le client mail qu'il préfère.
Je vais être honnête: maintenant, je fais presque la même avec github: quand j'ai un patch, j'ouvre un bug/feature req/whatever, je cale le patch en P.J. par contre je cherche pas a suivre la discussion. Si j'ai un mail, je vais suivre, sinon, bah... pfou, trop d'efforts, au pire j'ai le patch chez moi, et ça me coûte moins cher de le maintenir que de parvenir a un accord avec l'upstream!.
Je suppose que je devrais pas le dire, par contre. C'est vrai, ça se fait pas, de vouloir simplement contribuer ponctuellement aux logiciels que l'on utilise.
Je ne suis pas comme Jehan (bien moins bon, probablement), j'utilise surtout de petits softs pas gourmands, triés sur le repo apt, dont j'ai tendance a inspecter au moins vite fait le code, et dont dans le cas des jeux, je ne jouerais qu'un temps.
J'ai émis des patchs pour divers softs, cgdb, solvespace, divers jeux... et mon constat global est que quand ça commence a devenir "gros", y'a plus de bureaucratie que de technique, même en collant en pièce jointe des pdf de google-perftools avant et après.
J'ai déjà horreur de la bureaucratie IRL, c'est pas pour m'en coller dans des contributions ponctuelles. Cela dis, les projets sur lesquels on m'a pas trop fait chier, je garde un oeil sur leur source, les autres pas vraiment.
Bref, en l'occurrence, l'humain, ben... franchement, il est cool quand il est seul, en groupe, c'est une saleté.
[^] # Re: Et l'humain ?
Posté par freem . En réponse au journal Faciliter les contributions au code. Évalué à 9.
C'est vrai, mais quand je commence a contribuer a un soft, généralement, c'est parce qu'il y a un aspect qui me gêne, le plus souvent, des dysfonctionnements ou des problèmes de performance.
Contribuer du code, dans ce type de cas (surtout les perfs), c'est passer plusieurs heures à comprendre d'où viens le problème, qui sera variable selon le hardware, puis trouver sa racine, patcher, adapter son patch au style de codage, puis passer par ce que je considère être une pure galère: faut faire un fork, puis pull, puis push, puis faire une push request, attendre la réponse pendant N jours... et même si le patch en question touche juste une fonction de 20 lignes, on te diras de l'éditer toi-même jusqu'a ce qu'il colle a des trucs listés nulle part.
Je vais être franc: je trouve ce modèle bien trop bureaucrate, il nécessite bien trop de ressources matérielles (lancer un brouteur web, c'est mini 2Gio de RAM et un ponçage de disque dur gratos pendant 20s mini sur disque mécanique), et nécessite un polling humain.
En face de ça, il existe un modèle ancestral, certes, moins sexy, certes, basé sur: j'ai un truc qui me soule sur un soft, je me fais un patch perso, je j'envoie a la mailing list du projet, qui disent soit "oui", soit "non", soit "oui mais on va patcher ton patch", éventuellement avec des discussions qui ne nécessiterons pas l'usage de ces usines à segfaults et fuites d'infos que sont les navigateurs webs, chacun pouvant utiliser le client mail qu'il préfère.
Je vais être honnête: maintenant, je fais presque la même avec github: quand j'ai un patch, j'ouvre un bug/feature req/whatever, je cale le patch en P.J. par contre je cherche pas a suivre la discussion. Si j'ai un mail, je vais suivre, sinon, bah... pfou, trop d'efforts, au pire j'ai le patch chez moi, et ça me coûte moins cher de le maintenir que de parvenir a un accord avec l'upstream!.
Je suppose que je devrais pas le dire, par contre. C'est vrai, ça se fait pas, de vouloir simplement contribuer ponctuellement aux logiciels que l'on utilise.
Je ne suis pas comme Jehan (bien moins bon, probablement), j'utilise surtout de petits softs pas gourmands, triés sur le repo apt, dont j'ai tendance a inspecter au moins vite fait le code, et dont dans le cas des jeux, je ne jouerais qu'un temps.
J'ai émis des patchs pour divers softs, cgdb, solvespace, divers jeux... et mon constat global est que quand ça commence a devenir "gros", y'a plus de bureaucratie que de technique, même en collant en pièce jointe des pdf de google-perftools avant et après.
J'ai déjà horreur de la bureaucratie IRL, c'est pas pour m'en coller dans des contributions ponctuelles. Cela dis, les projets sur lesquels on m'a pas trop fait chier, je garde un oeil sur leur source, les autres pas vraiment.
Bref, en l'occurrence, l'humain, ben... franchement, il est cool quand il est seul, en groupe, c'est une saleté.
A vos moins, prêts?