Future of REVU and Debian Mentors

[Scott Kitterman]

On Thursday 02 August 2007 20:02, Emmet Hikory wrote:
> 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
6) Emailing of comments to a mailing list
7) Online diffs between uploads, even ones with the same version number
8) Automatic unarchiving and association of previous uploads with a new one
9) It's fast
10) It requires the use of no tools not standard to Debian.

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

I'm pretty certain you can't dget stuff from LP, but I've never tried from a 
PPA, maybe that's different.  It also doesn't have anything like 7 - 10 and 6 
is coming, but not here yet.

> 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
> changelog.
> 3) The packger adds a comment to the bug with a link to the PPA
> location, and submits for sponsorship in the usual manner

On revu, this is all done by dput revu .....

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

Slower and more complex than on REVU.

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

It would be equally easy to have all the comments in one place by not putting 
them in LP.  LP is to slow and runs to far behind.  I've already seen one 
double upload with the needs-packaging/UUS approach we're using now and 
people were actually updating it.

Karma is a don't care.

Status for the end user is nice, but no help to reviewers.  Right now we have 
a surplus of people filing needs packaging bugs and a deficit of people to do 
reviews.  I think the priority has to be a simpler, more efficient work flow, 
not adding steps and using slower tools.

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

And the proposed work flow has a lot more moving parts than the we have had up 
until recently.

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

Even if we end up with two instances of the tool due to social issues, common 
tool development would be a good thing and give both Debian and Ubuntu more 
labor to get  stuff developed.

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

How mahy packages get moved this way?

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

I agree with this completely.

Scott K