+1, but to be honest I think that index arrays are in trouble without some help (especially with unyt being a thing now)

John ZuHone, Chandra/ACIS Operations
Harvard-Smithsonian Center for Astrophysics

60 Garden St., MS-67 (w) 617-496-1816
Cambridge, MA 02138 (m) 781-708-5004


On May 7, 2018, at 8:29 PM, Matthew Turk <matthewturk@gmail.com> wrote:

+1 to a new branch and to allowing slightly lower barrier to entry for changes in 4.0.

I would also like to point out that in contrast to when 3.0 was under development, we now have a much, much more robust testing and review infrastructure in place. This is in no small part due to your work, Nathan, as well as Kacper, and I also want to highlight that people like Cameron and Bili are already using "4.0" in production and contributing changes and bug fixes. Plus, other changes (like index arrays) are being developed by people like John, and the number of people involved in this is much more comfortable than it was back then.

We are in a much better state than we were back then,and I think this will be a much easier development process and (eventual) transition. I am excited!


On Mon, May 7, 2018, 6:52 PM Nathan Goldbaum <nathan12343@gmail.com> wrote:
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
yt-dev mailing list -- yt-dev@python.org
To unsubscribe send an email to yt-dev-leave@python.org
yt-dev mailing list -- yt-dev@python.org
To unsubscribe send an email to yt-dev-leave@python.org