Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Colin Watson writes ("Bug#904302: Whether vendor-specific patch series should be permitted in the archive"):
> ...  My opinion from experience with this feature is that those
> derivative maintainers would have an easier time if they used
> patches with conditional behaviour (or maintained a local branch, of
> course, although that was part of what source package management
> features like this were trying to reduce).

Obviously I agree with the conclusion, but I would like to propose a
different way of looking at this:

The Debian archive and derivative archives, and the .dsc source
package formats, including "3.0 (quilt)" currently including the
vendor series feature, *are a version control system*. [1]

The vendor series feature *is a way to represent a branch*.
We should consider its merits in those terms, by comparing it to other
technology we have for handling branches.

In the current system [1], the obvious competing way to represent a
branch is for the derivative to actually change the source package.
If vendor series are forbidden, the same effect can always be achieved
that way.

Compared to changing the source package, the vendor series appears to
offer a reduction of maintainer friction.  This is a relatively minor
benefit.  (Note that resolution of any merge conflicts during rebase,
or whatever, is still necessary; the only benefit is a small degree of
automation and a slight reduction in different files etc. on
maintainer systems.)  However, that convenience comes at too high a
price.  In particular, the invisibility of the vendor series - that
very lack of friction - means that the vendor series is often wrong.

Conversely, derivatives must already have means for merging or
rebasing their own delta-represented-as-changes-to-the-source-package,
so as to track Debian.  (Vendor series cannot, for example, represent
changes to files in debian/.)  Those mechanisms are often fairly well
developed, and if they are insufficient they need to be improved [2].
And people can inspect the differences by comparing source packages.

So I think it is nearly always better, even without considering global
effects, to represent any needed derivative delta as a changes source
package, than to represent it as a vendor series.[3]

But forbidding vendor series has the global benefit that no-one who
deals with source packages from Debian derivatives has to write code
to deal with, and spend mental energy on, yet another way to represent
the delta.

Thanks,
Ian.

[1] By modern standards, an appallingly bad one.  I would argue that
it all made sense in 1993 (when the best alternative was CVS) but
nowadays we have much much better tools.  This is why I am engaged in
a project to provide something much better than .dsc, based on git.

[2] Tracking Debian is IMO still too hard.  I am working on that.

[3] That does not mean I think that changing the source package is
always or even mostly the best answer; often other approaches will be
better still.  It just means that vendor series are worse than
changing the source package.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.