<div dir="ltr">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). <div>
<br></div><div>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?</div><div><br></div><div>thanks,</div><div><br></div>
<div>j</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 14, 2013 at 4:43 PM, Cameron Hummels <span dir="ltr"><<a href="mailto:chummels@gmail.com" target="_blank">chummels@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Fair enough. I'm +1 on this proposal. I think getting back to a single line of development would be beneficial.</div>
<div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 14, 2013 at 11:52 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wed, Aug 14, 2013 at 2:47 PM, Cameron Hummels <<a href="mailto:chummels@gmail.com" target="_blank">chummels@gmail.com</a>> wrote:<br>
> I'm personally wary of switching because I'm concerned that all of my<br>
> scripts are going to break (some of them are broken from previous versions<br>
> of 2.2 or 2.3 to the dev version as it is).<br>
<br>
</div>You should not feel obligated to switch. Additionally, if you had<br>
breakages between 2.2 and 2.3, those should be reported as bugs --<br>
this is new information to me, and unless a particular deprecation was<br>
noted in the release notes, it's a major problem.<br>
<div><br>
> I know that this move to<br>
> combining 2.x with 3.0 will be better for the developers, but will it be<br>
> better for end users? Or is the idea that the devs switch first, figure out<br>
> where everything is broken, and then patch it up before the end users use<br>
> it?<br>
<br>
</div>There are a number of user-facing benefits in the 3.0 codebase, but<br>
yes, that is the general idea.<br>
<div><div><br>
><br>
><br>
> On Wed, Aug 14, 2013 at 9:58 AM, Matthew Turk <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, Aug 14, 2013 at 12:54 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>><br>
>> wrote:<br>
>> > +1<br>
>> ><br>
>> > One wrinkle: will we be sticking with the 'yt' and 'yt-3.0' branches? I<br>
>> > see<br>
>> > no problem with this in principle, although we learned with enzo<br>
>> > development<br>
>> > a while back that branches can be confusing. It might help if `yt<br>
>> > instinfo`<br>
>> > reported the branch and if we open a wiki page or something that we can<br>
>> > point people to describing the state of things.<br>
>><br>
>> I think at some point we should merge yt-3.0 *into* yt, and then 2.x<br>
>> can live inside stable for a while until we decide that 3.0 has<br>
>> reached that point.<br>
>><br>
>> In retrospect, the branch "yt-3.0" was not a good idea, since it will<br>
>> have a natural conflict with the release tag. So I think when it's<br>
>> time to release, we can probably just skip right to 3.1. Or maybe<br>
>> 3000? Not sure.<br>
>><br>
>> -Matt<br>
>><br>
>> ><br>
>> ><br>
>> > On Wed, Aug 14, 2013 at 9:49 AM, Sam Skillman <<a href="mailto:samskillman@gmail.com" target="_blank">samskillman@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> +1<br>
>> >><br>
>> >><br>
>> >> On Wed, Aug 14, 2013 at 9:45 AM, John ZuHone <<a href="mailto:jzuhone@gmail.com" target="_blank">jzuhone@gmail.com</a>> wrote:<br>
>> >>><br>
>> >>> I'm +1 on combining development and winding down 2.x.<br>
>> >>><br>
>> >>> On Aug 14, 2013, at 9:38 AM, Matthew Turk <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>><br>
>> >>> > Hi all,<br>
>> >>> ><br>
>> >>> > I'm just coming back online, but earlier this week I had the<br>
>> >>> > opportunity to talk to a few people about yt -- specifically,<br>
>> >>> > Nathan.<br>
>> >>> ><br>
>> >>> > There are a few disadvantages to continuing to develop in parallel:<br>
>> >>> ><br>
>> >>> > * Features and bug fixes don't get ported with regularity<br>
>> >>> > * Documentation is not being developed for 3.0 explicitly<br>
>> >>> > * Problems that may be present in 3.0 are not being noticed<br>
>> >>> > * New users (particularly for new codes) find themselves in a bit of<br>
>> >>> > a bind with how to install<br>
>> >>> ><br>
>> >>> > There are a few disadvantages to combining development:<br>
>> >>> ><br>
>> >>> > * Not everyone who uses patch-based codes has moved<br>
>> >>> > * All of the codes have not yet been ported (this is something I can<br>
>> >>> > do)<br>
>> >>> > * A few things do not yet work (boolean objects and clump finding<br>
>> >>> > come<br>
>> >>> > to mind)<br>
>> >>> ><br>
>> >>> > If we do decide to move soon, there are a few things that are major<br>
>> >>> > blockers which I would take on:<br>
>> >>> ><br>
>> >>> > * Porting the remaining codes<br>
>> >>> > * Fixing IO for spatial particle fields in patch-based codes, which<br>
>> >>> > is currently a major performance bottleneck<br>
>> >>> > * Rewriting clump finding to work with 3.0<br>
>> >>> ><br>
>> >>> > Additionally, I'd like to move all the Python3 changes and the<br>
>> >>> > Boxlib<br>
>> >>> > refactor to yt-3.0 if we do this.<br>
>> >>> ><br>
>> >>> > If there is support for this, I'd be happy to write this into a<br>
>> >>> > YTEP.<br>
>> >>> > I think we could continue to provide bug fixes for 2.x and perhaps<br>
>> >>> > do<br>
>> >>> > one more "major" release (2.6) and then only bug fixes from then on.<br>
>> >>> ><br>
>> >>> > -Matt<br>
>> >>> > _______________________________________________<br>
>> >>> > yt-dev mailing list<br>
>> >>> > <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
>> >>> > <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>> >>><br>
>> >>> _______________________________________________<br>
>> >>> yt-dev mailing list<br>
>> >>> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
>> >>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> yt-dev mailing list<br>
>> >> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
>> >> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>> >><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > yt-dev mailing list<br>
>> > <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
>> > <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>> ><br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Cameron Hummels<br>
> Postdoctoral Researcher<br>
> Steward Observatory<br>
> University of Arizona<br>
> <a href="http://chummels.org" target="_blank">http://chummels.org</a><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Cameron Hummels<div>Postdoctoral Researcher</div><div>Steward Observatory</div><div>University of Arizona</div><div><a href="http://chummels.org" target="_blank">http://chummels.org</a></div>
</div>
</div></div><br>_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
<br></blockquote></div><br></div>