Role of the Sponsorship Queue

[Brian Murray]

On Thu, Mar 04, 2010 at 10:32:16AM -0800, Bryce Harrington wrote:
> On Fri, Mar 05, 2010 at 02:57:47AM +0900, Emmet Hikory wrote:
> > Scott Kitterman wrote:
> > > "Emmet Hikory" wrote:
> > >> ?? ??Now, I happen to believe that it's worth having a sponsors queue.
> > >>I remember when we didn't have one. ??We created it specifically so
> > >>that those developers who didn't yet have upload rights to a given
> > >>package could get priority for reviews of their candidate packages
> > >>(which at the time primarily consisted of collections of the
> > >>previously unreviewed patches). ??If we don't wish to fast-track
> > >>uploads for developers, that's fine, but I believe that we'll end up
> > >>back in the days when people just repeatedly posted on IRC when they
> > >>had a debdiff, and I think that's a waste of the submitters time and
> > >>the time of anyone reading iRC (either in real-time or in logs).
> > >
> > > This leaves out the class of submitter that is currently very motivated around one or two bugs, but has no current intent to become an Ubuntu developer. ?? I think this unfortunate for two reasons:
> > >
> > > 1. ??It misses a good chance to get a fix into the archive.
> > 
> >     I'm not convinced this doesn't apply to a significant proportion
> > of the outstanding patch list currently, and I don't think that the
> > subscription of a special magic team necessarily has any relation to
> > the quality of a patch.  Yes, we're losing track of patches, but the
> > outstanding number of patches has been fairly constant for the past
> > year, and is lower than it has been.  This gives me confidence that
> > we're making progress, and can get the total available patches down to
> > a manageable level soon, especially if we encourage lots more folk to
> > help review the outstanding patches.
> 
> The underlying concern here seems to be for ensuring mid-level community
> contributors to get visibility onto their non-sponsor-ready
> (non-debdiff) patches.  The implication here is that these are lost in
> the noise, and no one is paying attention to the problem of getting
> attention onto these patches.  This is not true.  People *are* concerned
> about this, which is entirely why so many of us have been helping make
> the +patches view in launchpad a reality.
> 
> This new feature is based on a patch report tool I've been using for
> X.org for several months now, and I can attest it's made a great impact
> both in increasing the sponsorship time for X patches and has made
> inroads at clearing the stale patch backlog, and this is with only an
> hour or two of my time each week.
> 
> Even if no special patch review process were in place, I strongly
> believe that just exposing the patches via +patches is going to
> stimulate a lot of needed attention on patches.  The ability to sort
> them by age is explicitly designed to help make it easy to give patches
> timely attention.  The feature of being able to use +patches on teams as
> well as on specific source packages is with the intention of giving
> visibility to patches in infrequently reviewed source packages.

Oh wow, I didn't +patches worked in a person / team context[1].  That's
really awesome.

[1] https://bugs.launchpad.net/~ubuntu-reviewers/+patches
    https://bugs.launchpad.net/~ubuntu-server/+patches

-- 
Brian Murray                                                 @ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100308/bb3d63f1/attachment.pgp