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