l'exemple détaillé, c'est f-droid, qui n'a pas accepté le code, et qu'il n'y a rien qui parle de "bullying" pour XZ (juste que le dev principal prends des pauses de temps en temps).
Je ne lis pas ça, perso, mais plutôt qu'il y a eu une insistance de la part d'un contributeur pour merger un code, et que ce contributeur a eu le soutien d'un nombre inconnu de vrai utilisateurs (entre 0 et N).
Je trouve en effet le terme bullying de la part de 404 trop fort, par contre. J'imagine que c'est la recherche de retenue qui a échoué sur un 404, comme d'hab avec la "presse" (on pourrait arguer qu'un titre non provocateur ne sera pas lu, parce que noyé dans la masse des infos "choc!". C'est peut-être vrai, je ne sais pas.).
La gestion des contributions externes est loin d'être simple... une chose importante a prendre en compte ici, c'est: est-il possible d'installer la fonctionnalité d'un f-droid forké sur sa machine, ou existe-t-il une dépendance directe à un truc hébergé?
Dans le 2nd cas, on peut effectivement comprendre (en supposant l'auteur de la PR bugguée non pourvu de mauvaises intentions).
A priori, vu le nom du repo, ce n'est pas le cas, par contre.
Pour avoir survolé les changements de la requête de fusion (j'insiste, survolé. Je ne connais pas le code de fdroidclient, et je ne suis pas un dev java alors une analyse complète de ma part serait malvenue), le diff me parait quand même simple. Ce qui me questionne le plus, c'est pourquoi une PR pour changer la fonction de recherche modifie tant d'images? Ca augmente la masse apparente de revue nécessaire, après tout.
Le fait qu'à priori il ne soit pas possible de naviguer entre les commits dans gitlab n'aide pas ( "a priori" != "a fortiori". On utilise le 1er quand on n'a pas poussé assez les recherches. Petit rappel au cas où.).
Je me pose aussi la question de savoir combien de gens sont impliqués dans fdroidclient? A priori (cf plus haut) cette information est bien planquée, si elle existe. En fonction, on peut se poser la question de la disponibilité.
Après, évidemment, il est probable que personne ne soit payé, et donc il est compliqué de demander un travail. Certes. Mais le pendant c'est que l'auteur potentiellement de bonne foi ne l'est pas non plus. Bref, c'est compliqué.
La question principale pour moi ici, c'est: l'utilisateur peut-il utiliser ses modifications sans avoir a ce qu'elles soient fusionnées en amont. Si oui, je suppose qu'en effet l'insistance est mal-venue: rien n'empêche de forker quand les besoins d'infrastructure sont nuls. Bien sûr, un tel fork s'il est annoncé va user les claviers de ceux qui n'ont rien d'autre a faire que dire que ça va encore fragmenter, et bla bla.
Dans l'autre cas, c'est plus compliqué, surtout si le projet parent prétend en effet recevoir aisément les contributions de code.
Je me base sur cet example précis, mais je n'ai creusé, et ma réflexion s'applique plutôt à un cas général.
[^] # Re: C'est quand même très provoc
Posté par freem . En réponse au lien Bullying in Open Source Software Is a Massive Security Vulnerability. Évalué à 4.
Je ne lis pas ça, perso, mais plutôt qu'il y a eu une insistance de la part d'un contributeur pour merger un code, et que ce contributeur a eu le soutien d'un nombre inconnu de vrai utilisateurs (entre 0 et N).
Je trouve en effet le terme bullying de la part de 404 trop fort, par contre. J'imagine que c'est la recherche de retenue qui a échoué sur un 404, comme d'hab avec la "presse" (on pourrait arguer qu'un titre non provocateur ne sera pas lu, parce que noyé dans la masse des infos "choc!". C'est peut-être vrai, je ne sais pas.).
La gestion des contributions externes est loin d'être simple... une chose importante a prendre en compte ici, c'est: est-il possible d'installer la fonctionnalité d'un f-droid forké sur sa machine, ou existe-t-il une dépendance directe à un truc hébergé?
Dans le 2nd cas, on peut effectivement comprendre (en supposant l'auteur de la PR bugguée non pourvu de mauvaises intentions).
A priori, vu le nom du repo, ce n'est pas le cas, par contre.
Pour avoir survolé les changements de la requête de fusion (j'insiste, survolé. Je ne connais pas le code de fdroidclient, et je ne suis pas un dev java alors une analyse complète de ma part serait malvenue), le diff me parait quand même simple. Ce qui me questionne le plus, c'est pourquoi une PR pour changer la fonction de recherche modifie tant d'images? Ca augmente la masse apparente de revue nécessaire, après tout.
Le fait qu'à priori il ne soit pas possible de naviguer entre les commits dans gitlab n'aide pas ( "a priori" != "a fortiori". On utilise le 1er quand on n'a pas poussé assez les recherches. Petit rappel au cas où.).
Je me pose aussi la question de savoir combien de gens sont impliqués dans fdroidclient? A priori (cf plus haut) cette information est bien planquée, si elle existe. En fonction, on peut se poser la question de la disponibilité.
Après, évidemment, il est probable que personne ne soit payé, et donc il est compliqué de demander un travail. Certes. Mais le pendant c'est que l'auteur potentiellement de bonne foi ne l'est pas non plus. Bref, c'est compliqué.
La question principale pour moi ici, c'est: l'utilisateur peut-il utiliser ses modifications sans avoir a ce qu'elles soient fusionnées en amont. Si oui, je suppose qu'en effet l'insistance est mal-venue: rien n'empêche de forker quand les besoins d'infrastructure sont nuls. Bien sûr, un tel fork s'il est annoncé va user les claviers de ceux qui n'ont rien d'autre a faire que dire que ça va encore fragmenter, et bla bla.
Dans l'autre cas, c'est plus compliqué, surtout si le projet parent prétend en effet recevoir aisément les contributions de code.
Je me base sur cet example précis, mais je n'ai creusé, et ma réflexion s'applique plutôt à un cas général.