Cher journal,
Ces derniers jours, je me suis dit qu'il fallait vraiment que je me mette à me faire un budget annuel pour connaître ce que je peux dépenser sans avoir peur de me mettre dans de mauvais draps.
Je me souvenais d'un logiciel sympa pour suivre les dépenses qui s'appelle HomeBank.
Je commence à regarder les fonctionnalités à propos du budget et je me rends compte qu'on peut le saisir, mais qu'on ne peut pas avoir de vision annuelle. Pourtant c'est bien ce que j'attendais d'un outil qui me propose de saisir un budget vu que c'est le principe même d'un budget.
Bref, je vais donc voir l'état du projet et je tombe sur son site de développement sur la forge Launchpad de Canonical.
Je ne suis pas trop fan de cette forge, mais j'avais eu l'occasion de la côtoyer par le passé (de ce que l'historique de Launchpad me dit, c'était pour proposer des petites corrections de Movim il y a quelques années, je l'avais complètement oublié ).
Je savais donc comment voir l'état du projet, lire les bugs et récupérer le code avec Bazaar Explorer.
Je vois un rapport de bug qui fait exactement le même constat que moi à propos des budgets et qui propose même une capture d'écran d'un autre logiciel de compta pour montrer un écran qui serait utile. Ce n'est rien de bien compliqué en terme d'interface: un tableau de toutes les entrées du budget avec le détail pour chaque mois. La dernière colonne est la somme annuel pour chaque entrée du budget et la dernière ligne contient la somme pour chacun des mois.
Je me dis que, bon, HomeBank ça doit être sûrement du Python (oui, Launchpad est assez mal fait par rapport à GitLab, on ne voit pas le code facilement, je ne sais jamais où est le bon lien…) et que j'avais déjà eu l'occasion de faire un peu de GTK pour mon OpenMoko à l'époque. Du coup, cet écran ne devrait pas être trop dur, je télécharge donc le code depuis Launchpad.
J'ouvre le projet avec Gnome Builder: le bon côté c'est que le projet utilise les auto-tools standards, le mauvais côté est que ce n'est pas du tout du Python, mais du C.
Je ne me décourage pas: j'ai appris aux études à faire du C et je sais déjà comment marche dans les grandes lignes Gtk.
Là je comprends toute la douleur de ne pas avoir de gestion de Programmation Orientée Objet native dans le langage: des noms de fonction à rallonge qui prennent énormément d'arguments, juste parce qu'il faut toujours repasser l'objet que l'on souhaite modifier et ce avec le bon type et donc il faut référencer correctement le pointeur. Heureusement, Gtk est très bien pensé et propose déjà des macros qui aident beaucoup pour s'en sortir avec ce manque de C.
Je ne m'étais jamais rendu compte à quel point la POO est pratique pour le développeur: avec une ligne de POO typique, on donne le nom de l'objet à modifier (sans avoir à le triturer avec des Macros), la méthode que l'on souhaite exécuter sur cet objet (sans nom à rallonge, puisque l'héritage permet de retrouver facilement la bonne méthode) et on ne donne en paramètre de la méthode que ce qui est utilisé pour appliquer la méthode. Clairement, la POO permet donc de se concentrer sur la fonctionnalité métier souhaitée et je trouve ça un vrai plus: il y a beaucoup moins de distractions dans l'algorithme implémenté (et aussi moins de risques d'erreurs puisque le code est plus concis).
Bref, cette ligne que j'ai codé en C:
GtkWidget *view;
view = gtk_tree_view_new();
gtk_tree_view_append_column(GTK_TREE_VIEW(view), col);Ce traduirait en C++, à peu près comme ça:
Gtk::TreeView view;
view.append_column(col);Enfin bon, après quelques jours de compréhension du code de Homebank et de prototypage, j'arrive à développer la fonctionnalité désirée:
Maintenant que le challenge que je m'étais imposé est passé et en attendant la réponse d'un développeur sur Launchpad, je feuillette le site du projet HomeBank.
C'est à ce moment là que, au dernier paragraphe de la page Dévelopement, suite à tous les traditionnels paragraphes "Comment tester", "Comment rapporter un bug", "Traductions", je me rend compte qu'il y a un paragraphe "Source code repository" et qui dit ceci (la traduction est de moi):
I don't need help for coding purpose. You may submit patch (or branch, but I rarely uses it) for bugfix thus if you have skills to, but avoid launching yourself arbitrary alone in an enhancement (wish bug), if you do really want, contact me first.
One of the reason is that the code trunk available in launchpad is always related to the current stable release. The real development trunk is never public until RC stage, so you can't contribute to it. I do prefer working that way for freedom of breaking thing and refactor simply.
Je n'ai pas besoin d'aide pour développer le code. Vous pourriez envoyer des patch (ou des branches, mais je les utilise rarment) pour des correctifs si vous en êtes capables, mais évitez de vous lancer seul de manière arbitraire dans une nouvelle fonctionnalité, si vous le voulez vraiment, contactez moi d'abord.
Une des raisons est que de code disponible dans launchpad est toujours liée à l'actuel version stable réalisée. Le vrai code de développement n'est jamais publique jusqu'à l'étape de release RC, ainsi vous ne pouvez pas contribuer. Je préfère travailler de cette manière pour la liberté de casser les choses et de refactoriser simplement.
Et là je me dis que, wow, Bazaar est tellement mal prévu que le développeur de l'application n'est pas capable de collaborer avec cet outil. Et je comprends enfin pourquoi dans les commits de Bazaar, je ne vois que des messages du style "Release 5.x".
Bon, je me dis qu'il faut que je lui écrive un petit message pour m'excuser, car j'ai fait exactement ce qu'il a dit de ne pas faire. Tout en essayant de lui faire passer un message du style "si bazaar ne sait pas gérer des branches de travail personnels facilement, il faudrait vraiment étudier la possibilité de migrer sur une forge Gitlab (soit gitlab.com, soit gitlab.gnome.org).".
Mais, je lis une seconde fois le message du site et je vois que c'est écrit que ce n'est que "un des arguments" et que les autres sont donc complètement éludés… C'est là que je me dis, "Mince ! Le projet HomeBank est un super boulot, mais le développeur principal ne souhaite pas avoir de contributions et préfère développer seul dans son coin.".
Maintenant, j'ai un cruel dilemme pour ce weekend:
- Attendre de voir ce que le développeur va répondre sur le rapport de bug, mais je n'y crois pas trop, vu que le site du projet est assez claire (ma maigre chance est qu'il vient de faire une release du projet et que donc sa branche de développement privée ne doit pas être si éloignée du code source stable)
- Dois-je écrire et ennuyer le développeur de HomeBank, malgré le message sur son site ?
- Ou, puisque le site est assez claire, je devrais forker le projet pour que je puisse utiliser Git avec confort, éventuellement passer à un système de compilation plus moderne comme
mesonet pourquoi pas faire inclure le projet dans le projet GNOME directement pour qu'il bénéficie directement de sa structure communautaire et d'infrastructures solides ?
Je sais pertinemment que la dernière solution est assez indélicate et que ce sera pris comme un "fork agressif", mais d'un autre côté, le projet original n'est pas communautaire et ne souhaite clairement pas l'être.
Enfin, je sais que l'ambiance de LinuxFR est assez chaude, surtout sur le sujet des forks agressifs, mais j'aurai quand même bien voulu avoir votre avis sur cette situation… Finalement, peut être que je devrais juste attendre, mais ça fait du bien d’extérioriser :D
# Patience
Posté par Ririsoft . Évalué à 10.
Je te recommande un peu de patience et surtout d'avancer dans ton coin.
Prend le code en main, développe les fonctionnalités qui te manquent. Quand tu es content de ton travail et que ça marche bien fait une autre pull request au développer. S'il n'en veut pas laisse tomber et continue à avancer dans ton coin. Refais un point avec toi même et le développeur dans 6 mois et prend ta décision de forker à ce moment là.
# Oui : contactez-moi d'abord
Posté par Guillaume Savaton (site web personnel) . Évalué à 10.
Je me sens assez en phase avec ce conseil. Je suis le principal (et quasiment unique) développeur de l'éditeur de présentation Sozi et je reçois de temps en temps des pull requests qui ajoutent de nouvelles fonctionnalités.
C'est très gratifiant de savoir que des gens utilisent mon logiciel et souhaitent y contribuer. Habituellement, j'accepte sans problème que l'on m'envoie des corrections de bugs sans prévenir. Je suis plus embarrassé lorsqu'il s'agit d'ajouter ou de modifier une fonctionnalité.
Je comprends qu'un utilisateur puisse faire des modifications pour son propre usage (les licences libres servent à ça). Mais s'il souhaite vraiment collaborer au projet, alors je préfère qu'on en discute ensemble avant qu'il se mette à coder. En ce moment, par exemple, j'ai trois contributions pour Sozi que je ne souhaite pas intégrer : une parce qu'elle n'est pas complète, une qui s'apparente à un bricolage et qui mériterait d'être réécrite, et une autre parce qu'elle me semble incohérente avec la philosophie du projet.
L'autre problème que je rencontre parfois, c'est qu'une fois la nouvelle fonctionnalité ajoutée, les contributeurs disparaissent et on se retrouve tout seul pour maintenir leur code.
[^] # Re: Oui : contactez-moi d'abord
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 15 septembre 2018 à 14:12.
Je comprends bien que ça vous intéresse de discuter sur la solution à prendre.
Je ne veux absolument pas imposer ma solution, je suis tout à fait ouvert à la critique (comme dans le commentaire ci-dessous qui dit que ça ne tient pas sur mobile), mais je ne voulais pas attendre 15 jours avant de commencer à coder.
J'exagère un peu, mais ma motivation et mon temps était disponible au moment où je me suis intéressé au projet.
Je ne suis pas un jeune étudiant comme le laisse penser ZeroHeure ci-dessous: je suis père de famille, j'ai un travaille à assurer à 42h par semaines (eh non, je ne suis pas français ;)) et j'ai vraiment rarement du temps.
Avec un conseil comme "Contactez-moi d'abord", ça me laisse passer le message: "tu dois attendre que je te donne un feu vert et si moi je n'ai pas de temps maintenant pour en parler, ben, tu attendras mon retour de rush du boulot ou de vacances".
Dans la notion de collaborer, il faut que les 2 parties fassent un pas vers l'autre. C'est justement toute la force des forges comme Gitlab: elles permettent de discuter facilement des nouvelles fonctionnalités, d'en proposer 15 versions dans 15 branches différentes si nécessaire et de choisir à la fin la plus pertinente.
Avec cette vision, je comprends tout à fait pourquoi des contributeurs ont donné un patch / une nouvelle fonctionnalité puis sont partis: cette attitude ne me semble pas accueillante et même rebute à continuer à aider, car il y a un énorme goulot d'étranglement: une seule personne est capable de fusionner le code et ce sera toujours selon son temps disponible.
La solution pour détruire ce goulot d'étranglement est de faire du développement en communauté pour répartir les tâches: avoir plusieurs personnes pour trier les bugs, pour faire la revue de code et pour donner des idées quant à la direction à prendre. C'est un peu comme la parallélisation de nos CPUs: c'est un peu dur à gérer comme il faut au début (il faut avoir des gens de confiance), mais quand c'est bien géré, le projet avance beaucoup plus vite, puisque plusieurs cerveaux peuvent travailler en même temps !
[^] # Re: Oui : contactez-moi d'abord
Posté par cosmocat . Évalué à 5. Dernière modification le 15 septembre 2018 à 17:19.
C'est l'une des principal raison qui me fait penser que le fork doit être un dernier recours lorsqu'on a tout essayé avant. Car si tu fork, il faut avoir le temps (que tu semble ne pas avoir) de faire mieux que le mainteneur/développeur actuel, c'est à dire, ajouter encore des fonctionnalités, faire la maintenance, faire la revue des autres contributions,…
Et c'est pas donné à tout le monde.
Ce que j'aime bien faire dans un tel cas, c'est créer une pull request sur le dépôt initial, même si le mainteneur est pas coopératif comme ça les autres utilisateurs voient que la fonctionnalité existe et ils peuvent au moins la compiler eux même. Des fois, il y a même un build qui permet de télécharger le binaire compilé de la PR.
Mais je sais pas si c'est faisable sur Launchpad :-(
[^] # Re: Oui : contactez-moi d'abord
Posté par cosmocat . Évalué à 9.
Il me semble que ta vision des logiciels libres/open source est un peu idilique (biaisé par ceux ayant réussi).
Sur tous les logiciels développés, peu on assez de développeurs pour faire une "communauté".
La majorité ont 1 seul développeur (avec quelques contributeurs occasionnels). Et dans ce cas là, mettre de l'énergie à essayer de créer une communauté alors que ça intéresse personne est contre productif…
[^] # Re: Oui : contactez-moi d'abord
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 15 septembre 2018 à 23:33.
En effet, peut de projets ont assez de développeurs pour faire une communauté.
Mais regarde Gimp, Jehan nous le rappelle bien: ils ne sont pas 15 développeurs et pourtant il y a bien une communauté derrière.
Ici, comme je l'ai souligné dans un autre commentaire, le développeur souhaite travailler tout seul.
Personnellement, ça me dérange un peu et je ne voudrais pas faire un fork dans mon coin où je travaillerai tout seul aussi. L'idée est de joindre le projet à une communauté déjà existante comme GNOME ou KDE (comme l'a fait par exemple GCompris).
Dans ces communautés, il n'y a pas que des développeurs en plus: on y trouve des designer, des trieurs de bugs, des traducteurs, des graphistes, des administrateurs systèmes, des personnes en charge de l'administration de la fondation…
Enfin, un logiciel de comptabilité personnel tel que le propose HomeBank touche à mon avis un public assez grand, car tout le monde doit un jour ou l'autre faire le point sur son budget et peu de monde souhaite entrer dans de grands comptabilités d'entreprise comme le propose Odoo.
[^] # Re: Oui : contactez-moi d'abord
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Je vais donner un autre point de vue, qui est complètement le cul entre 2 chaises. Mais c'est vraiment comme cela que je vois la contribution au logiciel libre.
Alors d'un côté, tu as totalement raison. Si quelqu'un te file un méga-patch de centaines/milliers de lignes pour une grosse fonctionnalité dont tu ne veux pas, c'est dur de le rejeter (pour plein de raisons). Mais pour garder une cohérence au projet, ben des fois, faut bien.
Ceci dit, de l'autre côté, la personne essaie parfois de contacter, et se retrouve sans réponse pendant des jours, voire des semaines. Le truc, c'est que c'est totalement normal. On est des êtres humains, on fait des choses parfois en dehors du code. Et même si on devait coder quotidiennement à temps plein, ça ne signifie pas pour autant qu'on est obligé de répondre à toute question à la minute. On a une vie quoi.
Cependant la personne qui demande a aussi une vie. Attendre des jours, des heures même souvent, c'est dur quand on a une idée qu'on veut développer! On se met à le faire dans sa tête, on y passe des heures à y penser (qu'on a l'impression de perdre et on se dit qu'on aurait déjà bien avancé si on s'était mis directement à coder). Bien sûr, on pourrait/devrait juste poser la question et passer à autre chose en attendant la réponse (si même elle arrive). Mais l'humain est pas si rationnel et quand on a une idée en tête, c'est souvent pas si simple de "passer à autre chose".
En outre, du côté des mainteneurs, on entend très souvent la fameuse "Je suis développeur, je peux aider, vous m'expliquez ce que je dois faire?". Le truc, c'est que c'est pas si simple. D'ailleurs c'est peut-être même symptomatique d'un développeur à l'expérience limité de demander cela, comme s'il s'attendait à ce qu'on puisse lui décrire un logiciel énorme de tête en quelques minutes dans le détail. Car c'est le détail qui importe (bon bien sûr, on peut en faire dire de tête le nom de pas mal de fichiers ou fonctions et où plus ou moins précisément doit se passer tel ou tel changement, mais y a des limites quand même); oui je peux décrire la structure globale de GIMP en quelques minutes, mais une description si globale en général est inutile pour un développeur qui veut implémenter un truc précis. Il espère donc que tu lui dises où et quoi changer. Mais si on vérifie cela, on a déjà fait la moitié du boulot nous-même et on y a passé pas mal de temps.
Donc quand on donne juste une description simple, soit le contributeur potentiel comprend et il fait, soit (et c'est 90% des cas), il abandonne au bout d'un moment (et peut-être se dit que les dévs sont pas cool, ils aident pas les nouveaux, alors forcément…).
Là où je veux en venir, c'est qu'une demande qui vient avec un patch vaut 1000 propositions d'aide. C'est concret, c'est là, on sait tout de suite à quoi s'attendre (au niveau qualité du code notamment et on a une idée de ce qu'on pourra demander ou non à cette personne), etc. La proposition d'aide, notre réponse est invariablement "c'est cool, on attend le patch!" sans pour autant y mettre un espoir fou. On sait que dans beaucoup de cas, ça ne viendra pas. Je me rappelle même une fois une personne nous avoir dit avoir reçu un financement pour une fonctionnalité (j'ai retrouvé le ticket). Ce fut la première et dernière fois qu'on a entendu parler de lui.
Et en ce sens d'ailleurs, l'auteur du journal a très bien fait. Proposer un patch fonctionnel est la meilleure chose à faire quand on veut vraiment une fonctionnalité. C'est ce que j'ai appris au fil des ans, et désormais quand je veux vraiment quelque chose, je ne me pose pas la question: je la code moi-même. Attendre les autres mène rarement à l'obtention de la fonctionnalité (et ce, même si les développeurs du logiciels sont d'accord sur la fonctionnalité sur le principe; ça ne leur crée pas du temps magiquement ni ne la met en haut de leurs priorités: s'ils n'en estimaient pas eux-même le besoin au préalable, accepter qu'un autre puisse en avoir le besoin — et ce faisant accepter que cette fonctionnalité vaut le coup — ne change pas leur propre besoin).
Donc mon conseil aux contributeurs, c'est: oui bien sûr, discuter, c'est toujours bien! Mais ça ne veut pas dire que vous ne devez pas prendre un peu les devants. Les bons mainteneurs apprécient si vous avez un peu d'indépendance et que vous fassiez une implémentation dès le début. C'est la meilleure intro en tant que contributeur.
Par contre, oui, il faut être conscient que ça ne veut pas dire pour autant que votre patch sera accepté. Peut-être qu'il nécessitera juste des corrections. Peut-être que le mainteneur ne sera pas d'accord avec certains choix et qu'il faudra faire des compromis. Peut-être même (le pire des cas) que votre patch sera au final rejeté après avoir passé plein de temps pour coder et pour ensuite discuter et défendre la fonctionnalité. Ça arrive. Ça m'est aussi arrivé, et pas qu'une fois (même si globalement cela reste rare! Si vous êtes un bon développeur avec de bonnes idées, peu de mainteneurs refuseront tous vos patchs sans y penser à 2 fois, en tous cas pas les bons mainteneurs).
Mais vous savez quoi? C'est la vie! C'est pas une spécificité du développement logiciel. Dans plein de trucs dans la vie, il m'est arrivé de gâcher mon temps, en faisant ceci ou cela qui s'est avéré inutile ou refusé, ou autre. C'est chiant, mais bon. C'est pas la mort! On passe à autre chose.
En gros, la conclusion, c'est: que vous soyez mainteneur ou contributeur, soyez conscients que vous parlez avec des êtres humains:
On a un développeur qui a fait quelques patchs (de très mauvaise qualité technique d'ailleurs, donc énormément de temps de revue) pour GIMP et qui plusieurs fois nous dit des trucs genre "ce que je déteste le plus, c'est de perdre mon temps" dès qu'on se met à discuter ses patchs (pas pour les rejeter, mais réellement pour les discuter afin d'arriver au meilleur choix, qu'on ne sait pas forcément). Non seulement c'est très passif-agressif, met directement la discussion sur une mauvaise ambiance, mais en plus c'est oublier que nous aussi on existe. Nous non plus n'aimons pas perdre notre temps. Qui aime cela?
Mais on fait ce qu'on fait pour aboutir au meilleur logiciel ensemble, pas pour "perdre du temps". Si quelqu'un ne comprend pas ça, autant ne pas faire de logiciel libre.
Alors je le disais, il faut savoir refuser certaines contributions inadéquates. Ensuite sans plus de détails, je ne peux pas dire si c'est le cas des contribs que t'as reçue. Ceci dit, il faut aussi savoir demander à un contributeur à corriger son code pour le voir intégrer (cas de 2 des 3 contributions: demande au premier de compléter son patch, et au second de le refaire proprement).
Souvent aussi il faut savoir prendre de son temps pour faire faire fleurir les contributions. Je l'ai déjà dit, je fais beaucoup de revue de code dans GIMP. Mais soyons clair, la majorité de ce que je relis et corrige ne m'intéresse pas personnellement (ni pour notre projet ZeMarmot). Mais j'en vois l'intérêt pour d'autres et pour l'amélioration de GIMP en général. Si on devait refuser tous les patchs dès que le contributeur n'est pas capable de mieux, alors GIMP aurait genre moitié moins de fonctionnalités. La plupart du temps, on repasse derrière les patchs pour les peaufiner (et ce, même si la fonctionnalité ne nous intéresse pas personnellement!). Et d'autres repassent aussi derrière moi. Et ainsi de suite.
C'est aussi ça qui fait la qualité d'un logiciel libre: on n'est pas tout seul avec notre code et nos propres limitations.
Perso je n'aime pas tous les choix faits dans GIMP et j'en ai discuté plus d'un. Mais si je contribue, c'est parce que ce qu'on fait tous ensemble, j'aurais été incapable de le faire seul (de même pour les autres contributeurs). Et ça j'en suis très conscient. On a un logiciel extrêmement cool et puissant parce qu'on a travaillé ensemble, on a tous compromis ensemble.
Donc j'espère que tu ne refuses pas des fonctionnalités juste parce qu'elles ne t'intéressent pas. Ce serait tout de même un peu triste.
Bien sûr si la fonctionnalité a pour effet de rendre d'autres fonctionnalités moins bonnes, c'est une autre histoire. Mais ce n'est pas le cas de la plupart des fonctionnalités.
Perso notre build de GIMP local utilisé pour ZeMarmot a quelques petites différences, mais très mineures. Ce sont quelques détails qui ont été refusés dans GIMP (pour de bonnes raisons, même si je suis pas d'accord). J'en ai pas fait une maladie et je vais sûrement par forker GIMP (de manière publique j'entends) pour cette raison. Mais on garde ces différences au strict minimum.
Notre but n'est pas d'avoir notre propre GIMP mais d'améliorer le GIMP de base. Ne serait-ce que pour la qualité. C'est bien simple: presque tout ce que j'ai codé est d'autant mieux car d'autres gens sont passés derrière et ont aussi amélioré.
D'ailleurs l'un de mes buts dans GIMP est d'améliorer considérablement l'API et ses possibilités justement pour ne plus avoir de GIMP patché en local du tout. Je veux pouvoir transformer nos quelques différences de code en dur en plug-ins à la place.
Le truc, c'est aussi que maintenir un fork, c'est aussi un travail de dingue. Il faut le faire si vraiment tu n'as aucun choix (ou que tes différences sont vraiment minimes). Alors c'est vrai que c'est bien que ce soit possible, mais ce n'est absolument pas le plus intéressant dans les licences libres, selon moi. La possibilité d'un fork personnel est seulement une manière de rendre le pire cas "moins pire" (toujours d'après moi). :-)
Bon y a aussi les forks après abandon d'un projet par exemple, ou d'autres types de fork qui sont totalement différents. Je parle du cas du fork sans raison profonde, genre juste "comme ça je fais ce que je veux".
C'est effectivement une réalité, et la majorité des cas. Ensuite, je le rappelle (cf. plus haut): les contributeurs aussi ont une vie et des priorités. On peut leur demander d'aider mais on peut pas leur en vouloir s'ils refusent. J'ai personnellement contribué à des dizaines de projets (voir OpenHub et c'est loin d'être exhaustif!) et GIMP est le premier (hormis ceux que je maintiens ou ai créés) sur lequel je suis resté. Je ne pourrais pas humainement participer activement à tous les projets auxquels j'ai envoyé un patch.
Ça ne m'empêche pas de vouloir une fonctionnalité ailleurs et de la coder de temps en temps, mais oui le mainteneur doit être conscient que ça ne veut pas dire que je signe un contrat avec mon sang pour rester à ses côtés jusqu'à ma mort.
En tant que mainteneur de projet libre, c'est quelque chose à accepter. Ensuite bien sûr tu peux vouloir un projet petit et simple à maîtriser et qui prenne peu de temps en refusant de le rendre communautaire. C'est un choix et chacun est libre de le faire. Ensuite faudra pas espérer que son projet s'envole vers des sommets. On peut pas tout avoir. Bien sûr, pour beaucoup de gens, ce n'est pas ce qu'ils veulent. S'ils font le choix en plein conscience, c'est bien.
Personnellement je pense que ce n'est pas mauvais d'accepter de lâcher un peu prise parfois. D'ailleurs si les gens ne restent pas, c'est parfois aussi car certains mainteneurs peuvent garder trop de mainmise sur leur projet.
Au contraire, les plus gros projets ont des co-mainteneurs (voire ont changé de mainteneur à plusieurs reprises), et même quand parfois le créateur est resté depuis le début, cela ne l'a pas empêché de prendre des sous-mainteneurs (comme le noyau Linux) à tel point que dernièrement on a eu plusieurs exemples de tels mainteneurs qui essaient de rendre le projet encore plus indépendant d'eux (je pense bien sûr à Linus Torvalds et Guido Van Rossum).
La chose qui m'a fait rester sur GIMP? Très rapidement le mainteneur m'a attribué sa confiance. Au bout d'un mois ou 2, après plusieurs patchs, Mitch me dit en gros "tu fais chier avec tous tes patchs, ils sont tous bien, tiens prends toi un accès en écriture à git comme ça je gagne du temps". Franchement ça m'a impressionné. Je me suis dit "Waw juste comme ça, je peux pousser mes commits dans GIMP?". Il m'a donné sa confiance et j'ai d'autant plus fait gaffe à ce que je poussais et pendant longtemps je continuais à demander des revues de code avant de pousser dès que ce n'était pas totalement trivial. Au final je suis le plus gros développeur de GIMP sur la dernière année. Ce fut une très bonne leçon et j'essaie de l'appliquer aussi maintenant: dès que quelqu'un fait du code de qualité évidente et qu'il reste un peu, c'est le moment où faut "l'accrocher" avant qu'il aille voir ailleurs. Je lui propose donc d'avoir son accès en écriture. :-)
Alors soyons clair, ça marche pas tout le temps. Même ainsi, beaucoup de contributeurs disparaissent au bout d'un moment. Mais ça vaut le coup d'essayer.
Dans tous les cas, je ne suis pas seul à maintenir le code. On n'est pas beaucoup, mais je suis pas seul. Et c'est passé par le fait que le mainteneur (et tous les sous-mainteneurs) a su donner sa confiance aux gens et surtout a lâché un peu du lest. Il accepte qu'il ne sait pas tout, que certains sont de très bons développeurs (voire meilleurs que lui), qu'ils ont aussi de bonnes idées, que le logiciel peut servir à plus que ce dont lui se sert, etc.
En fait, le logiciel libre et/ou communautaire, quand c'est bien fait, je pense que ça peut faire de nous des bons philosophes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Oui : contactez-moi d'abord
Posté par Sufflope (site web personnel) . Évalué à 3.
Oh, pas que libre, pas la peine de faire du logiciel tout court. Ce paragraphe résonne avec mon expérience de développeur non-libre. A moins d'être un mercenaire qui fait n'importe quoi juste pour le pognon et change de boulot tous les 6 mois, auquel cas oui faisons du vite fait mal fait, de toute façon c'est pas nous qu'on f'ra la TMA.
[^] # Re: Oui : contactez-moi d'abord
Posté par CHP . Évalué à 7.
En somme :
le mauvais mainteneur, c'est un gars, il a un projet, on lui envoie un patch, il le rejette.
le bon mainteneur, c'est un gars, il a un projet, on lui envoie un patch, il le rejette aussi… Mais c'est un bon mainteneur
[^] # Re: Oui : contactez-moi d'abord
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
En fait, ce qui me gène le plus, c'est que la raison à la demande "Contactez moi d'abord" est que le développement actuel n'est jamais à disposition des autres développeurs avant une phase de RC.
Ce qui est sympa pour lui en effet, car, comme il le dit justement, il peut casser et refactoriser tant qu'il le veut.
Par contre, ça me met en face de moi un panneau: "Stop, c'est mon projet et je ne souhaite pas avancer à plusieurs dessus". Ce n'est pas que mon impression, puisque c'est la première phase du paragraphe cité: "I don't need help for coding purpose.".
Sauf, que je le rappelle, cette phrase est cachée à la fin d'une page hébergée sur son site personnel sur un site "free.fr". Je trouve que cet avertissement devrait être mis plus en avant sur le site (au moins au début de la page, même si ça casse l'ordre d'importance pour l'aide) et ça devrait être écrit sur Launchpad pour avertir les éventuels développeurs qui passeraient directement par ce biais.
Je trouve que l'idée d'un fork communautaire n'est pas si bête, car elle permettrait:
Bien évidemment, je ne pourrai pas être le seul à gérer ce projet, ce n'est pas l'idée du fork: l'idée est vraiment que la communauté puisse travailler à plusieurs dessus et ainsi avoir plus de "temps libre à disposition" (qui serait à peu près la somme du temps libre de 5 développeurs par exemple).
[^] # Re: Oui : contactez-moi d'abord
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
Tu devrais quand même attendre la réponse du dév. Comme je le disais, même quelques semaines d'attente, c'est pas trop demander dans le respect d'autrui (mon premier point plus haut: "l'autre a aussi une vie"), d'autant plus pour un tel sujet (prendre son bébé de ses bras, c'est pas rien).
Même si son texte paraît en effet assez-clairement anti-communautaire, on sait jamais! Et il vaut toujours mieux régler une situation pacifiquement que de s'embourber dans une guerre.
Je le disais aussi, un fork, c'est énormément de boulot, il faut en être conscient. Et tu parles de "5 développeurs", mais je pense pas que tu les aies déjà. Et c'est pas sûr que tu les aies jamais. Toi même disais que tu n'avais pas plus de temps que cela, et j'ai l'impression qu'hormis cette fonctionnalité de vision annuelle, tu n'as pas forcément plus de besoin pour l'instant. Je me trompe?
Alors quand le projet a été abandonné par ailleurs, c'est autre chose. Tu peux te permettre de le reprendre avec un taux de contribution faible (ce sera toujours plus qu'avant). Je maintiens quelques projets de la sorte où je fais quasi aucun développement, mais je les maintiens en vie, et surtout j'inclus des patchs si on m'en envoie (ce qui arrive peu pour des projets à faible visibilité).
Mais là on parle d'un projet activement développé, simplement de façon non-communautaire. Ça veut dire que soit ton fork risque au final d'être "derrière" le projet principal en terme de fonctionnalités et corrections de bug, soit vous devrez passer un temps fou pour backporter tous les changements d'un coup à chaque sortie (à ce que j'ai compris, il fait juste un seul commit public par sortie, avec tous les changements mélangés).
En fait ça me fait penser à la situation de Cinelerra qui n'est absolument pas enviable, avec 3 versions! Y a les auteurs originels (on sait même pas si c'est une personne seule ou plusieurs) qui développent toujours, mais dans leur coin, sans se soucier des forks (je crois qu'ils récupèrent même pas leurs changements — dites moi si je me trompe!) et uploade juste une archive des sources une fois de temps en temps pour chaque sortie. Y a une version communautaire qui essaie de rajouter des fonctionnalités tout en ré-intégrant le code de la version originelle à chaque sortie (donc les projets doivent dévier au fur et à mesure, rendant sûrement la version communautaire de plus en plus difficile à maintenir). Et enfin y a une 3ème version, j'ai jamais compris pourquoi! Enfin bon c'est le bordel quoi (rien que ça, ça donne pas envie d'essayer; je saurais pas quelle version tester), personne se parle, et au final il suffit de voir que Cinelerra n'est plus intégré dans presque aucune distribution, c'est la galère rien que pour installer. Ils ont bien encore leur petite communauté et fans (je croise encore des gens une fois de temps en temps dans des confs qui me disent utiliser ça; c'est fou) mais bon presque personne de nos jours ne le conseille. Quand on pense qu'y a 10-15 an, cet éditeur vidéo était dans toutes les distributions et était l'éditeur que tout le monde conseillait pour de l'édition vidéo sérieuse, c'est méga triste quoi.
Ma conclusion, c'est donc: attends la réponse, mais si vraiment il est confirmé que cette personne ne veut pas de patchs tels que le tien et est allergique à la collaboration, veux-tu vraiment t'embourber dans une telle situation?
Il me semble que les programmes de comptes personnels ne manquent pas. Et d'autres seront sûrement bien plus ouverts aux patchs. Ou alors c'est un type de logiciel bancaire particulier et y en a peu des comme ça? Ou celui-là est vraiment vraiment meilleur que les autres? Pourquoi s'accrocher à ce logiciel en particulier?
J'essaie vraiment juste de comprendre en quoi ce logiciel mériterait que tu veuilles aller jusqu'à un tel fork. Mon but n'est pas de te décourager. Si vraiment tu es méga motivé et as la foi, tu as tout à fait le droit et je te souhaite un bon développement (de même qu'à l'auteur originel d'ailleurs). Mais bon c'est à bien peser. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Oui : contactez-moi d'abord
Posté par totof2000 . Évalué à 4.
Pour ma part j'en ai essayé plusieurs, mais aucun n'était aussi simple et pratique que ce soft. Et surtout, il est dispo sous FreeBSD. LEs autres softs que j'ai essayés étaient beaucoupplus complexes à prendre en main.
Je ne sais pas pour le posteur initial, mais pour ma part, comme je l'ai dit, il a l'avantage d'être simple, mais relativement complet. Les autres softsque j'ai utilisés ont tendance à ressembler plus à une appli decompta "pro" qu'à une appli de gestion de compte personnelle.
[^] # Re: Oui : contactez-moi d'abord
Posté par Babelouest (site web personnel) . Évalué à 6.
J'ai la même approche que toi sur mes projets libres.
Quand je recois une demande de fonctionnalité sans rien d'autre derrière.
Si c'est facile à faire et justifié, je le fais et puis basta.
Si c'est moins facile, je le mets dans ma todo-list et je le ferai quand j'aurai le temps/l'envie.
Si je veux pas le faire, je dis non et j'explique pourquoi.
J'implique le demandeur pour m'assurer que la nouvelle version répond bien à sa demande.
Quand je recois un patch/une pull request, je regarde ce que ca apporte, et comment c'est codé.
Si ca ne sert à rien, je dis non merci et je dis pourquoi.
Si c'est un patch du genre
if (mon_exception_rien_qu_a_moi) { faire_un_truc_hyper_spécifique(); }, je dis non merci également et j'essaie de trouver une solution pour résoudre le problème initial tout en évitant de modifier mon code de cette manière.Si c'est pas propre ou doit être amélioré, je demande des corrections.
Enfin, si c'est fusionnable et correspond à mes critères de qualité, je m'assure de bien comprendre tout le nouveau code parce que je pars justement du principe que le contributeur va disparaître après, donc je veux maîtriser la contribution.
Je n'ai aucun état d'âme à refuser et fermer une pull request quand je ne la veux pas ou que je n'arrive pas à m'entendre avec la personne qui propose. J'argumente toujours avant et après ma décision, mais je ne souhaite pas faire de compromis là dessus, car au final, c'est moi qui maintient et fait évoluer le projet dans son ensemble.
Cela dit, mes projets sont suffisamment petits pour que je puisse les maintenir tout seul, donc je me permets de faire comme ca.
# autre temps, autre moeurs
Posté par ZeroHeure (site web personnel) . Évalué à 8. Dernière modification le 15 septembre 2018 à 13:17.
Je l'aime beaucoup moi aussi ce logiciel sympa et clair.
Homebank est un vieux logiciel, commencé sur Amiga. Il a un long historique de développement, d'attention et d'amour par son auteur, tout seul aux commandes, avant l'époque des forges, du développement communautaire et même … du Web. Il dit donc qu'il tient à son bébé, pour lui conserver une certaine orientation je suppose.
Et puis il n'a plus ton âge : nous les barbus, on a une vie plus compliquée maintenant, entre la famille, les loisirs communs, le travail, et … à la fin, notre jardin du logiciel libre où tout pousse, mais si lentement, qu'il vaut mieux nous approcher humblement, nous sortir de la rêverie avec douceur sans nous bombarder de propositions.
Ça m'étonnerait qu'il soit contre un patch bien foutu. Tout ce qu'il demande c'est d'en parler avant.
Tu remarqueras aussi que ta capture d'écran ne passera pas sur les mobiles, qui sont le nouvel axe de développement du projet.
Tu peux trouver la profession de foi de Maxime Doyen (l'auteur de Homebank) sur Viadeo, tu verras qu'il est passionné, loin d'être fermé aux nouveautés.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: autre temps, autre moeurs
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 15 septembre 2018 à 14:22.
Mmmmhhh, c'est intéressant que le projet soit aussi vieux, je n'y aurais pas pensé !
Pour la partie, sur les jeunes, je te laisse lire mon commentaire ci-dessus: je ne suis pas tout jeune non plus et j'ai aussi des responsabilités. Je pense que c'est ça qui me frustre le plus en fait: j'ai eu un peu de temps la semaine dernière et assez de motivation (j'aurai pu baisser les bras à de multiples reprises).
La seule erreur que j'ai faite est de supposer que le développement d'un logiciel libre était ouvert (forge disponible, triage de bugs public…). Dans les fait, actuellement, le développement est aussi fermé que celui d'Android et ça me rend bien triste :/
Le fait que le développement logiciel soit fermé ne me pose pas de soucis éthiques: ça reste un super logiciel libre à utiliser ! Par contre le message est claire: les reines du projets sont tenues par une seule personne et celle-ci ne peut pas être autant efficace qu'une communauté dont les membres travaillent en parallèle.
Edit: pour la partie mobile, le rapport peut fonctionner, car la fenêtre est scrollable. Je me pose par contre l'intérêt de la vision globale annuelle sur un mobile: l'idée de ce rapport est d'aider à ajuster le budget et donc je le ferais sur un vrai desktop. Pour moi, l'application mobile devrait surtout me servir à saisir les dépenses en direct.
[^] # Re: autre temps, autre moeurs
Posté par Sufflope (site web personnel) . Évalué à 4.
Je te propose deux axes de réponse :
[^] # Re: autre temps, autre moeurs
Posté par barmic . Évalué à 7.
Je pense qu'il y a surtout un malentendu. Un patch ou une merge request, ce n'est pas figée. C'est une proposition initiale. Elle peut très bien être discutée et c'est ce qui est fait. Si on regarde le fonctionnement des forges ou de la LKML c'est comme ça que ça se passe. Tu viens avec un bout de code en expliquant pourquoi tu l'a fait et c'est très bien comme ça :
Ça ne veut pas dire qu'il ne faut pas faire de petites fonctionnalités, au contraire. Juste que venir en disant « j'avais ce problème et j'ai pensé le résoudre comme ça, regarde le code que ça donne », c'est, je trouve la manière la plus pertinente de contribuer ponctuellement à un projet.
[^] # Re: autre temps, autre moeurs
Posté par Anonyme . Évalué à 4.
C’est ça que je ne comprends pas trop en fait. Visiblement il y a eu tout le temps d’en parler avant puisqu’il y a eu un rapport de bug.
Et puis franchement, vous avez déjà utilisé GitHub ou Gitlab ? Le système de relecture est tellement bien fait (je connais surtout Github, mais Gitlab semble être au même niveau) : il y a la possibilité de mettre un commentaire sur n’importe quelle modification, d’approuver ou de demander des changements (auquel cas, la PR est bloqué), le résultat des outils d’intégration continue est affiché et est également pris en compte pour pouvoir fusionner les changements, etc.
# En cas de doute il faut en parler -- avec la personne concernée
Posté par gasche . Évalué à 6.
Je n'hésiterais pas dans un cas comme cela à écrire au développeur de HomeBank. Tu fais des plates excuses sur le fait d'avoir commencé à coder avant de lire ses instructions, et que donc tu ne l'as pas contacté auparavant, mais que maintenant tu as un patch et/mais tu es prêt à refaire autre chose différemment s'il a une meilleure approche. Et là tu vois ce qu'il se passe.
[^] # Re: En cas de doute il faut en parler -- avec la personne concernée
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Oui, en effet, il faudra que je le contacte de toute manière.
J'ai écri ici sur LinuxFR pour avoir des avis plus rapidement que ce qui est écrit sur la page de support:
Je suis certainement dans le cas où je devrais attendre des mois, car il écrit clairement sur sa page de développement qu'il ne veut pas d'aide au développement.
Maintenant, je suis plus au clair sur ce que je devrais faire, merci à toutes vos réponses :)
Je ne vais pas forker sauvagement, ne vous inquiétez pas !
Je vais suivre vos conseils: contacter l'auteur pour m'excuser, continuer à suivre le launchpad pour voir si d'autres idées peuvent être intéressantes et, si l'auteur le souhaite, essayer de les implémenter.
[^] # Re: En cas de doute il faut en parler -- avec la personne concernée
Posté par gasche . Évalué à 5.
Je ne vois pas de raison d'avoir des certitudes, mais si tu penses attendre il vaut mieux écrire le plus tôt possible.
[^] # Re: En cas de doute il faut en parler -- avec la personne concernée
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Simplement à cause du paragraphe que j'ai cité dans le journal. Il commence clairement par:
Donc, répondre à un mail qui parle de collaboration va apparaître sûrement au fin fond de sa todo list ;)
[^] # Re: En cas de doute il faut en parler -- avec la personne concernée
Posté par gasche . Évalué à 10. Dernière modification le 16 septembre 2018 à 12:58.
On n'est pas là (ni toi) pour construire un modèle mental prédictif d'un individu à partir de sa page web ou pour lui faire une psychanalyse gratuite. Je pense que ce qui marche le mieux c'est d'être gentil avec les gens et de s'attendre au meilleur de leur part. En l'occurrence tu as travaillé sur le code de la personne, le plus naturel est de lui en parler de façon naturelle, et de s'attendre (naturellement) à une réponse, quoi qu'il y ait marqué sur sa page web.
Que tu ais un retour ou non, en fait dès maintenant, tu peux faire tout ce qui te semble gentil et raisonnable. Par exemple héberger ta branche modifiée quelque part (de préférence un endroit un peu plus visible que Launchpad, par exemple Gitlab), avec une mention claire du fait que c'est une version de travail que tu as envoyée upstream et que tu espères que ça va être intégré à terme.
Je trouve que tout cela est assez simple et que tu réfléchis un peu trop, à apprendre une page web par cœur et demander des avis sur LinuxFR avant d'envoyer un email. Fais comme ça vient !
[^] # Re: En cas de doute il faut en parler -- avec la personne concernée
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
C'est bien pour tous ces conseils et point de vue que j'ai écrit ici.
Mon but n'était pas de créer une polémique, mais d'expliquer ce que je ressentais avec ces informations disponibles sur le web. Et surtout d'avoir des avis extérieurs d'autres utilisateurs / développeurs de logiciel libres.
C'est la première fois que je contribue à un projet au développement fermé et ça m'est particulièrement étrange, car le rapport entre développeurs n'est pas équilibré: il est quand même le seul à avoir une branche avec le développement en cours !
J'aurai volontiers pris le temps de rebaser mes changements par exemple pour rendre la fusion plus simple et faire gagner du temps au mainteneur, mais je ne peux même pas techniquement faire ça.
[^] # Re: En cas de doute il faut en parler -- avec la personne concernée
Posté par Thomas Douillard . Évalué à 5.
En tout cas le pire que tu risques si tu tentes de le contacter, c’est qu’il ne te réponde pas. Par contre si tu ne tentes pas une approche, tu risques de continuer à gamberger jusqu’à la fin des temps (et c’est quelqu’un qui s’y connait en la matière qui te le dis /o).
[^] # Re: En cas de doute il faut en parler -- avec la personne concernée
Posté par gasche . Évalué à 4.
J'ai déjà travaillé avec des gens frileux, ayant peur de montrer leur travail intermédiaire au monde. Le modèle "je donne des tarballs de mes release mais pas l'accès au dépôt versionné" est malheureusement plus courant qu'on ne pourrait le croire. Parfois les gens ont changé de point de vue à force de discussion et mettent tout en ligne aujourd'hui. Souvent ils sont restés sur leur position. Quand je contribue, j'essaie de m'adapter aux choix et préférences des gens qui ont fait le gros du boulot—tout en étant clair sur le fait que je préfère faire les choses différemment, si on me pose la question. Si on fait comme ça vient, et que des deux côtés les gens ont de bonnes intentions, ça se passe en général bien.
# keep cool
Posté par sinner73fr . Évalué à 2.
Je suis moi aussi un geek assez ancien et j'ajoute plusieurs points complémentaires (les vieux on toujours des trucs à radoter ):
pour répondre a la question du post qui ne se pose même pas: ne pas forker, il n'y a aucune raison valable à cela
1) c'est un mal de société, mais je le clame haut et fort: le défaut de patience de nombreuses personnes à notre époque reste surprenant… Nombre devraient apprendre a se poser, communiquer, a respirer, voire a faire du yoga…
2) je trouve contradictoire de prôner un aspect communautaire et de ne pas commencer par un basique intrinsèque a ce concept qui est la communication, interpréter et rester sur des éléments vagues et incertains, dénué de tout élément factuel (un vrai NON du développeur) en n'ayant que soumis un merge request semble un peu cavalier, contacter l'auteur, même a posteriori semble une évidence, tu n'as par ailleurs pas a t'excuser, comme il a été dit, tu a juste agit de manière enthousiaste en ayant pas vu une pancarte, rien de bien grave
3) mon ressenti est que tu as eu un fenêtre de temps pour coder un truc qui t'étais utile à toi, que tu as maintenant à dispo pour ton besoin/usage (qui semble assez indépendant du code existant), donc il n'y a pas d'urgence pour le soft, ni le merge, ni les autres user.
C'est contradictoire de dire manquer de temps que et de ne pas accepter que c'est également le cas du développeur probablement, qui a un taf, peut être une femme, des gosses et un vie aussi, et qu'il fait ce qu'il peut avec tout ça, comme toi :)
4) certaines évols de tout projet doivent parfois s'appuyer sur d'autres non encore réalisées, et un patch de ce type peut tomber pour un développeur comme un "cheveux sur la soupe", impliquant a terme un plus gros travail sur les évols de base, tu fais un truc qu'il va devoir recoder (changement de datamodel) ou effectivement compliquera le refactoring, c'est a mon avis la motivation de facilitée (qui se comprends) de vouloir maîtriser de manière solo le cycle de dev (+ les apsects UI, le coding style, la ligne directrice du soft/projet, la liste des éléments peut facilement s'allonger ici) d'un logiciel et de vouloir être consulté avant pour un soucis d'efficacité et d'utilité pour le plus grand nombre, ce qui semble être la baseline de ce soft. On fait généralement un soft open source pour qu'il soit utile globalement, pas qu'il intègre tous les besoins, ou lubies exotiques de tout le monde, ou en tout cas pas avant d'avoir des basiques
5) tous les projets open source n'ont pas vocation a être communautaire à outrance comme le kernel ou d'autres application a large usages/public (gimp, gnome, kde, etc), on voit d'ailleurs que tous les projets communautaires sont sujets a des dissensions diverses et variées dues au maillon faible humain :)
rassurons nous (ou pas) dans quelques années le développeur humain ne sera plus de la partie.
6) la bande passante des dév étant souvent limitée, compte tenu ici du profil/age/travail du développeur, le temps consacré doit être assez discontinu, hors il faut parfois pouvoir se poser plusieurs heures d'affilée sur un sujet ou review d'un patch, ce qui n'est évidemment, tu en conviendra pas toujours possible. Bon je troll aussi, mais tu évoques tes 42h semaines, saches qu'en France il y a aussi des gens qui font autant voir plus d'heures (tous les français ne sont pas a 35h) et maintiennent ou contribuent en parallèle des soft open source, ceci conforte la partie impatience dont tu semble faire preuve, de manière constructive et volontaire certes, mais tout de même tu est trop exigeant là
7) ne te fie pas trop a ce qui est écrit sur un site web, tu ne sais pas si les infos sont à jour, et il semble perspicace de contacter la personne sur un sujet précis et de ne pas interpréter ce qui a été écrit a un instant T ou sert peut être de barrière psychologique niveau 1. Je ne te rejoins pas sur l'exposition un peu occultée que ces guidances ont, elle sont pour moi a l'endroit ou elle doivent être dans la section contribution
8) souvent, un mainteneur a des priorités, et il préfère avoir de l'aide sur des sujets prioritaires profitant a tous
9) si ton patch est bien pensé et de qualité, fait dans la ligne directrice du projet, je doute que le mainteneur ne l'accepte pas
10) concernant les fork plus globalement, je suis de ceux qui pense que c'est ce qui nuit grandement a GNU/Linux et l'open source en général: trop d'app/lib faisant plus ou moins la même chose, pas forcement toujours bien stables, codées, maintenues dans le temps, on se retrouve parfois dans un pâturage a devoir choisir un brin d'herbe sur sa nuance de vert et sa fraîcheur… Bien complexe.
Bref, soit confiant et patient !
Sinn'
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.