Distributed development toolset (Re: ArchiveReorganisation and sponsoring)

[Steve Langasek]

On Sun, Aug 31, 2008 at 11:56:10PM +0100, Colin Watson wrote:
> A number of us are already maintaining various packages in Bazaar:

>   https://wiki.ubuntu.com/BzrMaintainedPackages

> Some people have had problems and have gone back to their old toolsets;
> some people have been happy with it and find it speeds up both
> collaboration and individual development.

> Personally I absolutely swear by revision control for packages, and
> indeed was trying to use it everywhere I could long before we started
> considering the current plan for a global import of all packages. I've
> been actively working to produce accurate imports of the various private
> history archives I keep of my Debian packages into public Bazaar
> branches simply because it's obviously superior to my current hodgepodge
> of tools. (Note that I still use many of the "old" tools, e.g. debuild
> and dupload, and plan to continue doing so as there's no reason they
> should need to be superseded just yet; it's just that I also use
> debcommit each time I make an intermediate change.)

A decade ago, everyone was using CVS for revision control of their Free
Software projects.  And I used it, and I was happy; merging between branches
and correlating commits among multiple files was time-consuming, but I had
mastered these processes (at least as well as most), and I didn't know any
better and there wasn't anything better available anyway.

Then subversion came around, and debian-installer started using subversion,
so I started using it too.  And then I wasn't happy anymore, because some
things were better than CVS and some things were worse, and at the same time
I was spending more and more time working with upstreams of large projects
where it would be useful to have a shared revision history between Debian
packaging and upstream, and everyone was talking about distributed VCS but
the technology just wasn't there yet.

Now I've begun converting the packages I maintain to bzr, and I'm downright
ecstatic at how much more effective this makes me.  Using bzr-svn and
bzr-cvsps-import, I've even been able to rescue the Debian history from the
frankenstein pkg-pam repo we'd been using, and instantly become way more
productive besides - contributing significantly to the ease with which
the pam-config-framework spec was implemented for intrepid, despite pam
being frozen in Debian for lenny.

If one doesn't think that fine-grained revision history is necessary, then
they might not agree with my conclusions; but I can't see someone taking
that position if they work on a package that sees any significant amount of
development between releases (either upstream or Ubuntu).

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org