ArchiveReorganisation and sponsoring

[Colin Watson]

On Sun, Aug 31, 2008 at 03:46:30PM -0400, Scott Kitterman wrote:
> On Sun, 31 Aug 2008 19:30:11 +0100 Matt Zimmerman <mdz at ubuntu.com> wrote:
> >This is where I think we should be headed.  I realize there are some
> >issues with it at present, but as we start to use Bazaar more, we'll
> >be in a better position to put more effort into resolving them.
> 
> Do keep in mind that there are developers that do not use Bazaar at all.  
> For me, as a community developer, the fun factor associated with learning 
> VCS +1 is very low.  To the extent I'm pushed into learning a new, Ubuntu 
> unique toolset, it will probably translate fairly directly into less 
> contribution from me.  This is particularly true since this move away from 
> the Debian standard toolset does not appear to solve any problems I'm 
> actually having.

One excellent advantage of an import of all packages into Bazaar, which
we will be able to take advantage of immediately, is the provision of
logging, diffing, annotation, etc. for all packages in a unified way.

Right now, if you want to find out when and why something was changed -
even just in the packaging, discounting upstream code - you have to
apply guesswork based on changelogs, download whatever versions you can
find in the archive, grovel about in Launchpad's rather inconvenient
interface for fetching old versions of packages, and then attempt to
bisect until you find whatever upload was responsible for the change.

Once we have a coherent import of everything into revision control,
you'll be able either to check out the branch and use 'bzr blame' or
whatever, or use the web interface which I've found to stand up pretty
well against other revision control web interfaces I've used. As a
semi-random example:

  http://bazaar.launchpad.net/~ubuntu-core-dev/console-setup/ubuntu/files

Consider trying to find out when and why a change in the huge and
complicated debian/config.proto script was made without revision
control. (Of course I always write perfect changelog entries but others
may be less virtuous. ;-) ) With revision control, you find the line of
code you're curious about, click on the revision number in the second
column nearby, and there you have the log entry. That's a heck of a lot
better than bisecting by hand in my book, and I want to be able to do it
in the same way for every package.

Other GNU/Linux distributions have this kind of thing at least for their
packaging (e.g. http://cvs.fedoraproject.org/viewvc/) and frankly it
embarrasses me that we don't. I'm actually pretty surprised that you've
never had the need to find out when and why a change was made; is it not
common when fixing a bug to figure out when and why the bug was
introduced, in order to find associated bug reports or to take care not
to regress some other case? Personally, I find that this is *especially*
the case when touching a package I don't know very well, as is probably
the case in universe more than elsewhere.

Note that, at least in the early stages of the Ubuntu distributed
development plans (and, really, the later stages are very mutable in
this respect until we see how the earlier ones go), there is *no* plan
to require all Ubuntu developers to use Bazaar. In fact, we are putting
some effort into making it easy for people to carry on not doing so and
using whatever methods they prefer right now:

  * If you make an upload using only the standard Debian toolset, it
    will be imported into Bazaar. (Yes, you end up with only as much
    granularity in revision control as the importer is able to lay its
    hands on, namely successive diffs between uploaded versions of the
    package. This is usually still pretty useful.)

  * If you commit directly to the standard Ubuntu branch location in
    Bazaar and tag it when you upload, the importer will know that it
    doesn't have to do an import and will leave the branch alone.

  * If there's a clash between an upload and some not-yet-uploaded
    commits, you'll basically end up with two branches and somebody will
    have to merge them.

As far as I have been able to reason out, this will work exactly as
everyone wants.

Is there a problem with providing a facility to other developers that
you don't have to use? If not, perhaps it would be a good idea to wait
and see while we introduce this optional facility, and defer judgement
until then?

Cheers,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]