Par exemple si sur un projet je ne veux que les étiquettes "WIP", "v1.2.3" et "DEV" ?
L'idée fondamentale de l'ergonomie de git-bug, c'est de fonctionner de base avec zéro configuration, et un ensemble de règle de base raisonnable qu'il sera possible d'ajuster pour des besoins particuliers. Pour les étiquettes, l'utilisateur est libre de saisir ce qu'il veut et git-bug propose dans son interface de sélectionner facilement une étiquettes existante. Dans le futur il sera possible d'ajouter des contraintes et de le limiter à un ensemble particulier.
Mais tu va me dire, comment faire pour faire respecter des règles dans un système distribué ? Au final c'est assez simple. A la manière d'une blockchain, chaque client git-bug vérifie les nouveaux blocs de données et ignore simplement ceux qui ne respectent pas les règles. Tu peux librement faire ce que tu veux avec tes données locales, mais personne ne va les accepter.
Et si je ne veux autoriser que toto et tata à modifier l'état du bug ? Est-ce qu'on peut modifier les commentaires des autres ?
Actuellement, il n'y a pas de gestion forte des identités ni de gestion de droit. N'importe qui avec les droits d'écriture sur le dépôt peut créer, modifier ou éditer un bug et ses commentaires. Mais comme expliqué dans mon journal, c'est la suite du programme pour moi: avoir des profiles utilisateurs distribués avec les données des bugs, signer les opérations d'éditions et avoir un système de règles pour déterminer qui a le droit de faire quoi.
Est-ce que ça aurait du sens d'étendre pour des merge requests ? Git permet bien entendu d'utiliser une branche pour ça, l'intérêt serait de permettre de commenter le code avant de pouvoir réellement merger la branche.
Oui c'est tout à fait possible, mais largement en dehors de la portée du projet actuellement. Si il y a des volontaires, pas de soucis ;-)
Ça se rapproche de ce que fait Fossil si je ne m'abuse
Correct
Comment ça marche pour créer un importeur/exporteur ? Ça a l'air d'être du JSON, y'a une API pour récupérer directement les opérations assemblées et le ticket final ? Je travaille sur un gestionnaire de tickets et de merge-requests décentralisé (basé sur XMPP), et ça m'intéresserait de pouvoir faire les tickets en local quand internet n'est pas dispo, et de pouvoir synchroniser après coup.
Un importeur va simplement récupérer les informations depuis l'API du bug tracker distant et utiliser les fonctions de haut niveau de git-bug (créer un bug, ajouter un commentaire) pour répliquer les changements. Par exemple, l'importeur Github interroge l'API GraphQL de Github qui expose l'historique des éditions, compare avec les données existantes en local, insère les nouveaux changements tout en les taguant avec les identifiants unique Github pour pouvoir faire le lien pendant un futur import.
Un exporteur va faire l'inverse, et répliquer les changements locaux non présent sur le tracker distant. Bien sûr, seul les changements dont tu es l'auteur pourront être répliqués, à moins de construire une vrai passerelle qui a des jetons d'API Github pour tout les auteurs, mais c'est pas au programme.
[^] # Re: Permissions ? Merge-requests ? import/export ?
Posté par MichaelMure . En réponse au journal git-bug: un bug tracker distribué intégré dans git. Évalué à 3. Dernière modification le 06 décembre 2018 à 11:33.
L'idée fondamentale de l'ergonomie de git-bug, c'est de fonctionner de base avec zéro configuration, et un ensemble de règle de base raisonnable qu'il sera possible d'ajuster pour des besoins particuliers. Pour les étiquettes, l'utilisateur est libre de saisir ce qu'il veut et git-bug propose dans son interface de sélectionner facilement une étiquettes existante. Dans le futur il sera possible d'ajouter des contraintes et de le limiter à un ensemble particulier.
Mais tu va me dire, comment faire pour faire respecter des règles dans un système distribué ? Au final c'est assez simple. A la manière d'une blockchain, chaque client git-bug vérifie les nouveaux blocs de données et ignore simplement ceux qui ne respectent pas les règles. Tu peux librement faire ce que tu veux avec tes données locales, mais personne ne va les accepter.
Actuellement, il n'y a pas de gestion forte des identités ni de gestion de droit. N'importe qui avec les droits d'écriture sur le dépôt peut créer, modifier ou éditer un bug et ses commentaires. Mais comme expliqué dans mon journal, c'est la suite du programme pour moi: avoir des profiles utilisateurs distribués avec les données des bugs, signer les opérations d'éditions et avoir un système de règles pour déterminer qui a le droit de faire quoi.
Oui c'est tout à fait possible, mais largement en dehors de la portée du projet actuellement. Si il y a des volontaires, pas de soucis ;-)
Correct
Un importeur va simplement récupérer les informations depuis l'API du bug tracker distant et utiliser les fonctions de haut niveau de git-bug (créer un bug, ajouter un commentaire) pour répliquer les changements. Par exemple, l'importeur Github interroge l'API GraphQL de Github qui expose l'historique des éditions, compare avec les données existantes en local, insère les nouveaux changements tout en les taguant avec les identifiants unique Github pour pouvoir faire le lien pendant un futur import.
Un exporteur va faire l'inverse, et répliquer les changements locaux non présent sur le tracker distant. Bien sûr, seul les changements dont tu es l'auteur pourront être répliqués, à moins de construire une vrai passerelle qui a des jetons d'API Github pour tout les auteurs, mais c'est pas au programme.
Merci :)