[yt-dev] Proposal: Wind down 2.X development

Matthew Turk matthewturk at gmail.com
Wed Aug 14 11:52:54 PDT 2013


On Wed, Aug 14, 2013 at 2:47 PM, Cameron Hummels <chummels at gmail.com> wrote:
> I'm personally wary of switching because I'm concerned that all of my
> scripts are going to break (some of them are broken from previous versions
> of 2.2 or 2.3 to the dev version as it is).

You should not feel obligated to switch.  Additionally, if you had
breakages between 2.2 and 2.3, those should be reported as bugs --
this is new information to me, and unless a particular deprecation was
noted in the release notes, it's a major problem.

> I know that this move to
> combining 2.x with 3.0 will be better for the developers, but will it be
> better for end users?  Or is the idea that the devs switch first, figure out
> where everything is broken, and then patch it up before the end users use
> it?

There are a number of user-facing benefits in the 3.0 codebase, but
yes, that is the general idea.

>
>
> On Wed, Aug 14, 2013 at 9:58 AM, Matthew Turk <matthewturk at gmail.com> wrote:
>>
>> On Wed, Aug 14, 2013 at 12:54 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>> > +1
>> >
>> > One wrinkle: will we be sticking with the 'yt' and 'yt-3.0' branches? I
>> > see
>> > no problem with this in principle, although we learned with enzo
>> > development
>> > a while back that branches can be confusing. It might help if `yt
>> > instinfo`
>> > reported the branch and if we open a wiki page or something that we can
>> > point people to describing the state of things.
>>
>> I think at some point we should merge yt-3.0 *into* yt, and then 2.x
>> can live inside stable for a while until we decide that 3.0 has
>> reached that point.
>>
>> In retrospect, the branch "yt-3.0" was not a good idea, since it will
>> have a natural conflict with the release tag.  So I think when it's
>> time to release, we can probably just skip right to 3.1.  Or maybe
>> 3000?  Not sure.
>>
>> -Matt
>>
>> >
>> >
>> > On Wed, Aug 14, 2013 at 9:49 AM, Sam Skillman <samskillman at gmail.com>
>> > wrote:
>> >>
>> >> +1
>> >>
>> >>
>> >> On Wed, Aug 14, 2013 at 9:45 AM, John ZuHone <jzuhone at gmail.com> wrote:
>> >>>
>> >>> I'm +1 on combining development and winding down 2.x.
>> >>>
>> >>> On Aug 14, 2013, at 9:38 AM, Matthew Turk <matthewturk at gmail.com>
>> >>> wrote:
>> >>>
>> >>> > Hi all,
>> >>> >
>> >>> > I'm just coming back online, but earlier this week I had the
>> >>> > opportunity to talk to a few people about yt -- specifically,
>> >>> > Nathan.
>> >>> >
>> >>> > There are a few disadvantages to continuing to develop in parallel:
>> >>> >
>> >>> > * Features and bug fixes don't get ported with regularity
>> >>> > * Documentation is not being developed for 3.0 explicitly
>> >>> > * Problems that may be present in 3.0 are not being noticed
>> >>> > * New users (particularly for new codes) find themselves in a bit of
>> >>> > a bind with how to install
>> >>> >
>> >>> > There are a few disadvantages to combining development:
>> >>> >
>> >>> > * Not everyone who uses patch-based codes has moved
>> >>> > * All of the codes have not yet been ported (this is something I can
>> >>> > do)
>> >>> > * A few things do not yet work (boolean objects and clump finding
>> >>> > come
>> >>> > to mind)
>> >>> >
>> >>> > If we do decide to move soon, there are a few things that are major
>> >>> > blockers which I would take on:
>> >>> >
>> >>> > * Porting the remaining codes
>> >>> > * Fixing IO for spatial particle fields in patch-based codes, which
>> >>> > is currently a major performance bottleneck
>> >>> > * Rewriting clump finding to work with 3.0
>> >>> >
>> >>> > Additionally, I'd like to move all the Python3 changes and the
>> >>> > Boxlib
>> >>> > refactor to yt-3.0 if we do this.
>> >>> >
>> >>> > If there is support for this, I'd be happy to write this into a
>> >>> > YTEP.
>> >>> > I think we could continue to provide bug fixes for 2.x and perhaps
>> >>> > do
>> >>> > one more "major" release (2.6) and then only bug fixes from then on.
>> >>> >
>> >>> > -Matt
>> >>> > _______________________________________________
>> >>> > yt-dev mailing list
>> >>> > yt-dev at lists.spacepope.org
>> >>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >>>
>> >>> _______________________________________________
>> >>> yt-dev mailing list
>> >>> yt-dev at lists.spacepope.org
>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> yt-dev mailing list
>> >> yt-dev at lists.spacepope.org
>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >>
>> >
>> >
>> > _______________________________________________
>> > yt-dev mailing list
>> > yt-dev at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
>
> --
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> http://chummels.org
>
> _______________________________________________
> 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