Future of REVU and Debian Mentors

[Jordan Mantha]

On 8/3/07, Reinhard Tartler <siretart at ubuntu.com> wrote:
<snip>
> 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.

Well, I don't exactly agree. We don't need bzr-builddeb or hct for
what we're proposing, although it's probably nice, and a lack of a
decision is to be expected when there are several competing ideas and
no immediate need to decide. If we need to decide we can. Simply
putting debian/ in a bzr branch with a file that has the URL for
upstream tarball (which should be in a PPA) would work.

> [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!

That's true, but flexibility often leads to confusion for the
contributors. "So your saying I can use REVU or Launchpad or my own
web server? Which one is best?"

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

Well, tbh, I'm a bit sad that we need to divert energy from actually
doing MOTU work to writing web apps, especially when they don't get
done. You and Stefan did amazing work on REVU and I think all the MOTU
world is thankful for it, no doubt about it, but REVU2 hasn't seemed
to get going and I don't see people working on it. Is there enough
interest and ability to write apps like this? If there is then great!
If not though, rather than hobble around with "One day we'll get it
done" maybe we should quite while we are ahead and look to somewhere
else for what we need. I'm proud of what MOTU has done, but I think we
need to be practical as well.

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

I totally agree. I think small scripts are great. I'm more hesitant
about webapps as I think that immediately cuts down on the number of
contributors. Most people in MOTU Land can write/hack a shell script,
but a lot cannot write a webapp, and probably fewer can do it well ;-)
This is why I was excited about your django suggestion as perhaps that
would make it easier for people to contribute.

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

I totally agree. As I've said before, I don't think Launchpad will
never fully meet all of MOTUs needs, it's just too general for that.
What I'd like to see is the MOTU have a set of scripts and webapps
that "fill in the gaps" for things we need but Launchpad doesn't
provide. Obviously REVU was built as such, but perhaps it's time to
move REVU to a frontend for PPA and bzr branches.

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

Yes! I agree. I also think it needs some direction though. People
starting projects, but often do not finishing, scripts/apps before
they even know what's really needed can be a problem. One of my
biggest gripes with FLOSS, in general, that I have is that people
often don't "finish" anything. It's just perpetual Beta state, or
maybe more often Alpha, and it's all constantly changing. It often
comes off as "half baked" or mediocre. In your list of past projects,
with the exception of DaD, I think all of them are in various forms of
being unmaintained or undeveloped. So lets get a set of useful tools,
lets properly document them, and package it up. Perhaps a wiki page
with needed tools would help organize?

-Jordan