Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

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

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.