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

Nathan Goldbaum nathan12343 at gmail.com
Tue Jun 24 17:32:06 PDT 2014


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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','john.zuhone at nasa.gov');>
>>> >> >> jzuhone at gmail.com
>>> <javascript:_e(%7B%7D,'cvml','jzuhone at gmail.com');>
>>> >> >>
>>> >> >> > On Jun 24, 2014, at 12:38 PM, Matthew Turk <
>>> matthewturk at gmail.com
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140624/5f08b146/attachment.html>


More information about the yt-dev mailing list