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

Thu Aug 15 09:59:56 PDT 2013

+1 as well, for what it is worth.

On Thu, Aug 15, 2013 at 8:40 AM, Matthew Turk <matthewturk at gmail.com> wrote:

> 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
> >
> _______________________________________________
> 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/b827ec2d/attachment.htm>