[dist-bugs] About distributed bug tracking

[Pierre Habouzit]

On Wed, Jul 09, 2008 at 09:21:12PM +0000, Joey Hess wrote:
> Pierre Habouzit wrote:
> > One thing that could probably help would be to agree with several
> > important BTS authors on a bug UUID format.
> 
> I can only think of three ways to have a globally unique id that
> different BTSs could agree on:
> 
> * an URL (or something very much like an url, ie "Ubuntu bug #xxxxx")

  Yeah I think this is the best way to go. The tool could obviously hash
them using something of fixed length (I heard someone shout sha1 in the
back ;P) that wouldn't collide for real for the storage, but provide
those URIs for UUIDs.

> * a literal, random UUID
> * some form of checksum of a previous message sent to the bug
>   (either the first message, or a git-style checksum chain that
>   can be traversed to find the first one)

  We would need those for the bug number though, because of the very
aspect of a distributed system.

> >   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.
> 
> Hmm, so you're saying gits multiple merge strategies are a bad thing?
> I like a couple of them. :-)

  Well, git merging strategies are completely unaware of what they
merge, merely that it's textual (for the interesting strategies at
least). I like them a lot. What I don't like are strategies that try to
merge e.g. C code in a very clever fashion using the AST or god only
knows what else, to try to do complex merges for you.

  GIT chose not to do things like that because it has too many risks of
breaking stuff silently, which is against its spirit. Instead it even
generates more conflicts that some tools would do, and for the best,
because it makes solving conflicts easy[0]. That's what I meant.

  IOW one should focus on decent UIs to help people merge conflicts
rather than making them hard to happen. Note that in the context of a
BTS, conflicts are much easier to understand than code conflicts.
Conflicts will often be on things that can only have one value, and
where one guy chose a value while another guy chose another value. It's
simple to understand, and the user just has to make a simple choice:
"who is right ? A or B ? or do you rather even want a choice C?" That's
simple. And users that are not able to cope with such a trivial amount
of conflicts won't change bugs attributes in the first place, so won't
have any kind of conflicts to deal with.

  People dealing with conflicts will be the ones that triage bugs, hence
have to know the tool already. We have no reason to hide the complexity
from them, it would make our DBTS less predictable, which is a major
drawback usually.


  [0] For example, if you have the following:
	  ancestor:    left:      right:
	  a            aa         a
	  b            b          bb
      the diff3 based strategy won't pick 'aa\nbb\n'
      and frankly, that's a good thing, I've seen such conflicts save me
      at least a couple of times.
-- 
·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/20080710/4c6c707f/attachment.pgp>