Enfin, tout comme les dvcs actuelles, rien ne t'oblige à t'en servir de maniére decentralisé, donc la dichotomie que tu mets en place est totalement fausse. Si tu veux garder une façon centralisé de l'utiliser, tu peux, c'est juste que maintenant, les gens ne sont plus forcer de le faire. Si tu lit bien le site de SD, tu va voir qu'il est capable d'importer depuis trac, depuis redmine, etc.
L'exemple d'un bug qui est corrigé par plusieurs changeset est justement un exemple du probléme. Dans bugzilla, un bug affecte 1 version uniquement. Si je prends l'exemple de Mandriva, je trouve un probléme dans un paquet stable, le correctif doit passer la QA de façon formel, mais pas dans la version de dev. Le bug est donc dans un état sémi résolu ( corrigé dans une version et pas dans une autre ), et c'est un peu moche. Trac, mantis, et d'autres ont aussi ce modéle ( 1 bug == 1 version ).
Launchpad n'a pas ce modéle, mais du coup, comme il y a un fil de discussion par bug, on sait pas qui parle de quoi. Quand quelqu'un dit "le bug est corrigé pour moi", il faut qu'il précise dans quel version etc. Et donc ça entraine des risques d'erreurs.
Avec une instance forké d'un bug tracker par produit, c'est bien plus simple. On peut même imaginer qu'un revendeur d'un produit gére son propre bug tracker, ce genre de choses.
Les projets basés sur Ubuntu pourrait ainsi remonter les bugs plus facilement, tout comme les kernels hackers font passer leur patch d'un arbre à un autre aprés validation.
Tu parles de prendre les bugs pour debugger sans prevenir, je sais pas sur quel projet tu bosses, mais sur tout les projets ou je bosse, les gens corrigent sans prévenir, car les risques de collisions sont faibles. Quand il y a 5 personnes sur un projet, les gens vont rarement tous au même moment, sur le même truc. Et c'est bien plus lourd de prevenir que de corriger les rares problémes quand on le fait pas.
Et le probléme existe de toute façon deja avec un bts classique, donc je ne voit pas en quoi c'est génant ( à ce que je sache, personne ne va dire sérieusement "ah mais non, corriger le code sans le dire sur le bugzilla, ça va poser des problémes, faut empecher que ça arrive en forcant techniquement ça".
Quand à l'histoire des forks hostiles, rien ne dit que les gens doivent communiquer, le truc de base, c'est juste de pouvoir avoir une copie.
Pour l'histoire des bugs report, tu semble juste voir le coté "j'exporte les bugs chez les autres". Mais ça peut aussi être l'inverse, du style "j'importe le bug depuis les bts des distributions".
Et un point que j'ai oublié, c'est qu'on parle de web 2.0, de données captives, etc. Mais ce genre d'outil, c'est exactement dans l'optique des mouvements comme le DAta Liberation Front ( http://www.dataliberation.org/ ), ou finalement, si tu n'es pas content de tel ou tel presta, tu changes. Si tu veux faire des modifs à l'interface juste pour toi, tu le fait.
Peut être que ça va pas prendre, aprés tout, TLA n'a pas pris tout de suite, et n'aurait trés bien pu ne pas prendre. L'idée de dvcs, c'est que la théorisation de ce que foit la plupart des gens quand ils modifient dans leur coin un document.
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . En réponse au journal Canonical FAIL. Évalué à 2.
http://syncwith.us/sd/using . Et l'auteur va en parler lors des RMLLs
et y en a d'autres, cf http://lwn.net/Articles/281849/
Enfin, tout comme les dvcs actuelles, rien ne t'oblige à t'en servir de maniére decentralisé, donc la dichotomie que tu mets en place est totalement fausse. Si tu veux garder une façon centralisé de l'utiliser, tu peux, c'est juste que maintenant, les gens ne sont plus forcer de le faire. Si tu lit bien le site de SD, tu va voir qu'il est capable d'importer depuis trac, depuis redmine, etc.
L'exemple d'un bug qui est corrigé par plusieurs changeset est justement un exemple du probléme. Dans bugzilla, un bug affecte 1 version uniquement. Si je prends l'exemple de Mandriva, je trouve un probléme dans un paquet stable, le correctif doit passer la QA de façon formel, mais pas dans la version de dev. Le bug est donc dans un état sémi résolu ( corrigé dans une version et pas dans une autre ), et c'est un peu moche. Trac, mantis, et d'autres ont aussi ce modéle ( 1 bug == 1 version ).
Launchpad n'a pas ce modéle, mais du coup, comme il y a un fil de discussion par bug, on sait pas qui parle de quoi. Quand quelqu'un dit "le bug est corrigé pour moi", il faut qu'il précise dans quel version etc. Et donc ça entraine des risques d'erreurs.
Avec une instance forké d'un bug tracker par produit, c'est bien plus simple. On peut même imaginer qu'un revendeur d'un produit gére son propre bug tracker, ce genre de choses.
Les projets basés sur Ubuntu pourrait ainsi remonter les bugs plus facilement, tout comme les kernels hackers font passer leur patch d'un arbre à un autre aprés validation.
Tu parles de prendre les bugs pour debugger sans prevenir, je sais pas sur quel projet tu bosses, mais sur tout les projets ou je bosse, les gens corrigent sans prévenir, car les risques de collisions sont faibles. Quand il y a 5 personnes sur un projet, les gens vont rarement tous au même moment, sur le même truc. Et c'est bien plus lourd de prevenir que de corriger les rares problémes quand on le fait pas.
Et le probléme existe de toute façon deja avec un bts classique, donc je ne voit pas en quoi c'est génant ( à ce que je sache, personne ne va dire sérieusement "ah mais non, corriger le code sans le dire sur le bugzilla, ça va poser des problémes, faut empecher que ça arrive en forcant techniquement ça".
Quand à l'histoire des forks hostiles, rien ne dit que les gens doivent communiquer, le truc de base, c'est juste de pouvoir avoir une copie.
Pour l'histoire des bugs report, tu semble juste voir le coté "j'exporte les bugs chez les autres". Mais ça peut aussi être l'inverse, du style "j'importe le bug depuis les bts des distributions".
Et un point que j'ai oublié, c'est qu'on parle de web 2.0, de données captives, etc. Mais ce genre d'outil, c'est exactement dans l'optique des mouvements comme le DAta Liberation Front ( http://www.dataliberation.org/ ), ou finalement, si tu n'es pas content de tel ou tel presta, tu changes. Si tu veux faire des modifs à l'interface juste pour toi, tu le fait.
Peut être que ça va pas prendre, aprés tout, TLA n'a pas pris tout de suite, et n'aurait trés bien pu ne pas prendre. L'idée de dvcs, c'est que la théorisation de ce que foit la plupart des gens quand ils modifient dans leur coin un document.
Et j'aurais tendance à dire qu'au dela des bts et du code, il y a aussi une place pour un wiki distribué ( comme http://ikiwiki.info/tips/distributed_wikis/ , ou http://wiki.laptop.org/go/MikMik ).