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.
# keep cool
Posté par sinner73fr . En réponse au journal Forker ou ne pas forker ?. É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'