Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
On Tue, 07 Feb 2017 at 10:47:00 +0000, Ghislain Vaillant wrote:
> I know the discussion is leaning towards replacing usage of git-dpm
> with gbp-pq. I have nothing against it but, since we are talking about
> solutions for a git-centric workflow, has anyone considered the dgit-
> maint-merge workflow?
The dgit-maint-merge man page starts with some axioms:
The workflow makes the following opinionated assumptions:
· Git histories should be the non-linear histories produced by
git-merge(1), preserving all information about divergent
development that was later brought together.
I don't think that is actually a useful model of distro development.
I'm sure the rest of dgit-maint-merge(7) is a perfectly reasonable
workflow when you start from its assumptions, but I think they're
the wrong assumptions.
I think the downstream maintainer job in vendors like Debian (and Red
Hat, etc.) is essentially a rebasing patch series, whether we represent
it like that in git or not:
* we track an upstream version, which we treat as somehow canonical[1]
* we track what the downstream does as divergence from that upstream
version, and only secondarily as a product in its own right (this is
a core assumption in the design of all the non-native dpkg-source
formats, and also SRPMs, so this is clearly something that has been
considered important to downstreams)
* when we import a new upstream version, we adjust our divergence to
apply on top of that new version
* some of the divergence is vendor-specific and we will never upstream it
(for example adjusting paths/defaults to meet Debian Policy)
* some of the divergence is intended to go upstream, although our
upstreams don't always apply in-principle-upstreamable changes
as fast as we'd like them to; when it does get applied, it is often
applied to their current development branch (like a git-cherry-pick)
rather than being merged, and even if we send Github pull requests
or similar, the upstream will want them to be based on some upstream
branch and not on Debian's
* in Debian's case, even if they want to apply all the patches we propose
to their upstream source, our upstreams will never want to `git merge`
the contents of our VCS, because they usually don't want to merge
debian/ (and in fact we actively recommend that they don't)
That's why, although I find dgit an interesting idea, I think
dgit-maint-merge(7) is a trap. If I use dgit at all, it'll be
dgit-maint-gbp(7) or similar.
[Conflict-of-interest disclaimer: I am a happy user of gbp-pq for every
patched package I maintain, except for tap.py and pkg-gnome svn. I would
love to see gbp-pq adopted by DPMT so I can use it for tap.py, and
when pkg-gnome finally moves from svn to git, given the overlap among
active maintainers between pkg-{systemd,utopia,gnome}, I suspect they
are going to use gbp-pq like pkg-systemd and pkg-utopia do.
I also seriously considered maintaining tap.py outside DPMT as a way
to avoid git-dpm.]
Regards,
S
[1] but in most cases not Canonical :-)
Reply to: