De l'usage de Git, GitHub, et SVN...

[parisse]

Edit admin, splitté depuis ici : viewtopic.php?f=97&t=20557&start=90#p224142

---

<pubGithub>
Avec un giac upstream sur GitHub, il aurait directement pu proposer une PR
Pas besoin de créer des diffs à la main, et surtout, une énorme communauté potentielle qui peut rapidement consulter et modifier/proposer des changements simplement !
</pubGithub>

github est certainement tres bien pour des projets nouveaux, mais quand on a une maniere de fonctionner avec divers partenaires (dont geogebra et HP), on ne va pas tout changer a chaque fois qu'un nouvel outil apparait, vous verrez ca quand vous aurez des projets qui ont plus de 15 ans... En plus ici, les modifications sont vraiment mineures, cf. la description synthetique que j'en ai faite, ca m'a pris un bon 1/4 d'heure (y compris modification du Makefile.am et ajout de LISEZMOI.numworks dans le tarball).

[Adriweb]

Je comprends bien, mais il y a des projets bien plus gros (et certains plus vieux, même si certes 15 ans ça commence à faire - perso j'ai des (anciens) projets qui ont 9-10 ans, mais pas 15 ) qui ont fait le switch sur git (et généralement via github pour de l'open-source).

En l’occurrence, sans parler de changer de méthode de dev, avoir un miroir github (maintenu de facon automatique par un script, par exemple) aurait rendu la PR possible et donc instantané le diff.
Même si l'intégration ne s'y fait pas par là, tout le monde (surtout le mainteneur, en fait) y aurait gagné en temps/productivité.
D'ailleurs, geogebra est aussi mirroré sur GitHub, entre autre vu l'avantage que ça a pour la lecture du code pour n'importe qui.
En bref, j'ai du mal à trouver un inconvénient d'avoir au minimum un miroir sur GitHub, et vu les côtés positifs, j'encourage vivement à le faire.

[parisse]

Personnellement, je ne vois pas l'interet d'utiliser git pour giac. geogebra utilise SVN, donc pourquoi me fatiguer a utiliser autre chose? D'autre part, je ne vais pas integrer une modification dans mon code sans avoir bien regarde auparavant les consequences, donc une proposition de changement ne sera jamais instantanee.
Et puis je suis persuade que maintenir de la diversite est une richesse. Ne serait-ce que parce qu'un peu de competition force les divers systemes a s'ameliorer, et tout le monde y gagne.

[Adriweb]

Ben dis donc, on le fait dévier, ce pauvre topic

Personnellement, je ne vois pas l'intérêt d'utiliser git pour giac. geogebra utilise SVN, donc pourquoi me fatiguer a utiliser autre chose?

Oui, je sais. Mais je parlais au dessus de l'intérêt/avantage d'avoir un miroir automatisé, sur GitHub. Ca ne change donc en rien le processus de dev. habituel, svn ou pas.
(utiliser vraiment git ou non, c'est une autre question, pour ma part je trouve que c'est juste très dommage, pour des raisons de compatibilité/legacy, de devoir se coltiner un ancêtre du siècle dernier comparable à un vrai cauchemar une fois que l'on a pu goûter véritablement à git - et notamment tout ce qui gravite autour, comme les services du genre GitHub)

D'autre part, je ne vais pas integrer une modification dans mon code sans avoir bien regarde auparavant les consequences, donc une proposition de changement ne sera jamais instantanee.

Bien évidemment, et personne ne demande à ce qu'une PR soit mergée instantanément, ça n'a aucun sens dans la plupart des cas. Le mainteneur validera le patch et décidera de l'intégrer/merger (ou non). Où est le problème ?
Avec une PR sur GitHub (ou autre), au moins, le diff est visible, facilement et simplement, dans un interface agréable et pratique.
Et tout le monde peut participer/commenter/reviewer etc., et avec un suivi. Impossible de faire ça si quelqu'un envoie dans son coin un patch plus ou moins bien fait à l'auteur directement.

Et puis je suis persuade que maintenir de la diversite est une richesse. Ne serait-ce que parce qu'un peu de competition force les divers systemes a s'ameliorer, et tout le monde y gagne.

Du coup on en revient à git vs svn, alors que ce n'était pas mon propos (je rappelle encore qu'initialement je vantais juste les mérites d'un miroir sur github).
Bref, il y a la réalité, en face d'une philosophie cherchant à "entretenir une diversité" : quand une solution est tout simplement/objectivement (bien) meilleure qu'une autre dans les usecases qui nous concernent... pourquoi ne pas au moins tenter ? Et d'ailleurs, "tous" les grands groupes sont en train de migrer sur Git (et GitHub pour de l'open-source) si ce n'est pas déjà le cas Pour le coup ce n'est pas qu'un avis, c'est une simple constatation. Et pour que les groupes en question fassent une telle décision... c'est que ce n'est pas pour rien, vu l'impact.
Pour un exemple plus personnel (pro, en l'occurence), au boulot, svn était utilisé avant, puis on a migré sur git il y a quelques années. Plus personne désormais n'oserait toucher à du svn - comme je le disais plus haut, c'est un véritable cauchemar à côté, surtout une fois que l'on se débrouille un minimum. Je n'ai que très peu utilisé svn moi même, donc je ne saurais vraiment donner des exemples concrets, je suis sûr qu'il existe des tas de comparaisons, tout à fait objectives, montrant tout ce qu'il faut.

Mais bref, passons. Je ne suis pas un évangélisateur d'un système ou d'un autre et ne cherche à convaincre personne, puisque je suis persuadé qu'en testant les 2 systèmes, le choix viendra par lui-même d'une rare évidence.


En écrivant ceci, un point plus important m'est venu en tête : l'utilité des services comme GitHub (mais tout aussi bien un concurrent comme GitLab, hein ; je parle en général).

Pour moi, un projet open-source est tout simplement hostile à un écosystème open-source moderne tel qu'on a l(a bonne) habitude de le concevoir s'il ne respecte pas au moins ces principes:

• Une licence open-source correcte
• Un tracking de l'historique du projet
• Une accessibilité aisée et pratique aux sources:
  
  • en lecture: un visualisateur web (github, gitlab, cgit dans une moindre mesure, etc.)
  • et en écriture: donc via des lesdits outils qui proposent ça aussi (modèle de fork+PR, ou clone+MR, question de vocabulaire selon le service utilisé)
• De l'automatisation via des "intégrations" auxdits outils [en ligne] - c'est ce que proposent des outils de CI comme Travis, AppVeyor, etc. (pouvant être couplés à Jenkins ou autre):
  
  • lancement des builds (multi-plateforme/environnement/architecture si approprié) lors des commits, mais aussi lors des PR/MR.
  • lancement des tests (si possible unitaires et fonctionnels, pour pouvoir facilement tester ses/des contributions, internes ou externes) + rapport sur la PR
  • Optionnellement, des outils qui font du reporting sur, par exemple, le coverage des tests, du review pour les PR sur des choses comme le respect de la codestyle, analyse statique, etc.
• Des instructions suffisamment claires pour pouvoir builder/installer le projet soi-même
• Un outil de tracking de bugs, public (les issues de github/gitlab etc. font suffisamment bien le boulot)

Je pourrais trouver d'autres "obligations" de ce genre, mais ça me semble déjà pas mal.
Il y a quelques années, je n'aurais sûrement pas mis le 3ème point - mais de nos jours, il n'y a plus d'excuses pour ne pas le respecter, toutes les technologies et services nécessaires s'intègrent directement aux plateformes habituelles, et ce de manière simple (ça peut se faire en quelques lignes, littéralement)

Ainsi donc, ceci condamne d'office les projets où le code source figure dans un fichier .tar.gz trouvable au bout d'un lien sur le site de son/ses auteur(s), mais aussi ceux qui utilisent des plateformes vieillissantes et obsolètes comme SourceForge, etc.

Ironiquement, je pourrais faire la comparaison avec un projet que l'on connaît tous les deux (suffisamment par rapport aux critères d'ici, j'entends): NumWorks, bien que ne respectant pas (à l'heure de ce post) le premier point, respecte le reste, contrairement (pour autant que j'ai pu voir, tant mieux si je me trompe) à giac/xcas, qui aurait donc une "mauvaise note".
Pour ma part, je serais absolument ravi de voir des évolutions sur Giac/Xcas qui rempliraient les points ci-dessous. Et comme je le disais aussi, ce n'est pas aussi compliqué que ça peut en avoir l'air.

Mais d'ailleurs, je ne suis ni hypocrite ni irréprochable, par exemple parmi mes projets, mon propre "Project Builder", est donc bel et bien 'hostile' à un écosystème open-source pour le moment car il ne respecte pas l'intégralité des conditions ci-dessus (le 3ème, ici). Mais justement, on en est conscient et on y travaille avec Lionel ; ça va venir, espérons, avant la fin de l'année.

[Lionel Debroux]

Adriweb a raison sur l'amélioration possible du workflow avec un repo Git public, et sur l'utilité des services auxiliaires intégrés aux plate-formes Github, Gitlab, Bitbucket et plates-formes cousines. Mettre les intégrations en place prend un peu de temps, mais beaucoup moins qu'essayer de tout refaire soi-même et de maintenir un large jeu d'environnements de build + test au long cours.
Git et les écosystèmes associés sont devenus la norme, et les projets qui ne suivent pas cette norme vont à terme avoir moins d'utilisateurs et de contributeurs potentiels.

Pour les principaux projets hébergés sur Github qui me concernent:
* pour libti*/gfm/tilp, je n'utilise pas autant l'issue tracker qu'il faudrait, je reçois quelques pull requests, j'utilise à peine les tarballs, et je n'utilise ni le wiki ni le site. En revanche, libti* (repo tilibs) tirent parti de Travis CI, et pourraient tirer parti d'AppVeyor maintenant qu'ils ont ajouté l'intégration de vcpkg. J'utilise également Coverity Scan utilisable gratuitement pour les projets FLOSS hébergés sur Github, en uploadant manuellement des tarballs, mais je pourrais faire comme CEmu. En tout cas, même des builds et uploads manuels m'ont permis d'améliorer la qualité du code;
* pour GCC4TI, il y a l'issue tracker (où l'autre andouille n'a pas pu s'empêcher de poster des conneries), le wiki (à peine) et en revanche, j'utilise le site.

Si on a peur de se rendre complètement dépendant de Github, il faut se rappeler qu'il est possible d'en extraire les données avec par exemple github-backup. Et puis comme Gitlab existe, ils ne peuvent pas vraiment se fermer, sinon ils s'en mordraient beaucoup les doigts

Quant aux SCM: si l'on excepte le stage de fin d'études, où nous utilisions SVN, à titre professionnel, je n'ai jamais utilisé que Git, presque exclusivement au-dessus de SVN... parce que c'est bien: réécriture d'historique (je n'ai très vite plus pu m'en passer, ça limite beaucoup l'illisibilité du vilain workflow commit-and-fix), rebase et merge plus puissants que SVN (même si ce dernier s'est amélioré), miroir complet de l'historique des commits en mode déconnecté, et j'en passe.

[parisse]

J'ai le sentiment que vous attachez beaucoup trop d'importance aux processus formels, comme si l'administration d'un projet etait plus importante que le contenu du projet lui-meme, ou la bibliometrie plus importante que le contenu des articles de recherche. Ce n'est pas parce qu'un projet a des outils plus evolues que les choses avancent plus vite, en fait ca peut avoir l'effet inverse, par exemple pour moi tracer les bugs et corrections avec des outils genre bugzilla ou tout systeme equivalent est tres souvent significativement plus lourd que de lire informellement un bug sur un forum et le corriger.
On pourrait dire la meme chose des outils de developpement, je me debrouille tres bien avec emacs/gdb, d'autres avec vi, alors que les generations actuelles utilisent surement d'autres outils. Changer ses habitudes est couteux, encore plus si on prend de l'age, et potentiellement generateur d'erreurs.
Si un jour geogebra passe sur git pour les commit, je suivrai, mais je ne vais pas gerer moi-meme un repository, le source a jour de giac est entierement controle par une tarball en local sur mon ordi, avec copie de sauvegarde sur cle USB, sur le serveur de mon labo et le SVN de geogebra, je peux donc travailler meme sans reseau. Je suis desole si ca parait artisanal a des gens qui ont suivi des formations en informatique (je suis pour ma part entierement auto-didacte), mais c'est comme ca que j'ai toujours fonctionne, ca ne fonctionne pas si mal que ca, et je ne vois pas trop quels avantages je retirerai d'un changement vers l'ideal decrit par Adriweb, pour moi ca ressemble un peu a une discussion sur le meilleur langage de programmation.

[Lionel Debroux]

je peux donc travailler meme sans reseau

Même un log ou un blame pour un fichier arbitraire du repo, et sans avoir à faire des synchros de repositories type svnsync ou svnadmin load ?

Ces opérations sont raisonnablement fréquentes pour moi sur libti*. Et ce sont précisément celles-là que Git m'a permis de faire deux jours de suite pour mes collègues qui utilisaient tous SVN, pendant que le serveur SVN centralisé était down: ils en avaient besoin pour leur travail, mais ils étaient aveugles sans le repo centralisé inaccessible, alors que c'était trivial pour moi.
Je ne parle pas non plus des soirs où j'ai avancé des choses depuis une chambre d'hôtel ou chez moi (puisque j'ai développé avec ma machine perso, c'était de toute façon du logiciel ouvert). Le travail en mode déconnecté est réellement plus efficace avec Git qu'avec SVN, et la synchro entre repositories est plus simple

[parisse]

je peux donc travailler meme sans reseau

Même un log ou un blame pour un fichier arbitraire du repo, et sans avoir à faire des synchros de repositories type svnsync ou svnadmin load ?

Je ne comprends pas.
Comme indique plus haut, svn me sert uniquement a faire des commits pour d'autres projets qui utilisent giac. Le source de reference est sur mon ordinateur, je travaille essentiellement seul sur le code source. Donc aucun probleme pour travailler hors reseau, je fais juste une 2eme sauvegarde sue clef USB.

[Lionel Debroux]

Formulé autrement: quel système efficace et fonctionnant hors réseau as-tu mis en place pour, par exemple, retrouver quand tu as modifié tel ou tel ensemble de fichiers (log), ou pour retrouver quand - le qui étant d'autant moins intéressant dans ton cas puisque c'est en général toi, comme tu l'écris - un ensemble de lignes de code (qui a un certain effet visible, feature ou bug ou testcase) a été ajouté / modifié (blame) ?

[Adriweb]

(J'ai splitté le topic initial pour ne pas trop le perturber)