Sean Whitton writes ("Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)"): > On Mon, May 22, 2017 at 09:22:00PM +0100, Sean Whitton wrote: > > On Mon, May 22, 2017 at 01:42:54PM -0400, Jeremy Bicha wrote: > > > Of course, dgit is yet another workflow and my understanding is that > > > git-buildpackage (without dgit) is far more commonly used in Debian.
Jeremy: you're right that dgit is not yet used for the majority of uploads. I think this is a problem because I think we should all be sharing our git trees in a way that is directly useable by non-Debian-experts. But I think it is not true that dgit `is yet another workflow'. Of course it depends a bit on what you mean by `workflow', but in this context I think it means things like what your git branches look like, where you keep them, how you deal with new upstream versions; and it also means what build tools you use (eg cowbuilder vs sbuild). >From a maintainer's point of view, dgit tries not to impose workflow requirements. You can use dgit: - with patches-applied branches, or with patches-unapplied branches - with git-buildpackage; with git-dpm; with raw git - with sbuild or with pbuilder (although I am working on smoothing out some wrinkles with the use of pbuilder) - if you generate your orig tarballs from git, or if you download them from upstream, or if you repack them yourself using eg dpkg-repack etc. etc. I want every maintainer who is using git to be able to use dgit. We're not quite there yet, but the exceptional cases are much rarer now. (The main obvious one is packaging-only git trees.) So I think the `yet another standard' jibe is unfair. dgit is trying to *work with* maintainers' existing packaging tools, not supplant them. > Ian did claim that dgit gives you one workflow for all Debian packages. > It does indeed provide that. What I should have said was that it does > not enforce /that/ workflow; it just makes it available, primarily for > the benefit of NMUers and those who aren't already Debian contributors. Precisely. From a _user_'s point of view (or an NMUer, or security responder) dgit offers the same workflow for all packages. This is possible because dgit is mostly a converter between different source package representations, along with knowledge of where to find these representations and when to do what kind of conversion. Ian.