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

[Scott Kitterman]

On Mon, 1 Sep 2008 10:34:45 +0100 Matt Zimmerman <mdz at ubuntu.com> wrote:
>On Sun, Aug 31, 2008 at 06:10:21PM -0400, Scott Kitterman wrote:

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

In Universe, except for the last one these are all atypical.

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

I don't the syncs from Debian/upstream updates are particularly relevant 
(except for the forensics use case that Colin mentioned in another message 
in this thread).  The case where I see a clear win for DVCS is packages 
with multiple people working on them at the same time.  It is generally 
quite a challenge to keep the changes straight.

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

I do have a bias, but it isn't anything particular to Bazaar.  My bias is 
against having to learn new tools.  I don't qualify that as fun.  I have 
not used Bazaar enough to have formed any specifc opinions about it beyond 
too slow (there has been a lot of testimoney that its faster now, but most 
of the benifit seems to come from knowing what options to use).

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

Since we're planning on maintaining the Ubuntu branches on alioth, there 
would have to be some way to indicate that changes should not be added to 
the Bazaar repository, but to the Git repo on alioth.  Otherwise the repos 
would get out of sync.

In this paradigm, I don't think continues as it does today is an option.  
We have to have a way to mark packages as maintained elsewhere (and then 
import from there so there is a correct history available).

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

1.  New toolset to learn which takes time, causes a productivity hit during 
the learning process, and may increase error rates.

2.  Slower.  This is apparently getting better, but I think is still a 
problem.

3.  Potentially complicates inter-distro collaboration (I think this is 
solvable - see the pkg-clamav discussion above)

As Colin points out, use of this new facility is entirely optional, so I 
don't need to get too stressed out about it in the short term.  As I said 
in another message, I don't expect to block this change.  I just want to 
make sure it's thought through.

Scott K