C'est facile. Tu prends tout ce que tu peux faire avec un systéme distribué de gestion de sources, et tu appliques.
Tout d'abord, on peut imaginer ça pour travailler de maniére offline. Exemple, je suis dans le train, je suis la ou l'accés au net est pourri, ou je veux me concentrer sans être dérangé ( et donc je coupe le réseau ), j'ai mon bts offline pour bosser. Ça marche aussi si le bts est down, ou en maintenance.
Ensuite, pouvoir distribuer le bug tracker, ça permet aussi de faire facilement des forks.
Exemple, je fait une release, je fait un fork du code, pour la branche stable. Pour la liste des bugs reports, c'est pareil, j'ai une branche stable, et une branche dev. avec une gestion différente, et une durée de vie différente.
De même, si on veut forker un projet de maniére plus compléte, on peut. Le mainteneur est con, ne réponds pas, etc, on prends la liste des bugs, et on se barre. La liberté de base appliqué à la gestion de projet, comme pour le code.
Ça permet aussi d'avoir une TODO list personnel. Par exemple, je veut bosser sur tel driver du kernel. Je prends les bugs, je corrige, et je garde liste de ce que j'ai corrigé cote à cote avec le git.
Avoir la liste des bugs chez soi, ça permet de faire des traitements qu'on peut pas forcement faire à cause de la latence réseau, ou parce qu'on a pas les accés complets. De la recherche full texte, des requetes sql, des stats, etc.
Et au final, la problématique de la distribution est déja connu au niveau du code, il suffit de décreter une instance comme étant canonique, tout comme l'arbre git de linus est l'arbre officiel.
Dans le cas de Ubuntu, un bts distribué, ça permet aussi de pousser tout le bug upstream comme on pousse une branche git. Donc les commentaires sont preservés, et on peut imaginer merger les fils de discussions, ( ie, les discussions sur le bts fedora, sur le bts debian, etc ).
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . En réponse au journal Canonical FAIL. Évalué à 3.
Tout d'abord, on peut imaginer ça pour travailler de maniére offline. Exemple, je suis dans le train, je suis la ou l'accés au net est pourri, ou je veux me concentrer sans être dérangé ( et donc je coupe le réseau ), j'ai mon bts offline pour bosser. Ça marche aussi si le bts est down, ou en maintenance.
Ensuite, pouvoir distribuer le bug tracker, ça permet aussi de faire facilement des forks.
Exemple, je fait une release, je fait un fork du code, pour la branche stable. Pour la liste des bugs reports, c'est pareil, j'ai une branche stable, et une branche dev. avec une gestion différente, et une durée de vie différente.
De même, si on veut forker un projet de maniére plus compléte, on peut. Le mainteneur est con, ne réponds pas, etc, on prends la liste des bugs, et on se barre. La liberté de base appliqué à la gestion de projet, comme pour le code.
Ça permet aussi d'avoir une TODO list personnel. Par exemple, je veut bosser sur tel driver du kernel. Je prends les bugs, je corrige, et je garde liste de ce que j'ai corrigé cote à cote avec le git.
Avoir la liste des bugs chez soi, ça permet de faire des traitements qu'on peut pas forcement faire à cause de la latence réseau, ou parce qu'on a pas les accés complets. De la recherche full texte, des requetes sql, des stats, etc.
Et au final, la problématique de la distribution est déja connu au niveau du code, il suffit de décreter une instance comme étant canonique, tout comme l'arbre git de linus est l'arbre officiel.
Dans le cas de Ubuntu, un bts distribué, ça permet aussi de pousser tout le bug upstream comme on pousse une branche git. Donc les commentaires sont preservés, et on peut imaginer merger les fils de discussions, ( ie, les discussions sur le bts fedora, sur le bts debian, etc ).