[yt-dev] Backporting bugfixes and possible changes to development practices

[Nathan Goldbaum]

Hi all,

I spent some time this week coming up with a technical solution to our
social problem of doing bugfix releases. This is embodied in a new script,
"pr_backport.py", which I've created a pull request for here to include
with the yt repository.

https://bitbucket.org/yt_analysis/yt/pull-requests/1717/add-pr-backport-script#comment-9292153

Briefly, the script creates a temporary clone of yt_analysis/yt, figures
out which commits on the "yt" branch need to be included on the stable
branch, and then assigns those commits to a pull request, and then
interactively suggests mercurial commands to run in the temporary
repository to backport individual pull requests to the stable branch. This
is all done "manually" by copy/pasting mercurial commands suggested by the
script. I don't think this should be fully automated since merge conflicts
can and likely will be triggered, particularly if the stable and yt
branches begin to substantially diverge.

My hope is that this will make the task of backporting bugfixes, which up
until this point has been associated with such a high cognitive barrier
that no one has wanted to sit down and acutally do it, much easier.

I might be biased since I wrote the script, but using the final version
that I pull requested it took me about 10 minutes or so to go through the
list of pull requests and backport them to create this pull request:

https://bitbucket.org/yt_analysis/yt/pull-requests/1716/backporting-bugfixes-to-stable

Being able to backport bugfixes like this allows us to possibly make some
changes to our development workflow and suggested best practices.

1. We can now suggest most users stay on the stable branch rather than
switching to the dev branch to get bugfixes. We can also issue bugfix
releases on a much quicker cadence (monthly? biweekly?).

2. Since the "stable" branch is more stable and less buggy and the dev
branch is basically now just for new features, perhaps we can allow more
experimental development on the main yt branch without an onerous
requirement of documentation and review. This will help unblock the
development of major features like support for unstructured mesh data and
the new volume rendering interface.

3. Since there is less pressure to do a feature release just to get
bugfixes out, we might be able to have longer intervals between feature
releases, giving more time
to shake out issues.

I'm more or less just throwing these thoughts out there to get feedback
from the development community. Does the easy availability of bugfix
releases constitute a significant change for our development and release
mindset?

Thanks all for your time and input!

-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20150821/08fa48a3/attachment.htm>