Feature freeze starting next Wednesday sounds fine to me. It might also help to have a slack sprint to fix issues sometime in the next couple weeks. That was pretty successful the last time we did it. On Thu, Jun 2, 2016 at 10:18 AM, Matthew Turk wrote:

Hi folks,

Here are the outstanding issues for releasing 3.3:

https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&version=3.3

I'd like to propose, and hold myself accountable to, a feature freeze for 3.3. I think we should give a pass on *already* open pull requests, but set up a freeze starting Wednesday for non-bugfix changes until 3.3 is released, after which the gates can re-open. If anyone has any strong objections, let's bump it, but I'd like to see the release go out and not creep too far. (It's already got quite a lot in it!)

I'm going to start picking out bugs today to get going. Thanks to Nathan and Cameron for identifying these bugs for the 3.3 release, which was a non-trivial task.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

I think that this is the sort of thing that is excepted from the feature freeze--i think we mean no more adding of new frontends or analysis modules or large pieces of new functionality. Whatever you need to get Trident working correctly is fine by me. ===================================== 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 john.zuhone@cfa.harvard.edu http://hea-www.cfa.harvard.edu/~jzuhone =====================================

On Jun 2, 2016, at 9:05 PM, Cameron Hummels wrote:

I'm generally in favor of a feature freeze. My only hesitation is that we're just about done with Trident but once in a while we find that to fix problems in it, we have to make modifications to the LightRay or AbsorptionSpectrum analysis modules (or occasionally a frontend). I don't anticipate any more substantial modifications on this front, but if one pops up after Wed before 3.3 has been released, can we still push it through? It won't be anything major if it is. I just really want Trident to work well with a stable release of yt, so I'd love to have everything just *working* with 3.3.

Cameron

...

On Thu, Jun 2, 2016 at 8:36 AM, Nathan Goldbaum wrote: Feature freeze starting next Wednesday sounds fine to me.

It might also help to have a slack sprint to fix issues sometime in the next couple weeks. That was pretty successful the last time we did it.

...

On Thu, Jun 2, 2016 at 10:18 AM, Matthew Turk wrote: Hi folks,

Here are the outstanding issues for releasing 3.3:

https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&version=3.3

I'd like to propose, and hold myself accountable to, a feature freeze for 3.3. I think we should give a pass on *already* open pull requests, but set up a freeze starting Wednesday for non-bugfix changes until 3.3 is released, after which the gates can re-open. If anyone has any strong objections, let's bump it, but I'd like to see the release go out and not creep too far. (It's already got quite a lot in it!)

I'm going to start picking out bugs today to get going. Thanks to Nathan and Cameron for identifying these bugs for the 3.3 release, which was a non-trivial task.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org