My git-based Ubuntu package merge workflow

Robie Basak robie.basak at ubuntu.com
Thu Jan 14 12:55:38 UTC 2016


A followup on how this has developed.

We're adopting this workflow in the Canonical Server Team (and anyone
else who wants to join us!). It is particularly useful for bigger deltas
or when much churn has happened since the last merge, so is particularly
relevant for a bunch of server packages on which we are catching up
right now.

Where the delta is large, it helps us rationalise the delta by splitting
it up into smaller pieces that can be considered individually for
upstreaming or dropping. We're also regularly identifying and fixing
merge errors that have been carried forward for years using this method.

To share our work, we are pushing our generated git trees to
lp:~ubuntu-server-dev/ubuntu/+source/<package>. This is a
uploader-restricted team, so non-uploaders are pushing to
lp:~USER/ubuntu/+source/<package> and then submitting a Launchpad merge
proposal.

On upload, I intend to push the branch into ~ubuntu-server-dev so the
split logical delta is available for next time.

We also formalised some tag names:

old/debian: import of the base Debian revision from which we previously
diverged.

old/ubuntu: import of the old Ubuntu upload that we're "merging".

new/debian: import of the latest Debian upload onto which we're
"merging".

new/ubuntu: the result of the "merge" ready for upload.

For easier review:

reconstruct/<version>: identical to the Ubuntu upload of <version>, but
with commits leading up to it that reflect individual changelog entries,
with separate entries for the changelog of each upload itself, and any
new upstreams if they were included since we diverged from Debian.

logical/<version>: identical to the Ubuntu upload of <version>, except
that it misses changes to debian/changelog itself, any new upstream
versions (so changes not in debian/) and commits are refactored into one
commit per logical change, squashing together any churn.

To review the old way, you (for the sponsoree) can just "git diff
new/debian new/ubuntu" and "git diff old/ubuntu new/ubuntu" to get the
debdiffs you'd traditionally expect attached to a bug.

To review with this workflow, roughly I:

* Check that old/debian, old/ubuntu and new/debian match the trees I
  expect (as found in the archive). We could do with a script for this
  as it should be easy to automate.

* Check that logical/<old/ubuntu version> is identical to old/ubuntu
  except for debian/changelog and any upstream changes.

* Use "git log -p" against logical/<old/ubuntu version> to understand
  the previous delta.

* Use "git log -p new/ubuntu" to check that the old delta is correctly
  applied to new/debian. If this is complicated, I can also do this my
  rebasing old/debian..logical/<old/ubuntu version> into new/debian
  myself and diffing the result.

* Verify all the regular things I'd check with a merge - that it builds,
  that the changelog is accurate and closes any existing merge bug, that
  the delta makes sense against the new Debian version etc.

Thanks to the Launchpad team for all the work on git support to make
this possible!

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20160114/a61e4f31/attachment.pgp>


More information about the ubuntu-devel mailing list