[yt-dev] Merging the unit refactor

Matthew Turk matthewturk at gmail.com
Sun Feb 9 11:04:55 PST 2014 

Okay.  We all seem to be in agreement.

In the meantime, I will do my best to stop pushing to my
MatthewTurk/yt repository except as relates to the PRs there, and
would encourage everyone interested in units/sph/30docs work to go to
this URL:

https://bitbucket.org/MatthewTurk/yt

click on the dropdown next to the little eyeball in the upper right
and subscribe to notifications for pull requests.

-Matt

On Fri, Feb 7, 2014 at 5:33 PM, Sam Skillman <samskillman at gmail.com> wrote:
> for proposal in this_thread:
>     proposal += 1
>
>
>
> On Fri, Feb 7, 2014 at 1:42 PM, Britton Smith <brittonsmith at gmail.com>
> wrote:
>>
>> I like Cameron's idea a ton.  We do have to draw a line somewhere on these
>> docs or else they will never get done.  I really like the idea of allowing
>> changes into the development (here yt-3.0) branch with minimal/some docs,
>> but an absolute hard deadline when it comes to changes getting into stable
>> releases.  I also think we need to establish some sort of guideline for
>> minimally acceptable documentation otherwise we risk losing the bridge to
>> the rest of the developers.
>>
>> Britton
>>
>>
>> On Fri, Feb 7, 2014 at 4:31 PM, Cameron Hummels <chummels at gmail.com>
>> wrote:
>>>
>>> Hey guys,
>>>
>>> I'm +1 on this--no strings attached.  I totally agree with what Matt has
>>> said above, as I do see the need to get unit refactor into the main
>>> development line, since much of the current development has taken place
>>> there as of late.
>>>
>>> I think Matt's suggestions for blockers on the docs are spot-on, and I
>>> applaud the efforts that he has already made to get them moving.  I
>>> understand not having a full docs refactor immediately, in a desire to get
>>> the code available to the userbase.  I'm very happy to review stuff, but I'm
>>> afraid I cannot be much help in authorship given that I have little
>>> experience with the new refactor.
>>>
>>> The only small thing that I might suggest is to have some sort of
>>> timeline, even if it is a loose one, on when we can complete the narrative
>>> docs, the SPH smoothing docs, and bringing the docs fully up to speed with
>>> 3.0.  I realize this may take some time, but I think it is important to not
>>> get into a deficit on this, as it will likely just grow with time (I say
>>> this as an experienced procrastinator).  Maybe before 3.0 is officially
>>> released to the community as a stable version?  Maybe shortly after?  I'd be
>>> interested in other's thoughts on this and I'm flexible on this.
>>>
>>> Thanks, Matt.
>>>
>>> Cameron
>>>
>>>
>>>
>>>
>>> On Fri, Feb 7, 2014 at 12:41 PM, Matthew Turk <matthewturk at gmail.com>
>>> wrote:
>>>>
>>>> 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
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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