[yt-dev] Merging the unit refactor

Matthew Turk matthewturk at gmail.com
Fri Feb 7 11:41:42 PST 2014 

On Fri, Feb 7, 2014 at 2:37 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
> On Fri, Feb 7, 2014 at 11:33 AM, Matthew Turk <matthewturk at gmail.com> wrote:
>> On Fri, Feb 7, 2014 at 2:31 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
>>> One issue with recommending that people stay on the current yt-3.0 tip
>>> is that there are a number of bugs (the most serious are related to
>>> field detection), that are fixed in unitrefactor.
>>>
>>> The API changes in 3.0 we've been planning for a long time (see the
>>> YTEP repo) were always going to be a bit painful and I think we're
>>> finally at the point where that starts to become a concern.
>>>
>>> So long as there is a big docs push on a relatively short timescale,
>>> I'd be +1 on the approach Matt suggests.
>>>
>>> Matt, where is the documentation you are Britton have started work on?
>>>  I don't see it in MatthewTurk/yt.
>>
>> MatthewTurk/yt-units at 30docs
>>
>
> What about the stumbling blocks document?

doc/source/yt3differences.rst

Just added a few more items to it.

>
>>>
>>> On Fri, Feb 7, 2014 at 11:21 AM, John Zuhone <jzuhone at gmail.com> wrote:
>>>> I guess I see both sides of this. Part of me wants to say that we
>>>> should mark a "stable-ish" alpha/beta/wherever we are version of 3.0
>>>> right before the unit refactoring, and encourage people who use 3.0
>>>> already to stop there for now. I suppose the objection to this is what
>>>> happens when bugs in that version are found, but we also have to think
>>>> about fixing potentially any bug now in light of the new units
>>>> functionality. I'm not myself going to be doing any development from
>>>> this point that doesn't assume the new field system and units, so I
>>>> don't have to change it later.
>>>>
>>>> However, I am not particularly religious on what direction we should
>>>> go with this, so count me as a solid 0.
>>>>
>>>> On Fri, Feb 7, 2014 at 1:47 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>>>>> Hi everyone,
>>>>>
>>>>> I've done a lot of thinking and talking with people about the idea of
>>>>> merging the units stuff into the mainline yt 3.0 branch.
>>>>>
>>>>> There are clear advantages to doing this: people who want to use SPH
>>>>> smoothing would be able to get it from the primary repository, PRs
>>>>> could be done through that repository, and the access to new things
>>>>> would be considerably easier.  More public development and review
>>>>> could happen; while the development already *is* public, it's out of
>>>>> view in my fork of yt.  This is not productive.
>>>>>
>>>>> But the development of yt is not the point of yt.  Using yt to enable
>>>>> scientific discovery is the point of yt.
>>>>>
>>>>> In many ways, the units refactor will enable more scientific
>>>>> discovery.  But it's not ready.  There are people using yt-3.0
>>>>> *already* (prime example: http://nickolas1.com/d3test2/ ) to do really
>>>>> cool science in ways that they can't with 2.x.  And they're doing this
>>>>> with a yt that *mostly* works like the 2.x branch, with the same field
>>>>> names and units and all of that, so the docs *mostly* apply.
>>>>>
>>>>> The units refactor, if merged in, would pull the rug *completely* out
>>>>> from under them.  And there's no safety net.  There's a web of YTEPs
>>>>> and PR comments and notebooks posted to mailing lists, but there's no
>>>>> place they can go and see, "Hey, this worked before, why isn't it
>>>>> now?"  And that's not okay.
>>>>>
>>>>> I've long put off writing documentation, and honestly, I could come up
>>>>> with lots more reasons to put it off.  But I started on Wednesday
>>>>> actually writing things down in earnest, and I think that needs to be
>>>>> the next big push, which I am committed to doing.  Yeah, it's not that
>>>>> fun always.  Especially since things *are* still changing.  But it's
>>>>> not fair -- and it is certainly not in the spirit of *extreme empathy*
>>>>> -- to just change things.
>>>>>
>>>>> But I also want new development to continue.  And so I want a balance
>>>>> to be struck.  I'd like to enumerate the items that are necessary for
>>>>> documentation so that we can merge it in.  I think these are as
>>>>> follows:
>>>>>
>>>>>  * All notebooks should be ported to the 3.0 docs and unit-refactor style
>>>>>  * API documentation has to be able to be compiled
>>>>>  * At a *bare* minimum, a list of stumbling blocks has to be included
>>>>> for moving to 3.0.  Britton and I have started on this and made very
>>>>> good progress.
>>>>>  * We need a bookmark or tag to be included in the repo *pre*-refactor.
>>>>>  * Cookbook recipes must work (I think they mostly do now)
>>>>>
>>>>> Things I don't think we need to do before merging:
>>>>>
>>>>>  * Completely update 100% of the narrative docs
>>>>>  * Document how to add smoothing fields, as I believe this API is in flux
>>>>>  * Describe the underlying methods in great, extensive detail for the
>>>>> new frontends
>>>>>  * A full, complete review of the docs like we did in advance of 2.6
>>>>>
>>>>> As a thought, why don't we treat documentation the way we treat code?
>>>>> Within the project, it seems we're comfortable committing and
>>>>> submitting work-in-progress code, but not docs.  In the past, perhaps
>>>>> this was because the PRs and repos were separate.  They aren't
>>>>> anymore.
>>>>>
>>>>> How does this proposal for the merge sound?  Please render an opinion,
>>>>> as I'd like to have this settled before the early part of next week.
>>>>>
>>>>> Thanks everyone,
>>>>>
>>>>> Matt
>>>>> _______________________________________________
>>>>> yt-dev mailing list
>>>>> yt-dev at lists.spacepope.org
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>
>>>>
>>>>
>>>> --
>>>> John ZuHone
>>>>
>>>> Postdoctoral Researcher
>>>> NASA/Goddard Space Flight Center
>>>>
>>>> jzuhone at gmail.com
>>>> john.zuhone at nasa.gov
>>>> _______________________________________________
>>>> 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

More information about the yt-dev mailing list