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 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 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- John ZuHone

Postdoctoral Researcher NASA/Goddard Space Flight Center

jzuhone@gmail.com john.zuhone@nasa.gov _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

On Fri, Feb 7, 2014 at 11:33 AM, Matthew Turk wrote:

On Fri, Feb 7, 2014 at 2:31 PM, Nathan Goldbaum 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@30docs

What about the stumbling blocks document?

...

On Fri, Feb 7, 2014 at 11:21 AM, John Zuhone 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 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- John ZuHone

Postdoctoral Researcher NASA/Goddard Space Flight Center

jzuhone@gmail.com john.zuhone@nasa.gov _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

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 wrote:

On Fri, Feb 7, 2014 at 2:37 PM, Nathan Goldbaum wrote:

...

On Fri, Feb 7, 2014 at 11:33 AM, Matthew Turk wrote:

...

On Fri, Feb 7, 2014 at 2:31 PM, Nathan Goldbaum 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@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

...

...

...

...

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 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

...

...

...

...

...

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

...

...

...

...

...

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

wrote: this that 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- John ZuHone

Postdoctoral Researcher NASA/Goddard Space Flight Center

jzuhone@gmail.com john.zuhone@nasa.gov _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@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

for proposal in this_thread: proposal += 1 On Fri, Feb 7, 2014 at 1:42 PM, Britton Smith 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 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 wrote:

...

On Fri, Feb 7, 2014 at 2:37 PM, Nathan Goldbaum wrote:

...

On Fri, Feb 7, 2014 at 11:33 AM, Matthew Turk wrote:

...

On Fri, Feb 7, 2014 at 2:31 PM, Nathan Goldbaum < nathan12343@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@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

...

...

...

> 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

...

...

...

> 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 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

...

...

...

>> 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

...

...

...

>> 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

...

...

...

>> 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,

wrote: think this that the 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@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > -- > John ZuHone > > Postdoctoral Researcher > NASA/Goddard Space Flight Center > > jzuhone@gmail.com > john.zuhone@nasa.gov > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

We've been tracking development on this stuff using two trello boards: https://trello.com/b/yv7o0dTp/unit-refactor https://trello.com/b/HCLLFxEE/documentation We've found trello to be really useful - think of it as a distributed whiteboard. Right now we're blocked on merging unitrefactor into yt-3.0 by the red items on the documentation board. If you'd like access to the trello boards, let Matt know and he can set you up. Please also let us know if you think we're missing something. On Sun, Feb 9, 2014 at 11:04 AM, Matthew Turk wrote:

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 wrote:

...

for proposal in this_thread: proposal += 1

On Fri, Feb 7, 2014 at 1:42 PM, Britton Smith 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 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 wrote:

...

On Fri, Feb 7, 2014 at 2:37 PM, Nathan Goldbaum wrote:

...

On Fri, Feb 7, 2014 at 11:33 AM, Matthew Turk wrote: > On Fri, Feb 7, 2014 at 2:31 PM, Nathan Goldbaum > 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@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 >> 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 >>> 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@lists.spacepope.org >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >>> >>> >>> -- >>> John ZuHone >>> >>> Postdoctoral Researcher >>> NASA/Goddard Space Flight Center >>> >>> jzuhone@gmail.com >>> john.zuhone@nasa.gov >>> _______________________________________________ >>> yt-dev mailing list >>> yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org