[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Status of dgit (good for NMUs and fast-forwarding Debian branches)

My original announcement was quite cautious.  I've also recently seen
an article in LWN which was also rather cautious.  I think it's
probably a good idea to set out what the current state of play is:

dgit's current functionality seems to be in reasonably good shape, but
it lacks additional features which are important in some workflows.

dgit currently supports the following situations very well for DDs:

 * You're are not the maintainer, and want to cherry pick a patch from
   upstream, apply a patch from the BTS, or whatever.  Ie, NMUs and
   private changes.

   In this situation you do not need to know anything about the source
   code management practices of the maintainer (unless the package is
   still using some kind of hideous old debian/rules-based patch
   system).  I recommend liberal use of git-clean and git-reset.

 * The package has an existing fast-forwarding git branch whose
   content is exactly the same as (or can easily be made the same as)
   the Debian source packages.

The following situations are not currently supported well:

 * Your signing and login keys are on a host which is distant from the
   build and test host.  Ie, debsign -r and debrsign.  If you have
   enough bandwidth you can work around this by copying the git tree
   and build outputs to your signing host and running dgit push there.

   I am working on improving this; it's a SMOP but not trivial.

 * You are not a DD.  Fixing this is sadly blocked on changes in
   Debian's infrastructure including ftp-master and alioth.  I have
   started those conversations but it looks like nothing is going to
   happen quickly.

   I don't think this limitation is acceptable so if it persists I
   will perpetrate some kind of guerrilla workarounds.  But I don't
   expect improvement on this front for at least a month or two.

 * You are the maintainer and want to have a quilty kind of workflow.

   If you are the maintainer and are currently using a git-based patch
   stack system, dgit fetch will at least convert NMUs (whether made
   with dgit or not) into git commit(s) for you to incorporate into
   your patch stack (git-cherry-pick etc.), and you can then use your
   existing workflow for build and upload.

   But dgit push won't work for you because your tip git commit
   probably isn't a fast forward from the last upload.  Supporting
   this workflow well in dgit push involves some significant design
   work.  I have been thinking about this but it's not trivial.

I should also mention a non-goal:

 * I have no plans to support a workflow where dgit's git tree
   contains different contents to the source packages.

   My view is that the source code is the source code.  If something
   is not needed for [d]git users then it is not needed in the Debian
   soure package either; conversely if you need to put something in
   the Debian source package then by definition it is source code and
   should be in your vcs too.

   Furthermore, because dgit's need to bidirectionally gateway between
   git and the archive, it is difficult for dgit to do this properly.
   For example, if there are files in the source package that weren't
   in the last git commit pushed with dgit, then the git trees
   synthesised by dgit from source package (which dgit fetch/clone
   makes when the last upload was not done with dgit) would contain
   those files.  So the files would seem to have been created by the
   non-dgit-using upload.

   dgit's goal is that you should be able to use dgit's git tree in
   all situations where you could have used the source package
   directly.  If there are things in the source package which aren't
   in the dgit git tree then that's not the case.

   It may be that this means that there need to be separate git
   branches for dgit and for the sparser source.


Reply to: