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

Thu Aug 15 08:40:10 PDT 2013

On Thu, Aug 15, 2013 at 11:18 AM, j s oishi <jsoishi at gmail.com> wrote:
> Unfortunately, I chose to develop the Pencil Code frontend in 2.x, mostly
> because I was under pressure to get it together quickly, and I (still) have
> never used yt-3.0. It's going to take a while for it to come up to PR
> status, and that will require me to advertise it to Pencil Code users and
> try to patch up the huge number of variables, assuming it takes root in the
> community. I have at least one beta tester that I know of, but I haven't yet
> given it to her (she does not know how to use hg, so pulling from another
> repo, rebuilding and so forth will require some text to be written).
>

Awesome work on the pencil frontend!

> My question is, should I port the Pencil frontend to 3.0 post-haste and
> introduce Pencil people directly to 3.0? Or should I continue development in
> 2.X?

I'd recommend keeping it in 2.x, and then I will take on porting it
when the time comes.  In general, frontends can be ported without too
much trouble, but to take advantage of a few nice things in 3.0 they
need some work.  For instance, in 3.0, the number of methods to
implement on the IO handler is actually smaller, but they need to have
some management of data selection.

-Matt

>
> thanks,
>
> j
>
>
> On Wed, Aug 14, 2013 at 4:43 PM, Cameron Hummels <chummels at gmail.com> wrote:
>>
>> Fair enough.  I'm +1 on this proposal.  I think getting back to a single
>> line of development would be beneficial.
>>
>>
>> On Wed, Aug 14, 2013 at 11:52 AM, Matthew Turk <matthewturk at gmail.com>
>> wrote:
>>>
>>> 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
>>> >
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>