Re: Role of the Sponsorship Queue

By Scott Kitterman at 03/04/2010 - 07:32

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.

2. It misses the chance for people who think they don't think they want to become Ubuntu developers to discover they are wrong.

Scott K

Development

11 comments

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.

I agree that the model I describe serves those who may discover
that they really do wish to be Ubuntu Developers badly. I'm not
convinced the current model serves them that much better. For those
few who come to IRC and talk to us, we can certainly help them through
building a candidate, submitting it, etc. For those that don't, we're
lost, but I assert we're not more lost than we are now, and certainly
not more than if we try to push all the patches into the sponsors
queue.

It's almost like arguing against funding public health care since it
denies people the enjoyment of learning first aid. ;-)

Having more Ubuntu developers is a good thing, and certainly having
training for this is also a good thing. But relying on the sponsorship
process as the primary way to accomplish this is not going to be a net
win. It often takes longer to explain how to do something than to just
do it, so since the primary goal of sponsoring is to get the sponsoring
queue cleared, I expect the motivation is stronger to do the fixes
yourself (or reject the request) than to spend time educating.

Indeed, I think if there is expectations that the sponsoring process is
a primary training tool for Ubuntu developers, then this is not good.
It's like learning a college course by trying to take its final exam.
You may well learn something, but more likely you're going to find it
scary and frustrating.

Identifying potential candidates for becoming Ubuntu developers really
is not that hard, and can be done programmatically. Query for people
with karma > 500 and karma-this-month > karma-last-month, and who have
attached 3 or more patches to bugs, and who are not already team
members. You can also probably examine their existing team memberships
to programmatically identify people more or less interested in this.
Now you can bulk-mail all those people and encourage them to attend
Ubuntu developer training sessions or point them at a paint-by-numbers
procedure for doing debdiffs or something.

Bryce

I've read the whole thread =) Loads of stuff

We are mixing patch qualification & patch review & patch sponsoring

I think pre-patch review should be done by bugsquad

Patch author uploads patch and subscribes bugsquad (or someone else
for pre-patch review)

Steps for pre-patch review
a) check that problem still exists
b) check that patch or debdiff apply cleanly to latest package
c) check that package builds
d) check that it fixes problem
e) check that patch is sane and is the right-thing-to-do (optional)

If fails on any of these steps -> canned responses & unsubscribe sponsor team
If passes all of these steps -> subscribe sponsor team

Sponsor team - Steps for patch review:
e) check that patch is sane and is the right-thing-to-do
f) any other stuff sponsors do

If fails -> comment & unsubscribe sponsor team & canned response (eg
subscribe sponsors after all issues address or something like that)

If pass -> upload

I've used the new bugs with patches pages on launchpad and after
poking around I've realized there is a big melting pot of good/bad
patches, patches against old versions, patches for no longer existing
bugs. So to help everyone it would be great to work with bugsquad to
storm through the sponsor queue / all patches to at least identify
valid candidates and give a sense of direction for the rest of patch
authors.

ps.
Now to make this really awesome it would be amazing to use advance
free form build recipes & build latest ubuntu package with this patch
downloaded and applied into my ppa so I can test it ;-)

This is not exactly what lucid-qa-fixing-bugs-with-patches (and
<a href="https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews" title="https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews">https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews</a>) is talking about
but it's quite close and we could make changes to it if necessary.

~ubuntu-reviewers would be the team that does "pre-patch review" and the
patch-needswork tag is used to indicate that a patch is not ready yet,
so we can have separate working lists and graphs and all the rest of it it.

Features of the process: It leaves the sponsoring queue untouched so
people who just care about that list are fine and still help to solve
the problem, we have different work lists, we invite others to help us
solve the problem.

Have a great day,
Daniel

True

Actually, subscribing bugsquad is unnecessary. I believe the bugsquad
already has scripts to identify new patches and subscribe the team
automatically. And that's a better process since while the process of
uploading a patch is (relatively) obvious, knowing who to subscribe is
non-obvious and requires special process knowledge.

I think there's also a step that should be in there for packaging
patches into debdiffs (or to set up a branch and merge proposal).
See my similar post from earlier in this thread, I think I inserted it
at a point prior to your step (e).

It might also be good to have the procedure differentiate between
packages that have an active Ubuntu team to review patches and those
which don't. In the latter case it might be appropriate to just
redirect the submitter to send the patch upstream or to Debian.
Otherwise even if they make it through steps a-d, they'll get hung up at
step e.

Yep, there is a lot of room for automation in this new process. See my
post early in this thread for ideas. I hope someone gets inspired to do
some of this automation because I think it could make the Ubuntu
development process extremely powerful and convenient.

Bryce

Yes, there is a script that subscribes the ubuntu-reviewers team to bugs
with newly added 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.

Coupled with the patch review that Brian's team will be doing, I think
this is almost guaranteed to improve a lot over the next year. In the
process, it's likely going to generate a lot more demand for sponsoring
of sponsor-ready patches. Given the limited number of people who can do
sponsoring, I think it is right to raise the bar so the sponsor team can
efficiently use their time for the sponsor-ready stuff.

Emmet is right that if people are subscribing sponsors to unready
patches as a special incantation to get some attention to them, that is
just adding bureaucracy for patch authors, and misusing limited time of
sponsors which we really need for doing real sponsoring work. Lets
solve the need for patch reviews with patch review tools and procedures,
not force-fitting them into the sponsorship process.

Bryce

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

[1] <a href="https://bugs.launchpad.net/~ubuntu-reviewers/+patches" title="https://bugs.launchpad.net/~ubuntu-reviewers/+patches">https://bugs.launchpad.net/~ubuntu-reviewers/+patches</a>
<a href="https://bugs.launchpad.net/~ubuntu-server/+patches" title="https://bugs.launchpad.net/~ubuntu-server/+patches">https://bugs.launchpad.net/~ubuntu-server/+patches</a>

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] <a href="https://wiki.ubuntu.com/Bugs/Tags" title="https://wiki.ubuntu.com/Bugs/Tags">https://wiki.ubuntu.com/Bugs/Tags</a>

Actually it's a bit broader than that. Not individual bug subscriptions
but entire package subscriptions. This makes it quite powerful.

So for instance, the team ubuntu-x-swat subscribes to a whole mess of X
packages, which you can see here:

<a href="https://bugs.edge.launchpad.net/~ubuntu-x-swat/+packagebugs" title="https://bugs.edge.launchpad.net/~ubuntu-x-swat/+packagebugs">https://bugs.edge.launchpad.net/~ubuntu-x-swat/+packagebugs</a>

And here's the patches report for this team:

<a href="https://bugs.edge.launchpad.net/~ubuntu-x-swat/+patches" title="https://bugs.edge.launchpad.net/~ubuntu-x-swat/+patches">https://bugs.edge.launchpad.net/~ubuntu-x-swat/+patches</a>

So you see it itemizes all the patches posted to all bugs filed against
all the packages it is subscribed to. Or at least in theory... I know
there are should be about 30 patches listed for non-FixReleased bugs yet
this report is only showing 5, so something's buggy there.

Bryce

I really like this model of having a team subscribed to packages that
they care about as it provides a useful way to create multi-package bug
lists.

Topic	Started
Ubuntu sparc and ia64 ports	1 hour 54 min ago
moreutils: an 'errno' utility	2 hours 15 min ago
Patch Review Day	12 hours 57 min ago
Server Team 20100810 meeting minutes	14 hours 4 min ago
Hey ubuntu-devel, welcome to our Sale. Soviet However to south and	14 hours 38 min ago
Best Sales 2010!	1 day 18 hours ago
Best Sales 2010!	1 day 20 hours ago
ubuntu-devel@lists.ubuntu.com 06% OFF on Pfizer!	2 days 9 hours ago
ubuntu-devel@lists.ubuntu.com 74% OFF on Pfizer!	3 days 5 hours ago

Categories

Archives

Re: Role of the Sponsorship Queue

11 comments