<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="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 class="im">On Wed, Aug 14, 2013 at 2:47 PM, Cameron Hummels <<a href="mailto:chummels@gmail.com">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 class="im"><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 class="HOEnZb"><div class="h5"><br>
><br>
><br>
> On Wed, Aug 14, 2013 at 9:58 AM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, Aug 14, 2013 at 12:54 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">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">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">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">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">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">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">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">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">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">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">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>