ArchiveReorganisation and sponsoring

[Colin Watson]

On Sun, Aug 31, 2008 at 08:59:58PM -0400, Scott Kitterman wrote:
> On Sun, 31 Aug 2008 23:41:49 +0100 Colin Watson <cjwatson at ubuntu.com> wrote:
> >  * 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.

James Westby could say more, but I think for the moment the plan is that
if you tag a revision as corresponding to an upload in some conventional
way then it'll believe you. Perhaps it would be valuable to have the
actual source package imported on some other branch in case it doesn't
match; this is analogous to the old problem that upstream revision
control does not necessarily exactly match the .orig.tar.gz.

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

The importer infrastructure is mainly being developed by James, who's on
the Ubuntu Foundations team and not on the Launchpad team. We are of
course asking the Launchpad and Bazaar teams for support in various
ways, but the effort is being driven by Ubuntu and is not a Launchpad
project.

I would be inclined to say that if Ubuntu didn't suffer from a high
volume of change for change's sake, we would have fewer problems than we
do. :-) It's just a matter of what happens to be highest profile, I
guess ...

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

Understood, thanks.

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

Contrariwise, I do feel that ultimately it would make it a lot easier
for trainee developers to find their way around (perhaps at the cost of
some hopefully minimal readjustment for experienced developers).
Furthermore, as a sponsor I would love to be able to make use of
revision control when assessing trainees' work: for instance, I would
like to see the process they went through to develop their change and
the log messages they used to describe it, and I'd like to have the
merge of that metadata clearly recorded in the revision control history
of the package. I understand that, for people perhaps less used to
distributed revision control, the benefits may not seem quite so
obvious; that's why there will be no flag day and people will have
plenty of opportunity to try it out.

You've mentioned "packages that have lots of people touching them" a
couple of times now, and I'd just like to say that I dispute what seems
to be the underlying contention here. Yes, revision control is a useful
tool for mediating near-simultaneous work by multiple people, but it has
uses outside that. A package that is rarely changed and only by a small
number of people is exactly the kind of package that might well have
hidden complexity lurking in it where I might want to know the ancestry
of code before sponsoring a change to it, and for obscure packages I
might not be able to ask around for it. Packages off in some dusty
corner aren't ones most of us will be familiar with, and so the more we
can build tools to help us find our way around the better.

Furthermore, the process of establishing context for reviewing changes
when sponsoring is still a slow one. Even with a local mirror, it takes
a while to download and unpack a package, grab a debdiff from Launchpad,
and look at the context in which it will be applied. Drive-by reviewing
would be a lot easier if I could just bang a keyword into Firefox to
pull up the current source in Bazaar's web interface and look at the
context there. Obviously I'd still have to download it to apply, build,
and test, but it would make the initial triage pass easier. Often I
temporarily import code into revision control when sponsoring anyway, in
order that I can use tools like 'bzr diff' to see what I'm doing in
cases where I need to change the patch around a bit!

For me, none of these considerations are particularly specific to "busy"
packages.

Cheers,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]