Patch relations in Patchwork

It is possible to relate a patch to other patches in Patchwork. The relation is many to many, ie A patch x can be related to m other patches x1, x2, .. xN ; All these m patches will have the patch x related to them.

Generally speaking, patch relations in Patchwork form a Homogenous relation over the set of all patches. This relation is also an Equivalence relation over the set of all patches ie. it is reflexive, symmetric and transitive.

As a consequence of this, all relations are pairwise disjoint (Equivalence relations induce a partitioning of the set they are defined over). IOW, a patch can belong to one and only one relation.

The API

To relate a patch x to a patch y, either one of these operations are valid:

Removing a patch from a relation can be done by relating the patch to be deleted with "[]" (empty list). This neatly avoids Read-Modify-Write loops. Eg. If [a,b,c] form a relation. Removing patch b from this relation can be achieved by: PATCH /api/patch/b related: []

The API does not allow any of the patches being related to be a part of different relations. ie consider 2 relations [a,b,c] and [x,y,z], if we want the new relation to be [a,b,c,x]. We will first need to remove patch x from it's existing relation by PATCH /api/patch/x related: []. And then associate x with PATCH /api/patch/a related: [x].

Further to perform this operation, the user must have maintainer access to each project for which a patch exists in the relation.

PaStA interaction with relations API

PaStA needs to essentially figure out what are the optimal steps to go from one partitioning of the set of all patches to another.

In this case the set of all patches also changes over time. The set of all patches in PaStA and Patchwork need to be synchronised before PaStA forms equivalence classes.

This problem is made harder by the fact that PaStA might not know what is the current partitioning of all patches in Patchwork as other users can also edit relations. (Possible solution: make the problem simpler by only allowing PaStA to edit relations. Will have to think about what to do the case where we want user feedback. Maybe send messages back to PaStA)