Role of the Sponsorship Queue
macoafi at gmail.com
Wed Mar 10 02:49:25 GMT 2010
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. 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
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
"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 . 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.
More information about the ubuntu-devel