+1 on yt-3.0 in yt_analysis/yt.  I think this should definitely be done at some point, and now that it's getting to the point where people can use it, this may help lower that entry barrier just enough.  I would say keep the yt-3.0 repo around for now so that people who are developing in forks of it can finish what they're doing, issue a PR, and then move over to a fork of the main yt repo.

On Thu, Mar 14, 2013 at 9:44 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,

Tomorrow is the fifteenth, which puts us on track for 3.0a1:


Releasing an alpha of 3.0 means:

 * Tagging in the repo
 * Sending out an email to yt-users with plenty of caveats
 * Providing installation instructions
 * Soliciting feedback

I'd like to suggest that this also includes a code dump into
yt_analysis/yt at the tag point.  This means putting the branch yt-3.0
into the main yt repository.  This provides a few things:

1) Anyone who manually pulls can switch much more easily (this will
not affect "yt update" I believe)
2) We can consolidate a little bit of the differences between the two
3) Installing 3.0 from the install script just means changing the
branch name in install_script.sh.

On the downside, a blind "hg update -C" could potentially switch
branches.  I don't think this is a big deal since this is not a common
thing to do.

[+-][01] on pushing yt-3.0 branch into yt_analysis/yt?

I am neutral to killing off yt_analysis/yt-3.0 at this time and
developing yt-3.0 in yt_analysis/yt, but would entertain those
suggestions.  (This would mean higher traffic on pull requests.)

There are still a few outstanding things before the alpha.  Doug,
would you like me to pull in the artio changes?  And Chris, do you
think you'll have time to address the outstanding pull request
comments?  I also intend to fix RAMSES particles tomorrow, but if that
doesn't happen it's no big deal.

yt-dev mailing list