Default reviewer for Ubuntu merge proposals?

[Emmet Hikory]

James Westby wrote:
> 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).
<...>
> 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.

   My apologies for that.  While I have many thoughts in that area, I
was attempting to understand and discuss the specific point of your
mail.  Discrepancies are surely a result of my lack of familiarity
with the merge proposal interface, having used it only to propose
merges, and never as a reviewer.  I very much appreciate your patience
and supplementary explanations, which have vastly improved my
understanding of the issue under consideration.

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

   Indeed, and my apologies if my last mail was unclear.  I
misunderstood the implications of the default revewer team, and
believe that the use of ~ubuntu-dev is the best available compromise,
but that it only meets the requirements for System A in my listing
above: specifically as somewhere where the unsorted set of merge
proposals are stored (manipulation is a less important facet of System
A, and is listed mostly because of my assumptions regarding
implementation as part of the current launchpad code management
tools).

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

    My interest in rules is merely to improve discoerability.  I agree
that the nature of the problem (multiple potential reviewing
people/teams, changes in package sets over time, insufficient
meta-information to identify best reviewer, etc.) makes any algorithm
inherently fragile, and hence suggested that the greater problem is
perhaps best addressed with complementary views of the data (which was
perhaps clouded by my misperceptions of the mechanisms of merge
proposals).  Further your clarification that there is no ACL for merge
proposals makes many of my points moot.

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

    This would be System B in my listing above: somewhere where
developers can discover which merge proposals they can usefully
process (i.e. the developer concerned has commit access to the
destination branch).  Additional discussion about how that system
might work is again speculative and based on assumptions about
potential implementations.  I'm glad to read efforts are underway, as
this addresses my concerns about having a single default review team.
Please let me know if there are likely to be significant delays in
implementation of discoerability within launchpad: I would be happy to
to assist in development of and host an external query system
temporarily.

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

    I agree that discussion of discoverability should in no way halt
work, and that it is undersireable to expect branch contributors to
correctly identify the reviewer team.  My apologies for jumping on
this tangential issue in the assumption that it had not been
sufficiently considered.

-- 
Emmet HIKORY