Role of the Sponsorship Queue

[Mackenzie Morgan]

On Mon, Mar 8, 2010 at 5:39 PM, Brian Murray <brian at ubuntu.com> wrote:
> On Thu, Mar 04, 2010 at 10:32:16AM -0800, Bryce Harrington wrote:
>> 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.

How does this work? Is it just "person/team is subscribed to the bug"?
 Visiting /~kubuntu-dev/+patches and seeing bugs with patches that are
filed on packages to which ~kubuntu-dev has upload rights would be
nifty...

And having just finally finished reading all of this long thread...
I see value in having separate lists--or rather subset lists.

Debdiffs that are just about ready to go can be handled fairly
quickly.  Having a way to see just these is useful (that'd be the
sponsor queue).

"How to turn a known-good patch into a debdiff" is a good intro for
developers-in-training to get some really basic packaging stuff under
their belts.  So at this point the question becomes, "known-good
patch? How do we find those?"  For -proposed there's a
"verification-done" tag when a new package has been tested. For
patches, I see "patch" (which is used as "patch needs to be
reviewed"), "patch-refused", "patch-needswork", and
"patch-upstreaminput".  I don't see a "patch-good" tag for reviewers
and random helpful people to say "hey, I tried the patch and it
works!" I'm looking at [1]. Of course, they could comment that, but I
can't filter bugs in LP like that ;-)  So I think we need to add a
"patch-good" tag to the reviewer & bugsquad team processes and the
wiki page for after a patch has been tested.

OK, you might be thinking "but if they've tested the patch and
verified it works, why don't they just make the debdiff themself?"

Answer: Not everyone who can code and read code well enough to review
a patch knows how to make a debdiff.  Further, not every user capable
of applying a patch and typing "make" should need to know how to make
a debdiff to say "that patch fixes my problem!"

So, looking back at the list way at the start of the thread, I'm
thinking that the results of steps 2-5 should be one of those
"patch-*" tags, but now with "patch-good" as an option (because
otherwise the patch gets tested and then gets lost again).  Patches
ready for step 6 would then be able to be found with a simple tag
filter. Step 6 can be completed by any interested party who would then
subscribe sponsors if they cannot upload it themself.  At that point
someone with upload rights can see a sponsor queue that is nice & tidy
with the patches already tested and turned into a debdiff.

If you've got upload rights and you only want to see stuff with
debdiffs, look at the sponsor queue.
If you want to see known-good patches & debdiffs, filter on "patch-good" tag.
If you're in the mood to tweak broken patches, filter on "patch-needswork".
If you want to see everything, look at +patches.
How much effort you want to put in at the time can determine which
list you look at.

[1] https://wiki.ubuntu.com/Bugs/Tags

-- 
Mackenzie Morgan
http://ubuntulinuxtipstricks.blogspot.com
apt-get moo