Hi all, Currently there is active ongoing work in my fork of yt on the "sph-viz" branch. This branch contains the bitmap index work and accompanying changes to the particle selection API. Collectively these changes constitute a major backward incompatible change and thus cannot be easily integrated into the master branch on the main repo without major disruption. Doing that would also prevent us from being able to do a 3.5 or 3.6 release (currently there's no plan for a 3.6 release but crazier things have happened). We've already come to some level of consensus both here and in YTEP discussions that we want to make some major backward incompatible changes to yt in yt-4.0 and that the demeshening work should be one of those changes. To ease development going forward and make it clearer both how to get started and how to contribute, I'd like to push the current state of the "sph-viz" branch to the main yt repo and rename the branch "yt-4.0". Afterwards there will be "yt-2.x", "master", "stable", and "yt-4.0" branches in the main repo. Most pull requests will still go to master, but pull requests that implement changes or fixes that are specific to the demeshening or for planned features in yt-4.0 will go to the yt-4.0 branch. I'd additionally like to suggest that the threshold for merging code to the yt-4.0 branch should be lower than in master, possibly by reducing the number of required reviewers to one. I'd prefer not to make it harder to merge code than that to keep development velocity high and to make sure we're not blocked on getting code merged in for lack of reviewers who are familiar with the changes in the yt-4.0 branch. I don't think it's necessary to create a new repository, since the master branch will remain the default branch. People will only get the experimental yt-4.0 branch if they explicitly fetch it and check it out. As for testing, I think we'd just need to set up something in Jenkins to check the yt-4.0 branch as well as master for new PRs. The cloud CI services should "just work". We may end up turning off answer testing if it's too hard to have two separate sets of test answers for master and yt-4.0. Eventually, just like for yt 3.0 if you remember that, we will merge the yt 4.0 branch in. Doing that will require ensuring the documentation has been updated and developing community consensus that the new features are ready for widespread testing among people running on the yt master branch. Looking forward to hearing what people think about this, -Nathan Goldbaum