[Pkg-xen-devel] git workflow, redux

[Ian Jackson]

Summary:

I have tried the packaging-only repo and I really don't like it at
all.  I don't know how anyone copes with this - such hard work!
IMO we should switch to git-debrebase.  (As an alternative, if
you don't trust git-debrebase because it's my own tool, gbp pq
would be better, too, even though it's not as good as git-debrebase.)

Particularly, now that we have more people making substantial
contributions, it is important to have something that works for as
many as possible, and that is low friction for common tasks.


Knorrie wrote on irc:

  ... I only want to discuss it if you have packaging scenarios and
  want to do them in both ways and then discuss the result, so we can
  discuss based on actual work/commands/etc instead of feelings

Well, I don't propose to actually try doing the same task two
different ways, at least unless I completely fail to manage it the
first way I try.

But I will consider some scenarios:

                    packaging-only      git-debrebase

  Build binaries    100 lines of        dgit sbuild -A
  for release       instructions!         or
                    + pbuilder/sbuild   dgit pbuilder [options]

  Build binaries    ??? no idea         dpkg-buildpackage -uc -b
  ad hoc for         README.source
  testing            dirties the tree

  New upstream      ??? no idea how     # choose VERSION and COMMIT
  rebase              to do this        git tag upstream/VERSION COMMIT
                    fix up conflicts    git debrebase new-upstream VERSION
                     in quilt omg!      # fix up conflicts in git
                                        # edit changelog at some point

  Add a patch       obtain tree         # edit upstream files
                    with upstream src   git commit
                    do quilt stuff 

  Amend a patch     obtain tree         git debrebase -i
                    with upstream src   # is just like git-rebase
                    do quilt stuff

  Drop a patch      edit series or      git debrebase -i
                     soemthing ?        # is just like git-rebase

  Cherry pick       git format-patch    git cherry-pick
  from upstream     edit series?
                    how to check it
                    applies, or build?

  Update d/control  edit control.in     # edit control.in
                    run rules to        debian/rules debian/control
                     see output,        git commit debian/control
                    debdifff?           git diff

  git blame on      not possible        git blame
   upstream source

  machinery needed  orig targets        README.source saying
   in tree          genorig             `see dgit-maint-debrebase(7)'
                    README.source       and mentioning d/control.in

  push to salsa     check that          git debrebase prepush
                     patches apply?     # ^ won't fail
                    git push            git push

  uploading         100 lines of        git deborig
                    pratting about      dgit push-source
                    debsign, dput       (or dgit push if NEW)

You'll observe that the left hand column contains references to
documentation.  It also contains some ??? because I haven't bothered
to RTFM quilt recently.  (I used it once, a long time ago.  We have
much better tools now.)

You'll see that the right hand column is wider and longer.  That
is because it contains the complete actual command lines.


In fact, when I was doing the upload to experimental just now, I so
much missed git that I did the following:
  * Get the relevant branch and tag from salsa
  * Follow the instructions in README.source.md to generate a
    source package
  * dgit import-dsc
  * lots of git diff (sadly this procedure produces a not very
     helpful history)
  * dgit sbuild -A
  * dgit push



I'm going to quote some snippets from irc:

17:17 <babilen> My take on this is, is that I'm more than confident to
  deal with any security issue that arises in the future with the
  packaging style used for 4.8 in the stretch-security uploads

Likewise.  (I'd like to take this chance to publicly thank Wolodja for
his work on the stretch security updates.)


17:27 <Knorrie> also, a relevant question is whether we want to have a
  patch-burden-heavy workflow in debian stable, or if we could just
  follow the upstream stable branch, like the kernel team does with
  stable kernel releases

I don't think it is realistic to expect the situation to be different
in buster than it was in stretch.  When I uploaded 4.8 to stretch, it
was an upstream RC without patches.  The way upstream provide security
patches means we sometimes have to take upstream stable branches plus
some patches from advisories; sometimes upstream unstable branches (!)
and sometimes some unholy mixture.

It's awkward but git-debrebase makes this reasonably straightforward.
Doing this stuff with quilt would be nearly unworkable.


23:41 <Knorrie> babilen: doing stable security updates for a single
  xen version is a whole different flow than organizing a rolling
  release (with stable-backports) which follows latest upstream
  release in unstable/testing (and upstream rc in experimental), while
  also allowing to easily charry-pick things or merge branches between
  them

I think git-debrebase is going to be easier for all these things than
the current approach.


Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.