sistpoty at ubuntu.com
Mon Dec 11 23:09:51 GMT 2006
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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20061212/4d0517a2/attachment.pgp
More information about the Ubuntu-motu