If the release timeframe is end of year, I will put in the alpha channel rendering, enabling a lot of cool things. It is already functional in one of my forks, but it needs to be cleaned up. Sam On Tue, Oct 9, 2012 at 3:28 PM, Matthew Turk wrote:

Hi Jeff,

On Tue, Oct 9, 2012 at 2:19 PM, j s oishi wrote:

...

Hi,

Since testing is something that is so high priority for this, and otherwise 2.5 is just a stepping stone to 3.0 (which a *lot* of people are already diving into), maybe we should *only* include testing, unless there are some already done things we could toss in?

j

Come to mention it, I *really* like this idea. Perhaps we should identify a threshold for building out the non-core infrastructure fixes (i.e., having "pip install yt" work, having a good set of testing, etc etc) and then any other fixes or improvements that happen along the way are just icing on the cake? I think having better testing should definitely be the focus, particularly as we transition the codebase.

-Matt

...

On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk

wrote:

...

...

Hi all,

We should probably try to get a 2.5 release together by the end of the year. It would be really helpful if you are working on something, to fill it out and target both milestone 2.5 and version 2.5 as an issue. That way we can identify goals and push to stable. Testing should perhaps be a huge focus of this release. But, once it's done, I think we can try to transition to 3.0 for development.

Here's the current list, which may need curation a bit as some seem to be completed or in progress:

https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5

...

If you want to subdivide something, create a new milestone and target *that*, but with *version* 2.5.

-Matt

PS The new bitbucket redesign is quite nice! _______________________________________________ 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

Sounds good to me. I was actually also holding out a bit to incorporate testing into some of the new rendering capabilities anyways. On Tue, Oct 9, 2012 at 3:36 PM, Matthew Turk wrote:

Hi Sam,

On Tue, Oct 9, 2012 at 2:30 PM, Sam Skillman wrote:

...

If the release timeframe is end of year, I will put in the alpha channel rendering, enabling a lot of cool things. It is already functional in one of my forks, but it needs to be cleaned up.

What if we said instead that we'd release as soon as unit testing is ready and 3.0 is ready for daily use for patch-based AMR, and then if you have time before that point to get the alpha channel in good, but otherwise toss it into 3.0?

-Matt

...

Sam

On Tue, Oct 9, 2012 at 3:28 PM, Matthew Turk

...

...

Hi Jeff,

On Tue, Oct 9, 2012 at 2:19 PM, j s oishi wrote:

...

Hi,

Since testing is something that is so high priority for this, and otherwise 2.5 is just a stepping stone to 3.0 (which a *lot* of people are already diving into), maybe we should *only* include testing, unless there are some already done things we could toss in?

j

Come to mention it, I *really* like this idea. Perhaps we should identify a threshold for building out the non-core infrastructure fixes (i.e., having "pip install yt" work, having a good set of testing, etc etc) and then any other fixes or improvements that happen along the way are just icing on the cake? I think having better testing should definitely be the focus, particularly as we transition the codebase.

-Matt

...

On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk wrote:

...

Hi all,

We should probably try to get a 2.5 release together by the end of

...

...

...

...

year. It would be really helpful if you are working on something, to fill it out and target both milestone 2.5 and version 2.5 as an issue. That way we can identify goals and push to stable. Testing should perhaps be a huge focus of this release. But, once it's done, I

wrote: the think

...

...

...

...

we can try to transition to 3.0 for development.

Here's the current list, which may need curation a bit as some seem to be completed or in progress:

https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5

...

If you want to subdivide something, create a new milestone and target *that*, but with *version* 2.5.

-Matt

PS The new bitbucket redesign is quite nice! _______________________________________________ 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

Hi Casey, On Tue, Oct 9, 2012 at 3:59 PM, Casey W. Stark wrote:

Just so this is clear, if we are working on development that is not testing, should we move over to 3.0 now?

Not yet, but soon. Sorry, I should have been more clear -- I believe it's almost ready for primetime, and in a settled state for rectilinear, patch-based data. I will update the list very, very soon on its state. I'll go through the milestone list and take a crack at updating the tickets, the scripts, and report back. -Matt

- Casey

On Tue, Oct 9, 2012 at 2:38 PM, Sam Skillman wrote:

...

Sounds good to me. I was actually also holding out a bit to incorporate testing into some of the new rendering capabilities anyways.

On Tue, Oct 9, 2012 at 3:36 PM, Matthew Turk wrote:

...

Hi Sam,

On Tue, Oct 9, 2012 at 2:30 PM, Sam Skillman wrote:

...

If the release timeframe is end of year, I will put in the alpha channel rendering, enabling a lot of cool things. It is already functional in one of my forks, but it needs to be cleaned up.

What if we said instead that we'd release as soon as unit testing is ready and 3.0 is ready for daily use for patch-based AMR, and then if you have time before that point to get the alpha channel in good, but otherwise toss it into 3.0?

-Matt

...

Sam

On Tue, Oct 9, 2012 at 3:28 PM, Matthew Turk wrote:

...

Hi Jeff,

On Tue, Oct 9, 2012 at 2:19 PM, j s oishi wrote:

...

Hi,

Since testing is something that is so high priority for this, and otherwise 2.5 is just a stepping stone to 3.0 (which a *lot* of people are already diving into), maybe we should *only* include testing, unless there are some already done things we could toss in?

j

Come to mention it, I *really* like this idea. Perhaps we should identify a threshold for building out the non-core infrastructure fixes (i.e., having "pip install yt" work, having a good set of testing, etc etc) and then any other fixes or improvements that happen along the way are just icing on the cake? I think having better testing should definitely be the focus, particularly as we transition the codebase.

-Matt

...

On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk wrote: > Hi all, > > We should probably try to get a 2.5 release together by the end of > the > year. It would be really helpful if you are working on something, > to > fill it out and target both milestone 2.5 and version 2.5 as an > issue. > That way we can identify goals and push to stable. Testing should > perhaps be a huge focus of this release. But, once it's done, I > think > we can try to transition to 3.0 for development. > > Here's the current list, which may need curation a bit as some seem > to > be completed or in progress: > > > > https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5 > > If you want to subdivide something, create a new milestone and > target > *that*, but with *version* 2.5. > > -Matt > > PS The new bitbucket redesign is quite nice! > _______________________________________________ > 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

_______________________________________________ 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

Hi Mike, On Tue, Oct 9, 2012 at 9:23 PM, Michael Kuhlen wrote:

Hi Jeff

...

Holy crap, I didn't realize

pip install yt

was a goal! that would be awesome.

In that case you may be interested in this ubuntu PPA I made a little while ago, for yt (2.4) and yt-devel (2.5): https://launchpad.net/~kuhlen/+archive/ppa

The current version of yt-devel is based on changeset 467f57b (from 08/24). I need to update it...

I completely forgot to update the web page! I will do this either tomorrow or Thursday (although if anybody wants to issue a pull request to the website with the info, it can be redeployed asap.) Thank you again for doing this! I think the PPA, Kacper's ebuild, having pip install work, and TomR's MacPorts are all really, really good reasons to start focusing on reducing the install script overhead, handling things like dependencies in a more clear way, and making yt work as an independent software package much better. And I think the more we move into this area the more we should try to have a rolling, regular release schedule. Does that ring true to everybody else, too? The more we have the ability to install yt independently of hg, independently of the install_script, the more we should try to make a regular release schedule with it. -Matt

Cheers,

Mike

On Tue, Oct 9, 2012 at 4:03 PM, Matthew Turk wrote:

...

Hi Casey,

On Tue, Oct 9, 2012 at 3:59 PM, Casey W. Stark wrote:

...

Just so this is clear, if we are working on development that is not testing, should we move over to 3.0 now?

Not yet, but soon. Sorry, I should have been more clear -- I believe it's almost ready for primetime, and in a settled state for rectilinear, patch-based data. I will update the list very, very soon on its state. I'll go through the milestone list and take a crack at updating the tickets, the scripts, and report back.

-Matt

...

- Casey

On Tue, Oct 9, 2012 at 2:38 PM, Sam Skillman wrote:

...

Sounds good to me. I was actually also holding out a bit to incorporate testing into some of the new rendering capabilities anyways.

On Tue, Oct 9, 2012 at 3:36 PM, Matthew Turk wrote:

...

Hi Sam,

On Tue, Oct 9, 2012 at 2:30 PM, Sam Skillman wrote:

...

If the release timeframe is end of year, I will put in the alpha channel rendering, enabling a lot of cool things. It is already functional in one of my forks, but it needs to be cleaned up.

What if we said instead that we'd release as soon as unit testing is ready and 3.0 is ready for daily use for patch-based AMR, and then if you have time before that point to get the alpha channel in good, but otherwise toss it into 3.0?

-Matt

...

Sam

On Tue, Oct 9, 2012 at 3:28 PM, Matthew Turk wrote: > > Hi Jeff, > > On Tue, Oct 9, 2012 at 2:19 PM, j s oishi > wrote: > > Hi, > > > > Since testing is something that is so high priority for this, and > > otherwise 2.5 is just a stepping stone to 3.0 (which a *lot* of > > people > > are already diving into), maybe we should *only* include testing, > > unless there are some already done things we could toss in? > > > > j > > Come to mention it, I *really* like this idea. Perhaps we should > identify a threshold for building out the non-core infrastructure > fixes (i.e., having "pip install yt" work, having a good set of > testing, etc etc) and then any other fixes or improvements that > happen > along the way are just icing on the cake? I think having better > testing should definitely be the focus, particularly as we > transition > the codebase. > > -Matt > > > > > On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk > > > > wrote: > >> Hi all, > >> > >> We should probably try to get a 2.5 release together by the end > >> of > >> the > >> year. It would be really helpful if you are working on > >> something, > >> to > >> fill it out and target both milestone 2.5 and version 2.5 as an > >> issue. > >> That way we can identify goals and push to stable. Testing > >> should > >> perhaps be a huge focus of this release. But, once it's done, I > >> think > >> we can try to transition to 3.0 for development. > >> > >> Here's the current list, which may need curation a bit as some > >> seem > >> to > >> be completed or in progress: > >> > >> > >> > >> > >> https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5 > >> > >> If you want to subdivide something, create a new milestone and > >> target > >> *that*, but with *version* 2.5. > >> > >> -Matt > >> > >> PS The new bitbucket redesign is quite nice! > >> _______________________________________________ > >> 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

_______________________________________________ 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

-- ********************************************************************* * * * Dr. Michael Kuhlen Theoretical Astrophysics Center * * email: mqk@astro.berkeley.edu UC Berkeley * * cell phone: (831) 588-1468 B-116 Hearst Field Annex # 3411 * * skype username: mikekuhlen Berkeley, CA 94720 * * * *********************************************************************

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

Hi Sam, On Tue, Oct 9, 2012 at 9:42 PM, Sam Skillman wrote:

On Tue, Oct 9, 2012 at 10:34 PM, Matthew Turk wrote:

...

Hi Mike,

On Tue, Oct 9, 2012 at 9:23 PM, Michael Kuhlen wrote:

...

Hi Jeff

...

Holy crap, I didn't realize

pip install yt

was a goal! that would be awesome.

In that case you may be interested in this ubuntu PPA I made a little while ago, for yt (2.4) and yt-devel (2.5): https://launchpad.net/~kuhlen/+archive/ppa

The current version of yt-devel is based on changeset 467f57b (from 08/24). I need to update it...

I completely forgot to update the web page! I will do this either tomorrow or Thursday (although if anybody wants to issue a pull request to the website with the info, it can be redeployed asap.) Thank you again for doing this!

I think the PPA, Kacper's ebuild, having pip install work, and TomR's MacPorts are all really, really good reasons to start focusing on reducing the install script overhead, handling things like dependencies in a more clear way, and making yt work as an independent software package much better. And I think the more we move into this area the more we should try to have a rolling, regular release schedule. Does that ring true to everybody else, too? The more we have the ability to install yt independently of hg, independently of the install_script, the more we should try to make a regular release schedule with it.

Yes! I personally think regular releases should be nearly automated based on the passing of tests at regular intervals (i.e. monthly/quarterly). If we are diligent about setting up BB issues that track individual enhancements, even the features changelog could be easily generated.

I like this idea. We have speculated in the past about moving to quarterly releases. If we were better about managing the issue tracker (or JIRA!) and unit (not just answer) testing new functionality, this would be easier to manage. Furthermore, as you note, the changelog would be easier to write. Should we mandate that any substantial PR also include reference to an issue? Perhaps simply having an issue point to the PR and be closed when the PR is closed is good, to ensure we don't fragment the PR conversations but that we have a unified place where changes are tracked. I would support this. But we *need* to have a testing push to make it happen. I've been out of the loop most of this week, but I hope to be back in action next week. So what we're looking at is: 1) Issue tracking for enhancements, to allow for changelog writing and so on 2) Regular releases -- I'd push for quarterly -- with a real release coordinator 3) Much higher barrier to entry for testing Would contributors be willing to participate in this? I will commit to unit testing new functionality in advance of any push or PR. -Matt

Sam

...

-Matt

...

Cheers,

Mike

On Tue, Oct 9, 2012 at 4:03 PM, Matthew Turk wrote:

...

Hi Casey,

On Tue, Oct 9, 2012 at 3:59 PM, Casey W. Stark wrote:

...

Just so this is clear, if we are working on development that is not testing, should we move over to 3.0 now?

Not yet, but soon. Sorry, I should have been more clear -- I believe it's almost ready for primetime, and in a settled state for rectilinear, patch-based data. I will update the list very, very soon on its state. I'll go through the milestone list and take a crack at updating the tickets, the scripts, and report back.

-Matt

...

- Casey

On Tue, Oct 9, 2012 at 2:38 PM, Sam Skillman wrote:

...

Sounds good to me. I was actually also holding out a bit to incorporate testing into some of the new rendering capabilities anyways.

On Tue, Oct 9, 2012 at 3:36 PM, Matthew Turk wrote: > > Hi Sam, > > On Tue, Oct 9, 2012 at 2:30 PM, Sam Skillman > > wrote: > > If the release timeframe is end of year, I will put in the alpha > > channel > > rendering, enabling a lot of cool things. It is already > > functional > > in > > one > > of my forks, but it needs to be cleaned up. > > What if we said instead that we'd release as soon as unit testing > is > ready and 3.0 is ready for daily use for patch-based AMR, and then > if > you have time before that point to get the alpha channel in good, > but > otherwise toss it into 3.0? > > -Matt > > > > > Sam > > > > > > On Tue, Oct 9, 2012 at 3:28 PM, Matthew Turk > > > > wrote: > >> > >> Hi Jeff, > >> > >> On Tue, Oct 9, 2012 at 2:19 PM, j s oishi > >> wrote: > >> > Hi, > >> > > >> > Since testing is something that is so high priority for this, > >> > and > >> > otherwise 2.5 is just a stepping stone to 3.0 (which a *lot* > >> > of > >> > people > >> > are already diving into), maybe we should *only* include > >> > testing, > >> > unless there are some already done things we could toss in? > >> > > >> > j > >> > >> Come to mention it, I *really* like this idea. Perhaps we > >> should > >> identify a threshold for building out the non-core > >> infrastructure > >> fixes (i.e., having "pip install yt" work, having a good set of > >> testing, etc etc) and then any other fixes or improvements that > >> happen > >> along the way are just icing on the cake? I think having better > >> testing should definitely be the focus, particularly as we > >> transition > >> the codebase. > >> > >> -Matt > >> > >> > > >> > On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk > >> > > >> > wrote: > >> >> Hi all, > >> >> > >> >> We should probably try to get a 2.5 release together by the > >> >> end > >> >> of > >> >> the > >> >> year. It would be really helpful if you are working on > >> >> something, > >> >> to > >> >> fill it out and target both milestone 2.5 and version 2.5 as > >> >> an > >> >> issue. > >> >> That way we can identify goals and push to stable. Testing > >> >> should > >> >> perhaps be a huge focus of this release. But, once it's > >> >> done, I > >> >> think > >> >> we can try to transition to 3.0 for development. > >> >> > >> >> Here's the current list, which may need curation a bit as > >> >> some > >> >> seem > >> >> to > >> >> be completed or in progress: > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5 > >> >> > >> >> If you want to subdivide something, create a new milestone > >> >> and > >> >> target > >> >> *that*, but with *version* 2.5. > >> >> > >> >> -Matt > >> >> > >> >> PS The new bitbucket redesign is quite nice! > >> >> _______________________________________________ > >> >> 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

_______________________________________________ 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

-- ********************************************************************* * * * Dr. Michael Kuhlen Theoretical Astrophysics Center * * email: mqk@astro.berkeley.edu UC Berkeley * * cell phone: (831) 588-1468 B-116 Hearst Field Annex # 3411 * * skype username: mikekuhlen Berkeley, CA 94720 * * * *********************************************************************

_______________________________________________ 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 Britton, No worries about asking again -- there are currently two types of tests. One is nascent, and only a handful exist (although many libraries have many thousands) and that's unit testing. That's primarily what Sam and everyone else are talking about, although "testing" also includes Answer Testing, which is currently running every 30 minutes or so on my machine. We want to supplement answer testing with much smaller, more contained unit testing. Answer testing is the same thing you and I worked on about a year ago, and it's also what we use for Enzo. (That was the subject of the ticket, although now it needs to be extended.) But, we now want to add on very tiny, unit tests that do not require either a reference answer that's externally available or a lot of time to run the tests. So for instance, this would be the new interpolation tests and so on. -Matt On Wed, Oct 10, 2012 at 8:27 AM, Britton Smith wrote:

Hi all,

I apologize if I'm asking questions on things that have already been discussed. What documentation currently exists on the testing infrastructure, specifically how to write and contribute the tests? I have been long assigned to the issue of "testing documentation" on the issue tracker, but I took myself off it this morning because I haven't worked with it in so long that I don't remember how it works. I would be willing to help out getting the tests together, but it would be helpful if there was something I could go look at for how to do them and what remains. I've been out of the loop for a while, so sorry if this has been dealt with.

Also, I like the idea of having an issue that can be pointed to for each enhancement. I would support that as well as quarterly releases.

Britton

On Wed, Oct 10, 2012 at 10:48 AM, Matthew Turk wrote:

...

Hi Sam,

On Tue, Oct 9, 2012 at 9:42 PM, Sam Skillman wrote:

...

On Tue, Oct 9, 2012 at 10:34 PM, Matthew Turk wrote:

...

Hi Mike,

On Tue, Oct 9, 2012 at 9:23 PM, Michael Kuhlen wrote:

...

Hi Jeff

...

Holy crap, I didn't realize

pip install yt

was a goal! that would be awesome.

In that case you may be interested in this ubuntu PPA I made a little while ago, for yt (2.4) and yt-devel (2.5): https://launchpad.net/~kuhlen/+archive/ppa

The current version of yt-devel is based on changeset 467f57b (from 08/24). I need to update it...

I completely forgot to update the web page! I will do this either tomorrow or Thursday (although if anybody wants to issue a pull request to the website with the info, it can be redeployed asap.) Thank you again for doing this!

I think the PPA, Kacper's ebuild, having pip install work, and TomR's MacPorts are all really, really good reasons to start focusing on reducing the install script overhead, handling things like dependencies in a more clear way, and making yt work as an independent software package much better. And I think the more we move into this area the more we should try to have a rolling, regular release schedule. Does that ring true to everybody else, too? The more we have the ability to install yt independently of hg, independently of the install_script, the more we should try to make a regular release schedule with it.

Yes! I personally think regular releases should be nearly automated based on the passing of tests at regular intervals (i.e. monthly/quarterly). If we are diligent about setting up BB issues that track individual enhancements, even the features changelog could be easily generated.

I like this idea. We have speculated in the past about moving to quarterly releases. If we were better about managing the issue tracker (or JIRA!) and unit (not just answer) testing new functionality, this would be easier to manage. Furthermore, as you note, the changelog would be easier to write. Should we mandate that any substantial PR also include reference to an issue? Perhaps simply having an issue point to the PR and be closed when the PR is closed is good, to ensure we don't fragment the PR conversations but that we have a unified place where changes are tracked.

I would support this. But we *need* to have a testing push to make it happen. I've been out of the loop most of this week, but I hope to be back in action next week. So what we're looking at is:

1) Issue tracking for enhancements, to allow for changelog writing and so on 2) Regular releases -- I'd push for quarterly -- with a real release coordinator 3) Much higher barrier to entry for testing

Would contributors be willing to participate in this? I will commit to unit testing new functionality in advance of any push or PR.

-Matt

...

Sam

...

-Matt

...

Cheers,

Mike

On Tue, Oct 9, 2012 at 4:03 PM, Matthew Turk wrote:

...

Hi Casey,

On Tue, Oct 9, 2012 at 3:59 PM, Casey W. Stark wrote: > Just so this is clear, if we are working on development that is > not > testing, > should we move over to 3.0 now?

Not yet, but soon. Sorry, I should have been more clear -- I believe it's almost ready for primetime, and in a settled state for rectilinear, patch-based data. I will update the list very, very soon on its state. I'll go through the milestone list and take a crack at updating the tickets, the scripts, and report back.

-Matt

> > - Casey > > > On Tue, Oct 9, 2012 at 2:38 PM, Sam Skillman > > wrote: >> >> Sounds good to me. I was actually also holding out a bit to >> incorporate >> testing into some of the new rendering capabilities anyways. >> >> >> On Tue, Oct 9, 2012 at 3:36 PM, Matthew Turk >> >> wrote: >>> >>> Hi Sam, >>> >>> On Tue, Oct 9, 2012 at 2:30 PM, Sam Skillman >>> >>> wrote: >>> > If the release timeframe is end of year, I will put in the >>> > alpha >>> > channel >>> > rendering, enabling a lot of cool things. It is already >>> > functional >>> > in >>> > one >>> > of my forks, but it needs to be cleaned up. >>> >>> What if we said instead that we'd release as soon as unit >>> testing >>> is >>> ready and 3.0 is ready for daily use for patch-based AMR, and >>> then >>> if >>> you have time before that point to get the alpha channel in >>> good, >>> but >>> otherwise toss it into 3.0? >>> >>> -Matt >>> >>> > >>> > Sam >>> > >>> > >>> > On Tue, Oct 9, 2012 at 3:28 PM, Matthew Turk >>> > >>> > wrote: >>> >> >>> >> Hi Jeff, >>> >> >>> >> On Tue, Oct 9, 2012 at 2:19 PM, j s oishi >>> >> wrote: >>> >> > Hi, >>> >> > >>> >> > Since testing is something that is so high priority for >>> >> > this, >>> >> > and >>> >> > otherwise 2.5 is just a stepping stone to 3.0 (which a >>> >> > *lot* >>> >> > of >>> >> > people >>> >> > are already diving into), maybe we should *only* include >>> >> > testing, >>> >> > unless there are some already done things we could toss in? >>> >> > >>> >> > j >>> >> >>> >> Come to mention it, I *really* like this idea. Perhaps we >>> >> should >>> >> identify a threshold for building out the non-core >>> >> infrastructure >>> >> fixes (i.e., having "pip install yt" work, having a good set >>> >> of >>> >> testing, etc etc) and then any other fixes or improvements >>> >> that >>> >> happen >>> >> along the way are just icing on the cake? I think having >>> >> better >>> >> testing should definitely be the focus, particularly as we >>> >> transition >>> >> the codebase. >>> >> >>> >> -Matt >>> >> >>> >> > >>> >> > On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk >>> >> > >>> >> > wrote: >>> >> >> Hi all, >>> >> >> >>> >> >> We should probably try to get a 2.5 release together by >>> >> >> the >>> >> >> end >>> >> >> of >>> >> >> the >>> >> >> year. It would be really helpful if you are working on >>> >> >> something, >>> >> >> to >>> >> >> fill it out and target both milestone 2.5 and version 2.5 >>> >> >> as >>> >> >> an >>> >> >> issue. >>> >> >> That way we can identify goals and push to stable. >>> >> >> Testing >>> >> >> should >>> >> >> perhaps be a huge focus of this release. But, once it's >>> >> >> done, I >>> >> >> think >>> >> >> we can try to transition to 3.0 for development. >>> >> >> >>> >> >> Here's the current list, which may need curation a bit as >>> >> >> some >>> >> >> seem >>> >> >> to >>> >> >> be completed or in progress: >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5 >>> >> >> >>> >> >> If you want to subdivide something, create a new milestone >>> >> >> and >>> >> >> target >>> >> >> *that*, but with *version* 2.5. >>> >> >> >>> >> >> -Matt >>> >> >> >>> >> >> PS The new bitbucket redesign is quite nice! >>> >> >> _______________________________________________ >>> >> >> 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 >> >> >> >> _______________________________________________ >> 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

-- ********************************************************************* * * * Dr. Michael Kuhlen Theoretical Astrophysics Center * * email: mqk@astro.berkeley.edu UC Berkeley * * cell phone: (831) 588-1468 B-116 Hearst Field Annex # 3411 * * skype username: mikekuhlen Berkeley, CA 94720 * * * *********************************************************************

_______________________________________________ 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

Hi Britton, On Thu, Oct 11, 2012 at 4:42 AM, Britton Smith wrote:

Hi Matt,

Are there resources describing how to set up new tests?

Unit tests can be set up in the NumPy style, similar to what Anthony has been doing and I have been doing as well in the "tests" subdirectories. We've started sketching out some yt-specific support routines in yt/testing.py. The NumPy docs are here: http://docs.scipy.org/doc/numpy/reference/routines.testing.html https://github.com/numpy/numpy/blob/master/doc/TESTS.rst.txt The answer tests are not documented except by example; that's what that ticket was aiming at. I've assigned that to myself. -Matt

Britton

On Wed, Oct 10, 2012 at 7:26 PM, Matthew Turk wrote:

...

Hey Britton,

No worries about asking again -- there are currently two types of tests. One is nascent, and only a handful exist (although many libraries have many thousands) and that's unit testing. That's primarily what Sam and everyone else are talking about, although "testing" also includes Answer Testing, which is currently running every 30 minutes or so on my machine. We want to supplement answer testing with much smaller, more contained unit testing. Answer testing is the same thing you and I worked on about a year ago, and it's also what we use for Enzo. (That was the subject of the ticket, although now it needs to be extended.)

But, we now want to add on very tiny, unit tests that do not require either a reference answer that's externally available or a lot of time to run the tests. So for instance, this would be the new interpolation tests and so on.

-Matt

On Wed, Oct 10, 2012 at 8:27 AM, Britton Smith wrote:

...

Hi all,

I apologize if I'm asking questions on things that have already been discussed. What documentation currently exists on the testing infrastructure, specifically how to write and contribute the tests? I have been long assigned to the issue of "testing documentation" on the issue tracker, but I took myself off it this morning because I haven't worked with it in so long that I don't remember how it works. I would be willing to help out getting the tests together, but it would be helpful if there was something I could go look at for how to do them and what remains. I've been out of the loop for a while, so sorry if this has been dealt with.

Also, I like the idea of having an issue that can be pointed to for each enhancement. I would support that as well as quarterly releases.

Britton

On Wed, Oct 10, 2012 at 10:48 AM, Matthew Turk wrote:

...

Hi Sam,

On Tue, Oct 9, 2012 at 9:42 PM, Sam Skillman wrote:

...

On Tue, Oct 9, 2012 at 10:34 PM, Matthew Turk wrote:

...

Hi Mike,

On Tue, Oct 9, 2012 at 9:23 PM, Michael Kuhlen wrote: > Hi Jeff > > >> Holy crap, I didn't realize >> >> pip install yt >> >> was a goal! that would be awesome. > > In that case you may be interested in this ubuntu PPA I made a > little > while > ago, for yt (2.4) and yt-devel (2.5): > https://launchpad.net/~kuhlen/+archive/ppa > > The current version of yt-devel is based on changeset 467f57b > (from > 08/24). > I need to update it...

I completely forgot to update the web page! I will do this either tomorrow or Thursday (although if anybody wants to issue a pull request to the website with the info, it can be redeployed asap.) Thank you again for doing this!

I think the PPA, Kacper's ebuild, having pip install work, and TomR's MacPorts are all really, really good reasons to start focusing on reducing the install script overhead, handling things like dependencies in a more clear way, and making yt work as an independent software package much better. And I think the more we move into this area the more we should try to have a rolling, regular release schedule. Does that ring true to everybody else, too? The more we have the ability to install yt independently of hg, independently of the install_script, the more we should try to make a regular release schedule with it.

Yes! I personally think regular releases should be nearly automated based on the passing of tests at regular intervals (i.e. monthly/quarterly). If we are diligent about setting up BB issues that track individual enhancements, even the features changelog could be easily generated.

I like this idea. We have speculated in the past about moving to quarterly releases. If we were better about managing the issue tracker (or JIRA!) and unit (not just answer) testing new functionality, this would be easier to manage. Furthermore, as you note, the changelog would be easier to write. Should we mandate that any substantial PR also include reference to an issue? Perhaps simply having an issue point to the PR and be closed when the PR is closed is good, to ensure we don't fragment the PR conversations but that we have a unified place where changes are tracked.

I would support this. But we *need* to have a testing push to make it happen. I've been out of the loop most of this week, but I hope to be back in action next week. So what we're looking at is:

1) Issue tracking for enhancements, to allow for changelog writing and so on 2) Regular releases -- I'd push for quarterly -- with a real release coordinator 3) Much higher barrier to entry for testing

Would contributors be willing to participate in this? I will commit to unit testing new functionality in advance of any push or PR.

-Matt

...

Sam

...

-Matt

> > Cheers, > > Mike > > > On Tue, Oct 9, 2012 at 4:03 PM, Matthew Turk > > wrote: >> >> Hi Casey, >> >> On Tue, Oct 9, 2012 at 3:59 PM, Casey W. Stark >> >> wrote: >> > Just so this is clear, if we are working on development that is >> > not >> > testing, >> > should we move over to 3.0 now? >> >> Not yet, but soon. Sorry, I should have been more clear -- I >> believe >> it's almost ready for primetime, and in a settled state for >> rectilinear, patch-based data. I will update the list very, very >> soon >> on its state. I'll go through the milestone list and take a >> crack >> at >> updating the tickets, the scripts, and report back. >> >> -Matt >> >> > >> > - Casey >> > >> > >> > On Tue, Oct 9, 2012 at 2:38 PM, Sam Skillman >> > >> > wrote: >> >> >> >> Sounds good to me. I was actually also holding out a bit to >> >> incorporate >> >> testing into some of the new rendering capabilities anyways. >> >> >> >> >> >> On Tue, Oct 9, 2012 at 3:36 PM, Matthew Turk >> >> >> >> wrote: >> >>> >> >>> Hi Sam, >> >>> >> >>> On Tue, Oct 9, 2012 at 2:30 PM, Sam Skillman >> >>> >> >>> wrote: >> >>> > If the release timeframe is end of year, I will put in the >> >>> > alpha >> >>> > channel >> >>> > rendering, enabling a lot of cool things. It is already >> >>> > functional >> >>> > in >> >>> > one >> >>> > of my forks, but it needs to be cleaned up. >> >>> >> >>> What if we said instead that we'd release as soon as unit >> >>> testing >> >>> is >> >>> ready and 3.0 is ready for daily use for patch-based AMR, and >> >>> then >> >>> if >> >>> you have time before that point to get the alpha channel in >> >>> good, >> >>> but >> >>> otherwise toss it into 3.0? >> >>> >> >>> -Matt >> >>> >> >>> > >> >>> > Sam >> >>> > >> >>> > >> >>> > On Tue, Oct 9, 2012 at 3:28 PM, Matthew Turk >> >>> > >> >>> > wrote: >> >>> >> >> >>> >> Hi Jeff, >> >>> >> >> >>> >> On Tue, Oct 9, 2012 at 2:19 PM, j s oishi >> >>> >> >> >>> >> wrote: >> >>> >> > Hi, >> >>> >> > >> >>> >> > Since testing is something that is so high priority for >> >>> >> > this, >> >>> >> > and >> >>> >> > otherwise 2.5 is just a stepping stone to 3.0 (which a >> >>> >> > *lot* >> >>> >> > of >> >>> >> > people >> >>> >> > are already diving into), maybe we should *only* include >> >>> >> > testing, >> >>> >> > unless there are some already done things we could toss >> >>> >> > in? >> >>> >> > >> >>> >> > j >> >>> >> >> >>> >> Come to mention it, I *really* like this idea. Perhaps we >> >>> >> should >> >>> >> identify a threshold for building out the non-core >> >>> >> infrastructure >> >>> >> fixes (i.e., having "pip install yt" work, having a good >> >>> >> set >> >>> >> of >> >>> >> testing, etc etc) and then any other fixes or improvements >> >>> >> that >> >>> >> happen >> >>> >> along the way are just icing on the cake? I think having >> >>> >> better >> >>> >> testing should definitely be the focus, particularly as we >> >>> >> transition >> >>> >> the codebase. >> >>> >> >> >>> >> -Matt >> >>> >> >> >>> >> > >> >>> >> > On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk >> >>> >> > >> >>> >> > wrote: >> >>> >> >> Hi all, >> >>> >> >> >> >>> >> >> We should probably try to get a 2.5 release together by >> >>> >> >> the >> >>> >> >> end >> >>> >> >> of >> >>> >> >> the >> >>> >> >> year. It would be really helpful if you are working on >> >>> >> >> something, >> >>> >> >> to >> >>> >> >> fill it out and target both milestone 2.5 and version >> >>> >> >> 2.5 >> >>> >> >> as >> >>> >> >> an >> >>> >> >> issue. >> >>> >> >> That way we can identify goals and push to stable. >> >>> >> >> Testing >> >>> >> >> should >> >>> >> >> perhaps be a huge focus of this release. But, once >> >>> >> >> it's >> >>> >> >> done, I >> >>> >> >> think >> >>> >> >> we can try to transition to 3.0 for development. >> >>> >> >> >> >>> >> >> Here's the current list, which may need curation a bit >> >>> >> >> as >> >>> >> >> some >> >>> >> >> seem >> >>> >> >> to >> >>> >> >> be completed or in progress: >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5 >> >>> >> >> >> >>> >> >> If you want to subdivide something, create a new >> >>> >> >> milestone >> >>> >> >> and >> >>> >> >> target >> >>> >> >> *that*, but with *version* 2.5. >> >>> >> >> >> >>> >> >> -Matt >> >>> >> >> >> >>> >> >> PS The new bitbucket redesign is quite nice! >> >>> >> >> _______________________________________________ >> >>> >> >> 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 >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 > > > > > -- > > ********************************************************************* > * > * > * Dr. Michael Kuhlen Theoretical Astrophysics Center > * > * email: mqk@astro.berkeley.edu UC Berkeley > * > * cell phone: (831) 588-1468 B-116 Hearst Field Annex # 3411 > * > * skype username: mikekuhlen Berkeley, CA 94720 > * > * > * > > ********************************************************************* > > > _______________________________________________ > 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

_______________________________________________ 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

Matt, Anthony, Thanks for those links. I think they will be helpful. Is there a document somewhere that is specific to yt describing where the tests should go in the source, what still needs to be covered, stuff like that? Britton On Thu, Oct 11, 2012 at 10:50 AM, Anthony Scopatz wrote:

Hello Britton,

Also, for testing in general, please refer to the software carpentry lectures [1] and these notes that I have for software carpentry bootcamps [2]. Also feel free to either email me here or privately is you have any other questions.

Be Well Anthony

1. http://software-carpentry.org/4_0/test/ 2. https://github.com/scopatz/PurdueSCBC2012/tree/master/5-Testing

On Thu, Oct 11, 2012 at 9:04 AM, Matthew Turk wrote:

...

Hi Britton,

On Thu, Oct 11, 2012 at 4:42 AM, Britton Smith wrote:

...

Hi Matt,

Are there resources describing how to set up new tests?

Unit tests can be set up in the NumPy style, similar to what Anthony has been doing and I have been doing as well in the "tests" subdirectories. We've started sketching out some yt-specific support routines in yt/testing.py. The NumPy docs are here:

http://docs.scipy.org/doc/numpy/reference/routines.testing.html https://github.com/numpy/numpy/blob/master/doc/TESTS.rst.txt

The answer tests are not documented except by example; that's what that ticket was aiming at. I've assigned that to myself.

-Matt

...

Britton

On Wed, Oct 10, 2012 at 7:26 PM, Matthew Turk

...

...

Hey Britton,

No worries about asking again -- there are currently two types of tests. One is nascent, and only a handful exist (although many libraries have many thousands) and that's unit testing. That's primarily what Sam and everyone else are talking about, although "testing" also includes Answer Testing, which is currently running every 30 minutes or so on my machine. We want to supplement answer testing with much smaller, more contained unit testing. Answer testing is the same thing you and I worked on about a year ago, and it's also what we use for Enzo. (That was the subject of the ticket, although now it needs to be extended.)

But, we now want to add on very tiny, unit tests that do not require either a reference answer that's externally available or a lot of time to run the tests. So for instance, this would be the new interpolation tests and so on.

-Matt

On Wed, Oct 10, 2012 at 8:27 AM, Britton Smith

...

wrote:

...

Hi all,

I apologize if I'm asking questions on things that have already been discussed. What documentation currently exists on the testing infrastructure, specifically how to write and contribute the tests? I have been long assigned to the issue of "testing documentation" on the issue tracker, but I took myself off it this morning because I haven't worked with it in so long that I don't remember how it works. I would be willing to help out getting the tests together, but it would be helpful if there was something I could go look at for how to do them and what remains. I've been out of the loop for a while, so sorry if this has been dealt with.

Also, I like the idea of having an issue that can be pointed to for each enhancement. I would support that as well as quarterly releases.

Britton

On Wed, Oct 10, 2012 at 10:48 AM, Matthew Turk < matthewturk@gmail.com> wrote:

...

Hi Sam,

On Tue, Oct 9, 2012 at 9:42 PM, Sam Skillman

...

...

...

wrote: > > > On Tue, Oct 9, 2012 at 10:34 PM, Matthew Turk < matthewturk@gmail.com> > wrote: >> >> Hi Mike, >> >> On Tue, Oct 9, 2012 at 9:23 PM, Michael Kuhlen >> >> wrote: >> > Hi Jeff >> > >> > >> >> Holy crap, I didn't realize >> >> >> >> pip install yt >> >> >> >> was a goal! that would be awesome. >> > >> > In that case you may be interested in this ubuntu PPA I made a >> > little >> > while >> > ago, for yt (2.4) and yt-devel (2.5): >> > https://launchpad.net/~kuhlen/+archive/ppa >> > >> > The current version of yt-devel is based on changeset 467f57b >> > (from >> > 08/24). >> > I need to update it... >> >> I completely forgot to update the web page! I will do this either >> tomorrow or Thursday (although if anybody wants to issue a pull >> request to the website with the info, it can be redeployed asap.) >> Thank you again for doing this! >> >> I think the PPA, Kacper's ebuild, having pip install work, and >> TomR's >> MacPorts are all really, really good reasons to start focusing on >> reducing the install script overhead, handling things like >> dependencies in a more clear way, and making yt work as an >> independent >> software package much better. And I think the more we move into >> this >> area the more we should try to have a rolling, regular release >> schedule. Does that ring true to everybody else, too? The more we >> have the ability to install yt independently of hg, independently of >> the install_script, the more we should try to make a regular release >> schedule with it. > > > Yes! I personally think regular releases should be nearly automated > based > on the passing of tests at regular intervals (i.e. > monthly/quarterly). > If > we are diligent about setting up BB issues that track individual > enhancements, even the features changelog could be easily generated.

I like this idea. We have speculated in the past about moving to quarterly releases. If we were better about managing the issue tracker (or JIRA!) and unit (not just answer) testing new functionality, this would be easier to manage. Furthermore, as you note, the changelog would be easier to write. Should we mandate

...

...

...

...

any substantial PR also include reference to an issue? Perhaps simply having an issue point to the PR and be closed when the PR is closed is good, to ensure we don't fragment the PR conversations but that we have a unified place where changes are tracked.

I would support this. But we *need* to have a testing push to make it happen. I've been out of the loop most of this week, but I hope to be back in action next week. So what we're looking at is:

1) Issue tracking for enhancements, to allow for changelog writing and so on 2) Regular releases -- I'd push for quarterly -- with a real release coordinator 3) Much higher barrier to entry for testing

Would contributors be willing to participate in this? I will commit to unit testing new functionality in advance of any push or PR.

-Matt

> > Sam > >> >> -Matt >> >> > >> > Cheers, >> > >> > Mike >> > >> > >> > On Tue, Oct 9, 2012 at 4:03 PM, Matthew Turk >> > >> > wrote: >> >> >> >> Hi Casey, >> >> >> >> On Tue, Oct 9, 2012 at 3:59 PM, Casey W. Stark >> >> >> >> wrote: >> >> > Just so this is clear, if we are working on development

...

...

...

...

>> >> > not >> >> > testing, >> >> > should we move over to 3.0 now? >> >> >> >> Not yet, but soon. Sorry, I should have been more clear -- I >> >> believe >> >> it's almost ready for primetime, and in a settled state for >> >> rectilinear, patch-based data. I will update the list very, very >> >> soon >> >> on its state. I'll go through the milestone list and take a >> >> crack >> >> at >> >> updating the tickets, the scripts, and report back. >> >> >> >> -Matt >> >> >> >> > >> >> > - Casey >> >> > >> >> > >> >> > On Tue, Oct 9, 2012 at 2:38 PM, Sam Skillman >> >> > >> >> > wrote: >> >> >> >> >> >> Sounds good to me. I was actually also holding out a bit to >> >> >> incorporate >> >> >> testing into some of the new rendering capabilities anyways. >> >> >> >> >> >> >> >> >> On Tue, Oct 9, 2012 at 3:36 PM, Matthew Turk >> >> >> >> >> >> wrote: >> >> >>> >> >> >>> Hi Sam, >> >> >>> >> >> >>> On Tue, Oct 9, 2012 at 2:30 PM, Sam Skillman >> >> >>> >> >> >>> wrote: >> >> >>> > If the release timeframe is end of year, I will put in

wrote: that that is the

...

...

...

...

>> >> >>> > alpha >> >> >>> > channel >> >> >>> > rendering, enabling a lot of cool things. It is already >> >> >>> > functional >> >> >>> > in >> >> >>> > one >> >> >>> > of my forks, but it needs to be cleaned up. >> >> >>> >> >> >>> What if we said instead that we'd release as soon as unit >> >> >>> testing >> >> >>> is >> >> >>> ready and 3.0 is ready for daily use for patch-based AMR, and >> >> >>> then >> >> >>> if >> >> >>> you have time before that point to get the alpha channel in >> >> >>> good, >> >> >>> but >> >> >>> otherwise toss it into 3.0? >> >> >>> >> >> >>> -Matt >> >> >>> >> >> >>> > >> >> >>> > Sam >> >> >>> > >> >> >>> > >> >> >>> > On Tue, Oct 9, 2012 at 3:28 PM, Matthew Turk >> >> >>> > >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> Hi Jeff, >> >> >>> >> >> >> >>> >> On Tue, Oct 9, 2012 at 2:19 PM, j s oishi >> >> >>> >> >> >> >>> >> wrote: >> >> >>> >> > Hi, >> >> >>> >> > >> >> >>> >> > Since testing is something that is so high priority for >> >> >>> >> > this, >> >> >>> >> > and >> >> >>> >> > otherwise 2.5 is just a stepping stone to 3.0 (which a >> >> >>> >> > *lot* >> >> >>> >> > of >> >> >>> >> > people >> >> >>> >> > are already diving into), maybe we should *only* include >> >> >>> >> > testing, >> >> >>> >> > unless there are some already done things we could toss >> >> >>> >> > in? >> >> >>> >> > >> >> >>> >> > j >> >> >>> >> >> >> >>> >> Come to mention it, I *really* like this idea. Perhaps we >> >> >>> >> should >> >> >>> >> identify a threshold for building out the non-core >> >> >>> >> infrastructure >> >> >>> >> fixes (i.e., having "pip install yt" work, having a good >> >> >>> >> set >> >> >>> >> of >> >> >>> >> testing, etc etc) and then any other fixes or improvements >> >> >>> >> that >> >> >>> >> happen >> >> >>> >> along the way are just icing on the cake? I think having >> >> >>> >> better >> >> >>> >> testing should definitely be the focus, particularly as we >> >> >>> >> transition >> >> >>> >> the codebase. >> >> >>> >> >> >> >>> >> -Matt >> >> >>> >> >> >> >>> >> > >> >> >>> >> > On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk >> >> >>> >> > >> >> >>> >> > wrote: >> >> >>> >> >> Hi all, >> >> >>> >> >> >> >> >>> >> >> We should probably try to get a 2.5 release together by >> >> >>> >> >> the >> >> >>> >> >> end >> >> >>> >> >> of >> >> >>> >> >> the >> >> >>> >> >> year. It would be really helpful if you are working on >> >> >>> >> >> something, >> >> >>> >> >> to >> >> >>> >> >> fill it out and target both milestone 2.5 and version >> >> >>> >> >> 2.5 >> >> >>> >> >> as >> >> >>> >> >> an >> >> >>> >> >> issue. >> >> >>> >> >> That way we can identify goals and push to stable. >> >> >>> >> >> Testing >> >> >>> >> >> should >> >> >>> >> >> perhaps be a huge focus of this release. But, once >> >> >>> >> >> it's >> >> >>> >> >> done, I >> >> >>> >> >> think >> >> >>> >> >> we can try to transition to 3.0 for development. >> >> >>> >> >> >> >> >>> >> >> Here's the current list, which may need curation a bit >> >> >>> >> >> as >> >> >>> >> >> some >> >> >>> >> >> seem >> >> >>> >> >> to >> >> >>> >> >> be completed or in progress: >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5 >> >> >>> >> >> >> >> >>> >> >> If you want to subdivide something, create a new >> >> >>> >> >> milestone >> >> >>> >> >> and >> >> >>> >> >> target >> >> >>> >> >> *that*, but with *version* 2.5. >> >> >>> >> >> >> >> >>> >> >> -Matt >> >> >>> >> >> >> >> >>> >> >> PS The new bitbucket redesign is quite nice! >> >> >>> >> >> _______________________________________________ >> >> >>> >> >> 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 >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> 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 >> > >> > >> > >> > >> > -- >> > >> >

---

...

...

...

...

>> > * >> > * >> > * Dr. Michael Kuhlen Theoretical Astrophysics Center >> > * >> > * email: mqk@astro.berkeley.edu UC Berkeley >> > * >> > * cell phone: (831) 588-1468 B-116 Hearst Field Annex # 3411 >> > * >> > * skype username: mikekuhlen Berkeley, CA 94720 >> > * >> > * >> > * >> > >> >

---

...

...

...

...

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

_______________________________________________ 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

On Thu, Oct 11, 2012 at 8:07 AM, Anthony Scopatz wrote:

On Thu, Oct 11, 2012 at 10:04 AM, Britton Smith wrote:

...

Matt, Anthony,

Thanks for those links. I think they will be helpful. Is there a document somewhere that is specific to yt describing where the tests should go in the source, what still needs to be covered, stuff like that?

Matt will correct me if I am wrong, but no, I don't think so. At least not for unit tests. We (all of us yt-devs) are in the process of creating that stuff now.

I think the best place right now is in the ticket and the list -- and we can codify that later in a documentation page. But I am happy that this has spawned interest and buy in from the list -- and I think it's pretty fair to say that this is where the "yt-devs" would have that process. Britton is the second most frequent contributor to yt (after me) and I don't think a testing initiative would be successful without his participation. -Matt

Be Well Anthony

...

Britton

On Thu, Oct 11, 2012 at 10:50 AM, Anthony Scopatz wrote:

...

Hello Britton,

Also, for testing in general, please refer to the software carpentry lectures [1] and these notes that I have for software carpentry bootcamps [2]. Also feel free to either email me here or privately is you have any other questions.

Be Well Anthony

1. http://software-carpentry.org/4_0/test/ 2. https://github.com/scopatz/PurdueSCBC2012/tree/master/5-Testing

On Thu, Oct 11, 2012 at 9:04 AM, Matthew Turk wrote:

...

Hi Britton,

On Thu, Oct 11, 2012 at 4:42 AM, Britton Smith wrote:

...

Hi Matt,

Are there resources describing how to set up new tests?

Unit tests can be set up in the NumPy style, similar to what Anthony has been doing and I have been doing as well in the "tests" subdirectories. We've started sketching out some yt-specific support routines in yt/testing.py. The NumPy docs are here:

http://docs.scipy.org/doc/numpy/reference/routines.testing.html https://github.com/numpy/numpy/blob/master/doc/TESTS.rst.txt

The answer tests are not documented except by example; that's what that ticket was aiming at. I've assigned that to myself.

-Matt

...

Britton

On Wed, Oct 10, 2012 at 7:26 PM, Matthew Turk wrote:

...

Hey Britton,

No worries about asking again -- there are currently two types of tests. One is nascent, and only a handful exist (although many libraries have many thousands) and that's unit testing. That's primarily what Sam and everyone else are talking about, although "testing" also includes Answer Testing, which is currently running every 30 minutes or so on my machine. We want to supplement answer testing with much smaller, more contained unit testing. Answer testing is the same thing you and I worked on about a year ago, and it's also what we use for Enzo. (That was the subject of the ticket, although now it needs to be extended.)

But, we now want to add on very tiny, unit tests that do not require either a reference answer that's externally available or a lot of time to run the tests. So for instance, this would be the new interpolation tests and so on.

-Matt

On Wed, Oct 10, 2012 at 8:27 AM, Britton Smith wrote: > Hi all, > > I apologize if I'm asking questions on things that have already > been > discussed. What documentation currently exists on the testing > infrastructure, specifically how to write and contribute the tests? > I > have > been long assigned to the issue of "testing documentation" on the > issue > tracker, but I took myself off it this morning because I haven't > worked > with > it in so long that I don't remember how it works. I would be > willing to > help out getting the tests together, but it would be helpful if > there > was > something I could go look at for how to do them and what remains. > I've > been > out of the loop for a while, so sorry if this has been dealt with. > > Also, I like the idea of having an issue that can be pointed to for > each > enhancement. I would support that as well as quarterly releases. > > Britton > > > On Wed, Oct 10, 2012 at 10:48 AM, Matthew Turk > > wrote: >> >> Hi Sam, >> >> On Tue, Oct 9, 2012 at 9:42 PM, Sam Skillman >> >> wrote: >> > >> > >> > On Tue, Oct 9, 2012 at 10:34 PM, Matthew Turk >> > >> > wrote: >> >> >> >> Hi Mike, >> >> >> >> On Tue, Oct 9, 2012 at 9:23 PM, Michael Kuhlen >> >> >> >> wrote: >> >> > Hi Jeff >> >> > >> >> > >> >> >> Holy crap, I didn't realize >> >> >> >> >> >> pip install yt >> >> >> >> >> >> was a goal! that would be awesome. >> >> > >> >> > In that case you may be interested in this ubuntu PPA I made >> >> > a >> >> > little >> >> > while >> >> > ago, for yt (2.4) and yt-devel (2.5): >> >> > https://launchpad.net/~kuhlen/+archive/ppa >> >> > >> >> > The current version of yt-devel is based on changeset 467f57b >> >> > (from >> >> > 08/24). >> >> > I need to update it... >> >> >> >> I completely forgot to update the web page! I will do this >> >> either >> >> tomorrow or Thursday (although if anybody wants to issue a pull >> >> request to the website with the info, it can be redeployed >> >> asap.) >> >> Thank you again for doing this! >> >> >> >> I think the PPA, Kacper's ebuild, having pip install work, and >> >> TomR's >> >> MacPorts are all really, really good reasons to start focusing >> >> on >> >> reducing the install script overhead, handling things like >> >> dependencies in a more clear way, and making yt work as an >> >> independent >> >> software package much better. And I think the more we move >> >> into >> >> this >> >> area the more we should try to have a rolling, regular release >> >> schedule. Does that ring true to everybody else, too? The >> >> more we >> >> have the ability to install yt independently of hg, >> >> independently of >> >> the install_script, the more we should try to make a regular >> >> release >> >> schedule with it. >> > >> > >> > Yes! I personally think regular releases should be nearly >> > automated >> > based >> > on the passing of tests at regular intervals (i.e. >> > monthly/quarterly). >> > If >> > we are diligent about setting up BB issues that track individual >> > enhancements, even the features changelog could be easily >> > generated. >> >> I like this idea. We have speculated in the past about moving to >> quarterly releases. If we were better about managing the issue >> tracker (or JIRA!) and unit (not just answer) testing new >> functionality, this would be easier to manage. Furthermore, as >> you >> note, the changelog would be easier to write. Should we mandate >> that >> any substantial PR also include reference to an issue? Perhaps >> simply >> having an issue point to the PR and be closed when the PR is >> closed is >> good, to ensure we don't fragment the PR conversations but that we >> have a unified place where changes are tracked. >> >> I would support this. But we *need* to have a testing push to >> make it >> happen. I've been out of the loop most of this week, but I hope >> to be >> back in action next week. So what we're looking at is: >> >> 1) Issue tracking for enhancements, to allow for changelog writing >> and >> so >> on >> 2) Regular releases -- I'd push for quarterly -- with a real >> release >> coordinator >> 3) Much higher barrier to entry for testing >> >> Would contributors be willing to participate in this? I will >> commit >> to unit testing new functionality in advance of any push or PR. >> >> -Matt >> >> > >> > Sam >> > >> >> >> >> -Matt >> >> >> >> > >> >> > Cheers, >> >> > >> >> > Mike >> >> > >> >> > >> >> > On Tue, Oct 9, 2012 at 4:03 PM, Matthew Turk >> >> > >> >> > wrote: >> >> >> >> >> >> Hi Casey, >> >> >> >> >> >> On Tue, Oct 9, 2012 at 3:59 PM, Casey W. Stark >> >> >> >> >> >> wrote: >> >> >> > Just so this is clear, if we are working on development >> >> >> > that is >> >> >> > not >> >> >> > testing, >> >> >> > should we move over to 3.0 now? >> >> >> >> >> >> Not yet, but soon. Sorry, I should have been more clear -- >> >> >> I >> >> >> believe >> >> >> it's almost ready for primetime, and in a settled state for >> >> >> rectilinear, patch-based data. I will update the list very, >> >> >> very >> >> >> soon >> >> >> on its state. I'll go through the milestone list and take a >> >> >> crack >> >> >> at >> >> >> updating the tickets, the scripts, and report back. >> >> >> >> >> >> -Matt >> >> >> >> >> >> > >> >> >> > - Casey >> >> >> > >> >> >> > >> >> >> > On Tue, Oct 9, 2012 at 2:38 PM, Sam Skillman >> >> >> > >> >> >> > wrote: >> >> >> >> >> >> >> >> Sounds good to me. I was actually also holding out a bit >> >> >> >> to >> >> >> >> incorporate >> >> >> >> testing into some of the new rendering capabilities >> >> >> >> anyways. >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Oct 9, 2012 at 3:36 PM, Matthew Turk >> >> >> >> >> >> >> >> wrote: >> >> >> >>> >> >> >> >>> Hi Sam, >> >> >> >>> >> >> >> >>> On Tue, Oct 9, 2012 at 2:30 PM, Sam Skillman >> >> >> >>> >> >> >> >>> wrote: >> >> >> >>> > If the release timeframe is end of year, I will put in >> >> >> >>> > the >> >> >> >>> > alpha >> >> >> >>> > channel >> >> >> >>> > rendering, enabling a lot of cool things. It is >> >> >> >>> > already >> >> >> >>> > functional >> >> >> >>> > in >> >> >> >>> > one >> >> >> >>> > of my forks, but it needs to be cleaned up. >> >> >> >>> >> >> >> >>> What if we said instead that we'd release as soon as >> >> >> >>> unit >> >> >> >>> testing >> >> >> >>> is >> >> >> >>> ready and 3.0 is ready for daily use for patch-based >> >> >> >>> AMR, and >> >> >> >>> then >> >> >> >>> if >> >> >> >>> you have time before that point to get the alpha channel >> >> >> >>> in >> >> >> >>> good, >> >> >> >>> but >> >> >> >>> otherwise toss it into 3.0? >> >> >> >>> >> >> >> >>> -Matt >> >> >> >>> >> >> >> >>> > >> >> >> >>> > Sam >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > On Tue, Oct 9, 2012 at 3:28 PM, Matthew Turk >> >> >> >>> > >> >> >> >>> > wrote: >> >> >> >>> >> >> >> >> >>> >> Hi Jeff, >> >> >> >>> >> >> >> >> >>> >> On Tue, Oct 9, 2012 at 2:19 PM, j s oishi >> >> >> >>> >> >> >> >> >>> >> wrote: >> >> >> >>> >> > Hi, >> >> >> >>> >> > >> >> >> >>> >> > Since testing is something that is so high priority >> >> >> >>> >> > for >> >> >> >>> >> > this, >> >> >> >>> >> > and >> >> >> >>> >> > otherwise 2.5 is just a stepping stone to 3.0 >> >> >> >>> >> > (which a >> >> >> >>> >> > *lot* >> >> >> >>> >> > of >> >> >> >>> >> > people >> >> >> >>> >> > are already diving into), maybe we should *only* >> >> >> >>> >> > include >> >> >> >>> >> > testing, >> >> >> >>> >> > unless there are some already done things we could >> >> >> >>> >> > toss >> >> >> >>> >> > in? >> >> >> >>> >> > >> >> >> >>> >> > j >> >> >> >>> >> >> >> >> >>> >> Come to mention it, I *really* like this idea. >> >> >> >>> >> Perhaps we >> >> >> >>> >> should >> >> >> >>> >> identify a threshold for building out the non-core >> >> >> >>> >> infrastructure >> >> >> >>> >> fixes (i.e., having "pip install yt" work, having a >> >> >> >>> >> good >> >> >> >>> >> set >> >> >> >>> >> of >> >> >> >>> >> testing, etc etc) and then any other fixes or >> >> >> >>> >> improvements >> >> >> >>> >> that >> >> >> >>> >> happen >> >> >> >>> >> along the way are just icing on the cake? I think >> >> >> >>> >> having >> >> >> >>> >> better >> >> >> >>> >> testing should definitely be the focus, particularly >> >> >> >>> >> as we >> >> >> >>> >> transition >> >> >> >>> >> the codebase. >> >> >> >>> >> >> >> >> >>> >> -Matt >> >> >> >>> >> >> >> >> >>> >> > >> >> >> >>> >> > On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk >> >> >> >>> >> > >> >> >> >>> >> > wrote: >> >> >> >>> >> >> Hi all, >> >> >> >>> >> >> >> >> >> >>> >> >> We should probably try to get a 2.5 release >> >> >> >>> >> >> together by >> >> >> >>> >> >> the >> >> >> >>> >> >> end >> >> >> >>> >> >> of >> >> >> >>> >> >> the >> >> >> >>> >> >> year. It would be really helpful if you are >> >> >> >>> >> >> working on >> >> >> >>> >> >> something, >> >> >> >>> >> >> to >> >> >> >>> >> >> fill it out and target both milestone 2.5 and >> >> >> >>> >> >> version >> >> >> >>> >> >> 2.5 >> >> >> >>> >> >> as >> >> >> >>> >> >> an >> >> >> >>> >> >> issue. >> >> >> >>> >> >> That way we can identify goals and push to >> >> >> >>> >> >> stable. >> >> >> >>> >> >> Testing >> >> >> >>> >> >> should >> >> >> >>> >> >> perhaps be a huge focus of this release. But, >> >> >> >>> >> >> once >> >> >> >>> >> >> it's >> >> >> >>> >> >> done, I >> >> >> >>> >> >> think >> >> >> >>> >> >> we can try to transition to 3.0 for development. >> >> >> >>> >> >> >> >> >> >>> >> >> Here's the current list, which may need curation a >> >> >> >>> >> >> bit >> >> >> >>> >> >> as >> >> >> >>> >> >> some >> >> >> >>> >> >> seem >> >> >> >>> >> >> to >> >> >> >>> >> >> be completed or in progress: >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5 >> >> >> >>> >> >> >> >> >> >>> >> >> If you want to subdivide something, create a new >> >> >> >>> >> >> milestone >> >> >> >>> >> >> and >> >> >> >>> >> >> target >> >> >> >>> >> >> *that*, but with *version* 2.5. >> >> >> >>> >> >> >> >> >> >>> >> >> -Matt >> >> >> >>> >> >> >> >> >> >>> >> >> PS The new bitbucket redesign is quite nice! >> >> >> >>> >> >> _______________________________________________ >> >> >> >>> >> >> 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 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> 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 >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > >> >> > >> >> > ********************************************************************* >> >> > * >> >> > * >> >> > * Dr. Michael Kuhlen Theoretical Astrophysics >> >> > Center >> >> > * >> >> > * email: mqk@astro.berkeley.edu UC Berkeley >> >> > * >> >> > * cell phone: (831) 588-1468 B-116 Hearst Field Annex # >> >> > 3411 >> >> > * >> >> > * skype username: mikekuhlen Berkeley, CA 94720 >> >> > * >> >> > * >> >> > * >> >> > >> >> > >> >> > ********************************************************************* >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 > _______________________________________________ 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

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

Sorry all, I think that this was vastly misinterpreted. I meant this as an inclusive comment (we all here on this list, including Britton) are in the process of creating, clarifying, and defining what it means to to testing inside of yt. This was offered as an explanation as to why there is no formal documentation for the testing stuff. We (once again inclusive, everybody) are basically making it up as we go along at this point, taking hints from other projects and resources, as per the links that were provided and prior mailing list discussions. I assumed that since I posted this to yt-dev (and not yt-users) that it was everyone who receives this message would be included in the "We (yt-devs)" group. Clearly, I was mistaken on that note. Once again, I am sorry that this seems to have been misconstrued and I sincerely hope that no offense was taken. <insert rant about email being an imperfect form of communication here> Be Well Anthony On Thu, Oct 11, 2012 at 11:00 AM, j s oishi wrote:

Anthony,

It's great that you're contributing a lot to yt, and I (at least) certainly value the work you've been doing. However I think you might want to reconsider statements like this

...

We (all of us yt-devs) are in the process of creating that stuff now.

Not only is it a bit exclusionary in general, as a specific response to Britton, it is inappropriate. Britton has been around on this project longer than anyone except Matt and is qualitatively and quantitatively among the most central people to it:

hotei:/home/../yt-hg [11:50]$ hg churn matthewturk@gmail.com 1242803 ****************************** stephenskory@yahoo.com 165192 **** brittonsmith@gmail.com 113308 ***

yours,

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

Hey Anthony,

<insert rant about email being an imperfect form of communication here>

And this is why we should have an in-person meetup/sprint/workshop! I think especially after the workshop in January, it felt really nice to finally put a face to some emails, and provided us all with some context for the people we correspond with over the lists. Let's continue this in the other thread. :) So as a sidenote -- Stephen submitted some tests today: https://bitbucket.org/yt_analysis/yt/pull-request/296/kd-trees-tests and this afternoon I'm going to try to write the first set of tests for the profiling code. -Matt

I think this got sidelined in the midst of other talk about testing, but coordinating project tracking with JIRA looks great. +1 to JIRA chris On Wed, Oct 10, 2012 at 7:48 AM, Matthew Turk wrote:

Hi Sam,

On Tue, Oct 9, 2012 at 9:42 PM, Sam Skillman wrote:

...

On Tue, Oct 9, 2012 at 10:34 PM, Matthew Turk

...

...

Hi Mike,

On Tue, Oct 9, 2012 at 9:23 PM, Michael Kuhlen wrote:

...

Hi Jeff

...

Holy crap, I didn't realize

pip install yt

was a goal! that would be awesome.

In that case you may be interested in this ubuntu PPA I made a little while ago, for yt (2.4) and yt-devel (2.5): https://launchpad.net/~kuhlen/+archive/ppa

The current version of yt-devel is based on changeset 467f57b (from 08/24). I need to update it...

I completely forgot to update the web page! I will do this either tomorrow or Thursday (although if anybody wants to issue a pull request to the website with the info, it can be redeployed asap.) Thank you again for doing this!

I think the PPA, Kacper's ebuild, having pip install work, and TomR's MacPorts are all really, really good reasons to start focusing on reducing the install script overhead, handling things like dependencies in a more clear way, and making yt work as an independent software package much better. And I think the more we move into this area the more we should try to have a rolling, regular release schedule. Does that ring true to everybody else, too? The more we have the ability to install yt independently of hg, independently of the install_script, the more we should try to make a regular release schedule with it.

Yes! I personally think regular releases should be nearly automated

wrote: based

...

on the passing of tests at regular intervals (i.e. monthly/quarterly). If we are diligent about setting up BB issues that track individual enhancements, even the features changelog could be easily generated.

I like this idea. We have speculated in the past about moving to quarterly releases. If we were better about managing the issue tracker (or JIRA!) and unit (not just answer) testing new functionality, this would be easier to manage. Furthermore, as you note, the changelog would be easier to write. Should we mandate that any substantial PR also include reference to an issue? Perhaps simply having an issue point to the PR and be closed when the PR is closed is good, to ensure we don't fragment the PR conversations but that we have a unified place where changes are tracked.

I would support this. But we *need* to have a testing push to make it happen. I've been out of the loop most of this week, but I hope to be back in action next week. So what we're looking at is:

1) Issue tracking for enhancements, to allow for changelog writing and so on 2) Regular releases -- I'd push for quarterly -- with a real release coordinator 3) Much higher barrier to entry for testing

Would contributors be willing to participate in this? I will commit to unit testing new functionality in advance of any push or PR.

-Matt

...

Sam

...

-Matt

...

Cheers,

Mike

On Tue, Oct 9, 2012 at 4:03 PM, Matthew Turk wrote:

...

Hi Casey,

On Tue, Oct 9, 2012 at 3:59 PM, Casey W. Stark <

...

...

...

...

wrote:

...

Just so this is clear, if we are working on development that is not testing, should we move over to 3.0 now?

Not yet, but soon. Sorry, I should have been more clear -- I believe it's almost ready for primetime, and in a settled state for rectilinear, patch-based data. I will update the list very, very soon on its state. I'll go through the milestone list and take a crack at updating the tickets, the scripts, and report back.

-Matt

...

- Casey

On Tue, Oct 9, 2012 at 2:38 PM, Sam Skillman <

samskillman@gmail.com>

...

wrote: > > Sounds good to me. I was actually also holding out a bit to > incorporate > testing into some of the new rendering capabilities anyways. > > > On Tue, Oct 9, 2012 at 3:36 PM, Matthew Turk < matthewturk@gmail.com> > wrote: >> >> Hi Sam, >> >> On Tue, Oct 9, 2012 at 2:30 PM, Sam Skillman >> >> wrote: >> > If the release timeframe is end of year, I will put in the alpha >> > channel >> > rendering, enabling a lot of cool things. It is already >> > functional >> > in >> > one >> > of my forks, but it needs to be cleaned up. >> >> What if we said instead that we'd release as soon as unit testing >> is >> ready and 3.0 is ready for daily use for patch-based AMR, and

...

...

...

...

...

>> if >> you have time before that point to get the alpha channel in good, >> but >> otherwise toss it into 3.0? >> >> -Matt >> >> > >> > Sam >> > >> > >> > On Tue, Oct 9, 2012 at 3:28 PM, Matthew Turk >> > >> > wrote: >> >> >> >> Hi Jeff, >> >> >> >> On Tue, Oct 9, 2012 at 2:19 PM, j s oishi >> >> wrote: >> >> > Hi, >> >> > >> >> > Since testing is something that is so high priority for

...

...

...

...

...

>> >> > and >> >> > otherwise 2.5 is just a stepping stone to 3.0 (which a *lot* >> >> > of >> >> > people >> >> > are already diving into), maybe we should *only* include >> >> > testing, >> >> > unless there are some already done things we could toss in? >> >> > >> >> > j >> >> >> >> Come to mention it, I *really* like this idea. Perhaps we >> >> should >> >> identify a threshold for building out the non-core >> >> infrastructure >> >> fixes (i.e., having "pip install yt" work, having a good set of >> >> testing, etc etc) and then any other fixes or improvements

caseywstark@gmail.com> then this, that

...

...

...

...

...

>> >> happen >> >> along the way are just icing on the cake? I think having better >> >> testing should definitely be the focus, particularly as we >> >> transition >> >> the codebase. >> >> >> >> -Matt >> >> >> >> > >> >> > On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk >> >> > >> >> > wrote: >> >> >> Hi all, >> >> >> >> >> >> We should probably try to get a 2.5 release together by the >> >> >> end >> >> >> of >> >> >> the >> >> >> year. It would be really helpful if you are working on >> >> >> something, >> >> >> to >> >> >> fill it out and target both milestone 2.5 and version 2.5 as >> >> >> an >> >> >> issue. >> >> >> That way we can identify goals and push to stable. Testing >> >> >> should >> >> >> perhaps be a huge focus of this release. But, once it's >> >> >> done, I >> >> >> think >> >> >> we can try to transition to 3.0 for development. >> >> >> >> >> >> Here's the current list, which may need curation a bit as >> >> >> some >> >> >> seem >> >> >> to >> >> >> be completed or in progress: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5 >> >> >> >> >> >> If you want to subdivide something, create a new milestone >> >> >> and >> >> >> target >> >> >> *that*, but with *version* 2.5. >> >> >> >> >> >> -Matt >> >> >> >> >> >> PS The new bitbucket redesign is quite nice! >> >> >> _______________________________________________ >> >> >> 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 > > > > _______________________________________________ > 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

-- ********************************************************************* * * * Dr. Michael Kuhlen Theoretical Astrophysics Center * * email: mqk@astro.berkeley.edu UC Berkeley * * cell phone: (831) 588-1468 B-116 Hearst Field Annex # 3411 * * skype username: mikekuhlen Berkeley, CA 94720 * * * *********************************************************************

_______________________________________________ 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

Okay, me too. I've submitted a request for an Open Source License. On Fri, Oct 12, 2012 at 2:25 PM, Cameron Hummels wrote:

Agreed. I think this JIRA tool looks like just a further addition to the nice bitbucket interface, and it will potentially keep communication clean and archived. +1

On Fri, Oct 12, 2012 at 2:24 PM, Christopher Moody wrote:

...

I think this got sidelined in the midst of other talk about testing, but coordinating project tracking with JIRA looks great.

+1 to JIRA

chris

On Wed, Oct 10, 2012 at 7:48 AM, Matthew Turk wrote:

...

Hi Sam,

On Tue, Oct 9, 2012 at 9:42 PM, Sam Skillman wrote:

...

On Tue, Oct 9, 2012 at 10:34 PM, Matthew Turk wrote:

...

Hi Mike,

On Tue, Oct 9, 2012 at 9:23 PM, Michael Kuhlen wrote:

...

Hi Jeff

> Holy crap, I didn't realize > > pip install yt > > was a goal! that would be awesome.

In that case you may be interested in this ubuntu PPA I made a little while ago, for yt (2.4) and yt-devel (2.5): https://launchpad.net/~kuhlen/+archive/ppa

The current version of yt-devel is based on changeset 467f57b (from 08/24). I need to update it...

I completely forgot to update the web page! I will do this either tomorrow or Thursday (although if anybody wants to issue a pull request to the website with the info, it can be redeployed asap.) Thank you again for doing this!

I think the PPA, Kacper's ebuild, having pip install work, and TomR's MacPorts are all really, really good reasons to start focusing on reducing the install script overhead, handling things like dependencies in a more clear way, and making yt work as an independent software package much better. And I think the more we move into this area the more we should try to have a rolling, regular release schedule. Does that ring true to everybody else, too? The more we have the ability to install yt independently of hg, independently of the install_script, the more we should try to make a regular release schedule with it.

Yes! I personally think regular releases should be nearly automated based on the passing of tests at regular intervals (i.e. monthly/quarterly). If we are diligent about setting up BB issues that track individual enhancements, even the features changelog could be easily generated.

I like this idea. We have speculated in the past about moving to quarterly releases. If we were better about managing the issue tracker (or JIRA!) and unit (not just answer) testing new functionality, this would be easier to manage. Furthermore, as you note, the changelog would be easier to write. Should we mandate that any substantial PR also include reference to an issue? Perhaps simply having an issue point to the PR and be closed when the PR is closed is good, to ensure we don't fragment the PR conversations but that we have a unified place where changes are tracked.

I would support this. But we *need* to have a testing push to make it happen. I've been out of the loop most of this week, but I hope to be back in action next week. So what we're looking at is:

1) Issue tracking for enhancements, to allow for changelog writing and so on 2) Regular releases -- I'd push for quarterly -- with a real release coordinator 3) Much higher barrier to entry for testing

Would contributors be willing to participate in this? I will commit to unit testing new functionality in advance of any push or PR.

-Matt

...

Sam

...

-Matt

...

Cheers,

Mike

On Tue, Oct 9, 2012 at 4:03 PM, Matthew Turk wrote: > > Hi Casey, > > On Tue, Oct 9, 2012 at 3:59 PM, Casey W. Stark > > wrote: > > Just so this is clear, if we are working on development that is > > not > > testing, > > should we move over to 3.0 now? > > Not yet, but soon. Sorry, I should have been more clear -- I > believe > it's almost ready for primetime, and in a settled state for > rectilinear, patch-based data. I will update the list very, very > soon > on its state. I'll go through the milestone list and take a crack > at > updating the tickets, the scripts, and report back. > > -Matt > > > > > - Casey > > > > > > On Tue, Oct 9, 2012 at 2:38 PM, Sam Skillman > > > > wrote: > >> > >> Sounds good to me. I was actually also holding out a bit to > >> incorporate > >> testing into some of the new rendering capabilities anyways. > >> > >> > >> On Tue, Oct 9, 2012 at 3:36 PM, Matthew Turk > >> > >> wrote: > >>> > >>> Hi Sam, > >>> > >>> On Tue, Oct 9, 2012 at 2:30 PM, Sam Skillman > >>> > >>> wrote: > >>> > If the release timeframe is end of year, I will put in the > >>> > alpha > >>> > channel > >>> > rendering, enabling a lot of cool things. It is already > >>> > functional > >>> > in > >>> > one > >>> > of my forks, but it needs to be cleaned up. > >>> > >>> What if we said instead that we'd release as soon as unit > >>> testing > >>> is > >>> ready and 3.0 is ready for daily use for patch-based AMR, and > >>> then > >>> if > >>> you have time before that point to get the alpha channel in > >>> good, > >>> but > >>> otherwise toss it into 3.0? > >>> > >>> -Matt > >>> > >>> > > >>> > Sam > >>> > > >>> > > >>> > On Tue, Oct 9, 2012 at 3:28 PM, Matthew Turk > >>> > > >>> > wrote: > >>> >> > >>> >> Hi Jeff, > >>> >> > >>> >> On Tue, Oct 9, 2012 at 2:19 PM, j s oishi > >>> >> > >>> >> wrote: > >>> >> > Hi, > >>> >> > > >>> >> > Since testing is something that is so high priority for > >>> >> > this, > >>> >> > and > >>> >> > otherwise 2.5 is just a stepping stone to 3.0 (which a > >>> >> > *lot* > >>> >> > of > >>> >> > people > >>> >> > are already diving into), maybe we should *only* include > >>> >> > testing, > >>> >> > unless there are some already done things we could toss > >>> >> > in? > >>> >> > > >>> >> > j > >>> >> > >>> >> Come to mention it, I *really* like this idea. Perhaps we > >>> >> should > >>> >> identify a threshold for building out the non-core > >>> >> infrastructure > >>> >> fixes (i.e., having "pip install yt" work, having a good set > >>> >> of > >>> >> testing, etc etc) and then any other fixes or improvements > >>> >> that > >>> >> happen > >>> >> along the way are just icing on the cake? I think having > >>> >> better > >>> >> testing should definitely be the focus, particularly as we > >>> >> transition > >>> >> the codebase. > >>> >> > >>> >> -Matt > >>> >> > >>> >> > > >>> >> > On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk > >>> >> > > >>> >> > wrote: > >>> >> >> Hi all, > >>> >> >> > >>> >> >> We should probably try to get a 2.5 release together by > >>> >> >> the > >>> >> >> end > >>> >> >> of > >>> >> >> the > >>> >> >> year. It would be really helpful if you are working on > >>> >> >> something, > >>> >> >> to > >>> >> >> fill it out and target both milestone 2.5 and version 2.5 > >>> >> >> as > >>> >> >> an > >>> >> >> issue. > >>> >> >> That way we can identify goals and push to stable. > >>> >> >> Testing > >>> >> >> should > >>> >> >> perhaps be a huge focus of this release. But, once it's > >>> >> >> done, I > >>> >> >> think > >>> >> >> we can try to transition to 3.0 for development. > >>> >> >> > >>> >> >> Here's the current list, which may need curation a bit as > >>> >> >> some > >>> >> >> seem > >>> >> >> to > >>> >> >> be completed or in progress: > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5 > >>> >> >> > >>> >> >> If you want to subdivide something, create a new > >>> >> >> milestone > >>> >> >> and > >>> >> >> target > >>> >> >> *that*, but with *version* 2.5. > >>> >> >> > >>> >> >> -Matt > >>> >> >> > >>> >> >> PS The new bitbucket redesign is quite nice!

...

...

...

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

--

********************************************************************* * * * Dr. Michael Kuhlen Theoretical Astrophysics Center * * email: mqk@astro.berkeley.edu UC Berkeley * * cell phone: (831) 588-1468 B-116 Hearst Field Annex # 3411 * * skype username: mikekuhlen Berkeley, CA 94720 * * *

*********************************************************************

...

...

...

_______________________________________________ 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

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

I agree -- Casey has brought this to my attention a couple times. The reason it doesn't work now is because of external library difficulties, but I think they can be fixed. On Tue, Oct 9, 2012 at 2:30 PM, j s oishi wrote:

Holy crap, I didn't realize

pip install yt

was a goal! that would be awesome.

j

On Tue, Oct 9, 2012 at 5:28 PM, Matthew Turk wrote:

...

Hi Jeff,

On Tue, Oct 9, 2012 at 2:19 PM, j s oishi wrote:

...

Hi,

Since testing is something that is so high priority for this, and otherwise 2.5 is just a stepping stone to 3.0 (which a *lot* of people are already diving into), maybe we should *only* include testing, unless there are some already done things we could toss in?

j

Come to mention it, I *really* like this idea. Perhaps we should identify a threshold for building out the non-core infrastructure fixes (i.e., having "pip install yt" work, having a good set of testing, etc etc) and then any other fixes or improvements that happen along the way are just icing on the cake? I think having better testing should definitely be the focus, particularly as we transition the codebase.

-Matt

...

On Tue, Oct 9, 2012 at 5:14 PM, Matthew Turk wrote:

...

Hi all,

We should probably try to get a 2.5 release together by the end of the year. It would be really helpful if you are working on something, to fill it out and target both milestone 2.5 and version 2.5 as an issue. That way we can identify goals and push to stable. Testing should perhaps be a huge focus of this release. But, once it's done, I think we can try to transition to 3.0 for development.

Here's the current list, which may need curation a bit as some seem to be completed or in progress:

https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.5

If you want to subdivide something, create a new milestone and target *that*, but with *version* 2.5.

-Matt

PS The new bitbucket redesign is quite nice! _______________________________________________ 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