ArchiveReorganisation and sponsoring

[Emmet Hikory]

    In a recent IRC conversation, I was asked how
ArchiveReorganisation (1) would affect sponsoring, and thought I'd
raise the same question to the mailing list in hopes of developing an
answer.

    The current model (2) consists of two teams: Ubuntu Sponsors for
Main and Ubuntu Sponsors for Universe.  Those seeking sponsorship
subscribe one of these teams, depending on the component in which the
package resides, and members of those teams then review the upload
candidate.  There are a number of procedural differences in the ways
that the two queues work, but for the most part there is a fairly
simple and obvious interface from the point of view of someone seeking
to submit an improvement to Ubuntu.

    There are currently a few issues related to sponsoring that seem
relevant in the context of ArchiveReorganistion, as follows:

 * Updates to packages very specific to certain maintenance teams
(e.g. Mythbuntu Developers, Mozilla Team) are very rarely sponsored
except by members of those teams.
 * Updates to some packages in the Main queue may remain unreviewed
after for an extended time because the specific package falls between
different maintenance teams, yet casual sponsors viewing the bug
assume it belongs to some specific person or team.
 * Updates to some packages in the Universe queue may be lost in the
bugmail of the interested maintenance team, perhaps causing delay, or
perhaps resulting in an upload by a sponsor unfamiliar with the effect
of a change on the flavour concerned.

    Assuming that there remains no sponsoring interface in Launchpad,
one possible model for a solution might be modify pkgbinarymangler to
assign different maintainers based on seed contents, rather than
main/universe, so that each approved maintenance team would be
appropriately identified as the maintainer for the binary package.
Someone wishing to submit a new candidate package could then know the
appropriate team to approach when seeking sponsorship.  If we redefine
"universe" to mean unseeded packages (which is a close match to the
definition prior to the introduction of "Universe Flavours"), the
sponsoring process for the redefined universe can remain essentially
as it is now.  The Ubuntu Sponsors for Main team can be dissolved, and
instead those seeking sponsoring can directly subscribe the relevant
maintenance team responsible for the package.

    Unfortunately, this model has a few failings, as follows:

 * Some teams (e.g. Ubuntu Desktop) are subscribed to *lots* of bugs,
and sponsorship requests may be lost in the noise
 * Some teams (e.g. Mozilla Team) work exclusively in Vcs, and find
the presentation of debdiffs in bugs awkward to integrate
 * Some source packages may have differently seeded binary packages,
so that while the appropriate maintenance team may be identified for
that binary package, the members of that team may not be able to
upload the affected source package (this issue exists today, but to a
lesser degree).

    There is also currently a bug about awkward workflows for
sponsoring in Launchpad (3), and it may be that as mentioned there,
the proposed solution is to encourage revision modifications using the
branch merge request review workflow, towards eventual implementation
of NoMoreSourcePackages (4).  While this may well be suitable for
packages belonging to a specific maintenance team, who may have
branches for those source packages with which they work already
available, some outstanding bzr bugs (5) make this painful for
universe, where the sponsor may have never seen the package
previously, and may never intend to look at it again.

    So, if anyone has good ideas as to how to define a sponsorship
model that can be used with the reorganised archive, please reply here
and describe the model.  An initial set of requirements, to which
additions are encouraged, might include:

 * Provides an interface that is simple for someone new to Ubuntu
Development (but not necessarily to Debian format packaging) to
understand, and can be described in a couple lines of text (for ease
of passing the meme on IRC)
 * Provides a simple means by which a given set of sponsors can view
the work available to be sponsored and remove tasks from the list when
accepted or rejected
 * Does not require the creation of umpteen launchpad teams which must
be separately administered
 * Does not cause a greater flood of bugmail to those not involved in
the sponsorship
 * Does not flood the core developers with excess sponsorship requests
for packages properly belonging to another maintenance team
 * Allows the work of sponsoring to happen fairly quickly, with most
of the work being the testing of the solution to the bug, rather than
in preparing the binary for testing.

1: https://wiki.ubuntu.com/ArchiveReorganisation
2: The advertised model: there are various exceptions to this process
practiced by various subsets of people for various reasons.
3: https://bugs.launchpad.net/malone/+bug/179857
4: https://wiki.ubuntu.com/NoMoreSourcePackages
5: e.g. 86392, 180116, 197597, 252945 : more generally performance
issues for small one-time remote operations where there is no
pre-existing local repository, nor any expectation of keeping a
repository after the push is complete.  Server-side merges are
considered uninteresting, as they do not provide a mechanism for the
sponsor to test the result of a change locally prior to committing to
the archives.

-- 
Emmet HIKORY