[yt-dev] Near- and mid-term roadmap: 2.4, 2.x, 3.0

[Cameron Hummels]

I think the priority to make more codes supported at a high level is 
key, as yt can no longer be labeled an enzo-centric analysis routine.

Furthermore, I agree that refactoring the code is necessary to make 
major internal changes which will benefit us all in efficiency and 
functionality; I think you're right to have us make one major switch 
development-wise in as short a time as possible so as to minimize 
cross-repo transplants.  This summer works for me!

I like this plan and timeline--I'm just sorry I won't be around for part 
of it!

+1!

Cameron

On 6/7/12 4:50 PM, Matthew Turk wrote:
> Hi all,
>
> Sam and I are working on issuing a PR about the volume rendering
> refactor.  This is the last major code change to go in place for 2.4,
> pending the quad_proj changes being accepted or rejected.  I'm still
> thinking about this refine_by issue, and that might also make it in.
> After the volume_refactor, it's just testing and documentation left:
>
> https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.4
>
> After 2.4 is released, I am going to shift my new development
> exclusively to the yt-3.0 branch, which is currently hosted here:
>
> http://bitbucket.org/yt_analysis/yt-3.0
>
> This will include geometry refactoring and many remaining
> de-Enzoifications of the code base.  3.0 is nearing a usable state,
> but will not be ready for production for a while.  However, I think
> that allowing the codebases to diverge too rapidly will lead to
> problems: a fracturing.  So once the 3.0 codebase can muster feature
> parity with 2.x, I am going to ask that all development on the 2.x
> branch cease, and all pull requests for features and new functionality
> be applied only to the 3.0 branch.  In advance of this, I would like
> to solicit help: we've identified a number of relatively
> straightforward changes to this code base that can and should be made.
>   For instance, the changing of field names.  I'd also like to consider
> moving to a more spread-out source code layout, like one class per
> file.  Changes like these make it difficult to do cross-branch merges
> and transplants, which is why I would like to save them for after
> feature parity has been reached and development on 2.x has halted.
>
> Previous threads:
>
> http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001852.html
> http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001868.html
> http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001830.html
> http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-March/001941.html
> http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-March/001949.html
>
> If anyone has any strong objections to this strategy, please reply.
>
> Estimated Timeline:
>
>   * June 26, 2.4 release
>   * July 30, 3.0 reaches rough feature parity
>   * Fall sometime: 3.0 merged into main 'yt' branch
>   * Some time after that: 3.0 released
>
> Criteria for Feature Parity:
>
>   * All patch-based AMR codes support data region selection
>   * Parallelism is functional for all parallel-capable routines
>   * All patch-based AMR codes support projections, slices, cutting planes
>   * All patch-based AMR codes support volume rendering
>   * All patch-based AMR codes support halo finding
>   * Octree-based AMR codes (RAMSES and ART) support data region selection
>   * Octree-based AMR codes (RAMSES and ART) support slices, projections
> and cutting planes
>
> If any of you are interested in helping with this reengineering
> effort, I would be extremely interested in collaborating.  My goal for
> this effort is to focus on making yt a future-compatible code, and
> changing it from an organically grown system into one that we design
> based on the years of experience we all have now had with it.
>
> -Matt
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>