[dist-bugs] About distributed bug tracking

[Joey Hess]

Pierre Habouzit wrote:
>   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.

My understanding is that git lets you calculate the merge in any way you
like, including arbitrary domain-specific tools[1]. But that's only done
once, and the merge result is stored the same way no matter how it's
calculated, so others don't have to care how you got there.

Similarly, I think that arbitrary methods could be used to merge bug
state. Maybe you always want to take the state that some person or distro
you are following chose. Maybe you want to take the one with the most
votes. Or you want to always pick manually. As long as the result is
stored in a consistent way, it doesn't matter how you get there.

I think this is what Jesse is talking about when he says
| In Prophet, conflict resolutions are treated as first-class entities,
| keyed by fingerprints of the conflict they resolve.

But I also think that when possible a DBTS's design should avoid
conflicts occuring entirely. For example, posting a comment or a patch
to a bug should never create a conflict, unlike opening/closing.

-- 
see shy jo

[1] changelog mergers, for example
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://kitenet.net/pipermail/dist-bugs/attachments/20080709/9cd3673b/attachment.pgp>