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
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
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
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,