Distributed Development toolset [was: Re: ArchiveReorganisation and sponsoring]

[Matt Zimmerman]

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
   three-way merge

 * 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
more lightweight.

> >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,
though.

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

-- 
 - mdz