Role of the Sponsorship Queue

[Bryce Harrington]

On Wed, Mar 03, 2010 at 07:19:21AM +0900, Emmet Hikory wrote:
>> ??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
>    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.

Yeah, the patch upstream bit is tricky.  I would really like to factor
it out of the sponsoring process since it adds so much complication, but
in most cases it's pretty tightly wed.  I listed it as step #9 not to
suggest it should be done last, but rather to say that if it hadn't been
done up to that point, it needs to be attended to before the process can
be completed.


But really, we say "patch" but there are several different classes:

  a. Newly created code patches
  b. Cherrypicks from upstream VCS
  c. Backported patches
  d. Packaging patches
  e. Debdiffs of something from the above
  f. Merges

Really it is just a. that we're talking about as needing to go to
upstream.  The others (except Merges) may be worth sending to Debian
depending on the package.

With X.org, the majority of the time with patches of type a. I prefer to
see them go upstream first and only take them in ubuntu once they've
reached type b.  So I could see this inserted in the process as a
non-blocking step 1.5.

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

Right, I think I'm basically of the same mind as you that we really have
two parallel processes - one for sponsoring people's changes for Ubuntu,
and a second one for mentoring a packager towards MOTU/core-dev.

This is where having steps 6, 7, and 8 divided out is beneficial.  If
the review team can tag patches that have passed steps 1-5 in some
fashion, "patch-needs-packaging" or some such, then
packagers-in-training can use that as their incoming queue, package the
patch and post a debdiff (step 6), at which point it shows up in the
sponsor's queue to complete steps 7 and 8.

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

Perhaps rather than "special team" I should have said "appropriate
team".  I just recognize that we probably have many packages without
anyone really signed up to maintain them (ala Brian's call for
volunteers for packages with no subscribers, last year).

Bryce