[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Uploading new packages to Debian instead of Ubuntu [was Re: Skeletor?]



Hiya,

[ ccing debian-derivatives: This is a thread[-1] which started on
ubuntu-devel, and which I've turned into a thread about uploading new
packages to Debian instead of Ubuntu directly. It's not really about
Canonical software, more general packages.

Input is sought about your POV on this. Specifically whether you
think, in general, that us redirecting contributors from REVU (our
mentors equivalent) to Debian is something that should
happen/continue. ]

Replying to both mails in one.

On Mon, Aug 02, 2010 at 02:49:10PM -0500, Micah Gersten wrote:
On 08/02/2010 02:35 PM, Paul Sladen wrote:
On Mon, 2 Aug 2010, Mackenzie Morgan wrote:
pushing more for the packages to go to Debian first and then sync

Turn-around times have been one suggestion /why/ pushing to Debian in the
first instance does not happen enough---it is a lot easier to manipulate an
upload directly than wait for it to be proxied via a third-party (but with
REVU it could be argued that there is already that third-party).

To short circuit the difference in delay period between 'dput ubuntu' and
'dput debian' + sync back would effectively need a skilled DD able to act as
that proxy for new packages;  and most of the people of sufficient calibre
are probably already working on their personal packages, or $dayjob packages.
It's likely to be mind-numbing, which probably means bribing such a willing
individual.

As we are talking about individuals who do not have archive access
themselves, and given that the delays for REVU processing are
astronomical (tending towards infinite?), I don't think we need to be
concerned about increasing the turnaround time.

I don't see why it should be one single individual who does all of
this sponsoring. It only seems fair to Debian — given that we are
proposing to put stuff in their archive too — that we ask our
contributors to integrate properly, and that means breaking out into
the wider Debian world. Most DDs are willing to perform sponsoring
and, even better than that, there are packaging teams[0] which I've
found to be very welcoming to new contributors.

That one individual would be ultimately signing their name on lots
of packages, diluting their reputation if long-term maintenance doesn't end
up being forthcoming after they're marshalled the initial uploads.

Back when people like Scott and mjg59 were still DDs I found it relatively
easy (and therefore not overly onorous) to get uploads done on a
semi-predictable turn-around.

Actually, in addition to what I've said above, we now have the
#debian-ubuntu channel on OFTC set up. I believe that one function of
this channel could be to facilitate sponsorship in Debian. There's
also the Derivatives Front Desk[1], which is part of the same
initiative.

The question is, how to return to that situation of a semi-reliable 24-hour
turn-around without forcing everyone through the Debian New Maintainer
process in parallel.  Presumably the reason people are following the
/Ubuntu/ path in the first place is because of a perception of an easier
welcome with gradulated steps to direct involvement.

There are many great things that MOTU hopefuls and MOTUs can do, but I
don't think that (in general), maintaining entirely new packages
has proved to be one of these things.

	-Paul

Another side of that argument is, do we really want to take in a lot of
packages without that maintenance commitment?  The nice thing of pushing
through Debian is that someone is committing to maintaining the package.
Also, I think bdrung or someone said in -motu that make sure the
packaging is up to standards and then push through Debian.  Without the
actual commitment of maintenance, MOTU ends up with a lot more work to
do.  Maybe we should find a way to get more MOTUs in the position to
sponsor uploads in Debian as well?

I agree. Historically we have been really quite bad at maintaining
packages in Ubuntu: experience shows that people lose interest after a
short while and stop caring for uploads. There are no mechanisms to
catch this, and with our team development model there's really no way
to exert pressure on a particular individual to perform work
anyway. It's not clear if having ones name on a package in Debian will
make this situation any better.

One of my Big Things is contributing to Debian directly instead of
making uploads to Ubuntu. I think that MOTU functions best when it
performs a QA role, and that everything is so much smoother when work
is done as far upstream as possible. Most packages — especially ones
that turn up on REVU — will work on both distributions using exactly
the same source package.

To bring this mail back to the original post in the thread, I don't
think that REVU days or a REVU sprint are solutions. I think that
reducing the use of REVU is. You may argue, fairly, that this
increases the barrier for new contributors. But that's OK. Maintaining
a package is hard work. It requires commitment and graft from one or
more people. I believe that each package needs someone (be that an
individual or specialised team) caring for it. I believe that our
model doesn't provide for this. I further believe that,
philosophically and relating to being good FOSS citizens, we should be
doing our packaging work where most people can benefit: in
Debian. There is room for us to be flexible here, too, when the
situation demands it.

People are making an incredible contribution by developing new
packages for us. We should be careful not to demotivate them by making
this feel like jumping through hoops. It really is the right thing to
do, benefits more people and will actually lead to better quality
software packages in the end (in the main, you will find your
specialised Debian sponsor to be more knowledgeable about your
particular domain than a random MOTU).

Sorry for turning this into a soapbox-style diatribe. :)

Ta,
Iain

[-1]
https://lists.ubuntu.com/archives/ubuntu-devel/2010-August/031034.html
[0] http://wiki.debian.org/Teams#Packagingteams
[1] http://www.debian.org/News/2010/20100629

Attachment: signature.asc
Description: Digital signature


Reply to: