[yt-dev] Release 2.5?
Matthew Turk
matthewturk at gmail.com
Wed Oct 10 16:26:06 PDT 2012
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 <brittonsmith at gmail.com> 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 at gmail.com>
> wrote:
>>
>> Hi Sam,
>>
>> On Tue, Oct 9, 2012 at 9:42 PM, Sam Skillman <samskillman at gmail.com>
>> wrote:
>> >
>> >
>> > On Tue, Oct 9, 2012 at 10:34 PM, Matthew Turk <matthewturk at gmail.com>
>> > wrote:
>> >>
>> >> Hi Mike,
>> >>
>> >> On Tue, Oct 9, 2012 at 9:23 PM, Michael Kuhlen <mqk at astro.berkeley.edu>
>> >> 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 <matthewturk at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Casey,
>> >> >>
>> >> >> On Tue, Oct 9, 2012 at 3:59 PM, Casey W. Stark
>> >> >> <caseywstark at gmail.com>
>> >> >> 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 at 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 at gmail.com>
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> Hi Sam,
>> >> >> >>>
>> >> >> >>> On Tue, Oct 9, 2012 at 2:30 PM, Sam Skillman
>> >> >> >>> <samskillman at gmail.com>
>> >> >> >>> 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
>> >> >> >>> > <matthewturk at gmail.com>
>> >> >> >>> > wrote:
>> >> >> >>> >>
>> >> >> >>> >> Hi Jeff,
>> >> >> >>> >>
>> >> >> >>> >> On Tue, Oct 9, 2012 at 2:19 PM, j s oishi <jsoishi at gmail.com>
>> >> >> >>> >> 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
>> >> >> >>> >> > <matthewturk at gmail.com>
>> >> >> >>> >> > 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 at lists.spacepope.org
>> >> >> >>> >> >>
>> >> >> >>> >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >> >>> >> > _______________________________________________
>> >> >> >>> >> > yt-dev mailing list
>> >> >> >>> >> > yt-dev at lists.spacepope.org
>> >> >> >>> >> >
>> >> >> >>> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >> >>> >> _______________________________________________
>> >> >> >>> >> yt-dev mailing list
>> >> >> >>> >> yt-dev at lists.spacepope.org
>> >> >> >>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > _______________________________________________
>> >> >> >>> > yt-dev mailing list
>> >> >> >>> > yt-dev at lists.spacepope.org
>> >> >> >>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >> >>> >
>> >> >> >>> _______________________________________________
>> >> >> >>> yt-dev mailing list
>> >> >> >>> yt-dev at lists.spacepope.org
>> >> >> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> yt-dev mailing list
>> >> >> >> yt-dev at lists.spacepope.org
>> >> >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > yt-dev mailing list
>> >> >> > yt-dev at lists.spacepope.org
>> >> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >> >
>> >> >> _______________________________________________
>> >> >> yt-dev mailing list
>> >> >> yt-dev at lists.spacepope.org
>> >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > *********************************************************************
>> >> > * *
>> >> > * Dr. Michael Kuhlen Theoretical Astrophysics Center *
>> >> > * email: mqk at 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 at lists.spacepope.org
>> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> >
>> >> _______________________________________________
>> >> yt-dev mailing list
>> >> yt-dev at lists.spacepope.org
>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> >
>> >
>> > _______________________________________________
>> > yt-dev mailing list
>> > yt-dev at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
More information about the yt-dev
mailing list