We do have one blocker, at least from my point of view. At the moment I am -1.

We have done a lot of work to get a single yt codebase for Python 2 and 3, but we have not (to my knowledge) had a single test run where all tests are passing under Python 3, including answer tests.

Since the Python 3 stuff is everywhere in the code, we need to verify that all the tests pass (I bet they won’t just yet) before we release.

Also, we don’t yet know if “yt update” and “yt instinfo” will work under Python 3 (though I’m happy to find out).

Best,

John

> On Jul 9, 2015, at 2:08 PM, Matthew Turk <matthewturk@gmail.com> wrote:
>
> +1
>
> On Thu, Jul 9, 2015 at 1:06 PM, Britton Smith <brittonsmith@gmail.com> wrote:
>> This does not explicitly include the VR refactor, unless it happened to be
>> approved in the very near future.  Assuming the remaining issues with the
>> docs build were dealt with, it would be exactly what's in dev at this
>> moment.
>>
>> On Thu, Jul 9, 2015 at 7:00 PM, Michael Zingale
>> <michael.zingale@stonybrook.edu> wrote:
>>>
>>> does this include the new VR interface?  I'm +1 if it is the old interface
>>> for 3.2.
>>>
>>> On Thu, Jul 9, 2015 at 1:59 PM, Britton Smith <brittonsmith@gmail.com>
>>> wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Nathan and I just met briefly to discuss backporting all bugfix PRs from
>>>> the development branch to stable so as to do a minor release.  This has
>>>> become absolutely necessary as a large number of bugs have appeared and been
>>>> fixed since the last release, which was nearly 6 months ago.  By my rough
>>>> estimate, there have been about 200 PRs accepted since the last release,
>>>> with a large fraction of them being bug fixes.  Therefore, it seemed to both
>>>> Nathan and I that there were simply too many changesets that need to be
>>>> picked out of dev and transplanted to stable for such an operation to be
>>>> feasible.
>>>>
>>>> Instead, a far simpler solution is to bite the bullet and do a 3.2
>>>> release with everything currently in dev.  Fortunately, as we require
>>>> passing tests and documentation of new features, this would require
>>>> relatively little effort.  Most of the work is cleaning up errors in the
>>>> docs build, for which Nathan is filing tickets as I write this.
>>>>
>>>> I want to be clear that we desperately need a new release with the number
>>>> of bugs that have been fixed since the last one.  If we do not do this, then
>>>> someone else needs to step up and backport all those bugfixes to stable.
>>>>
>>>> For now, can I please get a +-1 on whether you agree with this proposal.
>>>> If this meets with approval, then I will coordinate taking the next steps.
>>>>
>>>> Britton
>>>>
>>>> _______________________________________________
>>>> yt-dev mailing list
>>>> yt-dev@lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Zingale
>>> Associate Professor
>>>
>>> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
>>> 11794-3800
>>> phone:  631-632-8225
>>> e-mail: Michael.Zingale@stonybrook.edu
>>> web: http://www.astro.sunysb.edu/mzingale
>>> github: http://github.com/zingale
>>>
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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