FYI: ubuntu-devel thread about merge proposals

[Martin Pool]

2009/12/9 Karl Fogel <karl.fogel at canonical.com>:
> James Westby <jw+debian at jameswestby.net> writes:
>> The subject is of interest to the list, but the decision may have
>> implications beyond this list, so I just sent this mail to ubuntu-devel:
>>
>>   https://lists.ubuntu.com/archives/ubuntu-devel/2009-December/029694.html
>>
>> It is about who the default reviewer should be for Ubuntu merge proposals,
>> something I have discussed with some of you previously.
>
> I just want to say, it seems eminently sane to me, especially the
> distinction between "can review" and "can merge".

Hi,

In that context let me just point you to
<https://bugs.edge.launchpad.net/launchpad-code/+bug/281056> about
notifying the review team and bugs linked from there.  Aaron kindly
wrote up a document about team roles and relationships which I've not
yet digested but is attached below, and you may have comments on that
too.

-- 
Martin <http://launchpad.net/~mbp/>


Hi Martin,

Here's a stab at defining the relationships related to code review.


Per-branch relationships
========================

Owner
- -----
Each branch has an owner, who is the only person or team, aside from
admins, who can write to the branch.

Review Team
- -----------
Each branch has a "review team".  This is the group of people (or
person) whose reviews are trusted input for deciding whether to accept a
merge into this branch.  By default, this team is requested to review
any new proposal to merge into this branch.  If the review team is not
set, the branch owner is used as the review team.  This setting does not
cause any additional mail to be sent to members of the review team.

Subscribers
- -----------
Each branch has zero or more subscribers.  They may be subscribed to
metadata changes, revision updates, and / or code review.  Subscriptions
allow the subscriber to control the kinds of email sent to them, and
also the size of branch update diffs.  They allow an individual to
override the subscription settings their team may have.  Subscribers to
code review are notified when this branch is the source or target of a
merge proposal.  When a branch is created, we automatically subscribe
its owner to code review.  It seems like a good idea to subscribe the
review team too, but we don't at present.

Per merge-proposal relationships
================================

Registrant
- ----------
The person who proposed the merge.  This person has edit rights on the
merge proposal.

Source branch owner
- -------------------
The source branch owner has edit rights on the merge proposal.

Target branch owner and review team
- -----------------------------------
They have edit rights on the merge proposal.  Their reviews are not
shown as "(community)".  They can set the overall status of the merge
proposal (i.e. mark it "approved"/"rejected"/"work in progress").

Team Reviewers
- --------------
Teams who have been requested to review.  Members of these teams may
claim their team's review.  If a member of this team performs a review,
and the requested review type doesn't conflict with the specified review
type, the team review request is automatically reassigned to the reviewer.

Individual Reviewers
- --------------------
People who have been requested to review or who have performed reviews.
  They receive all email about this merge proposal.  If they have not
yet reviewed, they can only opt out by reassigning their review request.
 Otherwise, they cannot opt out.

Commenters
- ----------
People who have made comments about the merge proposal.  Being a
commenter does not cause them to receive email, and there is no way for
them to opt-in to email about this particular proposal.

They could subscribe to code review on the source branch, and this would
have the same effect as being subscribed to the merge proposal, as long
as no further merge proposals were made for the source branch.