<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 2, 2015 at 8:07 PM, John ZuHone <span dir="ltr"><<a href="mailto:jzuhone@gmail.com" target="_blank">jzuhone@gmail.com</a>></span> wrote:our efforts in this regard.<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>
<br>
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."<br></blockquote><div><br></div><div>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.</div><div><br></div><div>See:</div><div><br></div><div><a href="https://bitbucket.org/yt_analysis/yt/pull-requests/1716/backporting-bugfixes-to-stable/diff" target="_blank">https://bitbucket.org/yt_analysis/yt/pull-requests/1716/backporting-bugfixes-to-stable/diff</a><br></div><div><a href="https://bitbucket.org/yt_analysis/yt/pull-requests/1730/backporting-bugfixes-to-stable/diff" target="_blank">https://bitbucket.org/yt_analysis/yt/pull-requests/1730/backporting-bugfixes-to-stable/diff</a><br></div><div><br></div><div>My hope is to have one of those pull requests once a week, allowing us to issue stable releases once a month or so.</div><div><br></div><div>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.</div><div><br></div><div>-Nathan</div></div></div></div>