[yt-dev] Merging the unit refactor
Nathan Goldbaum
nathan12343 at gmail.com
Fri Feb 7 11:31:43 PST 2014
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.
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
More information about the yt-dev
mailing list