Improving releng workflows (and patch management in general) with a DVCS

[Benny Siegert <bsiegert%gmail.com@localhost>]

Now that we are discussing workflows, I would like to add my 2 cents, with my pkgsrc-releng hat on.

In general, we throw around far too many patches on mailing lists or as email attachments, where we could use DVCS commits instead.

Since pkgsrc-releng is the bit I am most familiar with, here is a workflow that could replace the slightly crufty pkgsrc-pullup tool. I am using git commands as an example but that could also be any other DVCS.

The simplest workflow, pulling up a single commit, would just need a commitid (and a description) as input. The script can then do

git cherry-pick $commitid
git commit —amend # change log message so it mentions ticket #, etc
# verify the package build works
git push

The more sophisticated case, where you pull up several commits and/or fix merge conflicts could be:

git checkout pkgsrc-2016Q1
git checkout -b my-pullup
git cherry-pick a b c d
# fix conflicts, then test build

Crucially, the steps up to here can be carried out by the *originator* of the pull request. The releng just has to have access to the branch somehow, e.g. by pushing it into the master pkgsrc repo, or *gasp* to a clone on github.

For applying this, I see two ways:
(1) merge, force a merge commit to be created so you can annotate it with pullup ticket metadata.
(2) squash all individual commits into a single one, annotate the log message, then apply to the stable branch (either by fast-forward merge or by cherry-pick).

Compare and contrast to the current way:

„Hey, please pull up these commits that I identify by URLs to mail-index.netbsd.org/pkgsrc-changes. One of the ones in the middle does not apply cleanly, so I attached a patch for distinfo but not the rest. Good luck.“

Comments? Thoughts?

—Benny.