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

Britton Smith brittonsmith at gmail.com
Sat Aug 17 06:22:35 PDT 2013 

+1 along with the proposed documentation sprint.


On Thu, Aug 15, 2013 at 12:59 PM, Anthony Scopatz <scopatz at gmail.com> wrote:

> +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
>>
>
>
> _______________________________________________
> 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/20130817/5d1a492a/attachment.html>

More information about the yt-dev mailing list