« 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.
Je rêve d’un système de gestion des tickets a) auto-hébergé, b) simple d’utilisation (pour organisation interne du travail d’une équipe, pas pour des développeurs), c) simple de conception (solution du genre de celles proposées dans le fil ►http://seenthis.net/messages/150466) et d) accessible depuis partout e) avec éventuellement authentification.
Les raisons sont les suivantes :
– a) contrôle des données, utilisable en local/intranet/internet, reproductible
– b) c’est tellement efficace, les tickets, pourquoi le réserver au développement logiciel ?
– c) facile à maintenir, exporter/importer, archiver
– d) les avantages du web
– e) pour le contenu interne (mais binaire : connecté = accès à tout le contenu, non-connecté = rien - facile à gérer au niveau du serveur web)
J’aimerais que les tickets permettent :
– 1. un ticket par tâche, avec commentaires successifs (un ticket, quoi)
– 2. un statut (ouvert/fermé, ou en cours/terminé)
– 3. des labels/mots-clés pour indexer et regrouper les tickets
– 4. assigner le ticket à une personne
– 5. s’abonner à un ticket (pour recevoir des notifications de mise à jour) ou abonner qqn d’autre
– 6. fixer une date limite (voire des dates limites)
– 7. envoyer des alertes automatiques par mail 15 jours avant la date limite
Pour être plus simple, mieux vaut diviser le problème. On peut donc imaginer :
– un système de forum simple comme #seenthis ou #nononsense : permet 1, 3 et 5.
– pour 2., peut être peut-on se servir de mots clés : #fermé, #réouvert, etc. et le plus récent est celui qui vaut.
– pour 3., peut être peut-on aussi se servir de mots-clés : resp:@severo (id. le plus récent indique le/la responsable en cours)
– pour 5. on peut imaginer abonner qqn·e d’autre simplement en le/la citant : @severo - implique qu’un script analyse tous les messages et ajoute la personne citée comme « abonné » au ticket
– pour 6., on peut imaginer simplement mettre une URL vers un événement dans un calendrier partagé (implique de mettre en place un système de calendrier partagé - voir #baikal par exemple). Autre solution : un mot-clé : due:2014-01-17
– pour 7. il faudrait trouver un programme qui se branche sur le calendrier partagé, et qui envoie les alertes (ça doit exister) - reste à définir le délai d’envoi par rapport à la date limite
Je suis preneur de tout conseil ou commentaire !
peut-être qu’avec un peu d’amelioration du plugin ticket de #SPIP cela pourrait se faire ? il y a je pense que le 6/7 qui manque, à ma connaissance
Oui c’est une possibilité, même si le plugin Tickets est clairement fait pour la gestion de bugs. On pourrait rendre optionnels certains champs (priorité, type de bug) et permettre d’ajouter d’autres champs, comme les mots-clés par exemple.
Pour les dates, j’ai l’impression qu’il faut plutôt se brancher sur un système à part.
En fait, le plugin Tickets est sûrement une bonne idée pour la partie serveur. Mais au delà, j’aimerais travailler sur la partie « client ». Pour l’affichage, un format auto-descriptif du modèle de données, c’est à dire que l’HTML du ticket suffise à l’importer dans un autre système. Il faudrait donc que toutes les données soient présentes sur le texte du commentaire. Ce qui irait dans le sens de l’import export en format mail que propose @fil :
►http://seenthis.net/messages/216935
Une mise à jour du ticket, où on changerait la personne assignée, le statut, on ajouterait un mot-clé et on écrirait un commentaire, pourrait donc être affichée de la manière suivante
Un commentaire
resp:@severo #todo statut:#open #conception
C’est surtout une question de squelette pour l’affichage du ticket.
Et si une syntaxe est définie, on pourrait aussi publier à partir de la seule plage de texte. Comme on ferme habituellement des commits avec « fixes #1234 », on pourrait ainsi changer de responsable en écrivant « resp:@maieul » dans le texte, au lieu d’utiliser un formulaire. Ce commentaire pourrait être envoyé par mail, entré sur le site, etc.
En fait, pour être précis, je veux mettre les infos du ticket dans le texte, en plain/text, pas dans le HTML.
Ce qui n’empêche pas de redonder avec des microdata, mais c’est une autre histoire.
Pour « tout faire en texte », c’est assez fluide et compréhensible pour l’ajout, comme ce que fait seenthis (l’ajout de tags dans les commentaires est pris en compte dans la recherche de seens), mais si tu veux enlever des infos (tag, date, ou autre), ce n’est plus aussi simple pour les néophytes. Si on doit rajouter une syntaxe en plus genre « -#truc » ou « -resp :@truc »… ça commence à faire beaucoup de ptits caractères partout, et ça me parait assez geek.
Vu que tu parles de tickets, et donc de todolist finalement, et en plus de texte, je t’invite aussi à lire les discussions qu’il y a eu autour du plugin « Todo » pour SPIP, dont le but était justement de générer à partir de texte brut uniquement ET que ce texte brut soit aussi lisible tel quel même avant transformation.
▻http://contrib.spip.net/Todo#forum462129
Tu trouveras notamment des liens vers des tentatives de formats « standardisés » de todolist en texte brut. Notamment le format TodoTxt : ►https://github.com/ginatrapani/todo.txt-cli/wiki/The-Todo.txt-Format
La version SPIP en est inspirée mais n’est pas pareille.
Bien sûr, que ce soit TodoTxt ou celui de SPIP, ce sont des trucs pour une seule personne. Mais ça peut quand même donner des idées pour un système multi-utilisateurs avec commentaires.
Ah pour le Todo de SPIP (que j’ai commencé et qu’Éric a continué), il y aussi cet article de conception :
▻http://blog.smellup.net/spip.php?article72
oui j’ai lu attentivement ces échanges sur Todo, c’est exactement dans cette voie là que j’aimerais travailler.
Une autre précision, c’est surtout l’usage qui m’intéresse. J’aimerais tester avec un site qui ne fasse que ça, et qui soit facile à utiliser pour des gens qui n’ont jamais touché à des tickets.
Tickets versionnés comme le code, de manière descentralisée :