[dist-bugs] Hello!

[Joey Hess]

Jesse Vincent wrote:
> As we've been building Prophet, our peer to peer database and SD (a peer 
> to peer bugtracker on top of Prophet), we've been guided by the  
> following possibly-contentious belief:
>
> Distributed source control is all about being able to have many, many,  
> possibly divergent branches of a project and being able to easily share 
> changes.  Distributed databases, on the other hand, should be able to 
> incorporate all changes from any peer and percolate toward eventual 
> consistency.

That makes good sense for low-level databases in general, I think. You
need primitives that can sync together. What about bug tracking
specifically though? I see that Prophet uses some form of voting to
resolve conflicts. Does that mean that SD can only track one state for a
bug, and if there's a conflict over the state, someone wins? Or can SD
track multiple states?

I think that managing multiple states for a single bug are important,
since bugs can apply to many different, divergent, or even unrelated[1]
code bases. You definitly want to make it easy to agree on a state for a
bug, when there really is a common state, but it seems to me that tracking
disagreements and divergent states is just as important.

BTW, in one of your slides you mention targeting scaling to the order of 
50 thousand bugs. That seems a bit low -- Debian has an order of magnitude
more. What's the main scalability issue, is it data syncing, or the
merging algorythm? Perhaps keeping half a million bugs siloed away in
a single BTS is something we want to get away from, so I'm just curious. :-)

-- 
see shy jo

[1] The DNS security announcement couldn't have come at a better time
    for the purposes of providing an 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/b675cfc0/attachment.pgp>