ArchiveReorganisation and sponsoring

Scott Kitterman ubuntu at
Mon Sep 1 01:59:58 BST 2008

On Sun, 31 Aug 2008 23:41:49 +0100 Colin Watson <cjwatson at> wrote:
>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> 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 
>> VCS +1 is very low.  To the extent I'm pushed into learning a new, 
>> unique toolset, it will probably translate fairly directly into less 
>> contribution from me.  This is particularly true since this move away 
>> 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.

Yes.  This can certainly be a challenge.

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

Yes.  I agree.  I think this an important capability we would gain.

>Other GNU/Linux distributions have this kind of thing at least for their
>packaging (e.g. 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.

Yes.  I can see this adjunct to the main repository having particular a 
particular value.  It could have used it was recently as this week.

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

This is good to hear.

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

Presumably it will check if the upload really matches and not just take it 
on faith?  In the cases in Debian where I'm involved in teams that use 
svn/git, skew between the vcs and the archive is often problematic.  If we 
can eliminate that risk, then the potential for VCS is all that much more.

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

I understand this is the way things are heading.  I am conservative by 
nature (this is not a statement about politics) and believ that generally 
things are not so bad right now and that we need to carefully consider both 
the risks and benefits before making change.

I'm not familiar enough with Canonical's internal arrangements to know how 
closely the group tasked with providing this infrastructure is to the 
normal Launchpad development group.  It is my judgement that that group 
suffers from a high volume of change for change sake, much of which is not 
very well thought through from the perspective of distro development.

I fear it's the same group with the same approach to development and I 
worry a lot about how this is really going to work.

My pushback isn't intended to stop this effort, I just want to ask the 
questions now so it'll be thought through before I have to try and use it.

I think the case (as you make it above) for forensic analysis is a good 
one.  I think the case for it benifitting the sponsoring process (outside 
the packages that have lots of people touching them) is, so far, much more 

Scott K

More information about the ubuntu-devel mailing list