| |||||||||||||
|
| |||||||||||||
MergingMergingPosted May 14, 2008 18:59 UTC (Wed) by iabervon (subscriber, #722)In reply to: Merging by corbet Parent article: Distributed bug tracking
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.
(Log in to post comments)
Merging Posted May 14, 2008 19:35 UTC (Wed) by elanthis (subscriber, #6227) [Link] "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] 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 (subscriber, #31018) [Link] 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] 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 (subscriber, #31018) [Link] 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] 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 (subscriber, #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] 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).
|
|
||||||||||||