Review Process

[Stefan Potyra]

Hi folks,

I've just been looking over the proposed process from Daniel, and tbh I don't 
think it will - in its current form - help in any way to improve the current 
situation with new packages. Nonetheless, there are some bits, I like with 
it. Please see this as constructive criticism to get the new process for 
universe in a good shape soon.

To understand the whole problem, I'd first of all like to take a look behind 
the idea of the reviewing process:

Imho the review process currently serves four goals:
1) get more software into ubuntu
2) keep the (new) software in ubuntu in good quality
3) teach motu-hopefules how to make good packages
4) "hire" more motu's based on their good packaging work

The bottlenecks behind the current process are imo:
1) packages don't get reviewed often enough
2) packages often sit stale on revu and don't get any feedback at all for a 
very long time
3) the throughput of revu is very low.

Imo none of these three issues can be solved with the new process. But the big 
questions remaining is, how to solve these problems?

Well, tbh. I don't know really myself. However here are some thoughts:
For 1) doing more revu-days might help.

2) could get fixed by allowing non motu's to do initial reviews as well.

And for 3) I don't see a clear solution. Basically this problem is imo caused 
by the bad state some packages are initially in and because of problem 1). It 
might help, if packages from non-motus would only require one vote and 
packages from motus wouldn't need to go through revu, but this might be in 
contrast to goal 2).

Finally, it might also help to do motu-school sessions for packaging to get 
goal 3) covered better outside of revu. Maybe motu-school sessions might even 
be held in a seminar like manner (dunno if that's the same term in english) 
where motu-hopefuls hold the actual lessons and motu's will review the 
lessons in question prior to it and give comments during the lessons to 
correct possible errors or make things more clear. But that's just a crazy 
idea from me.

Ok, given this, I don't think the new proposed process will help because none 
of the 3 problems are covered with it.

Apart from that I further believe that it creates more problem than it solves:

1) abstraction from sourcepackage to bzr-archives
To serve goal 3), it's imo vital to provide a method that's very close to 
working with packages for ubuntu. In universe most packages are just plain 
source packages w.o. any bzr archive behind them. Also since debian uses 
source packages, this knowledge is highly useful for merges as well.
Also lp only accepts (at least to my knowledge *g*) source packages. This 
makes this knowledge imo pretty vital for a motu to be.

With revu, you are forced to learn the basic stuff about source pacakages: 
You're forced to upload signed source packages (almost) like to the real 
archive.

2) It's harder for the reviewers to check the complete package. Unless we have 
some means (maybe a script?) to fetch a bzr-branch and turn it into a regular 
source package, this makes it harder for a potential reviewer to testbuild 
the package and get a complete picture of the resulting source package. For 
revu I do "dget <link to dscfile>" and have the source package at hand.

3) I personally like to make separate comments to a specific version of an 
upload. I haven't found out how this is addressed via the proposed process, 
maybe someone can enlighten me there. Ideally this could be done by s.th. 
like a bug report that's referred to right next to the branch in question. 
That way we would get an email-interface for free :).

4) While it's nice to have a good solution provided by lp, this also means 
that we cannot fix any bugs/inconveniences ourselves. We also cannot add 
features to it directly.

Imo 2) and 3) are easily solvable. 4) isn't needed if the lp solutions really 
good, but I don't see a way how to address 1).

Things, that I'm really missing in revu though, and that would be a great plus 
for the review process:

* for packages already in the archive, revu sucks. Also for merges. What would 
be really helpful is to have a debdiff to the latest debian and/or ubuntu 
version of the proposed upload.

* orig-tarball: I always check, if the orig-tarball is in fact the same thing 
as the upstream supplied one. That's a tedious task though, as it usually 
involves looking around various urls.

* autobuilding: There should be a convenient way for a reviewer to have the 
package autobuilt. With revu-tools we have at least a basic method to do this 
(I must admit, that I've never tested these myself), but ideally there would 
be just a button to have it autobuilt on all ubuntu supported architectures.


Apart from that, I like from the proposed process, that people will learn how 
to use bzr. That's definitely a big plus for goal 3). 

Maybe what would really benefit the current review process would be a mixed 
solution between revu and lp:

The bzr-branch could be used for motu-hopefuls and motus to prepare a package. 
They can thus easily cooperate on the newer package and help each others out. 
They would also learn bzr as a side effect.
Basic problems could then be corrected while working on the branch.
Once the package is in shape, it gets submitted to revu. There one motu will 
give a final +1 and upload the package to universe (or reject it). Packages, 
on which motu's work as well, could go directly into the archives, 
circumventing revu at all (though that rule might still be debatable.)

What do you think?

Cheers,
     Stefan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20061212/4d0517a2/attachment.pgp