Default reviewer for Ubuntu merge proposals?
Emmet Hikory
persia at ubuntu.com
Wed Dec 9 08:01:51 GMT 2009
James Westby wrote:
> When you create a merge proposal in LP for Bazaar branches you are
> invited to name the person or team you wish to review the change.
> Sometimes you will know that you want someone in particular to
> review it, so you can search for them and choose them easily.
<...>
> Therefore, I propose that ~ubuntu-dev be made the default reviewer for all
> branches.
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.
Essentially, while I expect the tradition of "There are no maintainers
in Ubuntu" will continue, members of a team supporting a given package
set are likely more qualified to review the impact of a given patch on
the package set as a whole, etc.
I don't think it should be the resppnsibility of a merge requestor
to try to identify the best team, 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, from which grew the
MOTU Reviewers team (as distinct from Ubuntu Dev in general),
consisting of those who wanted to review stuff but had more limited
upload rights. This team was later abandoned in favor of the
ubuntu-{main,universe}-sponsors teams (somewhere around Edgy, again
IIRC) as process was formalised (and in an attempt to close the gap
for sponsored uploads to main), which processes we're outgrowing
(through both distributed development efforts and archive
reorganisation).
So, longer term, I think it makes sense to try to automate the
process of helping people submitting branches find the best reviewers
using the information about package sets and associated groups. Where
a package set is associated with a person rather than a group (e.g. a
per-package uploader has upload rights, but does not represent a
team), the package could be treated as not belonging to a package set
(to avoid cases of blocking for a single reviewer). 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, although I suspect
the majority of these packages will ultimately be reviewed by MOTU
(and so it may be as reasonable to have a MOTU Reviewers team again),
as many developers will not have permission to approve merge requests
for this set. 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.
--
Emmet HIKORY
More information about the ubuntu-devel
mailing list