Pour faire suite à des discussions en call plateforme et échanges avec notre développeur WebU, à propos de la publication des matériels open source, nous sommes en mesure de proposer les deux options suivantes, sujet ouvert à vos avis et suggestions. Si une solution vous parait plus pertinente que l’autre ou si une troisième voie existe, n’hésitez pas à compléter.
Une personne avec les droits nécessaires (référent projet ?) va créer le release sur gitlab, télécharge l’archive et l’upload dans l’espace du projet sur NextCloud, puis la partage avec un lien public. Ces liens pourraient être listés sur le forum ou le wiki public. Dans ce cas, l’action est manuelle mais peu être rapidement rendue opérationnelle (se pose ensuite la question de l’espace NextCloud, peut être un dossier dédié aux publications finalisées ?).
On duplique le projet gitlab entier dans un autre groupe (« Projets Publiés » par exemple) avec la visibilité « publique » dans lequel on créera les releases. La synchro entre projet « privé » et « publié » pourrait être déclenchée par des utilisateurs autorisés, ou automatisée à chaque commit (mais pas forcément idéal et/ou très utile). L’avantage est que le dépôt public du projet peut être consulté par GitLab et téléchargé également via Git. Le dépôt n’accepte pas de commit de l’extérieur évidemment, mais tout l’historique des modifications est consultable (on regarde pour rendre ce point plus optionnel).
Ok. Pour moi l’Option 1 absolument pas. On a inventé git exactement pour eviter ça :). La seule chose qui peut arriver est: est-ce il y a du matériel qui ne se convient pas à être publié sur un repo git? Je dirais non… Aussi les « artifacts » comme les images ou des fichiers cad je les trouves tranquillement gérables dans un repo.
Donc je dirais Option 2 mais avec une petite modifs: dès que le projet ou le delivrable du projet est accepté comme Open Source, son repertoire n’est pas dupliqué mais plutot transferé dans le groupe « Open Source Projects », est le developpement continue dans le répo publique. Pas nécessaire de garder en sync les deux, ça va être la galère. Pourquoi le dépôt ne devrait pas accepter des commit de l’extérieur? Dès qu’un projet est open source, on vuet bien que qui veut puisse y contribuer.
Parce que pour contribuer au projet dans le cadre de Fédération, il faut faire partie de l’équipe projet, et être membre authentifié de la plateforme. Alors que là on parle de ce qui est accessible publiquement. C’est à discuter : mais si tu permets du développement sur la plateforme Fédération avec uniquement le git, est-ce que c’est pertinent ? Ou alors il faut y attacher aussi un NextCloud, un Discourse… et reproduire un espace projet complet ?
Quand on parle de « publication » ici on parle bien de ce qui va être rendu public, de façon structurée et accessible. Et donc le choix qu’on a fait est de faire un « snapshot » du projet à un moment T, accessible publiquement (même aux gens non authentifiés sur la plateforme). Si des personnes veulent contribuer dans le cadre Fédération, elles peuvent rejoindre le projet, ou alors elles peuvent forker en récupérant le contenu publié et en allant mener leurs travaux dans un autre cadre.
Et la solution 1 ne serait qu’un intermédiaire, si la solution 2 met beaucoup de temps à être mise en place. On a besoin de publier des choses à court terme, pour garantir la pérennité de Fédération.
Je comprends très bien et bien sûr vous avez une vision plus large de la mienne. Pour moi de toute façon une fois que le projet est publique, dans le vrai sens du terme, n’aurait pas vraiment non plus de sens de garder l’obligation de développer au sein de la Féderation en étant enregistrés (si le projet est vraiment open source est n’est pas soumis à contrôle export ou autres choses).
Je dirais à ce point là aussi de transférer le projet directement sur Github, dans une organisation, ça donne plus de visibilité au projet et ça aide aussi le branding de Féderation selon moi. Même si le fork est un droit que justement qui veut doit avoir, n’est pas bénéfique pour le projet en sens absolu.Ça génère de la fragmentation et de la confusion: une fois que le projet est vraiment publique, est il n’y a pas de contraint de sorte (e.g. de garder le projet stock;e sur un serveur français et ainsi de suite), garantir la plus large accessibilité à la contribution est l’objectif primordiale, je trouve.
Pour moi un projet, une fois qu’il est approuvé pour être open source, peut beneficier des contribution de ceux qui veulent.
Alors que là on parle de ce qui est accessible publiquement. C’est à discuter : mais si tu permets du développement sur la plateforme Fédération avec uniquement le git, est-ce que c’est pertinent ? Ou alors il faut y attacher aussi un NextCloud, un Discourse… et reproduire un espace projet complet
Je vois ce que tu veux dire, mais je dirais que le projet a quand même un perimètre limité à definir. git permet de stocker tout ce qui est stocké dans un cloud, avec de fonctionnalité en plus (git blame qui permet exactement de voir qui a contribué sur quoi, la date de la contribution, le contribution peuvent être signé, etc…). Et dans le cas extrème, avec quelque ligne de code le matériel de Discourse peut être migré au sauvegardé à travers des API. Mon hypothèse est, dans le cas qui soit vraiment nécessaire de réproduire un espace projet complet, cet espace peut être serialisé et stocké dans un repo git et externalisé.
Dans ce cas pas d’interaction avec la communauté GitHub et Gitlab FOSM ?
SI le projet est forké puis tu veux le reprendre (amélioré) sur FOSM? Ca rend le suivi dur non ?
Dans ce cas pas d’interaction avec la communauté GitHub et Gitlab FOSM ?
C’est une proposition, mais pour moi, une fois que le projet est publique, il existe seulement dans un endroit. Il faut en discuter, mais cet endroit pour moi doit permettre à la plus part possible de monde d’y contribuer.
Après c’est à évaluer:
Dans un projet publique sur FOSM > Les externes doivent s’enregistrer, moins de reach
Dans un projet publique sur Github > La communauté de FOSM doit avoir un compte Github (très probable qu’ils l’ayent déjà) pour contribuer mais beaucoup plus de public potentiel.
De toute façon pour moi la condition importante et ne pas avoir plusieurs sources… La coordination de plusieurs forks est très difficile et si possible ça sera mieux de l’eviter.
SI le projet est forké puis tu veux le reprendre (amélioré) sur FOSM? Ca rend le suivi dur non ?
Si le projet devient publique, sa gestion est faite dans le repo « publique ». Après on peut aussi laisser le choix au résponsable du projet s’il veut garder le repo publique sur le Gitlab de FOSM ou pas. Ma si il choisi de le migrer sur une autre plateforme « globale », n’import qui peut contribuer. Dans le cas ça soit sur Github, il faut avoir un compte Github.
Personnellement je préfère la solution 2 pour les publications finales.
Je pense que même pour les projets hardware, c’est mieux d’utiliser Gitlab
Le problème c’est que la plupart des utilisateurs qui font du hardware ne savent pas utiliser Git (moi même j’ai fait mon premier commit en 2021 ).
Du coup, pour publier des projets à court terme, est-ce qu’il ne pourrait pas y avoir des personnes du cercle projet (ou plateforme) pour aider à mettre sur Gitlab les éléments à publier ?
Voici le procès que je propose:
1- Un contributeur a finit son projet hardware mais ne sait pas utiliser git (moi par exemple ) -> il met ce qu’il souhaite publié dans un dossier Nextcloud (temporaire) et il contacte le cercle projet
2- Le cercle projet lui demande d’activer gitlab dans l’administration du projet
3- Un membre du cercle projet (très calé sur gitlab ) fait la publication pour le compte du contributeur
4- Le contributeur fait des tuto gitlab comme ça dans 6 mois quand il veut mettre à jour son projet il saura le faire tout seul
ça peut paraître un non sens pour ceux qui ont l’habitude d’utiliser Git, mais je vous assure que pour les autres c’est très compliqué de se mettre à Gitlab du jour au lendemain
Ça me semble très raisonnable… Et je m’offre pour le support Git quand ça servira avec le post-scriptum de dire à tout le forum: si vous avez du slack time, investissez ça pour apprendre git. Et si vous avez des problèmes, n’hésitez pas à m’envoyer un DM ici sur le forum.
).
) -> il met ce qu’il souhaite publié dans un dossier Nextcloud (temporaire) et il contacte le cercle projet
) fait la publication pour le compte du contributeur