Role of the Sponsorship Queue

[Emmet Hikory]

Daniel Holbach wrote:
> On 04.03.2010 18:43, Emmet Hikory wrote:
>>     Having to subscribe a team is more complicated than not
>> subscribing a team.  Creating a process that discourages developers
>> from reviewing the patch queue reduces the people looking at patches,
>> and further reduces the people we believe to be best suited at review
>> to review patches.
>
> How do you think we realistically solve this problem? It's all fine and
> good to look at it from a theoretical point of view, but how do you get
> developers who are not even willing or interested in keeping up with
> sponsoring to also care and look at a bunch of
> patches/not-patches/stuff-that-might-fix-something? Instead of caring
> about one queue, they're now supposed to take care of two queues.
>
> We discussed this at UDS and Brian and others came up with an idea how
> we can try to fix the problem by getting more people involved who can
> help to triage those patches. We need this help from others.

    I agree with everything in the UDS session *except* that we
shouldn't be expecting developers to participate in this wok as well,
and that we shouldn't be expecting developers to take the final step
(integrate several patches into a candidate and upload (with
sponsoring if necessary).  The right way to solve the problem is to
actively promote the reviewers queue.  To point any developer who is
bored to the reviewers queue.  To make the reviewers queue an exciting
place to get started.  I believe the sponsors queue will work much
more smoothly, and without so much push if it only contains candidates
submitted by developers who are ready, able, and willing to sort anty
issues that may be discovered (assuming they aren't so trivial that
the sponsor oughtn't just upload with the tweak).

>>     The ubuntu-universe-sponsors queue gets to zero several times a
>> cycle.  I believe part of the reason that this happens is because the
>> guidelines for processing this queue encourage developers to
>> prioritise uploads of stuff that is ready to upload, and remove stuff
>> that needs work from the queue (subscribing themsellves and following
>> up later).  That the main sponsors queue doesn't get unclogged is not,
>> to me, a good argument for why it makes sense to encourage
>> non-candiate patches, but precisely the opposite.
>
> What do you mean by non-candidate patches? If we need to change the
> workflow for sponsoring we can certainly discuss that.

    A "candidate upload" is something that could just be uploaded.  To
save space in the librarian, we encourage those who can't directly
upload to submit this in the form of a debdiff or diff.gz.  That these
end up being "patches" is mostly accidental.  A "non-candidate" patch
is a patch to fix some specific issue.  My personal feeling is that
most candiidates should include *several* fixes, from various sources:
one upload per patch or issue is just a waste of buildd time.

> I agree that it would be nice if all developers would be able to look at
> all the bugs, at all the patches and all the branches of the areas of
> Ubuntu they take an interest in.
>
> Having put *a lot of effort* myself into getting people to buy into the
> idea of sponsoring and reviewing patches for others, I don't think you
> will get people interested in also caring about a loooooooong list of
> random patches... it might work for some though. And to be frank: in
> this already very long discussion I didn't see any other half-way
> serious attempts to solve the problem of those 2000 unattended patches.

    I've also put a lot of effort into this.  I have not encountered
your difficulties with getting people to sponsor.  I believe this to
be because I documented a procedure (in gutsy) that specifically
excluded any non-candidate patches from being eligible.  I've also
worked with many folk to review patches, and I have found that it's a
rare developer who isn't happy to work with someone else's patch and
get it integrated, although everyone seems to agree that it's more
work to start from a bare patch than from something a developer has
already put through all the rights channels and fully investiated.

> I personally think it's unfair to have a theoretical discussion about
> what would be nice and what developers could do in an ideal world, if it
> blocks a spec from UDS that tries to get others involved to help us fix
> the problem.

    When the spec was discussed at UDS, I made my views clear.  I did
not ave the impression that the results of the discussion included
stuffing non candidate patches into the sponsors queue.  Had this been
made clear to be before, I'd have argued against it earlier.  I do not
see how the presence or absence of a spec has any relation to the
merits of the discussion.

-- 
Emmet HIKORY