A la faveur de [Résolu] Suppression du projet giseh/cicas ? et en restaurant le projet, je découvre que l’ensemble des projets du dossier giseh sont configurés avec
Du coup j’ai l’impression que git.spip.net sert plus de plateforme de distribution que de plateforme de collaboration, et je me demande dans quelle mesure c’est vraiment conforme à l’esprit de la zone…
Est-ce que c’est explicitement une volonté de @equipement ?
Historiquement, je sais qu’on a passé beaucoup de temps à lui demander de venir sur les espaces collaboratifs de SPIP, entre autres pour que ses plugins soient installables facilement par SVP.
Mais aussi pour que l’on puisse :
Donc, j’ai plus l’impression que c’est une erreur de configuration qu’une volonté délibérée.
Et je serais favorable à ce que la règle soit que tous les projets de la forge SPIP soient au moins en fork + MR possibles.
Alors je ne sais pas. La seule fois où j’ai fait une MR sur un de ses plugins, je me suis fait engueuler parce qu’il fallait discuter avec lui avant.
Je suis donc partagé entre : pousser vers la logique collaborative, ou bien se dire qu’on a deja abouti à quelque chose
J’ai indiqué à Maïeul, le 15/10/2024 :
Avant de proposer une requête de fusion, il convient de créer un ticket qui décrit le besoin (ou le problème). Si ce besoin est retenu par l’auteur du plugin et que ce dernier sollicite une requête de fusion, il convient alors d’en proposer une.
cf. convention de nommagre (#3) · Issues · giseh / cioidc · GitLab
Oui, enfin il y aussi beaucoup de plugin ou l’on accepte des micro requetes de fusion sans que le ticket ne soit là avant. Bref,
En fait l’état d’esprit de la zone spip c’est « on contribue ensemble ». Certes il y a de facto des personnes référentes sur des plugins, mais on ne peut pas dire comme tu l’a fait qu’il y a UNE méthode pour proposer les choses qui passe nécessairement par un ticket puis une MR.
Je pense ne pas trop être présomptueux en disant que je maintiens un nombre conséquent de plugins, mais si une personne me propose une MR sur un ds plugins en quesitons, je ne l’enverrai pas bouler parce qu’elle n’a pas ouvert un ticket préalable. Au pire, je discute avec elle pour voir si cette MR est vraiment pertinente en l’occurence, et si besoin on travaille pour aboutir à la meilleure solution.
Marrant ce fil parce que je découvrais aussi le souci ce matin et exprimais:
Hum. Va peut être falloir discuter des règles sur les groupes dans la forge : le lieu n’est pas non plus fait pour n’avoir aucune collaboration, même si tu veux avoir une surveillance sur le dépôt, bloquer les forks et les MR ça me paraît abusif comme règle (de mon point de vue).
Pour revenir sur le fond, à mon sens un depot devrait être au moins forkable, et dans l’idéal accepter les MR.
D’un autre côté, il est vrai qu’en l’espèce, la présence de ces depots sur git.spip.net est liée à une demande récurrente formulée de les y déposer, afin de profiter du debardeur et de l’installation auto. Donc bon, est-ce que « la communauté » n’a pas un peu chercher à forcer à utiliser un otuils qu’equipement ne voulait pas ? En ce sens je peux comprendre qu’il puisse vouloir que sa zone fonctionne autrement.
Mais en soit, permettre le fork et la MR n’implique pas de forcer à accepter les MR. Donc equipement continuerait in fine a avoir la main sur ses plugins.
Donc mon avis et qu’il faut menager les manières de fonctionner des un·es et des autres, tout en permettant aux gens qui veulent aller plus loin dans la collaboration sur un projet libre qui aurait déposé sur git.spip.net de pouvoir le faire facilement
Et donc
C’est sans doute pas très clair et pas très tranché, mais je ne vois pas mieux.
Pour revenir sur le fond, à mon sens un depot devrait être au moins forkable, et dans l’idéal accepter les MR.
+1, et on devrait inscrire ça dans la charte, ou bien dans le texte de création de compte de Gitlab mais dans la charte ça me parait le mieux.
Même si on doit en discuter et s’engueuler pendant 6 mois pour le concrétiser, c’est pas grave, on aura avancé.
Pour les projets qui n’acceptent ni fork ni PR, il y a github.com
Pas que : j’avais aussi souhaité pouvoir soumettre des MR.
Voilà c’est l’essentiel. Pas d’obligation à intégrer des merges. Tout le monde a le droit de refuser et d’éminents coredevs ne s’en privent pas parfois. Pas de problème du moment que c’est libre car alors on peut forker… avec la charge d’entretien qui va avec ensuite.
Et qu’il y ait un bouton pour faciliter le fork ou pas, c’est un détail selon moi.
est-ce que « la communauté » n’a pas un peu chercher à forcer à utiliser un otuils qu’equipement ne voulait pas ?
À donf.
Le code est là : super.
Dans le dialogue on peut essayer de construire plus de coopération,
mais point n’est besoin d’exiger plus .
Je ne comprend pas cette allergie vis-à-vis de la création de ticket.
Créer un ticket, qui décrit le besoin (ou le problème), présente plusieurs avantages :
Moi ce que je ne comprend pas, c’est le refus par principe de permettre les MR. Ca a aussi des avantages
bref il n’y a pas de raisons d’opposer comme vous le faite MR et ticket. L’un et l’autre sont complémentaires (voir le cas de spip, qui gère des tickets qui précéde des MR parfois, mais aussi parfois des MR sans ticket quand le problème est rapide à voir et à résoudre).
Sur saisies / formidable / autres plugins dont je suis le mainteneur principal, des gens ouvrent parfosi des tickets avant des MR, parfois pas quand la MR est mineur, et je ne fais pas tout un foin parrce qu’il n’y a pas eu de ticket préalable à la MR.
+1
C’est cette rigidité qui hérisse les ressentis.
Cf ce sujet parallèle où tout roule : Import des plugins bank et factures sur git.spip.net
la rigidité est pénible
la rigidité à exiger de la souplesse
est pénible aussi
(JLuc Tseu)