Re: [Launchpad-users] Summary of code review relationships

[Martin Pool <mbp@xxxxxxxxxxxxx>]

2009/12/9 Aaron Bentley <aaron@xxxxxxxxxxxxx>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Martin,
>
> Here's a stab at defining the relationships related to code review.

Thanks,

I hope you won't mind me sending this to the list, because I think it
will help others and they may also have questions.

>
>
> 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.

It may be worth mentioning this is the name that appears in the branch
url (except for product-namespace branches.)

Isn't there still a branch registrant, or did that go?

>
> 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.

"By default" meaning unless someone requests the review through the
web ui and chooses a different reviewer?  iow the person requesting
the review can choose?

>
> 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.

Thanks, that's clear and useful.

>
> 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").

Is that second bit beyond what is implied by "edit rights"?  If so,
maybe you should clarify what the edit rights are?

>
> 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.

.. and "doesn't conflict" means ... the actual review contains a
superset of the words in the requested review?

>
> 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.

So thanks, that's cleared it up a lot for me.  I'd like to see it or
something based on this go into launchpad's help.  I can add it if you
want.  Hopefully it will also help people understand either how to use
the current system, or how to file more informed bugs - for example
there was something recently from Guilhem confused about
subscriptions.

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