[dist-bugs] About distributed bug tracking

[Pierre Habouzit]

  Hi people.

  Distributed bug tracking is something I'm really thinking about for a
long time. We've had discussion on #git in the past to design such a
system, and bts-link was an early effort to make different BTSes work
together.

  When I've thought about DBTSes, here is what I came up with (you'll
see that many of the things I thought were necessary have already been
said before):

  * one needs an easy to parse storage. bugs-everywhere totally fails in
    that regard, because they have a very curious storage. I had chose
    mboxes because it allow easy interaction with MUAs, but any MIME
    holding stuff works for me.

  * one need to have a generic way to deal with metadata for the bug.
    There are tons of metadata that you want to have at hand, a non
    restrictive list contains:
      + subject;
      + submitter;
      + commits ids that fixes the bug or enhance its status;
      + status;
      + bug id;
      + upstream for the bug (if it was imported, where was it from in
	the first place if it was not from a DBTS);
      + ....
    Some people may also like to add their own metadata stuff to say if
    a bug has been checked by QA, or add versioning information, or
    whatever.

  * the tool should focus on storage and distribution first. GIT has
    shown how successful such an approach is. Then tools that interpret
    the metadata are built around them, at the pace of the users needs
    (IOW don't try to make versionning builtin, rather have an
    extensible efficient storage, and just use a new field each time you
    want a new feature).

  * such a tool must not be written to be able to interact with itself
    only, but should be written first to interact with non distributed
    BTSes.  The most wanted feature of such a DBTS is to able e.g. for a
    metaproject that uses several sub projects, to interact with all
    upstreams BTSes, and import bugs that hurt you into your DBTS to
    track them. That's the most straightforward way to do this.

  * DBTSes must support partial "cloning" of subparts of their content
    (selected by tags, severities, or any combination of the metadatas).

  The fourth point is by far the most important and it imposes all the
other. One of the consequences is that one way or the other, when you
import a bug in your database from e.g. a bugzilla, and then someone
else does the same thing, then you pull the bug from his DBTS into
yours, you _must_ be able to find out easily its the same bug. IOW
importing http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980 (just
a random bug that was in my cut buffer) should:
  1. generate the same UUID for the bug in our DBTS for any importer ;
  2. more importantly: this bug evolves, has more and more comments, you
     want that imports that are not at the same level are still working
     fine when pulling one from the other.
One thing that could probably help would be to agree with several
important BTS authors on a bug UUID format. As a general rule, having a
microformat for information exchange is probably useful. Note that
bugzilla has already an XML export for their bugs. I dislike XML a lot,
but it's an existing interface. It shall probably not be the native
exchange format for a DBTS, but it's probably important to support.


  Ideally a DBTS that e.g. has as remotes the Debian BTS and e.g. the
glibc bugzilla, should be able to "merge" bugs that come from both, and
be able to push incremental changes that were made on both at the DBTS
user discretion. That means that a bug could have several "remotes" as a
content source, and could be able to push its state to several other
"remotes".


  Wrt merging, merging comments and attachments is pretty
straightforward: it's just adding a new mail to the mbox and be done
with it. Though, I disagree with the comments I read in the archive.
Changing the bug description is just a metadata change. It's not because
it's by far the larger metadata in the bug that it's different to merge
a description change than to merge a status change or a versionning
information change or ...

  Updates to the metadata _are_ problematic, and we must just provide a
unified way to deal with them. Again, learning from git, one should not
write different merging techniques and try to be clever for the user, it
sometimes fails, and when it does, it does it silently, which is worse
than requiring a few trivial efforts when a conflict arise.

-- 
·O·  Pierre Habouzit
··O                                                madcoder at debian.org
OOO                                                http://www.madism.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://kitenet.net/pipermail/dist-bugs/attachments/20080709/454b1f69/attachment.pgp>