[yt-dev] Merging the unit refactor

Fri Feb 7 13:31:22 PST 2014

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140207/bb8af966/attachment.htm>