Future of REVU and Debian Mentors

[Emmet Hikory]

On 8/3/07, Scott Kitterman <ubuntu at kitterman.com> wrote:
> 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.

    Thanks for these.  I was sure my view wasn't complete.  I'd
suggest numbers 6, 8, and 10 are/could be handled by LP, as follows:

6: updates are bugs, and go to the Ubuntu-bugs mailing list.  Further,
if people are interested in specific packages, subscription is an
option (and recommended for packages reviewed).

8: This just requires the appropriate reference in the previous desire
to link a bug to a PPA archive: one should be able to link to a
package without referencing a specific version.  Packagers would be
expected to archive their own packages, once they were no longer
interesting.  Note that REVU doesn't currently allow dget based on the
package name: one must collect the url from the latest candidate.
Also, as comments from uploaders regarding the changes are
appreciated, another link to a PPA location in a bug comment may be
just as good.

10: I'm not sure what extra tools (beyond LP itself) are required.
One just dput's and makes the necessary bug adjustments.  Reviewers
just comment.  If this is about LP not being in Debian, neither is
REVU (although REVU could be packaged, whereas LP will not be soon).

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

    PPAs allow dget (and use of other package management tools, for
that matter).  I'm in agreement about 7 and 9, although I'm not sure
of the value of 7 for reasons previously outlined.

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

    Well, no.  #1 & #2 are currently done in LP, with the current
process.  #3 is currently `dput revu ...`, whereas I'm suggesting
`dput ppa ...`, which doesn't seem that different.

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

    How is it slower than REVU?  To me the time required to leave a
comment in REVU and the time required to leave a comment in LP seem
about the same.  As for setting "Fix Committed", this is currently the
responsibility of the packager, who must watch this mailing list for
REVU upload notification, and make the appropriate change: it doesn't
seem that hard to adjust a bug status to save the effort when
uploading.

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

    Absolutely true.  In the beginning, there was a wiki page that
people were to list packages they wished to have packaged.  These
entries were to include the upstream URL, licensing information, and a
URL for candidate packages.  This was dropped in favour of a LP-based
system, as it was too hard to track well.  I'd suggest that we should
have a strong plan for an alternative method to track packaging
requests prior to moving away from an LP-based system.

-- 
Emmet HIKORY