Future of REVU and Debian Mentors

[Reinhard Tartler]

This reply is marked to the start of this thread, but directed to all
followups that has been written so far. It expresses my general opinion
on that matter and is therefore not directly directed to Emmet. However,
I'd like to thank Emmet nevertheless for his input on REVU.

"Emmet Hikory" <emmet.hikory at gmail.com> writes:

>     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

Scott Kitterman added to this list:

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

Thank you both for the interesting compilation of REVU feature.

Emmet goes on with an alternative workflow:
>
> 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
> 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".

In general, I like the idea of stressing the use of the
'needs-packaging' bugs. They often contain links to REVU uploads, and it
feels natural to join these resources.

Maintaining a source package in bzr is as well a nice idea. However,
since it seems that we cannot agree on the exact way how to package a
software, and our current tools for managing packages in bzr (read:
bzr-builddeb and hct) definitely need a lot more work for that, I don't
think this is feasible. I tried compiling the different ways of managing
packages in VCSs, which can be found at [1]. The feedback however was,
that there is a big disagreement on the exact mode to be used when
packaging software.

[1] http://wiki.tauware.de/misc:vcs-packaging

I think we can therefore safely conclude that the least common
denominator for source packages are the source package format mandated
by Debian policy, read: *.diff.gz, *.orig.tar.gz and *.dsc. Which brings
us back to the reviewing problems we had before. I don't think it
matters a lot if the packages are hosted by REVU, the contributor, a
launchpad PPA or whatever. Leaving this choice intentionally open brings
us extra flexibility!

Emmet Hikory wrote additionally:
> 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:

Again, this is not directed at Emmet specifically, but to the whole MOTU
community:

I'm a bit sad that there seems to be a general attitude among MOTUs that
we get the tools we are working with crafted by either Debian or
Launchpad. This raises the assumption that there is not much technical
understanding needed for packaging software in ubuntu. I do not think
this is true. I rather think that we should focus more on crafting tools
which aid us in the daily workflow. With 'us' I mean 'we, the community
of Ubuntu Developers'.

Let me rethink about past projects:

 * (obviously) REVU
 * sistpoty's mergeWebTool http://tiber.tauware.de/~sistpoty/MoM
 * lucas multidistrotools
 * Adri200 + Lutins DaD: http://dad.dunnewind.net/
 * ...

I do think there is still a lot of room for crafting dedicated MOTU
tools. The Project [2] is of course a good start! We should stress it
more and work more on extending those tools. As far as I can see, it is
a branch of small scripts for day-to-day tools for Ubuntu Developers. I
expect that many fellow developers have local branches on their
computers where they hack their own tools and merge them back to the
trunk from time to time (where it fits). I imagine that we can also
craft wepapps to aid us, like the examples I listed above!

[2] https://launchpad.net/ubuntu-dev-tools

And please don't misunderstand me. I'm not saying no to launchpad. Au
contraire, I rather say, lets craft tools that fit and extend
launchpad. The launchpad guys are very open for suggestions and
collaboration with other open source projects. If we need interfaces,
I'm sure they can help us in many ways, even if its 'just' with advice.

Thinking further about it, I think this is also a great area, where our
hopefuls can get into action! You absolutely don't need any privilege or
permission or anything to craft tools like I listed above. I think this
is also a good way of showing interest and in the end, qualification for
Ubuntu Developer status! Consider starting or contributing such a
project, it's really worth it!

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20070803/7f3c9b4b/attachment.pgp