Future of REVU and Debian Mentors
mantha at ubuntu.com
Mon Jul 30 19:46:19 BST 2007
On 7/30/07, Andy Price <andy-price at ubuntu.com> wrote:
> On 30/07/07 14:12, Sarah Hobbs wrote:
> > I'd question why we're encouraging our hopefuls to put in new packages,
> > when for the majority of them don't care for what they're packaging -
> > they're only doing it for the experience - which means that they wont
> > update the package, and in the next release (or sooner) it'll sit in the
> > archive and rot, as no one cares about it.
> The only advantages of packaging for Ubuntu instead of Debian I see are
> that you get to visibly contribute to Ubuntu, perceivably improving your
> "community kudos" and adding to your repertoire for use in a MOTU
> application. Though I'm beginning to see this might be a bad idea. But
> as I mentioned on this list a while ago, I think people wanting to
> package for universe should be nudged in the direction of Debian first
> anyway. I personally found it easier to get a new package into Debian
> than into Ubuntu, presumably because Debian has a more tried-and-tested
> process and a larger amount of potential sponsors. I can see the few
> active MOTUs are rather stretched at the moment.
It would be nice if we could get away from "packaging for Debian" or
"packaging for Ubuntu" as much as possible. There are enough
similarities that it should be mostly just "packaging". So it really
shouldn't matter whether an Ubuntu user or Debian user packages up an
app, it should end up in both, I guess that's what I'm saying. One way
I think we could do this would be to basically stop uploading from
REVU to Ubuntu NEW unless it's Ubuntu-specific. Instead we could
perhaps have a system that forwards the package to Debian with a
"Approved by Ubuntu" stamp on it.
What I dislike seeing is either of the following:
* "Just get your package into Ubuntu because Debian is a pain"
* "You *must* get your package into Debian and learn how to maintain it there"
On some level I think it's unfair for new contributors to have to
learn *two* distros development systems (even though they are
similar). I also think it's a shame, and indeed counter-productive, to
have so many 0ubuntu1 packages in Universe.
> > I'd prefer to see people fixing bugs in *existing* packages. The
> > sponsorship queue is shorter, and it benefits more people. When we have
> > a huge number of bugs in universe, I cant see the point of adding more
> > packages with bugs, which the original hopefuls won't fix, as they only
> > did it for experience sake.
> Couldn't have put it better myself. The amount of needs-packaging bugs
> on launchpad is a tad unnerving, though.
I agree with Sarah that I'd prefer to see, in general, people ensuring
that existing packages are in good shape. Further, I think somehow
perhaps our focus on training up new MOTUs has gotten all twisted
around. New people wanting to get involved in MOTU are most often
pushed towards REVU and pacakging from scratch. I think this is really
not productive at all. It is throwing people in the deep end of the
pool before they know how to swim, IMO. It's also not very productive
for the reviewers either. It's difficult to see people thrash about
trying to learn how to package on REVU.
I think it is much more productive to have people start out with
existing packages. I generally see the order that a Hopeful should go
through as: unmet deps, merges/syncs, FTBFS/bugs, NEW packages. The
reason is that unmet deps are often fairly simple changes (not
requiring patching or messing around with debian/rules too much) and
give an into to what it takes to do a debdiff, get sponsored, and what
debian/control and changelog does. Merges and syncs give you a
broader view of different packaging styles, more about how Ubuntu
works (processes, common Ubuntu changes, etc.). FTBFS and general bug
fixing is where you are dealing more with patching and debian/rules,
you might also be interacting more with upstreams, etc. Finally you
get to packaging a brand new package from scratch. By this time you've
seen how different packages do changelog entries, patch systems, build
helpers. You should also know how to deal with Debian and upstream
fairly well and how the social aspect of MOTU and Debian work. I think
this is where it really becomes productive for both the packager and
MOTU. For the packager they've already seen how they can contribute,
how things work a bit, so they are less likely to get intimidated or
scared off. For the MOTU they should see much higher quality packages
and much fewer update/comment cycles before a package is ready for
Anyway, that's kinda how I view it from seeing almost 2 years of MOTU Hopefuls.
More information about the Ubuntu-motu