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.
Si je suis en offline et que je prend un bug pour le debugguer sans prévenir, rien ne garantit qu'un autre ne fera pas la même chose
en même temps. Travail ingrat et redondant.
A la limite pour mettre à jour le statut des demandes qui me sont affectées avant la déconnexion ou pour les instruire ok.
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.
Sauf qu'en général on déclare un seul un bug report qui donnne lieu à un changement ou plusieurs changements disjoints et c'est ce(s) changement ( changeset) qu'on répercute sur chaque branche. Ces changements référencent un seul et même défaut.
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.
Combien de projets sont vraiment forkés ?
Parler, convaincre , faire des compromis c'est pas mal aussi.
Ensuite imagine qu'une personne poste un bug sur ton fork "hostile".
Comme vous ne vous parlez plus, chacun le corrigera de son coté avec des conflits de merge inutiles ou chacun attendra que l'autre ait pris en compte le bug pour récupérer la correction en pull. Je demande à voir.
Ç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.
Y'a Mylin pour ca. Allez admettons !
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.
Au prix d'une plus grande complexité.
Avec la gestion de conf on y trouve son compte, mais là le jeu en vaut t'il la chandelle ?
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 ).
Avec le risque que cette façon de déléguer le taf soit accueillie fraichement comme sur le journal.
Dsl j'ai du mal à accrocher.
Dans les faits, quand ca plante quand tu cliques ici, tu postes ca sur Ubuntu. Le mainteneur Ubuntu (je sais c'est pas un bon exemple) qualifie le bug et instruit un nouveau "bug request" chez tous les projets qui sont concernés si le bug dépend de plusieurs pbs corrélés.Il instruit sa propre demande comme dépendante de la résolution d'autres et patche chez lui ce qui le concerne, si nécessaire.
Pas besoin de réplication de bug request pour tout ça.
Mais je ne demande qu'à être convaincu et j'espère que tu nous posteras une jolie dépêche quand ca sortira.
[^] # Re: Et la timeline ?
Posté par El Titi . En réponse au journal Canonical FAIL. Évalué à 1.
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.
Si je suis en offline et que je prend un bug pour le debugguer sans prévenir, rien ne garantit qu'un autre ne fera pas la même chose
en même temps. Travail ingrat et redondant.
A la limite pour mettre à jour le statut des demandes qui me sont affectées avant la déconnexion ou pour les instruire ok.
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.
Sauf qu'en général on déclare un seul un bug report qui donnne lieu à un changement ou plusieurs changements disjoints et c'est ce(s) changement ( changeset) qu'on répercute sur chaque branche. Ces changements référencent un seul et même défaut.
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.
Combien de projets sont vraiment forkés ?
Parler, convaincre , faire des compromis c'est pas mal aussi.
Ensuite imagine qu'une personne poste un bug sur ton fork "hostile".
Comme vous ne vous parlez plus, chacun le corrigera de son coté avec des conflits de merge inutiles ou chacun attendra que l'autre ait pris en compte le bug pour récupérer la correction en pull. Je demande à voir.
Ç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.
Y'a Mylin pour ca. Allez admettons !
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.
Au prix d'une plus grande complexité.
Avec la gestion de conf on y trouve son compte, mais là le jeu en vaut t'il la chandelle ?
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 ).
Avec le risque que cette façon de déléguer le taf soit accueillie fraichement comme sur le journal.
Dsl j'ai du mal à accrocher.
Dans les faits, quand ca plante quand tu cliques ici, tu postes ca sur Ubuntu. Le mainteneur Ubuntu (je sais c'est pas un bon exemple) qualifie le bug et instruit un nouveau "bug request" chez tous les projets qui sont concernés si le bug dépend de plusieurs pbs corrélés.Il instruit sa propre demande comme dépendante de la résolution d'autres et patche chez lui ce qui le concerne, si nécessaire.
Pas besoin de réplication de bug request pour tout ça.
Mais je ne demande qu'à être convaincu et j'espère que tu nous posteras une jolie dépêche quand ca sortira.