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

[Scott Kitterman]

On Sun, 31 Aug 2008 22:08:52 +0100 James Westby <jw+debian at jameswestby.net> 
wrote:
>On Sun, 2008-08-31 at 15:46 -0400, Scott Kitterman wrote:
>> >With update-manager, on a fast connection, a lightweight checkout takes
>> >about 10 seconds vs. apt-get source at about 4 seconds.  That's not bad 
at
>> >all, and Bazaar hints that it might be even faster once the branch 
format 
>> is
>> >upgraded to the latest.
>> 
>> Except for the small minority of packages that are routinely touched by a 
>> lot of people, I don't see any advantage that would cause me to be 
>> satisfied with waiting any additional amount of time.
>
>I recently had a couple of sponsorship requests that went untouched for
>almost two months, with the packages uploaded a couple of times each
>with that time. As I was dogfooding I was able to integrate those 
>changes with a single command (after importing the new versions,
>which is not a step that anyone else would be expected to do). I also
>had a available a tool specifically to inspect the changes and resolve
>conflicts where they arose. If I hadn't been dogfooding I would have
>had to download source packages, and used debdiff and patch to
>approximate the same thing, and had less help in investigating the 
>changes.

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.

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

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

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

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

>On Sun, 2008-08-31 at 16:25 -0400, Scott Kitterman wrote:
>> We have a very good revision control system with a capable and stable 
>> toolset in our archive.  Admitedly it's not very reversion friendly,
>but it 
>> generally does the job.
>
>I'm not so sure. I'd never say it didn't work, and work well for many
>things, but I often find it lacking.

I guess that's a big part of the difference.  I think it works pretty well.

>> IMO the question isn't version control or not, but is the benefit 
>> associated with another layer of complexity and granularity worth it.
>I 
>> believe that ouside of a core of packages that are routinely touched
>by 
>> many people (I'd guess this is at most 2 ot 3 percent of the archive)
>the 
>> benifit is at best undemonstrated.
>> 
>
>I would partly agree, I think it is undemonstrated, but not "at best".
>This is one thing that I will be working on.

I say at best because many disadvantages are quite clear to me.

Scott K