Distributed bug tracking [LWN.net]

Distributed bug tracking

Posted May 14, 2008 17:06 UTC (Wed) by tzafrir (subscriber, #11501)
In reply to: Distributed bug tracking by iabervon
Parent article: Distributed bug tracking

I added a comment while offline and you added a comment while off-line.

When is the potential conflict between our added messages get merged?

to post comments

Distributed bug tracking

Posted May 14, 2008 18:20 UTC (Wed) by iabervon (subscriber, #722) [Link] (14 responses)

Different people adding different comments should be trivial to merge; the system just gets
both comments in some arbitrary order, just like if two people send email to a mailing list at
the same time. The interesting case is when people try to make incompatible changes to the
same bug, but I sort of feel like there aren't really any incompatible changes if the changes
are represented in enough detail. If the model is that people make statements about bugs in an
unordered (except when they reference each other), append-only fashion, and the mutable fields
of a bug are generated from the currently-known set of these, rather than being stored as
particular values, then there shouldn't be any possibility of conflicts to resolve.

Merging

Posted May 14, 2008 18:38 UTC (Wed) by corbet (editor, #1) [Link] (13 responses)

In fact, the merging of comments works just fine, at least in Bugs Everywhere. Each comment is its own file, so there's no conflicts; they all just mix in together.

The problem is the "incompatible" changes - global stuff like severity, assigned-to, title, resolution status, etc. I don't think there will be any way to automatically merge changes to such parameters. What would be nice, though, is merging code which understands things at the right level rather than just forcing somebody to run an editor on its internal files to clean things up.

Merging

Posted May 14, 2008 18:51 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

When you're commenting on an open bug and someone else closes it, there's no 
technical conflict. But does it warant a reopen?

Merging

Posted May 14, 2008 18:59 UTC (Wed) by iabervon (subscriber, #722) [Link] (9 responses)

I still think the right thing is to not do global changes exactly, but give comments the
ability to attempt to modify them, and have the effective status come from combining them,
where a comment that references another comment can override its changes, and comments that
don't reference each other have a cumulative effect. This then requires that, for each field,
there's a way of combining a bunch of values: take the maximum severity and priority, all of
the assignees, all of the titles, all of the resolutions, and so forth.

That is, somebody reports a bug. Somebody else posts a request for more info, with a flag to
close the bug as "needs info". The first person replies to the post with the info, with a flag
to remove the "needs info" resolution. But first, a third person commits a fix, with a
resolution "fixed in commit X". Since the earlier reply doesn't reference this comment, the
reopen effect doesn't apply to it, so it's left as "fixed in commit X"; then the original
person can confirm it or deny it in a reply to the "fixed" comment.

My contention is that all of the global stuff can be handled like this, and likely handled
better than actually having central values anyway.

Merging

Posted May 14, 2008 19:35 UTC (Wed) by elanthis (guest, #6227) [Link] (8 responses)

"take the maximum severity and priority, all of the assignees, all of the titles, all of the
resolutions, and so forth."

Maximum is not correct in most cases.  How would I lower a priority?

In general, though, I like your idea.  Each update includes a set of changes (with or without
a comment) to an earlier revision of the bug.  If any of those fields conflict with any
revisions between the target and the new one, those over-ride the new one.  Pretty
straightforward.

Merging

Posted May 14, 2008 20:22 UTC (Wed) by iabervon (subscriber, #722) [Link] (7 responses)

You'd lower the priority by replying to the comment(s) that raised it with your reply changing
the priority. That would remove them from the set that the maximum is taken over. The idea is
that a bug has a high priority for some reason, and the reason is given in the comment that
raises it. In order for the bug to go back to being low priority, you need to refute (or at
least have seen) the reason it was high. If it was also high priority for some other reason
you haven't looked at yet, it's still high priority until you do.

So my algorithm is: take all of the comments (including the original report) that affect
(field) that don't have any descendants that affect (field); these are the relevant comments.
Of the relevant comments, take the least upper bound of their values (least upper bound being
maximum for numbers, and union for sets). This is the effective value of the field.

Merging

Posted May 15, 2008 7:28 UTC (Thu) by rvfh (guest, #31018) [Link] (6 responses)

Or... only one person can change the priority or whatever of a given package at a given time:
the triager. Then there's not conflict to solve to start with.

If you need more people changing, ok, but they can still talk before, and agree on who is in
charge (does not need to be the person solving the bug).

Why should computers programs solve _all_ our problems when we can just use a bit of
communication?

So my algorithm is:
- bug reported (no priority or whatever)
- triager takes responsibility over it (decided in a 'live' session; if you are in a plane,
then someone else will do it, tough! At least until you land and talk to them)
- people only add comments, maybe saying: please push priority to 'severe'

Obviously, only the core maintainers' request for priority change are taken into account :)
But they don't do it themselves anymore. The central server is replaced in this function by a
central person (who can delegate, of course).

I obviously consider the ability of posting comments/patches much more important to distribute
that that of changing the priority of the bug :)

Merging

Posted May 15, 2008 12:07 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (3 responses)

If you can't distribute the work over more than one person, what's the point in a 
distributed system in the first place? Only the copy of the triager counts. The other 
copies are unreliable.

Merging

Posted May 15, 2008 15:04 UTC (Thu) by rvfh (guest, #31018) [Link] (2 responses)

Only the 'metadata' is centralised, and again, the triager can delegate (which a centralised
server usually doesn't do ;) so you still have a better system.

IMHO, only the comments/patches really need to live with the code.

Merging

Posted May 15, 2008 21:46 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (1 responses)

So what is it better than today? A centralized place for meta-data: the bug tracking system.

We have the metadata centralized. There are many places where you have hacks to refer beterrn
the source and the bugs database (e.g: specially-formatted commit messages close bugs,
trac-style formatting of commit messages)

Merging

Posted May 16, 2008 7:34 UTC (Fri) by rvfh (guest, #31018) [Link]

I got your point, but do you get mine?

What was being discussed was the merging of metadata such as priority and all the other stuff,
which could be problematic on a decentralised system (comments/patches are the easy part), and
I was suggesting to _not_ automatise and risk making mistakes (e.g. priority inversion), but
rather let someone (human being) decide and solve the conflict: the triager.

A server does not delegate, a triager can, so this is a marginal and dynamic centralisation,
rather than a full and static one, like e.g. Bugzilla.

Merging

Posted May 15, 2008 15:56 UTC (Thu) by iabervon (subscriber, #722) [Link] (1 responses)

For priority, I'm not particularly sure a single value even makes any sense. Surely, different
developers should see different priorities depending on whose opinions they care about. If a
bug only applies to one site, and that site has a Red Hat support contract, it's going to be a
high priority for any Red Hat employees, and for anyone who particularly wants to help Red
Hat, but a Novell engineer who's just looking for something to fix might not even have the
ability to get a candidate fix tested without going through a Red Hat contact. And if a single
bug is shared between multiple projects when it's unclear where the problem originates, each
project may have a different priority for it, depending on whether it's looking like it's in
that project or not. I think it's best to follow the git model of distribution with
centralization: the official database is only special in that lots of people happen to care
more about it. If people decide, temporarily or permanently, to care about some other
database, the transfer is seamless.

For severity, I think you really do want to have end users who hit the problem to be able to
say how bad it is for them, and revise this as they find workarounds and remove the failing
case from their workflows or are forced into the failing case more frequently. And the
severity from the point of view of people who might work on it should reflect some sort of
vote among the users.

Merging

Posted May 18, 2008 14:43 UTC (Sun) by oak (guest, #2786) [Link]

> For severity, I think you really do want to have end users who hit the 
problem to be able to say how bad it is for them

In the comment yes.  Letting them to edit the fields is not going to work 
though, if you want the severity to have any meaning.  Users in general 
think their problems to be blockers (for them) or at least critical and 
don't read what the severity values are supposed to mean.

Besides, for users the bug reporting should be easy, not showing them the 
extra fields makes the bug filing easier (Bugzilla may be a bit 
intimidating for first timers).

Merging

Posted May 15, 2008 13:33 UTC (Thu) by Jel (guest, #22988) [Link] (1 responses)

Well, one way to manage conflicts to attributes like Status would be to 
prioritise based on some combination of update time, and authority level 
of the person doing the update.  But how you manage authority/roles in a 
distributed, version-controlled bug tracker is another question.

Merging

Posted May 15, 2008 21:53 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

Update time assumes you can serialize them. What if I worked in my personal branch on
something for a whole year unaware of the fact that the project has moved elsewhere?

I might have added tons of irrelevant comments and changes to bug reports.


Authority level basically assumes a centralized model.