Je débute l'explication de ce commit qui porte sur le module linuxbin en rappelant d'où vient ce module et ce qu'on veut en faire plus tard.

Le module linuxbin tire son nom du fait qu'il contient les utilitaires et fichiers de configuration du répertoire ~/bin sous les machines Linux.

Concernant les fichiers de configuration, linuxbin permet d'être certain que tout le monde possède toujours le même environement de travail (variables d'environement principalement) pour une machine donnée. Par exemple, quand une nouvelle version de MATLAB est installée sur une machine, le PATH doit être adapté chez tout le monde. Il suffit alors de modifier linuxbin et de demander à tout le monde de mettre à jour son ~/bin via un svn update pour régler le problème.

Concernant les utilitaires, il s'agissait initialement de petits scripts dont tout le monde a besoin sous Linux pour travailler avec Metafor (lancer un calcul ou une batterie). Au cours du temps, ces scripts ont grossi et ont tellement évolué qu'on n'imagine plus travailler sans eux! Aujourd'hui, comp.py permet de d'effectuer un checkout des sources Metafor, compiler, lancer une batterie et envoyer les résultats par e-mail. De manière similaire launch.py permet de lancer un calcul Metafor sur un serveur (simple PC ou cluster) avec notifications par e-mail et gestion éventuelle des queues batch et disques locaux.

Ces scripts sont tellement utiles qu'ils sont maintenant intégrés aux versions distribuées de Metafor (Techspace). En pratique, pour nous, il faut depuis peu faire un checkout de linuxbin à côté des sources de Metafor (oo_meta et oo_nda).

Le module linuxbin peut être également intéressant pour n'importe quelle personne utilisant les machines qui y sont configurées (nic4 ou les autres machines du CECI). Par exemple, Dominik utilise linuxbin alors qu'il n'utilise pas encore Metafor. D'autres thésards, dans d'autres services, pourraient utiliser linuxbin (Kim Liégeois, David Thomas).

Enfin, de plus en plus de personnes développent du code hors de Metafor. Le module linuxbin pourrait contenir le code commun à tous ces codes pour qu'ils restent compatibles entre eux. Il pourrait également aider à partager certaines classes de base (interface BLAS, TBB, timers, gestion des streams, solveurs externes, etc.) et certains modules de base (batterie de tests, CMakeLists.txt, lancement de processus multiples sur cluster, etc.)

En conclusion, linuxbin doit être rendu public. Il doit devenir accessible à n'importe qui voulant travailler sur nos machines ou avec nos libs ou avec nos codes. C'est dans ce but que le repository linuxbin, anciennement dans le repository SVN de Metafor a été transféré sur github.

Le repository SVN a été converti en un repository git et envoyé sur github dans l'organisation “ulgltas” que j'ai créée. Cette organisation permet de gérer les permissions d'accès aux différents codes. Elle contient actuellement “waves”, “linuxbin”, “ceci” (les tutos du CECI) et 2 forks (“pfem” de Marco et “plotter2d” de Yves). C'est à cet endroit que je compte mettre les autres codes open source qu'on va créer (gen4?, geniso?).

Pour récupérer un repository public de github, il n'y a pas besoin de compte github. Un simple “git clone” anonyme suffit.

git clone https://github.com/ulgltas/linuxbin.git ./bin

Néanmoins, si vous voulez un jour commiter des modifs, il vous faudra un compte. Je vous conseille donc de créer un compte github et je vous ajouterai dans les développeurs ulgltas. Ca vous permettra de faire des git push.

Le script comp.py a été modifié pour pouvoir gérer linuxbin en plus de oo_meta, oo_nda et parasolid lors de la compilation de Metafor.

J'ai profité de cette amélioration du script pour nettoyer un peu ce code. En particulier:

• j'ai supprimé la possibilité de spécifier les repositories dans les paramètres. Il y en a maintenant 3 différents et ils doivent être que très rarement changés (1 pour oo_meta et oo_nda - 1 pour parasolid et 1 pour linuxbin).
• j'ai supprimé la possibilité de baconniser sur une machine annexe. Ce code était assez vieux, non testé, relatiement complexe. De plus, il appelait une fonction battery.py baconnize qui n'existe plus.
• j'ai fait qq modifs de forme “interractif” ⇒ “interactive”.
• j'ai renommé certaines options: BUILD_OPT ⇒ CMAKELIST.

Migrez d'abord tous vos ~/bin:

ssh blueberry
rm -r bin
git clone https://github.com/ulgltas/linuxbin.git ./bin

et ceci pour chaque machine (blueberry, spring, thorgal et fabulous)

Si vous avez des working-copies de Metafor qui utilisent linuxbin sous SVN, faites pareil:

cd dev
rm -r linuxbin
git clone https://github.com/ulgltas/linuxbin.git

Et voilà, vous avez migré…

Si vous ne voulez pas modifier linuxbin, votre lecture s'arrête ici.

Si vous voulez modifier linuxbin:

1. Créez vous un compte github.
2. Dites-le moi et je vous inclus dans l'organisation ulgltas ansi que dans une ou des équipes.
3. Je vous conseille alors d'associer une clef SSH à votre compte. Ca va vous permettre de travailler de manière aussi simple avec github qu'avec nos machines (sans passwd). La clef à envoyer est votre clef publique des stations.
4. Le clone ssh peut se faire via la commande: (login=git, pas votre username!)

 git clone git@github.com:ulgltas/linuxbin.git

A ce moment, vous avez (et c'est le problème majeur de git), 100000 manières pour travailler:

1. vous modifiez le source et faites des commits locaux sur une machine donnée.
2. une fois que vous voulez publier vos modifs sur github, vous faites un git pull (équivalent de svn update pour être sûr d'être à jour), puis git push origin master.

Cette manière n'a pas d'intérêt par rapport à une procédure SVN. C'est du SVN mais avec plus de commandes. Le seul intérêt est d'avoir l'interface web de github. Elle est aussi la plus simple.

1. vous faites un “fork” de linuxbin sur votre compte github personnel (il suffit de cliquer sur le bouton “fork” en haut à droite à partir de https://github.com/ulgltas/linuxbin)
2. vous clonez alors votre copie de linuxbin et vous la modifiez autant que vous le voulez (git add, git commit, git push)
3. une fois que vous voulez partager vos modifs avec le reste du groupe, vous faites un “pull request”. Github a en effet mémorisé le fait que votre repository est une copie d'un autre et vous permet de demander un pull vers le repository parent.

C'est la manière qu'à choisi Dominik (cfr https://github.com/dboemer/linuxbin). C'est aussi la manière la plus “open source” de faire. Elle permet a des inconnus de modifier un repository auquel ils n'ont pas accès en écriture. Autrement dit, pour reprendre l'exemple de Dominik, il n'a pas besoin d'être un membre de l'organisation ulgltas pour modifier linuxbin. Ses modifications sont envoyées pour analyse aux membres de l'organisation qui acceptent le “pull request” après une éventuelle discussion et des corrections itératives.

L'inconvénient est la lourdeur du procédé. Par exemple, aujourd'hui, Dominik doit synchroniser son fork avec les modifs que je viens de faire via les commandes:

git remote add upstream https://github.com/ulgltas/linuxbin.git
git fetch upstream
git rebase upstream/master

Bref, je ne conseille pas cette méthode à ceux qui ne veulent pas s'impliquer un peu dans l'apprentissage de git/github.

Cette manière est utilisable avec SVN mais peu recommandée vu le manque de robustesse des algos de fusion de branche de SVN.

L'idée est donc de créer une branche de dévelopement à son nom et de commiter dans celle-ci tant que les modifs ne sont pas finalisées. Une fois que les modifs sont OK, il suffit alors de fusionner (git merge) la branche personnelle à la branche maître (master).

C'est ici, pour moi, qu'on obtient un vrai intérêt de github sur SVN (ou du moins sur la manière dont nous utilisons SVN pour Metafor).

En d'autres mots:

• récuperation d'une working copy:

git clone git@github.com:ulgltas/linuxbin.git

* création d'une branche / envoi de la branche sur github

git checkout -b romain
git push -u origin romain

• modif du code / commits dans la branche

git add .
git commit -m "commit 1"
git add .
git commit -m "commit 2"
git push origin romain

• merge de la branche avec master

git checkout master
git merge romain

Ce système me semble être un bon compromis entre la méthode 1, qui ressemble à du SVN en moins pratique, et la méthode 2 qui nécessite des synchronisations dans tous les sens et une duplication des repositories. C'est la méthode que je vais essayer d'appliquer.

Quoiqu'il en soit, si vous avez des idées, ou des remarques, n'hésitez pas à m'en parler. Comme dit plus haut, j'aimerais à terme mettre plusieurs projets sur github pour les rendre accessibles à n'importe qui (le mailleur gen4 en particulier). Ils seront donc gérés par git et non plus par SVN. Il est donc important de trouver une manière simple de travailler avec git pour le futur de Metafor.

— boman 2016/08/18 13:18