[yt-dev] Volume Rendering Refactor

[Nathan Goldbaum]

On Wed, Sep 2, 2015 at 8:07 PM, John ZuHone <jzuhone at gmail.com> wrote:our
efforts in this regard.
>
> But the dev branch is by definition going to be unstable (which is why the
> alternative branch is named "stable"), even after all of these
> considerations. By getting code into the dev branch, we get a chance for
> users to take a whack at it in ways that most of us won't, which will by
> its very nature do a much better job at catching bugs in corner cases than
> programmed tests, which is the ultimate "test" for determining how "stable"
> this code is and whether it merits that label.
>
> This points to the fact that we really do need to change things so that
> the stable branch is updated much more often than it has been, so that we
> don't have to keep shuttling people onto dev whenever they need a recent
> bugfix, which is frankly risky at the very least. That way we can
> consistently say "feel free to use the dev branch, but we have a separate
> branch called 'stable' for a reason."
>

And I'm making it a personal mission to make sure the pr_backport.py script
is being used every week after the PR hangout to ensure that bugfixes make
their way to stable.

See:

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

My hope is to have one of those pull requests once a week, allowing us to
issue stable releases once a month or so.

If we do merge this while it isn't 100% finished, users and developers who
normally work off the dev branch will still be able to go back to the
stable branch to do their volume renderings. Definitely a bit annoying and
not ideal, but this way the VR refactor gets a lot more hands-on testing,
bugfixes, and feedback than if it lived on in the experimental bookmark
until just before the 3.3 release. It also prevents a possible schism in
the community for users of the ExodusII frontend and other unstructured
mesh codes, since the version of yt they need is currently based on the VR
refactor work.

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