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

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



Bonjour,

Le 11/06/18 à 20:19, Marc Chantreux <mc@unistra.fr> a écrit :
MC> > C'est parfait si les portails se causent (chacun référence les
MC> > projets de tous les autres, tu peux faire une recherche sur l'un
MC> > d'eux parmi ses projets seulement ou parmi tous les projets de tous
MC> > les portails).  
MC> 
MC> s/C'est/Ce serait/
MC> 
MC> il n'y a a ma connaissance pas de projet de ce genre et il faudrait pe
MC> spécifier la facon de fonctionner d'un tel dispositif.

J'imaginais des gitlabs connectés les uns aux autres, par ex chacun
avertissant les autres sur un hook git post-push en envoyant
nom / description / auteur|éditeur / README(.md|.txt)? s'il existe
si l'un d'eux à changé.

Un peu à la façon des moissonneurs OAI…
(voire complètement, il doit y avoir moyen de se mettre d'accord sur la
façon de générer automatiquement une fiche minimale sur chaque projet
d'après son contenu, et utiliser le protocole OAI pour la diffusion).

MC> > MC> infras mais que les depots publics soient mirrorés chez des tiers
MC> > MC> libres et que ce service leur soit financé ...  
MC> > Oui, le pb reste de financer avec de l'argent public une infra
MC> > hébergeant tout code libre,  
MC> 
MC> hmm ... (encore une fois: *mon* point de vue et je ne connais pas la
MC> position officielle de mon employeur sur le sujet): quand je vois
MC> comment l'état passe du temps et de l'argent a financer les gourmettes
MC> de la french tech ... je crois que ce n'est pas une question de moyen
MC> mais de priorité. je n'y vois pas de capitalisme de connivence mais
MC> 
MC> * y a une véritable et sincère volonté de nos dirigeants de soutenir
MC>   l'inovation
MC> * l'inovation est un processus lent qui n'est pas compatible avec des
MC>   agendas politiques ou commerciaux
MC> * les décideurs sont issus de milieux ou la culture de la compta et
MC>   de la rationalisation domine. il est difficile de leur faire entendre
MC>   que l'entropie et l'erreur sont les 2 mamelles de l'inovation et qu'on
MC>   peut s'enthousiasmer pour la résolution un problème sans vouloir
MC> monter une statup.

Certes, mais on devrait arriver à leur expliquer que toutes les startups
qui innovent dans le numérique peuvent le faire grace à un vivier de code
libre, et de codeurs pour le produire.

En mettant à disposition de tout codeur une forge logicielle pour exposer
son code, voire l'améliorer avec son voisin intéressé, on augmente les deux
viviers à très peu de frais !

C'est donc un service public qui servirait d'abord aux startup du
numérique, y'a qqun dans la salle pour expliquer ça à nos chers
décideurs ?
;-)

MC> si le denier public m'était conté, des projets comme le programme LTS de
MC> debian ou gimp aurait un ETP permanent
MC> 
MC> * financé par l'état
MC> * désigné par la communauté

Et ce serait très rentable…

Lorsque IBM a abandonné "IBM http server" pour le remplacer par apache
et payer des employés IBM à plein temps sur apache, c'était pas par
philanthropie, simplement pour augmenter leur rentabilité !

MC> c'est une goute d'eau dans le budget de l'état mais ca des boosts
MC> conséquents pour ces projets.

Qui permettrait également de les utiliser davantage au sein de l'état et
faire encore des économies (pas tellement l'économie de la licence, plutôt
l'économie liée au fait de mieux maîtriser le produit et tout le cycle
déploiement / exploitation / maintenance).

MC> > gitolite est simple et très efficace, "juste un git" avec des droits
MC> > fins simple à configurer, donc plutôt fiable (peu de risque d'ouvrir
MC> > une porte sans s'en rendre compte).  
MC> 
MC> "juste un git" serait ce que je fais actuellement pour mes depots
MC> privés: juste déclarer un remote via ssh:
MC> 
MC> soit dans mon .ssh/config une entrée du genre
MC> 
MC>     host hq
MC>     hostname hq.example.com
MC>     username mex
MC> 
MC> et mon depot présent dans ~/src/domination dont je veux créer un
MC> "serveur" sur hq:
MC> 
MC>     cd ~/src/domination
MC>     g remote add hq hq:domination
MC>     scp -r .git hq:domination
MC>     g getch hq
MC> 
MC> et voilà :) (y'a peut-être plus académique que scp pour créer le depot
MC> bare distant: si un expert sait comment et pourquoi ca m'intéresse)

J'utilise gitolite
- ajout du dépôt dans la conf gitolite, commit & push de cette conf
- clone du dépôt vide qu'il vient de créér

Avec git only, ta façon de faire me semble académique (le .git de
ton repo local est un bare repo, donc le copier sur le serveur crée un bare
repo, tu peux juste le nommer domination.git pour rendre plus explicite que
c'est un bare repo). Sinon, dans le cas de création d'un repo qui n'existe
pas encore chez toi, tu peux faire l'init du dépôt bare sur le serveur puis
le cloner, mais ça revient au même.

  ssh hq "git init --bare domination.git"
  cd ~/src
  git clone hq:domination.gitcd 
  cd domination

-- 
Daniel

Cette femme qui prétend que je suis dyslexique,
jamais je ne l'ai interviewée !
Georges W. Bush (15/09/2000)


Reply to: