Default reviewer for Ubuntu merge proposals?

[James Westby]

On Wed Dec 09 13:57:37 +0000 2009 Emmet Hikory wrote:
>     Essentially, in the absense of per-package teams (which presumably
> contain all the teams allowed to upload to the package and no
> individuals), I think we end up either needing two systems, as
> follows:
> 
> System A: this is used to actually process merge requests.  This has
> broad permissions, and some developers end up belonging to a team that
> has outstanding merge requests that they do not have permission to
> process effectively.
> 
> System B: this is used to find writable merge requests.  It presents
> the lists of packages with outstanding merge requests that belong to a
> some set (perhaps start with hardcoded development teams, but ideally
> also either search for everything for a specific developer (perhaps
> only the user) or for some combination of teams and packages (to allow
> the user to enter their permissions or a subset thereof).
> 
> Or there needs to be a way that one can claim a merge proposal that
> happens to have defaulted to some other team/person so that one can
> recover things.  While using the merge proposal UI is nice, would a
> merge proposal automatically be marked complete if the target branch
> was pushed with the results of a merge from the candidate branch (this
> would allow using LP for discovery, but losing the merge request
> interface in cases where one reviews a merge that was defaulted to a
> team to which one doesn't belong).

Is this last sentence a question? Assuming it is, the answer is "Yes,
but..." The "but" is that you don't "lose the merge request interface,"
you can happily add reviews to any merge proposal on LP, regardless of
whether you have anything to do with the project at all.

I'm struggling to tell whether you are discussing the points of my
mails, or just dumping some thoughts on code review, merge proposals,
sponsorship etc. to the list. I know you have plenty of experience with
sponsorship, but I'm unsure how much experience you have with merge
proposals in particular. I appreciate that you may wish to improve
our sponsorship process, and have strong opinions on how it should
work; I am in the same position. However, I feel you are making too
many leaps in your replies that assume too much about how I am
acting.

For instance, your two systems above, as far as I understand them,
are very similar to the things that I am asking the Launchpad
developers to provide us with. I bought this specific question to
the mailing list, as it is a compromise and may have unforseen effects
on the Ubuntu development community.

We cannot have the default review team be a team that contains anyone
that can upload to the package, as LP does not store that information
in that manner. It could request a review from every team/person
that can upload, but this shares some difficulties with some of your
suggestions. For instance, what happens when a package changes
sets? We would have to write code that changed the reviewers around,
which would have plenty of corner cases of its own.

We must however have a default team that is asked for a review, for
the case where the person proposing the change is new to Ubuntu
development and doesn't know the intricacies of how Ubuntu development
is organised. This group is not insignificant, and in fact may grow
even larger over time.

You have proposed that we use rules to determine a suitable team
from the list of uploaders, but you didn't aid me in understanding
how this would work by giving an example algorithm that we could
use when I asked. I also have doubts that this is the way to go as
it is fragile; the example of changing package sets given above
breaks it for example.

I have therefore proposed that we use ~ubuntu-dev. This allows anyone
that can upload the package to claim that review (with the downside
that it also allows some that can't, but I can live with that.) It
is also not fragile, and clear for new contributors ("I want an
Ubuntu developer to review this.") It also, due to the way merge
proposals works, doesn't block anyone with an LP account from also
reviewing the change if they like.

Yes, it means we end up with a unsorted pile of review requests,
but that issue runs deeper than the choice of a default. If you wish
to develop a site that shows the best people to request a review
from for a given package then you are free to do so, and experienced
contributors can use it, we are only talking about a default here.

We can also work on tools to aid with discovering requests relevant
to you. We have discussed how Harvest will be able to do some of this.
I am also discussing the issue with Launchpad developers, and hope
to have something elegant and usable available in Launchpad for this.
There are some concerns around efficiency and the like, but I hope
they are not insurmountable.

My apologies that I was amiss in not talking about discoverability
in my original mail. It is an important issue. However, in my opinion
it requires neither halting all work until a design is decided upon,
nor pushing all the work on to the contributors such that they have
to ensure to subscribe the correct team. Apologies also for the length
of the email, but as I said, there are many intricacies to this issue,
and your responses so far suggested to me that I hadn't put enough
detail in to my statements thus far.

Thanks,

James