Re: Need for launchpad
On Fri, Jan 13, 2006 at 12:41:29AM -0800, Steve Langasek wrote:
> Now, it may be that this is an unrealistic pipe dream on my part that's
> incompatible with Ubuntu's goals/release schedule, but it seems to me that
> everyone involved would get more mileage out of the "giving-back" process if
> there were more emphasis on trying to get changes made in sid *before*
> changing things in universe, wherever possible. I realize there are some
> practical issues on the Debian side that would need to be addressed to make
> this a reality, and I know there are plenty of cases when Ubuntu won't be
> able to wait for Debian before making particular changes, but I think it
> would greatly mitigate the concerns over divergence if people viewed
> universe as less of a sandbox for innovation than they seem to today.
I wouldn't say that it's quite a pipe dream, but I think it's an
oversimplification. I'm puzzled that you seem to admit that this approach
isn't really practical today, for reasons beyond the control of Ubuntu
developers, and yet are still disappointed that it isn't happening that way.
It may be that the issues are more obvious to me, given that I have
substantial first-hand experience with both Debian and Ubuntu development.
I realize that to many Debian developers, Ubuntu is a black box, because
while our development process is just as open as Debian's, they simply have
no interest in it, and I think this leads to many of the misunderstandings
which surface in threads like this one.
By way of illustration, consider this (intentionally) oversimplified view
from the reverse perspective:
If you want Ubuntu changes to propagate into Debian more quickly, the
mechanics are very straightforward. Queue all Ubuntu source uploads,
build, sign and upload to Debian incoming. Ubuntu uploads of packages
inherited from Debian are versioned in an NMU-ish way where a following
maintainer upload to Debian would override it. If you're concerned about
branding changes (which, by the way, are few and far between on an ongoing
basis), you could apply the same heuristic used in the Ubuntu patch
archive to flag uploads which look like branding changes, and eyeball the
changelog before letting them through. Each time one of these uploads is
made, generate a debdiff relative to the existing source package in sid,
and email a debdiff to the BTS with the patch tag. Ubuntu changes are now
promptly made available in sid, and all of the patches are filed in the
BTS. Done and done.
It sounds awfully efficient compared to managing hundreds of patch queues by
hand between individual developers, but anyone who has spent time in Debian
can easily spot the holes in it. Likewise, a proposal that Ubuntu
developers should put their changes into Debian instead sounds simple, but
to an Ubuntu developer is obviously impractical.