Advertisement
Front, Kernel, Security, Distributions, Development. See your byline here on LWN.net.
| |||||||||||||
|
| |||||||||||||
MergingMergingPosted May 15, 2008 12:07 UTC (Thu) by tzafrir (subscriber, #11501)In reply to: Merging by rvfh Parent article: Distributed bug tracking
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.
(Log in to post comments)
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.
|
|
||||||||||||