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

j s oishi jsoishi at gmail.com
Thu Aug 15 08:18:35 PDT 2013


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

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?

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20130815/5d09fc1f/attachment.html>


More information about the yt-dev mailing list