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

[James Westby]

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.

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.

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.

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?

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.

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

Thanks,

James