Role of the Sponsorship Queue

[Emmet Hikory]

Bryce Harrington wrote:
> On Wed, Mar 03, 2010 at 03:32:30AM +0900, Emmet Hikory wrote:
>>     I think that these are both importnat things to have.  We need a
>> list of arbitrary stuff that needs review and treatment.  Sometimes
>> that's testing, sometimes that's getting it upstream, sometimes it's
>> uploading, sometimes it's requesting modifications, sometimes it's
>> porting to newer or older versions.  This is absolutely critical work.
>
> I like to break processes down into the constituent tasks, and then for
> each task see which of these buckets they fit into:
<...>
> From the sounds of things in this thread, the sponsorship process could
> benefit from such an examination.
<...>
> The steps in a typical patch's lifecycle:
>
>  1. Propose a patch for a given bug
>  2. Test that the patch applies to the package and builds
>  3. Test that the patch fixes the issue
>  4. Test that the patch doesn't cause other regressions
>  5. Go to 1 if any test failed
>  6. Package the patch into a debdiff
>  7. Review the patch for acceptability
>  8. Upload patch to Ubuntu
>  9. Send the patch to the appropriate upstream

    For the patch review workflow, I like this idea a lot.  Whlie
automation would be keen, I think we could also benefit from dropping
this into some larger buckets based on our current teams until
automation is available.  Perhaps something like:

Step 1: some random user (may or may not be a member of any given team)
Steps 2-5: Members of the bugsquad and testing teams (may or may not
also be members of other teams)
Steps 6-8: Members of the development team

   I'm a little uncertain about step 9.  Some upsteams would like to
receive lots of patches early and often.,  Others want trusted
reviewers to test them at the distribution level before pushing them
upstream.  Most are somewhere in the middle.  In cases where we know
an upstream wants patches, and we have a good relationship through
some member of bugsquad (who may happen to also be a developer), I
think that member of bugsquad should be able to forward the patch,
etc.  In cases where we're less sure, it may be better to have the
patch first reviewed by a developer.

    That said, a significant number of our development team may not
(yet) have upload access to a given package.  In fact, we consider
prior success at arranging uploads to packages to which one has not
been grated upload access as part of the criteria to determine if
upload access is granted.  Even with this process (or the extended one
with full automation), I think there remains a need for a way in which
those developers who cannot upload directly can have their work
uploaded (and having it go through the patch process again is just a
waste of time and effort for all parties concerned).

> #9b is best done by the original patch submitter, although there are
> cases where it is difficult or complicated to get upstream to take the
> patch, or where the contributor simply does not have interest in seeing
> it go upstream.  In these cases, maybe it would be nice to bubble the
> upstreaming work up to a special team focused on getting package patches
> taken upstream.

    I've encountered many cases where the original patch author had no
interest in this, or even negative interest.  I'd also like to avoid
having yet another special team that would be expected to deal with
15,000 upstream development groups (although perhaps only 5,000
different processes).  Where the original submitter does not wish to
follow up, I think we ought capture the patch and process it as
appropriate (granting credit to original authors).  In many cases we
already have significant experience in working with the various
upstreams within our bugsquad team.  One of the strengths of Ubuntu
has always been helping to get more users using software, and we've
made great strides in sharing bug reports upstream so that lots of
software is much better: let's extend the same approach to patches,
building on our strength as a point of communication between users and
software authors.

N.B.; All developers are implicity members of bugsquad

-- 
Emmet HIKORY