[Strawman] Sponsoring after Permissions Reorg

[Emmet Hikory]

Daniel Holbach wrote:
> On 09.12.2009 10:31, Emmet Hikory wrote:
>> Your sponsoring page is sometimes useful, but often hours out
>> of date, which can be a factor on those (currently unfortunately rare)
>> occasions when several people are reviewing stuff in parallel.
>
> 20,50 * * * * /home/dholbach/bin/update-sponsors-list.sh
>
> Hours of date would surprise me.

    Cool!  I hadn't checked the timing in quite a while.  I retract
the claim that timing may be off by more than 30 minutes (although
that's still too slow to be useful without other sources of
coordination during repeated parallel sponsoring).

>> Sponsor Request:
>>  * Prepare a candidate revision
>>  * Check ${SITE} to see what team(s) support the package
>>  * Contact (one of) the development team(s) to request sponsorship as
>> documented on ${SITE} for that team
>
> I'd really prefer if this was simpler for people seeking sponsorship.
> The reality is that people don't know about the process, which is why
> the list of bugs with patches attached is exploding.

    I don't think that there is an identify between the list of bugs
with patches attached and the list of bugs that need to be sponsored.
Many patches need testing, or have not been integrated into the
packaging.  It's easy for us to forget, but there's often a
significant learning effort to go from being able to produce a code
patch (which skill one may have aquired in any of a large variety of
contexts) to the ability to prepare a candidate revision of a package
for upload: essentially one needs to be able to understand how the
packaging is done, which of the many available patch systems is used,
how to properly manipulate that patch system, how to ensure that the
patch is applied using the selected patch system in the package, etc.

    For the cases where a simple patch is being provided, I think that
we want to make the process as simple as possible, to reduce the
amount of time that anyone needs to invest in learning to develop
Ubuntu in order to submit a bugfix, workaround, etc.  For the cases
where someone is actively learning how Ubuntu Development works, and
how we do things, I think that the overhead of learning to work with
various teams supporting the various package sets is fairly minor
compared to the amount of general learning about Debian-format
packaging, Ubuntu development cycles, practices, processes, and
procedures, etc.  Further, I think we should be encouraging
prospective developers who are working to learn all these things to
work with one or another of our package set support teams (or MOTU),
rather than presenting them with a large disparate group of
individuals (a single sponsors team) and expecting them to find some
way to get introduced to key individuals in the name of making the
process "easy".

    To achieve these somewhat disparate goals, I continue to claim
that we would do best to retain a semantic distinction between the set
of patches available, and the set of candidate revisions for upload,
and have separate (perhaps overlapping) teams that support them.  I
know that in my own experience in getting involved in Ubuntu
development, I first spent time creating patches (as I didn't really
understand best practices in integrating them in packages), for which
often distinct people would create candidate revisions and perform
uploads, and then began to prepare candidate uploads (frequently using
patches submitted by others, from other distributions, or from
upstream) which were sponsored, and lastly was able to upload myself.
While I'm sure that not everyone has followed this path, I know I've
seen several others in #ubuntu-motu who appeared to do so, and I don't
think we'll get better at keeping up with user-submitted patches by
restricting the set of people reviewing raw patches (as distinct from
candidate revisions) to developers who could potentially upload them
directly.  I'm also not convinced that a significant portion of those
submitting one-off patches of various sorts have any interest in
attempting to learn or follow *any* process that we document, however
simple it may be, as they don't necessarily want to be Ubuntu
Developers, or even to develop Ubuntu, but just want to avoid the pain
of merging their patch every time someone uploads the package, or want
the bug fixed in the "official version" due to some local policy, or
similar.

-- 
Emmet HIKORY