[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: (sourcesup?) Re: (par lot de douze ?) Re: github et microsoft



salut et merci pour ton retour,

je me rend compte qu'il y a probablement pas mal de membres de l'ESR sur
la liste et que nous risquerions de polluer avec un gros off-topic
sourcesup. même si j'ai très envie de te répondre, peut-être devrions
nous continuer cette discution sur

    https://groupes.renater.fr/sympa/info/suplibre

ou devlog

    http://devlog.cnrs.fr/

mais pas ici... je suis sur ces deux listes et t'invite a reposter
librement sur l'une d'elle.

c'est l'idée de contributors dans github. dans gitolite tu as même
depuis tres longtemps la notion de droits par branches ce qui est assez
cool.

par contre sur ces 2 points ma réponse n'est pas spécifique sourcesup

> ne marche pas, ça gueule de suite ! Parfois, le coté décentralisé de GIT/HG
> me donne une impression d'hyper centralisation ;-)
> Bref, après quelques années, je suis dubitatif personnellement sur le modèle
> PR dans les petits groupes.

git lui-même n'a pas de notions de PR et choses comme ça:

* les dépots peuvent se cloner et s'archiver librement
* chacun est maitre de son dépot
* git propose des outils comme git-format-patch et git-apply
  qui permettent de publier des modifications sans que tu n'aies
  connaissance des dépots tiers. je me souviens que dans le projet koha,
  on utilisait ce genre d'outils entre développeurs et lorsque tu
  utilises un mua extensible (perso: mutt+vim+fugitive+gitgutter),
  t'as pas besoin d'interface web
* des outils comme gitolite permettent d'acceder en ssh a un clone
  distant et te permettent d'ajouter des notions de droits par branche
  (mais ca n'est deja plus git)

bref ... la premiere fois qu'on m'a parlé de gitlab, j'étais juste
contre: pourquoi imposer aux gens qqchose qui supprime de la souplesse
en plus de ruiner la productivité ... (je suis notamment completement
incapable d'utiliser le systeme d'issues de github ... c'est un
/dev/null pour moi ... alors qu'un message a une liste de diff me va
tres bien).

pourquoi gitlab et pourquoi jupyter sont pour moi une même question:
parceque ces outils, aussi pauvres fonctionellement soient-ils, sont
utilisables par le plus grand nombre au bout de quelques heures. alors
tant pis pour la puissance de git d'un coté et de l'environement unix de
l'autre (de toute facon, ai-je déjà entendu dire, la plupart des
chercheurs sont sous windows ...): gitlab et jupyter sont un outils
commun pour travailler.

donc si les PR ne constituent pas une bonne pratique dans ton cas, les
branches le sont probablement et je te rejoinds sur le fait que de
nombreux projets n'ont besoin que de ça (et qu'en vrai vu qu'un simple
acces ssh suffit pour partager son boulot, un dépot central ne nécessite
pas autre chose qu'une machine accessible en ssh avec un compte commun
et un ~/.ssh/authorized_keys contenant les clefs des développeurs)

> Cela fait bien, hype, la partie web est jolie
> (très important pour les gens) mais est-ce vraiment efficace ?

si tu n'as que des développeurs à l'aise avec leur tooling: la réponse
est évidement non ... mais colle un seul stagiaire dans la boucle et
ta perception du monde va changer.

avant de devenir l'administrateur de la platteforme sympa de strasbourg,
je t'aurais dis que nous avons un devoir de transmission dont nos ainés
(que je remercie par centaines au passage) se sont acquitté avant nous
et dont nous avons été les bénéficiaires. Ce boulot m'a permis de parler
à des gens de tous horizons de la communauté ESR et j'en retiens que
sauf rares exceptions, la notion de poweruser qui nous était chère il
y a 20 ans est complètement obsolète:

* soit les gens se foutent maitriser un outils
* soit ils s'avouent simplement incompétents et incapables de dégager
  du temps

et peu importe que je pense que c'est suboptimal et que ca augmente a
terme le TCO de la recherche:
* les informaticiens sont des serviteurs de l'ESR et nous devons
  intégrer, comprendre et respecter ces chois.
* j'ai peut-être tout simplement tord :)

cette réflexion vaut probablement pour toute organisation de taille
conséquente.

rendez-vous sur une des 2 listes pour la partie purement ESR :)

cordialement,
marc


Reply to: