On Sun, Jun 10, 2007 at 20:55:21 +1200, Martin Langhoff wrote: > On 6/10/07, Jan Hudec <bulb@xxxxxx> wrote: > >I don't know about any *distributed* bug tracker, which is the point here. > > As an end user, I suspect I _don't_ want to have to report a bug in a > distributed bug tracker ;-) As an end user, you would just post the bug report to a mailing list. The bug tracker would take care of adding it to the "master repository". > In that space, the Malone guys (canonical) > have their fingers on one of the most serious issues, and perhaps it's > interesting to see what they've done there. It's really useful, even > if I don't think I want to have to maintain it :-/ I don't think they even have a mail interface. You have to register to post a bug, just as with most of the crappy web-based bug trackers out there. They have some nice integration with bazaar, but AFAIK the branch has to be mirrored on launchpad, to which the whole thing is really tied too much. Also I can find download link anywhere there, nor anywhere they'd state it's license (and from what I heard it is NOT open-source). So while they might have some nice features, it's not that suitable for general public. > >We have several distributed version control tools, but no other distributed > >tools for the other tasks in configuration management. > > Bugtrackers are co-owned by developers, users and (where they exist) > project managers. I agree that branches don't make that much sense in bug trackers. Except in rare cases like when the project is forked or such. The bug tracker is there so the people stay in sync. However I think trying to design a distributed bug tracker can bring useful insignts into the problems involved. > > - The web interface is usually not a good match for the problem. Email > > interface is better in many respects, but it still does not cut it. > > I agree. I love/hate debbugs too. ... there's a related issue of what the mail user agents can do. If my mail client was really good as personal task manager, mail-based bug trackers would work quite well. But the MUAs are not all that good. > > - You can't really use the ability of version control to work > > disconnected, > > when you don't also have the bug information. > > A cache fixes the reading part - see my other post, and imagine being > able to have a local sqlite cache of the BT key data indexed by > referenced SHA1, showing up with your commits in gitk. > > The write part is solved (in part) by committing to git the fix -- if > you mentionm the bug ID, the central BT will pick it up when your > commit appears in the branches/repos that the BT can see. > > For "just adding a comment", the write part is solved by the "email" > interface, like with debbugs. > > > - Distributed version control is designed to decrease the workload of the > > central maintainer(s) while keeping him in control. But with centralized > > And to provide a single place for users to report a problem and track > its status. Just like there is the "master" repository, there would be the "master" bug tracker. > >If it uses git as it's database, which it probably will, > > Well - hmmm. Git's database is great at tracking _content identity_. > But a bug's content identity (description+comments+status) changes all > the time. I don't think it's naturally a good match. > > Perhaps it makes sense to mix git's storage model with something else...? You are right here. Git can be used to store the data bits, but they need to be glued together somehow (with tags or something). So we can as well store them in some other kind of database and it might be even better. > >Yes. But for many people current bug tracking tools do NOT work 99%. > > Hmmm. I agree in that "does not work disconnected" is a big issue with > web tools, but debbugs works disconnected, and is good. Git's > bugtracker (git@vger) works disconnected too ;-) And googlegears might > help the rest of us. Is there any other problem with current BTs? Well, there is no BT that would satisfy all the points above ;-). Debbugs has a good email interface, but it's a huge beast and tied with the Debian archive logic quite a lot. The rest -- except maybe gnats (I'll have to look at that -- it looks interesting) -- does not seem to have much sensible email support. Following up on the note about MUAs above, one interesting idea to create a bug tracker (that would not be git specific nor actually use git for anything) would be to: - Create a mailing list bot, that would watch for bug reports either on dedicated address or by watching for [BUG] or something, and replies to them. - Export the bug database via read-only imap (or pop3 or webdav). There are already tools to create local cache for such protocols, which would resolve the disconnected issue and give good query speed, because the data would be local. - The server would make sure that all the messages applying to a particular issue are correctly linked with In-Reply-To: headers to form a single thread. - Status of the bug could be expressed with mailbox it is in (backwards compatible way) or some kind of tags (which would need to be supported by the mail client -- I really think it's about time for something like that). - Other metainformation about the bug could be added as a special message inserted at the begining of the thread, or added into the first message - Than support for todo management could be improved in some mail clients. It is not precondition for this kind of bug tracking to be useful and on the other hand would be useful on it's own. - It could even be done as another interface to an existing web-based BT, though I would prefer if the web interface would not have to be running then. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
