+1. Let's do this. On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk wrote:

Hi all,

I'd be +1 on this. Keep the yt-3.0 branch separate, make yt_analysis/yt-3.0 read-only, and move yt-3.0 the branch itself into the main yt_analysis/yt repository.

On Tue, Nov 26, 2013 at 7:29 AM, John Wise wrote:

...

Hi,

As someone that just moved to the yt-3.0 repo (and not having much time for dev anymore...), I think this is a good idea. Having it separate was a barrier for me because 2.x worked for most of my analysis, and I just kept on using 2.x because of convenience. However, if the latest changes were in the main repo, then users could easily switch to the 3.0 branch and test things out.

+1

Cheers, John

On 11/26/2013 07:20 AM, Britton Smith wrote:

...

Hi all,

Now that we have pushed out the last (or nearly the last) major release of yt-2.x, many are now joining the effort to work on yt-3.0. As you may have noticed, there is a yt-3.0 branch in the main yt repo hosted at https://bitbucket.org/yt_analysis/yt. However, most of the actual development has been happening in a separate yt-3.0 repo (https://bitbucket.org/yt_analysis/yt-3.0).

I think it may now be time to consider moving yt-3.0 development over to the main repository. I think this will lower the barrier of entry for a number of people and should not be a big problem to users of 2.x now that that version has mostly stabilized.

As for logistics, a number of people have done work in forks of the yt-3.0, so we should not remove it entirely. Instead, I propose making it read-only, and having people push their changes to a fork of the main yt repo and working off of that from now on. The magic of mercurial should make this relatively painless.

Thoughts? +/-1?

Britton

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech http://cosmo.gatech.edu _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Can we detail how to get changes in our yt_analysis/yt-3.0 repos into the yt-3.0 branch of yt_analysis/yt? I'm guessing it's simple but probably not as simple as hitting the PR button on Bitbucket. On Nov 26, 2013, at 9:52 AM, Sam Skillman wrote:

+1

On Tue, Nov 26, 2013 at 6:38 AM, j s oishi wrote: +1. Let's do this.

On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk wrote: Hi all,

I'd be +1 on this. Keep the yt-3.0 branch separate, make yt_analysis/yt-3.0 read-only, and move yt-3.0 the branch itself into the main yt_analysis/yt repository.

On Tue, Nov 26, 2013 at 7:29 AM, John Wise wrote:

...

Hi,

As someone that just moved to the yt-3.0 repo (and not having much time for dev anymore...), I think this is a good idea. Having it separate was a barrier for me because 2.x worked for most of my analysis, and I just kept on using 2.x because of convenience. However, if the latest changes were in the main repo, then users could easily switch to the 3.0 branch and test things out.

+1

Cheers, John

On 11/26/2013 07:20 AM, Britton Smith wrote:

...

Hi all,

Now that we have pushed out the last (or nearly the last) major release of yt-2.x, many are now joining the effort to work on yt-3.0. As you may have noticed, there is a yt-3.0 branch in the main yt repo hosted at https://bitbucket.org/yt_analysis/yt. However, most of the actual development has been happening in a separate yt-3.0 repo (https://bitbucket.org/yt_analysis/yt-3.0).

I think it may now be time to consider moving yt-3.0 development over to the main repository. I think this will lower the barrier of entry for a number of people and should not be a big problem to users of 2.x now that that version has mostly stabilized.

As for logistics, a number of people have done work in forks of the yt-3.0, so we should not remove it entirely. Instead, I propose making it read-only, and having people push their changes to a fork of the main yt repo and working off of that from now on. The magic of mercurial should make this relatively painless.

Thoughts? +/-1?

Britton

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech http://cosmo.gatech.edu _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

+1 On Tue, Nov 26, 2013 at 7:33 AM, Britton Smith wrote:

John, if you have a fork of yt-3.0 and a fork of yt, you should be able to do the following: hg push yt-3.0-fork yt-fork Then, you should be able to issue PR from your yt-fork.

On Tue, Nov 26, 2013 at 3:28 PM, John ZuHone wrote:

...

Can we detail how to get changes in our yt_analysis/yt-3.0 repos into the yt-3.0 branch of yt_analysis/yt? I'm guessing it's simple but probably not as simple as hitting the PR button on Bitbucket.

On Nov 26, 2013, at 9:52 AM, Sam Skillman wrote:

+1

On Tue, Nov 26, 2013 at 6:38 AM, j s oishi wrote:

...

+1. Let's do this.

On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk wrote:

...

Hi all,

I'd be +1 on this. Keep the yt-3.0 branch separate, make yt_analysis/yt-3.0 read-only, and move yt-3.0 the branch itself into the main yt_analysis/yt repository.

...

Hi,

As someone that just moved to the yt-3.0 repo (and not having much time for dev anymore...), I think this is a good idea. Having it separate was a barrier for me because 2.x worked for most of my analysis, and I just kept on using 2.x because of convenience. However, if the latest changes were in the main repo, then users could easily switch to the 3.0 branch and test things out.

+1

Cheers, John

On 11/26/2013 07:20 AM, Britton Smith wrote:

...

Hi all,

Now that we have pushed out the last (or nearly the last) major

release

...

of yt-2.x, many are now joining the effort to work on yt-3.0. As you may have noticed, there is a yt-3.0 branch in the main yt repo hosted at https://bitbucket.org/yt_analysis/yt. However, most of the actual development has been happening in a separate yt-3.0 repo (https://bitbucket.org/yt_analysis/yt-3.0).

I think it may now be time to consider moving yt-3.0 development over to the main repository. I think this will lower the barrier of entry for a number of people and should not be a big problem to users of 2.x now that that version has mostly stabilized.

As for logistics, a number of people have done work in forks of the yt-3.0, so we should not remove it entirely. Instead, I propose making it read-only, and having people push their changes to a fork of the

On Tue, Nov 26, 2013 at 7:29 AM, John Wise wrote: main

...

...

yt repo and working off of that from now on. The magic of mercurial should make this relatively painless.

Thoughts? +/-1?

Britton

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech http://cosmo.gatech.edu _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

One item that I feel I ought to bring up is that there are two major, disruptive changes that haven't landed yet: * Field renaming / units * unifying objects and rebranding things In principle I think we can mostly provide fully-featured compatibility layers for these, but I am still somewhat anxious about them. The first one is basically ready to go *except* for volume rendering (waiting on a ytep and some reimplementation) and the second is in need of some work still, which I have not yet put in. What if we unify, and then put out a final alpha release of 3 before these land? For big disruptive changes it is probably in our best interests to ease the process of switching branches - thus unifying the repos. On Nov 26, 2013 12:10 PM, "Stuart Mumford" wrote:

+1 On 26 Nov 2013 15:33, "Britton Smith" wrote:

...

John, if you have a fork of yt-3.0 and a fork of yt, you should be able to do the following: hg push yt-3.0-fork yt-fork Then, you should be able to issue PR from your yt-fork.

On Tue, Nov 26, 2013 at 3:28 PM, John ZuHone wrote:

...

Can we detail how to get changes in our yt_analysis/yt-3.0 repos into the yt-3.0 branch of yt_analysis/yt? I'm guessing it's simple but probably not as simple as hitting the PR button on Bitbucket.

On Nov 26, 2013, at 9:52 AM, Sam Skillman wrote:

+1

On Tue, Nov 26, 2013 at 6:38 AM, j s oishi wrote:

...

+1. Let's do this.

On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk wrote:

...

Hi all,

I'd be +1 on this. Keep the yt-3.0 branch separate, make yt_analysis/yt-3.0 read-only, and move yt-3.0 the branch itself into the main yt_analysis/yt repository.

...

Hi,

As someone that just moved to the yt-3.0 repo (and not having much time for dev anymore...), I think this is a good idea. Having it separate was a barrier for me because 2.x worked for most of my analysis, and I just kept on using 2.x because of convenience. However, if the latest changes were in the main repo, then users could easily switch to the 3.0 branch and test things out.

+1

Cheers, John

On 11/26/2013 07:20 AM, Britton Smith wrote: > > Hi all, > > Now that we have pushed out the last (or nearly the last) major release > of yt-2.x, many are now joining the effort to work on yt-3.0. As you > may have noticed, there is a yt-3.0 branch in the main yt repo hosted at > https://bitbucket.org/yt_analysis/yt. However, most of the actual > development has been happening in a separate yt-3.0 repo > (https://bitbucket.org/yt_analysis/yt-3.0). > > I think it may now be time to consider moving yt-3.0 development over to > the main repository. I think this will lower the barrier of entry for a > number of people and should not be a big problem to users of 2.x now > that that version has mostly stabilized. > > As for logistics, a number of people have done work in forks of the > yt-3.0, so we should not remove it entirely. Instead, I propose making > it read-only, and having people push their changes to a fork of the

On Tue, Nov 26, 2013 at 7:29 AM, John Wise wrote: main

...

> yt repo and working off of that from now on. The magic of mercurial > should make this relatively painless. > > Thoughts? +/-1? > > Britton > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >

-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech http://cosmo.gatech.edu _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

---

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Hi Nathan, yt update updates along the DAG, and won't switch named branches. Same for install script and hg update. Clones will default to the tip *or* the @ bookmark in recent versions, but the install script for instance always specifies a branch. So until branch yt-3.0 is p2 of a merge commit on branch yt, I don't think we're in trouble. And, I think we can and should still take PRs for branch "yt". :) Matt On Nov 26, 2013 12:40 PM, "Nathan Goldbaum" wrote:

I tend to agree with Matt's suggestion.

One possible issue: does 'yt update' update to the tip of the repo or the yt branch? I would also be careful to make sure we educate everyone about hg branches which I know were confusing in the past for enzo development, although we had many more branches in enzo. In particular, fresh clones of the repo will by default update to the tip, which is likely to be 3.0. Is that an issue?

Second, will we still allow PRs into the yt branch? I know we're not planning on adding new features to 2.X, but how should we handle bugfixes?

All in all I think it will be useful to do this - it has definitely caused confusion in the past that there are two repos. I just think we need to be careful.

Nathan

On Tuesday, November 26, 2013, Matthew Turk wrote:

...

One item that I feel I ought to bring up is that there are two major, disruptive changes that haven't landed yet:

* Field renaming / units * unifying objects and rebranding things

In principle I think we can mostly provide fully-featured compatibility layers for these, but I am still somewhat anxious about them. The first one is basically ready to go *except* for volume rendering (waiting on a ytep and some reimplementation) and the second is in need of some work still, which I have not yet put in.

What if we unify, and then put out a final alpha release of 3 before these land? For big disruptive changes it is probably in our best interests to ease the process of switching branches - thus unifying the repos. On Nov 26, 2013 12:10 PM, "Stuart Mumford" wrote:

+1 On 26 Nov 2013 15:33, "Britton Smith" wrote:

John, if you have a fork of yt-3.0 and a fork of yt, you should be able to do the following: hg push yt-3.0-fork yt-fork Then, you should be able to issue PR from your yt-fork.

On Tue, Nov 26, 2013 at 3:28 PM, John ZuHone wrote:

Can we detail how to get changes in our yt_analysis/yt-3.0 repos into the yt-3.0 branch of yt_analysis/yt? I'm guessing it's simple but probably not as simple as hitting the PR button on Bitbucket.

On Nov 26, 2013, at 9:52 AM, Sam Skillman wrote:

+1

On Tue, Nov 26, 2013 at 6:38 AM, j s oishi wrote:

+1. Let's do this.

On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk wrote:

Hi all,

I'd be +1 on this. Keep the yt-3.0 branch separate, make yt_analysis/yt-3.0 read-only, and move yt-3.0 the branch itself into the main yt_analysis/yt repository.

...

Hi,

As someone that just moved to the yt-3.0 repo (and not having much time for dev anymore...), I think this is a good idea. Having it separate was a barrier for me because 2.x worked for most of my analysis, and I just kept on using 2.x because of convenience. However, if the latest changes were in the main repo, then users could easily switch to the 3.0 branch and test things out.

+1

Cheers, John

On 11/26/2013 07:20 AM, Britton Smith wrote:

...

Hi all,

Now that we have pushed out the last (or nearly the last) major release of yt-2.x, many are now joining the effort to work on yt-3.0. As you may have noticed, there is a yt-3.0 branch in the main yt repo hosted

at

...

https://bitbucket.org/yt_analysis/yt. However, most of the actual development has been happening in a separate yt-3.0 repo (https://bitbucket.org/yt_analysis/yt-3.0).

I think it may now be time to consider moving yt-3.0 development over to the main repository. I think this will lower the barrier of entry for a number of people and should not be a big problem to users of 2.x now that that version has mostly stabilized.

As for logistics, a number of people have done work in forks of the yt-3.0, so we should not remove it entirely. Instead, I propose making it read-only, and having people push their changes to a fork of the

On Tue, Nov 26, 2013 at 7:29 AM, John Wise wrote: main

...

...

yt repo and working off of that from now on. The magic of mercurial should make this relatively painless.

Thoughts? +/-1?

Britton

_______________________________________________ yt-dev mailing

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

On Tue, Nov 26, 2013 at 3:05 PM, Britton Smith wrote:

Ok, cool. I think we have a consensus that this should happen at some point. Matt, I am in favor of your idea to unify first, another alpha release, and then pulling in those two big changes only when they're ready. I think the sooner we get active yt-3.0 development in the main repo, the sooner others will get involved.

I think we should still allow PRs to the yt branch for a while still, but only for bug fixes and such. We should encourage all new features to go into yt-3.0 from here on out. I would propose that when we do an official release of yt-3.0, we merge yt-3.0 into the yt branch.

So, in conclusion, should we do this?

Yes! I'd also like to solicit some comments on this YTEP: https://bitbucket.org/yt_analysis/ytep/pull-request/29/adding-a-ytep-3000-fo... I'm fine with pushing the yt-3.0 branch as of right now over to the main repo, and then closing off the yt-3.0 repo as soon as the outstanding PRs are either finished or moved over. -Matt

On Tue, Nov 26, 2013 at 5:49 PM, Matthew Turk wrote:

...

Hi Nathan,

yt update updates along the DAG, and won't switch named branches. Same for install script and hg update.

Clones will default to the tip *or* the @ bookmark in recent versions, but the install script for instance always specifies a branch. So until branch yt-3.0 is p2 of a merge commit on branch yt, I don't think we're in trouble.

And, I think we can and should still take PRs for branch "yt". :)

Matt

On Nov 26, 2013 12:40 PM, "Nathan Goldbaum" wrote:

...

I tend to agree with Matt's suggestion.

One possible issue: does 'yt update' update to the tip of the repo or the yt branch? I would also be careful to make sure we educate everyone about hg branches which I know were confusing in the past for enzo development, although we had many more branches in enzo. In particular, fresh clones of the repo will by default update to the tip, which is likely to be 3.0. Is that an issue?

Second, will we still allow PRs into the yt branch? I know we're not planning on adding new features to 2.X, but how should we handle bugfixes?

All in all I think it will be useful to do this - it has definitely caused confusion in the past that there are two repos. I just think we need to be careful.

Nathan

On Tuesday, November 26, 2013, Matthew Turk wrote:

...

One item that I feel I ought to bring up is that there are two major, disruptive changes that haven't landed yet:

* Field renaming / units * unifying objects and rebranding things

In principle I think we can mostly provide fully-featured compatibility layers for these, but I am still somewhat anxious about them. The first one is basically ready to go *except* for volume rendering (waiting on a ytep and some reimplementation) and the second is in need of some work still, which I have not yet put in.

What if we unify, and then put out a final alpha release of 3 before these land? For big disruptive changes it is probably in our best interests to ease the process of switching branches - thus unifying the repos.

On Nov 26, 2013 12:10 PM, "Stuart Mumford" wrote:

+1

On 26 Nov 2013 15:33, "Britton Smith" wrote:

John, if you have a fork of yt-3.0 and a fork of yt, you should be able to do the following: hg push yt-3.0-fork yt-fork Then, you should be able to issue PR from your yt-fork.

On Tue, Nov 26, 2013 at 3:28 PM, John ZuHone wrote:

Can we detail how to get changes in our yt_analysis/yt-3.0 repos into the yt-3.0 branch of yt_analysis/yt? I'm guessing it's simple but probably not as simple as hitting the PR button on Bitbucket.

On Nov 26, 2013, at 9:52 AM, Sam Skillman wrote:

+1

On Tue, Nov 26, 2013 at 6:38 AM, j s oishi wrote:

+1. Let's do this.

On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk wrote:

Hi all,

I'd be +1 on this. Keep the yt-3.0 branch separate, make yt_analysis/yt-3.0 read-only, and move yt-3.0 the branch itself into the main yt_analysis/yt repository.

On Tue, Nov 26, 2013 at 7:29 AM, John Wise wrote:

...

Hi,

As someone that just moved to the yt-3.0 repo (and not having much time for dev anymore...), I think this is a good idea. Having it separate was a barrier for me because 2.x worked for most of my analysis, and I just kept on using 2.x because of convenience. However, if the latest changes were in the main repo, then users could easily switch to the 3.0 branch and test things out.

+1

Cheers, John

On 11/26/2013 07:20 AM, Britton Smith wrote:

...

Hi all,

Now that we have pushed out the last (or nearly the last) major release of yt-2.x, many are now joining the effort to work on yt-3.0. As you may have noticed, there is a yt-3.0 branch in the main yt repo hosted at https://bitbucket.org/yt_analysis/yt. However, most of the actual development has been happening in a separate yt-3.0 repo (https://bitbucket.org/yt_analysis/yt-3.0).

I think it may now be time to consider moving yt-3.0 development over to the main repository. I think this will lower the barrier of entry for a number of people and should not be a big problem to users of 2.x now that that version has mostly stabilized.

As for logistics, a number of people have done work in forks of the yt-3.0, so we should not remove it entirely. Instead, I propose making it read-only, and having people push their changes to a fork of the main yt repo and working off of that from now on. The magic of mercurial should make this relatively painless.

Thoughts? +/-1?

Britton

_______________________________________________ yt-dev mailing

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

+1/+1 on all fronts. My only holdup would've been if `hg up` defaulted to the tip of either branch, but Matt assures me that it does not (there were problems a few years ago with this). Since this is not a problem, I am in favor. Cameron On Tue, Nov 26, 2013 at 1:15 PM, John ZuHone wrote:

On Nov 26, 2013, at 3:05 PM, Britton Smith wrote:

So, in conclusion, should we do this?

+1

_______________________________________________ yt-dev mailing list yt-dev@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

Hi John, Yup -- they have been somewhat irregularly, but now we'll keep them in sync much more frequently. On Tue, Nov 26, 2013 at 3:22 PM, John ZuHone wrote:

Will the changes from 2.6 get merged into the 3.0 branch now as well?

John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Mail Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 781-708-5004 john.zuhone@nasa.gov jzuhone@gmail.com

On Nov 26, 2013, at 3:18 PM, Cameron Hummels wrote:

+1/+1 on all fronts. My only holdup would've been if `hg up` defaulted to the tip of either branch, but Matt assures me that it does not (there were problems a few years ago with this). Since this is not a problem, I am in fav or.

Cameron

On Tue, Nov 26, 2013 at 1:15 PM, John ZuHone wrote:

...

On Nov 26, 2013, at 3:05 PM, Britton Smith wrote:

So, in conclusion, should we do this?

+1

_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

+1 On Nov 26, 2013, at 7:29 AM, John Wise wrote:

Hi,

As someone that just moved to the yt-3.0 repo (and not having much time for dev anymore...), I think this is a good idea. Having it separate was a barrier for me because 2.x worked for most of my analysis, and I just kept on using 2.x because of convenience. However, if the latest changes were in the main repo, then users could easily switch to the 3.0 branch and test things out.

+1

Cheers, John

On 11/26/2013 07:20 AM, Britton Smith wrote:

...

Hi all,

Now that we have pushed out the last (or nearly the last) major release of yt-2.x, many are now joining the effort to work on yt-3.0. As you may have noticed, there is a yt-3.0 branch in the main yt repo hosted at https://bitbucket.org/yt_analysis/yt. However, most of the actual development has been happening in a separate yt-3.0 repo (https://bitbucket.org/yt_analysis/yt-3.0).

I think it may now be time to consider moving yt-3.0 development over to the main repository. I think this will lower the barrier of entry for a number of people and should not be a big problem to users of 2.x now that that version has mostly stabilized.

As for logistics, a number of people have done work in forks of the yt-3.0, so we should not remove it entirely. Instead, I propose making it read-only, and having people push their changes to a fork of the main yt repo and working off of that from now on. The magic of mercurial should make this relatively painless.

Thoughts? +/-1?

Britton

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech http://cosmo.gatech.edu _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org