[dist-bugs] RFC buginfo microformat (merging divergent states)

[Joey Hess]

This is where things begin to get a bit shakey for me.

One question I have is whether a single buginfo should be able to have
multiple merge= fields, for a multi-way merge. If so, the way to do such
a merge needs to be specified.

And I couldn't think of a better mechanism for breaking ties than having
a designated tiebreaker state.

Probably lots of other problems, and lots to learn from existing prior
art, so take this with several salt tablets.


## merging divergent states

Being distributed means that E and F might both change the state of a bug
independently, accidentially (or purposefully) producing two diverging
states. In this case, it's desiriable for there to be a way to merge the
states, and this is done by adding a merge field.

A state merge needs a tiebreaker state, one of the two states that
wins if there is a conflict. The ref field indicates the tiebreaker state.
(And additional state changes can be included in the same buginfo to override
the tiebreaker).

When merging two states, do a diff between the parent state and each child.
If a state field was changed by only one child, or the same change was made
in both children, that change is made to merged state. If a state field was
changed in different ways by both children, the tiebreaker wins.

For example, these buginfos diverge into two states for a bug, which is then
merged back without ties:

	\[[buginfo Y state=open sig="gpg-E-1"]]
	\[[buginfo Y state=open state-blocked=X sig="gpg-F-1"]]
	\[[buginfo Y ref="gpg-E-1" merge="gpg-F-1" sig="gpg-F-2"]]

The merged state is: state=open state-blocked=X

These buginfos diverge a state, which is merged back only with ties:

	\[[buginfo Y state=closed sig="gpg-E-1"]]
	\[[buginfo Y state=open state-blocked=X sig="gpg-F-1"]]
	\[[buginfo Y ref="gpg-E-1" merge="gpg-F-1" state-unblocked=X sig="gpg-F-2"]]

The merged state is state=closed. Note that if the "state-unblocked=X"
was omitted, the state would have been: state=closed state-blocked=X

No merging is required for simple comments. A buginfo that does not change
any state fields does not introduce a divergent state of a bug, and so it
can be issued at any time, referring to any specific state, or to all
states (by not explicitly referring to any). This is used to comment on a
bug. Since no divergent state is introduced by a comment, every state based
on the state a comment refers to has the comment added to it.

State merging normally needs to be done manually, but in some cases, tools
for automatic merging of divergent states would be a good thing to have.

If a tool knows that E and F are both working on the same project, and
E closes a bug, while F diverges the state by adding a blocker, as in the
above example, a tool could realize that these need to be merged, and generate
a simple merge buginfo.

Or, a project could decide that to avoid dealing with divergent states
that cannot be merged without a conflict, the last buginfo issued always
wins. A tool could be developed to enforce that by generating merge
buginfos.

Or, a project could decide that bug state divergence is allowed within the
project, but only if it's explicitly requested by adding a field.
Otherwise, automated merges are done as described above.

-- 
see shy jo
-------------- 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/20080708/eb066674/attachment-0001.pgp>