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
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
