Distributed Development toolset [was: Re: ArchiveReorganisation and sponsoring]
mdz at ubuntu.com
Mon Sep 1 10:34:45 BST 2008
On Sun, Aug 31, 2008 at 06:10:21PM -0400, Scott Kitterman wrote:
> I have no idea what dogfooding is unless it relates to experimenting with
> using bzr and 'eating your own dogfood'. I fear it's some bzr specific new
> way of doing stuff that I'm shortly going to be forced to learn.
It's shorthand. See http://en.wikipedia.org/wiki/Eat_one's_own_dog_food
> >Trading off the extra time that you spend waiting to grab the source
> >to sponsor such a change, with the reduction in time that I had in
> >integrating the changes, and the better experience I had while doing
> >it is something that I, as the sponsoree, would appreciate. It doesn't
> >take in to account any benefits that you may get as the sponsor from
> >the new system either.
> This already puts you into the class of packages where I will conceed the
> potental for benifit is higher. Most packages get zero to one manual upload
> per cycle and it mostly boils down to examinig and understanding a diff.
> Currently I get that diff handed to me in the sponsorship request. I don't
> see a VCS making it easier.
For the simplest case, it should be no easier or harder. Fetching a diff
from a Bazaar branch is no harder than downloading a bug attachment (they're
both just hyperlinks).
Some cases where it could be significantly easier include:
* The package has been updated since the patch was created, and it needs a
* There is more than one patch outstanding to include
* The patch requires changes before it can be included
> >Changing the system will always bring with it a new set of trade-offs
> >and compromises, and not everyone can win all of the time. You are
> >correct that in getting the source of a package to sponsor, where you
> >have never touched the package before, you will always have a penalty
> >with this change.
> Yes and I don't see an upside benifit outside the small minority of
> packages that get regularly touched by multiple people.
This is not even a minority, much less a small one. Most packages are
touched by at least the Debian maintainer, upstream, and one or more Ubuntu
developers during a typical development cycle. Many also receive
third-party contributions, and I expect that more would if the process were
> >The aim is obviously to minimise these penalties, while getting us
> >the benefits that we want. Does the situation that I outlined above
> >present a trade-off that gets us overall benefit? What are the
> >differences when the sponsor touches the package all the time, but the
> >sponsoree doesn't? When both work on the package all the time? What
> >about the time investment from everyone learning some new tools? From
> >working around and fixing the bugs that we hit along the way?
> So far (except as noted) I don't see any advantage. The cost is cimpounded
> be the selection of what is (for me) an Ubuntu unique VCS. If a more
> standard tool had beeen selected, I could at least consider that I'd get to
> leverage the time spent learning in other places.
Fortunately for us, Bazaar is very easy to learn, particularly if you've
used other version control systems.
I can't help but get the impression that you're biased against Bazaar,
> Finally, we are in the process of setting up a joint Debian/Ubuntu Git repo
> for clamav (pkg-clamav on alioth). How is this supposed to work with
> efforts like that (move to Launchpad is a non-starter)?
There are at least two options: 1. everything works exactly the same as it
does today, or 2. the git repository is imported.
> I say at best because many disadvantages are quite clear to me.
The only one you've pointed out so far is that it involves Bazaar, which you
see as a disadvantage. What are the others?
More information about the ubuntu-devel