Future of REVU and Debian Mentors

Emmet Hikory emmet.hikory at gmail.com
Fri Aug 3 01:02:00 BST 2007

On 7/30/07, Reinhard Tartler <siretart at ubuntu.com> wrote:
> Andy Price <andy-price at ubuntu.com> writes:
> > At one point I was getting interested in developing REVU but I think I
> > heard a rumour that launchpad was going to be used for reviewing
> > packages in future. Is that true?
> Personally, I don't think this will come in near future, if at
> all. Therefore I feel that it makes sense to work on it in any case,
> since this way, we can adapt it more easily to our needs.
> Curently, my plan is rather to integrate it with PPAs. Currently, the
> REVU2 specs says that it implements an apt-get'able repository. This
> could be changed to "it uses an apt-get'able repository, just what the
> PPAs provide".

    My view of REVU is that it currently provides the following services:

1) dget'able respository for packages
2) Automated keyring check for uploaders
3) Automated execution of lintian and linda
4) Provision of URLs for easy package review
5) Comments engine for packages

    With the exception of #3, I believe these requirements are soon to
be met by LP itself, and would suggest the following workflow as a
LP-specific alternative to REVU:

1) Someone opens a bug with a upstream link and adds the "needs-packaging" tag.
2) A packager marks the bug "In-Progress", and self-assigns
3) The packager prepares an initial revision, optionally commits to a
BZR branch, and uploads to the PPA.  The bug is closed in the
3) The packger adds a comment to the bug with a link to the PPA
location, and submits for sponsorship in the usual manner
4) Sponsors review, and leave comments in the bug
5) The second positive sponsor review results in an upload, and sets
the status to "Fix Committed".

    The advantages of this would be that there would be only one place
where comments and bug status would be visible, that those requesting
packaging of new software would be able to see the progress, and have
a better understanding of when it should be expected, that packagers
and reviewers could subscribe to specific packages for notification of
updates without tracking the entire REVU mailing list, the packager
may review automated build-logs prior to requesting sponsorship, and
that both packagers and reviewers would receive LP karma for the work

    The disadvantages would be the lack of web-accessible links to
internal package files for review discussion, that both the packager
and the reviewer would be expected to run linda and lintian manually
(or perhaps using special reviewing scripts), and that much of the
documentation would need to be updated for the new workflow.

    Regarding the original topic of discussion, I would suggest that
regardless of the utility of a REVU-like tool for Debian Mentors, it
doesn't make sense to use the same resource for Debian and Ubuntu, as
there may be good reasons why a certain upload is better for one
distribution or the other at any given time, those whose review is
required are different, and there are a few different packaging
practices in place that need to be respected.  I'm also not
comfortable with the "Reviewed by Ubuntu" tag for Debian uploads, as I
can easily imagine that a few small mistakes in the use of that tag
could lead to frustration by one-party or another.

    I suggest that DCT's current practice of opening RFP bugs that
point to the Ubuntu package, moving to ITP in collaboration with
Utnubu, and slowly integrating is a better model, as it ensures more
human attention to the package, and respects the cultural differences
between the distributions.

    I'd also like to encourage those new to packaging to work on
bugfixes for existing packages, rather than preparing new packages.
This is often much easier for a beginner, provides a way to
demonstrate one's ability to work well with various packaging styles
(important for MOTU), and allows one to develop one's own opinion of
best practices and understand the choices available in packaging.


More information about the Ubuntu-motu mailing list