Role of the Sponsorship Queue

[Daniel Holbach]

On 04.03.2010 18:43, Emmet Hikory wrote:
> Daniel Holbach wrote:
>> On 04.03.2010 12:06, Emmet Hikory wrote:
>>> Complicating the process by which
>>> a patch is reviewed is not the way to make more patches get reviewed.
>>> Developers asking non-developers to go review patches before
>>> developers do is likely to just reduce the average quality of response
>>> to patch submitters : If developers are good at patch review, we're
>>> removing our best team from the set of reviewers.  If developers
>>> aren't especially better at review, we're telling everyone else they
>>> are second class which can't help motivation.
>>
>> I'm not sure I understand.
> 
>     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.


>     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.

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 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.

Have a great day,
 Daniel