Thoughts on 3.0 (quilt) and VCS workflows

[Colin Watson]

I thought some people here might be interested in the bug I just filed
on dpkg-dev:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204

This was independent of the discussion in
https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2010-February/000508.html
as I hadn't read that yet, but the second problem I mention in that bug
is essentially the same thing.  I realise the solution I propose isn't
optimal given further bzr development, but I think it's the cleanest
method that works right now even if the cost is losing bzr conflict
resolution (which is annoying, but I'd rather that than have to mangle
quilt patch files by hand or accidentally mis-refresh a quilt patch to
include the upstream diff or any of the other things that can go wrong
when you confuse quilt about its base file contents).  Thoughts?


I cannot agree with Dmitrijs that we should use the single-debian-patch
mode, by the way.  The first big package I converted to 3.0 (quilt),
just this weekend, was openssh, and that was after very clear and
definite feedback over the years from several different users (including
at least one big customer) that they were finding it difficult to audit
the source package.  This is a source package with 6000+ lines of Debian
patches, a substantial proportion of which by line count are (a) relied
upon by many users and (b) never going to go upstream for various
reasons which don't imply that they need to be removed from Debian.  By
converting it to the 3.0 (quilt) format, I was able to give them
separated patches with distinct rationales and DEP-3 bug forwarding
information, so that they can back out any individual patch they're
uncomfortable with it.  I've already had positive feedback from said big
customer.  They would have gained very little from the
single-debian-patch model.

Many people who look at source packages are not particularly familiar
with bzr, and I don't think they should have to become familiar with
some of the wilder and wackier corners of bzr in order (for example) to
deploy openssh with the patch set they want; this is an obvious case of
yak-shaving for a sysadmin.  Even given fully integrated and polished
looms or pipelines or whatever, debian/patches/ will still be a useful
export format.  What I want from bzr is simply to make the exported
patch files easier to manage, not to collapse them all into one - I had
that with the 1.0 source format and I only put up with it because at the
time all the alternatives were worse.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]