http://gogs.io

Regarde peut-être du côté de ►https://gitea.io ? C’est ce que @azerttyu a choisi d’utiliser dans le futur pour #spip :)

en version courte #gogs est en fin de vie. Le fork #gitea est lui maintenu et en cours de vie actif.

des infos sur cette « fin de vie » de gogs ? ▻https://github.com/gogits/gogs me semble tout à fait actif...

...renseignements pris, le développement de gogs est « bloqué » entre les mains d’un seul dev, pas très ouvert aux suggestions !
=> zou ! on a migré sous ►https://gitea.io (fork de gogs) : la migration à pris 3 minutes et cet outil semble très bien :)

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 !)

“Think different, think Gitlab” ... ;-)

@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 ?

il n’y a pas moyen de gérer les issues sous forme d’un repo git ? (voire d’une branche du projet principal si on est aventureux). #bizarre

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

▻http://veracity-scm.com

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

▻http://programmers.stackexchange.com/a/194131

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

ça éventuellement : ▻https://blog.sciunto.org/posts/gitbackup ?

@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.

#git #go #github