Default reviewer for Ubuntu merge proposals?

[Emmet Hikory]

James Westby wrote:
> On Wed Dec 09 08:01:51 +0000 2009 Emmet Hikory wrote:
>>     As a medium-term solution for a default, this seems reasonable.
>> As we continue with the process of migrating to a variety of teams
>> closely supporting various package sets, I think it would make sense
>> to try to set the default reviewer for a merge proposal for a package
>> based some analysis of which package sets contain that package.
>
> Which LP team would you choose for an arbitrary package that has:
>
>  * zero or more teams able to upload due to it's membership in a set.
>  * zero or more teams able to upload due to per-package upload rights.
>  * core-dev able to upload.
>
> (where I'm using LP's equivalence of teams and single people).
>
> I see this as an insoluble problem because we do not have per-package
> upload teams

    I think I misunderstood the mechanisms in place.  I'd like to
assign the most relevant team in cases where one exists, with the
assumption that teams with wider rights would be able to discover
available merge proposals through some listing or searching interface
and claim them (or at least merge and commit them).  If the mechanism
is that only members of the default review team are able to interact
with the merge proposal then I withdraw my objections and completely
agree that ~ubuntu-dev is the appropriate choice as long as we're
limited to LP teams/people, although in that case I think we'll need
some other system to improve discoverability of merge proposals one
can actually process.

>> and I fear that extended use of a
>> single large team including many people who cannot actually complete
>> the requested merge will repeat the confusion we had back in the
>> Breezy timeframe (IIRC) regarding sponsorship,
>
> What sort of confusion?

    I'd appreciate input from someone who was actually a developer at
the time, but my vague memory is as follows.  During the Hoary
development cycle, bugs in main were put in Bugzilla and bugs in
universe were put in Malone.  MOTU just randomly grabbed bugs and
fixed them.  As the volume grew, the bugsquad grew, and we began to
submit patches and debdiffs, at which point the MOTU started to just
grab bugs with patches.  At some point in the Breezy cycle, all the
bugs from Bugzilla were dumped into Malone, and Malone became the
default place for all bugs.  As a result, it became harder and harder
for MOTU to just find patches on packages in universe, and bugsquad
was scanning bugs and announcing universe bugs with patches on
#ubuntnu-motu to get uploaded.  This didn't scale well, and the MOTU
Reviewers team was created to act as an assignee for bugs that needed
MOTU review of patches or debdiffs.

    The specific confusion was that experienced by MOTU not able to
easily find bugs with patches that they could process because they
were overwhelmed by bugs with patches that they couldn't process
coming from the same source (I don't think Malone could search by
component back then, and I'm fairly sure that most MOTU weren't deeply
familiar with searching in Malone at time, as the wiki contained links
to most of the useful canned searches).

>> Where a package
>> has been determined not to belong to a package set (either directly or
>> through invalidation of narrow sets as indicated above), the use of
>> the generic ubuntu-reviewers team seems reasonable,
>
> Why ubuntu-reviewers?

    Because I misread what you wrote previously.  I meant "~ubuntu-dev
with merge request mail somehow routed to ubuntu-reviews@".  Sorry for
any confusion engendered by my previous confusion.

>> The least-well-served by this model would be
>> per-package-uploaders not participating in a group, but my suspicion
>> is that those with such specific interests are likely to be keeping a
>> close watch on packages for which they have upload permission, and so
>> may be able to make do with some mechanism to autosubscribe to merge
>> requests for the (small) set of brances of interest.
>
> There is already such a mechanism. Subscription is orthoganal to the
> default reviewer. In your model per-package-uploaders would not be
> able to claim the default review on packages they have upload rights
> for, which, as they are the most likely to review, seems not ideal.

    Indeed.  Alternately, passing a merge request to a per-package
uploader in such a way that others cannot claim it risks blocking on a
single person who may not be able to process the review in a timely
manner for any of a number of reasons (busy, ill, vacationing, etc.).

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

    Then again, perhaps I've misunderstood the semantics again.

-- 
Emmet HIKORY