[yt-dev] RFC: Staggered deprecation through 3.1 and 3.2

Tue Jun 24 18:09:02 PDT 2014

Ah - I see that now.

Yes, I agree that fixing the cookbook should be a blocker.  FWIW that card
is marked as such.  As I said the other day, the blockers are on the yt-3.0
and the documentation board.  We won't do the yt-3.0 release until all the
cards marked as blockers are cleared.

This is a big task - any help we can get on this from anyone following
along would be much appreciated.  There are a lot of little tasks or tasks
that can be completed in a couple hours by anyone that has a little with
yt-3.0.

On Tue, Jun 24, 2014 at 6:04 PM, Cameron Hummels <chummels at gmail.com> wrote:

> I think all of the cookbook items are blockers to be honest, because the
> cookbook recipes should be tests that are seen as failing.
>
> https://trello.com/c/NJMfoXdl/22-be-able-to-run-the-cookbook
>
>
> On Tue, Jun 24, 2014 at 5:32 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>>
>>
>> On Tuesday, June 24, 2014, Cameron Hummels <chummels at gmail.com> wrote:
>>
>>> I think there remain some issues in the VR working in 3.0, which I
>>> identified on the cookbook post on the trello board for yt-3.0.  For
>>> example, I know the overlaying grids and overlaying boundaries does not
>>> currently work.
>>>
>>
>> I don't see this on trello.  Can you make a card and mark it as a blocker?
>>
>>
>>>  That may be an easy fix, but it's something to keep in mind.  I was
>>> going to work on it last week as I was doing the cookbook update, but I
>>> figured it was just going to get replaced with the scene interface, so it
>>> wasn't worth the time.
>>>
>>> I guess I'd still like to have all of the API breakage occur in the big
>>> jump from 2.x to 3.0, but if people really want to get 3.0 out the door
>>> asap, then perhaps that isn't compatible. Personally, I'm +1 on waiting to
>>> have all the halo+VR stuff in 3.0 instead of 3.1, but if everyone else
>>> wants a 3.0 out sooner, I will not block it.  I think having a super fancy
>>> VR and awesome halo interface is one of the big pulls to getting people who
>>> have not yet switched to join 3.0 (from both 2.x as well as non-users) even
>>> if it takes a few more months, but I may be the minority here.
>>>
>>> Cameron
>>>
>>>
>>> On Tue, Jun 24, 2014 at 10:08 AM, Nathan Goldbaum <nathan12343 at gmail.com
>>> > wrote:
>>>
>>>> Ok - I think the script in the issue description is sufficient.  Let me
>>>> know if you need something more detailed.
>>>>
>>>>
>>>> On Tue, Jun 24, 2014 at 10:07 AM, Matthew Turk <matthewturk at gmail.com>
>>>> wrote:
>>>>
>>>>> That's the one -- you mentioned it in a blockers email a few days ago.
>>>>>
>>>>> On Tue, Jun 24, 2014 at 12:06 PM, Nathan Goldbaum <
>>>>> nathan12343 at gmail.com> wrote:
>>>>> > Sorry - not sure which issue you're talking about - this one maybe?
>>>>> >
>>>>> >
>>>>> https://bitbucket.org/yt_analysis/yt/issue/827/enzo-particle-fields-work-differently-than
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Tue, Jun 24, 2014 at 10:02 AM, Matthew Turk <
>>>>> matthewturk at gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Related to that, do you have a reproducible script for the particle
>>>>> >> issue you reported?  If so, could you add that to either an issue
>>>>> or a
>>>>> >> trello card so I can work on it?
>>>>> >>
>>>>> >> On Tue, Jun 24, 2014 at 11:58 AM, Nathan Goldbaum <
>>>>> nathan12343 at gmail.com>
>>>>> >> wrote:
>>>>> >> > I'd be +1 on this plan, although we should note that this is the
>>>>> plan in
>>>>> >> > the
>>>>> >> > release announcement.  We may also want to note that there are
>>>>> some
>>>>> >> > issues
>>>>> >> > with volume rendering of oct and particle data at the moment (I
>>>>> believe
>>>>> >> > that's the case - let me know if I'm wrong there).
>>>>> >> >
>>>>> >> > I think that leaves analysis modules and documentation as the main
>>>>> >> > blockers
>>>>> >> > for a 3.0 release.
>>>>> >> >
>>>>> >> > -Nathan
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > On Tue, Jun 24, 2014 at 9:53 AM, John ZuHone <jzuhone at gmail.com>
>>>>> wrote:
>>>>> >> >>
>>>>> >> >> +1 on Matt's proposal. -1 on a beta.
>>>>> >> >>
>>>>> >> >> My worry about a beta release is that it will slow adoption,
>>>>> whether
>>>>> >> >> rightly or wrongly. I think we agree that we're ready to
>>>>> encourage
>>>>> >> >> adoption
>>>>> >> >> of 3.0.
>>>>> >> >>
>>>>> >> >> John ZuHone
>>>>> >> >> Laboratory for High-Energy Astrophysics
>>>>> >> >> NASA/Goddard Space Flight Center
>>>>> >> >> 8800 Greenbelt Rd., Mail Code 662
>>>>> >> >> Greenbelt, MD 20771
>>>>> >> >> (w) 301-286-2531
>>>>> >> >> (m) 781-708-5004
>>>>> >> >> john.zuhone at nasa.gov
>>>>> >> >> jzuhone at gmail.com
>>>>> >> >>
>>>>> >> >> > On Jun 24, 2014, at 12:38 PM, Matthew Turk <
>>>>> matthewturk at gmail.com>
>>>>> >> >> > wrote:
>>>>> >> >> >
>>>>> >> >> > I think Britton covered the halos, but the VR works as-is.  As
>>>>> far as
>>>>> >> >> > 3.0beta, I'm a bit nervous about that as we want to avoid the
>>>>> >> >> > situation where we are in beta for 1+ years... I am worried
>>>>> about the
>>>>> >> >> > perception of a "beta" tag.  Is that overblown?  Would calling
>>>>> it
>>>>> >> >> > "yt-3.0-2014" work?
>>>>> >> >> >
>>>>> >> >> >> On Tue, Jun 24, 2014 at 10:32 AM, Nathan Goldbaum
>>>>> >> >> >> <nathan12343 at gmail.com> wrote:
>>>>> >> >> >> Do the old VR and halo interfaces work?  Not much effort has
>>>>> gone
>>>>> >> >> >> into
>>>>> >> >> >> porting them, I think.
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >>> On Tuesday, June 24, 2014, Sam Skillman <
>>>>> samskillman at gmail.com>
>>>>> >> >> >>> wrote:
>>>>> >> >> >>>
>>>>> >> >> >>> I'm +1 on this, particularly since I'm at fault for not
>>>>> pushing on
>>>>> >> >> >>> the
>>>>> >> >> >>> VR
>>>>> >> >> >>> as much as I'd like to.
>>>>> >> >> >>>
>>>>> >> >> >>>
>>>>> >> >> >>> On Tue, Jun 24, 2014 at 7:44 AM, Matthew Turk
>>>>> >> >> >>> <matthewturk at gmail.com>
>>>>> >> >> >>> wrote:
>>>>> >> >> >>>>
>>>>> >> >> >>>> Hi all,
>>>>> >> >> >>>>
>>>>> >> >> >>>> One thing we really tried to do with 3.0 was break all the
>>>>> APIs we
>>>>> >> >> >>>> thought we'd need to before release.  This included things
>>>>> like
>>>>> >> >> >>>> ds/pf,
>>>>> >> >> >>>> index/hierarchy, the way data selections were made, etc.
>>>>> >> >> >>>>
>>>>> >> >> >>>> It's starting to become clear that we are approaching
>>>>> maturity at
>>>>> >> >> >>>> different rates in these initiatives.  I am wondering if
>>>>> perhaps
>>>>> >> >> >>>> we
>>>>> >> >> >>>> should de-couple the release from all of the API breakages,
>>>>> and
>>>>> >> >> >>>> instead note which interfaces we know are going to change
>>>>> in the
>>>>> >> >> >>>> future.
>>>>> >> >> >>>>
>>>>> >> >> >>>> Pragmatically, what this would mean is:
>>>>> >> >> >>>>
>>>>> >> >> >>>> * Release a 3.0 with the old VR and halo finding interfaces
>>>>> >> >> >>>> * Release a 3.1 with either the new VR or the new halo
>>>>> finding (or
>>>>> >> >> >>>> both)
>>>>> >> >> >>>> * Do the same for 3.2
>>>>> >> >> >>>>
>>>>> >> >> >>>> This doesn't fit with the usual "major numbers are where
>>>>> APIs
>>>>> >> >> >>>> break"
>>>>> >> >> >>>> philosophy that comes from semantic versioning, but I think
>>>>> from
>>>>> >> >> >>>> the
>>>>> >> >> >>>> perspective of pragmatism, if we identify those sections of
>>>>> the
>>>>> >> >> >>>> code
>>>>> >> >> >>>> that are *going* to change, and we pitch 3.0 as the first
>>>>> part of
>>>>> >> >> >>>> a
>>>>> >> >> >>>> staged release of totally rewritten infrastructure, we can
>>>>> likely
>>>>> >> >> >>>> come
>>>>> >> >> >>>> out okay.
>>>>> >> >> >>>>
>>>>> >> >> >>>> I'd like to put this out there for discussion.
>>>>> >> >> >>>>
>>>>> >> >> >>>> -Matt
>>>>> >> >> >>>> _______________________________________________
>>>>> >> >> >>>> yt-dev mailing list
>>>>> >> >> >>>> yt-dev at lists.spacepope.org
>>>>> >> >> >>>>
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>> >> >> >>
>>>>> >> >> >> _______________________________________________
>>>>> >> >> >> yt-dev mailing list
>>>>> >> >> >> yt-dev at lists.spacepope.org
>>>>> >> >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>> >> >> > _______________________________________________
>>>>> >> >> > yt-dev mailing list
>>>>> >> >> > yt-dev at lists.spacepope.org
>>>>> >> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>> >> >> _______________________________________________
>>>>> >> >> yt-dev mailing list
>>>>> >> >> yt-dev at lists.spacepope.org
>>>>> >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > _______________________________________________
>>>>> >> > yt-dev mailing list
>>>>> >> > yt-dev at lists.spacepope.org
>>>>> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>> >> >
>>>>> >> _______________________________________________
>>>>> >> yt-dev mailing list
>>>>> >> yt-dev at lists.spacepope.org
>>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > yt-dev mailing list
>>>>> > yt-dev at lists.spacepope.org
>>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>> >
>>>>> _______________________________________________
>>>>> yt-dev mailing list
>>>>> yt-dev at lists.spacepope.org
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> yt-dev mailing list
>>>> yt-dev at lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Cameron Hummels
>>> Postdoctoral Researcher
>>> Steward Observatory
>>> University of Arizona
>>> http://chummels.org
>>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>
>
> --
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> http://chummels.org
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140624/5ffaa315/attachment.html>