Merging [LWN.net]

Merging

Posted May 15, 2008 7:28 UTC (Thu) by rvfh (guest, #31018)
In reply to: Merging by iabervon
Parent article: Distributed bug tracking

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 :)

to post comments

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).