REVU: Automated Package Checks

[Jordan Mantha]

On Fri, Jan 23, 2009 at 1:49 AM, Kjeldgaard Morten <mok at bioxray.au.dk> wrote:
> On 23/01/2009, at 00.30, Nathan Handler wrote:
>
>> For those of you who might be unaware, I have taken over Siegfried
>> Gevatter's (RainCT) role of REVU Coordinator. For the past few days, I
>> have been thinking about something, and I want to get the opinions of
>> the rest of the people in the community before taking any action.
>
> ... and kudos to you for taking on this task, Nathan!
ditto

> The REAL problem with REVU is that not enough MOTUs care about it to
> enable us to keep up with the demand for reviews.
>
> IF we want this interaction with the community, this way of meeting
> and training new developers, we really have to do more!

I am fairly strongly against using REVU as an educational tool. IMO at
least, it should be use primary by existing developers to get work
done. The frustration of trying to learn how to package, learning the
Ubuntu processes, and waiting around for feedback mean we're often
just shoving newbs into the deep end of the pool and expecting them to
have fun. I'm not much surprised that they don't come back for more.
It also means we generate a lot of archive "cruft". Besides our
primary duties of keeping packages in sync with Debian and forwarding
bugs and applying fixes, we have almost 800 source packages to
maintain on our own. Given a core group of even 40 developers that's
20 packages *per* MOTU that are needing to be maintained without *any*
help from Debian.

> If we don't, we should consider closing down REVU. Personally, I don't
> think it's a good idea, but it is even worse having a queue of over a
> hundred packages where uploaders are waiting months between review
> cycles! That is detrimental to our standing respect in the community.
> The large number of packages in the "needs-work" section is also
> testiment to the number of uploaders who have given up, and every one
> of those is a potentially useful contibutor lost. Those still hopeful
> of getting their packages processed generally re-upload quite quickly,
> and so their package can wait for another month or two. This is BAD.

I wouldn't want REVU closed down completely I don't think, it's a very
useful tool. What I do think is that perhaps we can rethink the
purpose and process around how we use it. The issues seem to be 1) too
many requests to handle with the resources available and 2) too long
of turnaround time and very variable "results". So here's a "solution"
I've been tossing around in my head:

1) New contributors are not to be encouraged to package from scratch.
If somebody wants to go for it anyway, they will be expected to be the
primary maintainer of the package and should give a rationale beyond
"dunno, I just wanted to package something" for including it in
Ubuntu. MOTU documentation should be fairly clear that generally
people should try some other packaging tasks before try to package
something from scratch.

2) For packages uploaded to REVU from non-developers (in this case I
think developers = ~ubuntu-dev), a developer should be paired up with
the REVU uploader as a primary sponsor. This developer will be
responsible for seeing the REVU process to completion (hopefully
meaning an upload to the archives, but could also be removing it from
REVU if the contributor gives up or the software is outright
unsuitable). The primary sponsor should work closely with the REVU
uploader so they shouldn't pick up too many packages at any given
time. They will also give the 1st ACK.

3) A group of MOTU who may either not have the time or desire to be
primary sponsors will take packages that have been ACKed by primaries
and do the 2nd review and ACK. This allows people who don't mind doing
a one-time review of an already good package to do something on REVU.

4) REVU would need to be modified a bit to handle this workflow. One
thing would be like a package description whiteboard that MOTU can
look at to see if they want to sign up as primary supervisors.
Currently it takes a bit of digging around to find what a package is
all about. It might also be nice to have a little "Sign up as primary"
box that would then subscribe you to the package and let the REVU
uploader know that somebody has taken on their project.

> As someone who has been doing lots of REVUs this cycle, it is quite
> depressing seeing that no matter how hard you work, the list keeps
> growing, and the packages you advocate do not attract a second advocate.

Right. IMO, this is due to flawed process/philosophy. You can't have a
"we'll include *anything*" philosophy, an easy tool to upload too,
random and arbitrary reviewing, and expect it to work efficiently or
effectively, IMO.

> As a temporary measure, to get rid of this long queue, perhaps we
> should only require one advocate for an upload? This is what Debian
> does, and I'd like to suggest a discussion of that on the next MOTU
> meeting.

I really would suggest not doing away with the 2nd ACK. It has often
proven useful. It also gives the 1st ACK a bit of freedom as they know
somebody else will double check their reviewing. Instead of cutting
out the useful bits let's perhaps rethink our philosophy about REVU a
little. One of the things that I'm wondering about is our general "we
don't care *what* it is as long as it's good packaging". While I know
Mark has wanted Universe to represent the entirely of the FLOSS
ecosystem essentially, we simply don't have resources to do that. If
Mark wants to spend some money hiring dedicated REVU people then I'd
more than welcome that, but until then I think we should focus on
processes that adequately reflect where we are today, not where we
hope to be some day. I think asking questions like, "why do we need
this in Ubuntu?", "how is this software different/better than
<existing package>?" might be useful for prioritizing work around
software that is of the most good to our users. It's very hard, though
not impossible, for me to justify to myself wasting MOTU time
maintaining solely a package that only 10 people in the whole Ubuntu
user-base every use.

-Jordan