Contribuer à un logiciel libre n'est pas chose facile, surtout lorsqu'il s'agit de code, car il faut mettre en place l'environnement de développement adéquat, ce qui peut s’avérer très compliqué en fonction du ou des langages sur lequel s'appuie le logiciel et des ses dépendances.
Il y a quelques jours, un service web a été lancé qui change un peu la donne. Ce service permet de cloner un dépôt GitHub dans un environnement de développement en ligne. On peut donc tester et modifier un logiciel issu d'un dépôt directement à partir d'un navigateur web, sans rien avoir à installer. Et cela se fait très simplement, en ouvrant une URL de la forme suivante : https://repl.it/github/<user>/<repo>.
Par exemple, voici l'adresse d'un de mes dépôt : https://github.com/epeios-q37/atlas-python. Pour l'utiliser avec ce service, il suffit d'ouvrir l'URL https://repl.it/github/epeios-q37/atlas-python. J'ai ajouté à ce dépôt un fichier .replit, qui est au format TOML et qui permet d'indiquer au service l'action à lancer lors de l'appui sur le bouton run. En cas d'absence de ce fichier, le service affiche un petit formulaire permettent de le créer rapidement.
Ce dépôt est en Python, un langage interprété, donc le bouton run lance le logiciel immédiatement. Dans le cas d'un logiciel compilé, c'est plus long, puisqu'il faut justement compiler le logiciel auparavant. Le dépôt https://github.com/epeios-q37/xppq-cli, par exemple, contient un logiciel C++. Pour l'utiliser avec ce service, l'URL est https://repl.it/github/epeios-q37/xppq-cli. Le fichier .replit que j'ai crée compile le logiciel avant de le lancer, donc cela va prendre (nettement) plus de temps. Ceci dit, j'y teste l'existence de l'exécutable pour éviter de lancer la compilation à chaque fois que l'on clique sur le bouton run. Donc, le premier lancement va être long, mais pas les suivants.
À noter qu'il n'est pas nécessaire de cliquer sur le bouton run pour lancer l'application ; on peut la lancer directement à partir de la console. Cette dernière est une véritable console GNU/Linux, avec pas mal de choses préinstallées. On peut également facilement transférer des fichiers.
Point de vue limitations, on ne peut y faire tourner que des application GNU/Linux, et, à quelques exceptions prés, que des applications avec une interface en ligne de commande. Mais il y a un grand nombre de langages disponibles, et il n'est pas nécessaire de créer un compte.
La création d'un compte comporte néanmoins certains avantages, en plus de pouvoir y conserver ses REPL. On peut en effet y lier son compte GitHub. Ce faisant, les modifications que l'on apporte à un de ses dépôts GitHub en utilisant ce service peuvent être répercutées directement de ce service dans le dépôt. De la même manière, on peut faire des Pull Request sur des dépôts tiers également directement de ce service. N'en ayant pas l'utilité, je n'ai pas testé ces fonctionnalités.
Ce service s’appuie en partie sur des logiciels libres, mais n'est pas lui-même libre. En outre, il ne fonctionne actuellement qu'avec GitHub, ce qui peut ne pas faire l'affaire de tous compte tenu d'un certain évènement. Cependant, grâce à lui, il est probable que plus de personnes envisageront d'apporter leurs contributions à leurs logiciels préférés…
L'annonce concernant ce service : https://repl.it/site/blog/github.
# Libre chez gitlab ?
Posté par raphj . Évalué à 10. Dernière modification le 17 décembre 2019 à 06:35.
J'ai l'impression que les fonctionnalités décrites correspondent au Web IDE chez Gitlab, qui est, lui, libre et qu'on peut héberger soi-même si besoin.
https://docs.gitlab.com/ee/user/project/web_ide/
Je n'ai essayé ni l'un ni l'autre donc je ne sais pas comment ils se comparent, mais si j'avais besoin d'une telle fonctionnalité, je pense que me tournerais vers cette deuxième solution et j'invite les autres à faire de même.
[^] # Re: Libre chez gitlab ?
Posté par zurvan . Évalué à 3.
heu, non, j'ai l'impression que ce n'est pas du tout la même chose, le journal parle d'une solution pour interagir directement en ligne de commande avec du code hébergé sur github (via un bash), ce qui permet de voir le résultat de ce code, alors que ce que tu montres sur gitlab n'est qu'un éditeur de code source, en ligne (ce que permet également github nativement).
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Libre chez gitlab ?
Posté par raphj . Évalué à 5. Dernière modification le 17 décembre 2019 à 16:02.
Il semble bien y avoir une fonction terminal (en beta) pour tester. Cherche « Terminal » dans la page. Il y a aussi des liens avec l'intégration continue. Ça paraîtrait dangereux d'envoyer des changements dans un dépôt sans pouvoir les tester avant de toute façon.
Je me trompe peut-être cela dit.
[^] # Re: Libre chez gitlab ?
Posté par zurvan . Évalué à 4.
ah, c'est bien alors, surtout si c'est en 100% libre !
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Et l'humain ?
Posté par pizaninja . Évalué à 4.
Mon retour d'expérience:
Ce n'est pas la partie technique qui me semble le plus difficile, mais plutôt le côté humain/négociation: le fait de convaincre les valideurs de pull requests du bien fondé d'une proposition d'amélioration.
[^] # Re: Et l'humain ?
Posté par ZeroHeure (site web personnel) . Évalué à 3.
Comme dans toute discussion :
Il faut prendre du recul, se demander si on a bien expliqué, réviser sa position pour être sûr de ne pas tomber dans un cas particulier, se dire que les autres voient peut-être des problèmes futurs, montrer qu'on sera là pour les futures révisions, … Comme dans toute discussion il faut qu'on ait confiance en toi.
Dans le cas du code, il faut y aller progressivement, commencer par des petites choses. Jehan a très bien expliqué comment la confiance des autres développeurs de Gimp s'est installée (c'était un journal, une dépêche ou une interview je ne me souviens plus — peut-être même simplement un commentaire).
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Et l'humain ?
Posté par freem . Évalué à 9.
C'est vrai, mais quand je commence a contribuer a un soft, généralement, c'est parce qu'il y a un aspect qui me gêne, le plus souvent, des dysfonctionnements ou des problèmes de performance.
Contribuer du code, dans ce type de cas (surtout les perfs), c'est passer plusieurs heures à comprendre d'où viens le problème, qui sera variable selon le hardware, puis trouver sa racine, patcher, adapter son patch au style de codage, puis passer par ce que je considère être une pure galère: faut faire un fork, puis pull, puis push, puis faire une push request, attendre la réponse pendant N jours… et même si le patch en question touche juste une fonction de 20 lignes, on te diras de l'éditer toi-même jusqu'a ce qu'il colle a des trucs listés nulle part.
Je vais être franc: je trouve ce modèle bien trop bureaucrate, il nécessite bien trop de ressources matérielles (lancer un brouteur web, c'est mini 2Gio de RAM et un ponçage de disque dur gratos pendant 20s mini sur disque mécanique), et nécessite un polling humain.
En face de ça, il existe un modèle ancestral, certes, moins sexy, certes, basé sur: j'ai un truc qui me soule sur un soft, je me fais un patch perso, je j'envoie a la mailing list du projet, qui disent soit "oui", soit "non", soit "oui mais on va patcher ton patch", éventuellement avec des discussions qui ne nécessiterons pas l'usage de ces usines à segfaults et fuites d'infos que sont les navigateurs webs, chacun pouvant utiliser le client mail qu'il préfère.
Je vais être honnête: maintenant, je fais presque la même avec github: quand j'ai un patch, j'ouvre un bug/feature req/whatever, je cale le patch en P.J. par contre je cherche pas a suivre la discussion. Si j'ai un mail, je vais suivre, sinon, bah… pfou, trop d'efforts, au pire j'ai le patch chez moi, et ça me coûte moins cher de le maintenir que de parvenir a un accord avec l'upstream!.
Je suppose que je devrais pas le dire, par contre. C'est vrai, ça se fait pas, de vouloir simplement contribuer ponctuellement aux logiciels que l'on utilise.
Je ne suis pas comme Jehan (bien moins bon, probablement), j'utilise surtout de petits softs pas gourmands, triés sur le repo apt, dont j'ai tendance a inspecter au moins vite fait le code, et dont dans le cas des jeux, je ne jouerais qu'un temps.
J'ai émis des patchs pour divers softs, cgdb, solvespace, divers jeux… et mon constat global est que quand ça commence a devenir "gros", y'a plus de bureaucratie que de technique, même en collant en pièce jointe des pdf de google-perftools avant et après.
J'ai déjà horreur de la bureaucratie IRL, c'est pas pour m'en coller dans des contributions ponctuelles. Cela dis, les projets sur lesquels on m'a pas trop fait chier, je garde un oeil sur leur source, les autres pas vraiment.
Bref, en l'occurrence, l'humain, ben… franchement, il est cool quand il est seul, en groupe, c'est une saleté.
A vos moins, prêts?
[^] # Re: Et l'humain ?
Posté par vv222 (site web personnel) . Évalué à 2.
Parfait, tu es prêt à contribuer à ./play.it ;)
Notre première contribution de patch reçue par e-mail a été surprenante… pour celui qui l’a envoyée. Il ne s’attendait en fait pas à ce qu’on fasse de notre côté tous les efforts nécessaires à l’intégrer.
De mon point de vue c’est au mainteneur du projet de faire le travail requis à l’intégration d’une contribution (à partir bien sûr du moment où cette contribution est souhaitée). La contrepartie bien sûr c’est que le mainteneur a souvent peu de temps restant pour contribuer lui-même directement au développement logiciel.
Pour ma part j’alterne par périodes : je fais des pauses dans la maintenance, durant lesquelles je ne fais que des réponses rapides aux éventuels nouveaux contributeurs pour qu’ils ne se sentent pas oubliés, pour pouvoir passer un peu de temps sur la partie développement.
Je suis certain que ce n’est pas la meilleure manière de fonctionner, ce n’est peut-être même pas plus efficace que des règles de contribution rigides mais détaillées, mais ça marche très bien depuis des années pour un projet axé autour d’un logiciel avec une demi-douzaine de contributeurs réguliers et tout un tas de contributeurs ponctuels, que ce soit pour fournir des patchs, du code tout frais ou des retours d’expérience.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.