« Le danger Github »
▻http://carlchenet.com/2016/01/22/le-danger-github
« Finalement, l’utilisation de Github suit cette tendance de massification de l’utilisation d’Internet. Comme aujourd’hui les utilisateurs d’Internet sont aspirés dans des réseaux sociaux massivement centralisés comme Facebook et Twitter, le monde des développeurs suit logiquement cette tendance avec Github. »
#Github #GAFA #git #logiciel_libre
la question du rapport de bug est effectivement central, et c’est ce qui fait que je ne met plus de nouveau projet sur github (en attendant de migrer les anciens !)
@lluc Gitlab est aussi une solution centralisée, sauf erreur. Il faut donc trouver un hébergement stable. Et cela inclut un système de gestion de bogues ?
En autohébergement, un serveur git ou svn, selon les goûts, et un mantis + une ferme de mediawiki, c’est tout de même très éfficient... + un openldap évidemment au milieu... En fait, pour SVN, ce qui manque à mon goût, c’est l’outil d’administration pour la gestion des droits sur les référentiels...
@stephane Bah Gitlab c’est centralisé dans le sens où c’est pas un logiciel avec une base décentralisée, ou P2P ou etc. Mais c’est bien un logiciel libre que chacun peut installer pour soi. Donc c’est pas un silo comme les GAFA quoi.
►https://gogs.io - « a painless self-hosted Git service »... Performant, libre et très simple à déployer.
@stephane Généralement on utilise les « issues » que l’on qualifier avec système de « tags »
Sinon Fossil peut être intéressant : c’est un gestionnaire de version décentralisé qui prend en compte les sources, un wiki et les issues de la même manière : quand tu récupères le code tu as aussi le reste, et quand tu modifie une issue tu le le fais localement puis tu la pousses sur le maitre comme dans du code. C’est utilisé et développé par SQLite et donc le stockage est fait dans SQLite.
▻http://fossil-scm.org/index.html/doc/trunk/www/index.wiki
@lluc C’est documenté où ? Je n’ai aucun doute que des geeks pointus peuvent y arriver mais si c’est comme cela qu’on espère concurrencer Github, c’est mal barré.
Le code source libre (MIT) :
▻https://gitlab.com/gitlab-org/gitlab-ce
Un exemple du système de tickets sur leur propre projet (que personnellement je trouve très clair et lisible, assez proche de chez Github) :
►https://gitlab.com/gitlab-org/gitlab-ce/issues
La documentation :
▻https://about.gitlab.com/documentation
Et notamment la doc du logiciel lui-même :
▻http://doc.gitlab.com/ce
@stephane je n’ai pas vocation, avec mes petits bras musclés, à concurrencer Github ...
Un début de réponse ici :
▻https://about.gitlab.com/features
►https://gitlab.com/gitlab-org/gitlab-ce/issues
▻https://git-scm.com/book/fr/v2/Git-sur-le-serveur-GitLab
▻http://framacode.org/gitlab.php
#git #gitlab
Aucune des alternatives ne s’attaque à la motivation essentielle de la centralisation : les aspects sociaux et découvrables. Le reste, c’est du bricolage.
Sans ça, GitHub reste et restera une meilleure solution. À moins d’une forte motivation idéologique, il n’y a aucune raison pragmatique de changer.
@robin Met le doigt là où ça fait mal... La découvrabilité (discoverability) sociale décentralisée est un défi clé pour le libre. Un projet bien établi peut s’héberger n’importe où et y attirer les badauds alors que le foisonnement anarchique des outils émergents se nourrit beaucoup de la proximité sociale... Tout comme un auteur célèbre peut poster sur son propre blog et attendre que les lecteurs déboulent alors que le reste du monde doit faire la tournée des bars pour mettre l’article sous le nez de ses potes.
@fil on en avait un peu parlé sur d’autres messages
▻http://seenthis.net/messages/218296
▻http://seenthis.net/messages/237028
►https://github.com/ginatrapani/todo.txt-cli/wiki/The-Todo.txt-Format
@archiloque c’est intéressant fossil !
Voir l’article suivant sur ses qualités et défauts :
▻http://www.omiyagames.com/farewell-fossil-version-control
Mentionne une alternative (morte ?) qui inclut aussi les tickets dans le versionnement : veracity
Sur wikipedia on appelle ça Distributed bug tracking systems, et y’a pas foule :
▻https://en.m.wikipedia.org/wiki/Category:Distributed_bug_tracking_systems
Une alternative basée sur git :
▻https://github.com/glogiotatidis/gitissius/blob/master/README.org
Et finalement : peut être que ce n’est pas une bonne idée
J’ai utilisé ▻http://gitblit.com pendant un certain temps. Ça demande du temps d’exploitation mais cette solution propose une gestion de tickets intégrée au dépôt et un système d’annotations un peu pauvre en guise de wiki. Fossil est peut-être plus riche
pure Java stack
pure Java stack
pure Java stack
Coïncidence, l’#IETF commence à réfléchir à son usage (intensif) de Github ▻https://mailarchive.ietf.org/arch/msg/ietf-announce/YI7AA1iXozBG1BGRpyRt7JVIqSQ
@Fil Bof, avoir une copie du dépôt Github est la partie la plus facile (car Git est réparti). C’est le problème des rapports de bogue qui est pénible.