proposal to merge yt-3.0 development into main repo
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
Also, to be clear, I think we should keep yt-3.0 development in the yt-3.0 branch of yt for the time being. On Tue, Nov 26, 2013 at 12:20 PM, Britton Smith <brittonsmith@gmail.com>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
On 11/26/2013 01:21 PM, Britton Smith wrote:
Also, to be clear, I think we should keep yt-3.0 development in the yt-3.0 branch of yt for the time being.
On Tue, Nov 26, 2013 at 12:20 PM, Britton Smith <brittonsmith@gmail.com>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?
+1 Having one repo would greatly simplify some dirty hacks I've made in jenkins. Same goes for issues/PRs linking @ bitbucket Cheers, Kacper
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
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 <jwise@physics.gatech.edu> 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
+1. Let's do this. On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk@gmail.com> 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 <jwise@physics.gatech.edu> 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
+1 On Tue, Nov 26, 2013 at 6:38 AM, j s oishi <jsoishi@gmail.com> wrote:
+1. Let's do this.
On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk@gmail.com>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 <jwise@physics.gatech.edu> 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
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 <samskillman@gmail.com> wrote:
+1
On Tue, Nov 26, 2013 at 6:38 AM, j s oishi <jsoishi@gmail.com> wrote: +1. Let's do this.
On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk@gmail.com> 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 <jwise@physics.gatech.edu> 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
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 <jzuhone@gmail.com> 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 <samskillman@gmail.com> wrote:
+1
On Tue, Nov 26, 2013 at 6:38 AM, j s oishi <jsoishi@gmail.com> wrote:
+1. Let's do this.
On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk@gmail.com>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 <jwise@physics.gatech.edu> 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
+1 On Tue, Nov 26, 2013 at 7:33 AM, Britton Smith <brittonsmith@gmail.com>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 <jzuhone@gmail.com> 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 <samskillman@gmail.com> wrote:
+1
On Tue, Nov 26, 2013 at 6:38 AM, j s oishi <jsoishi@gmail.com> wrote:
+1. Let's do this.
On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk@gmail.com>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 <jwise@physics.gatech.edu> 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
+1 On 26 Nov 2013 15:33, "Britton Smith" <brittonsmith@gmail.com> 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 <jzuhone@gmail.com> 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 <samskillman@gmail.com> wrote:
+1
On Tue, Nov 26, 2013 at 6:38 AM, j s oishi <jsoishi@gmail.com> wrote:
+1. Let's do this.
On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk@gmail.com>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 <jwise@physics.gatech.edu> 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" <stuart@mumford.me.uk> wrote:
+1 On 26 Nov 2013 15:33, "Britton Smith" <brittonsmith@gmail.com> 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 <jzuhone@gmail.com> 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 <samskillman@gmail.com> wrote:
+1
On Tue, Nov 26, 2013 at 6:38 AM, j s oishi <jsoishi@gmail.com> wrote:
+1. Let's do this.
On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk@gmail.com>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 <jwise@physics.gatech.edu> 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
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" <stuart@mumford.me.uk> wrote:
+1 On 26 Nov 2013 15:33, "Britton Smith" <brittonsmith@gmail.com> 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 <jzuhone@gmail.com> 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 <samskillman@gmail.com> wrote:
+1
On Tue, Nov 26, 2013 at 6:38 AM, j s oishi <jsoishi@gmail.com> wrote:
+1. Let's do this.
On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk@gmail.com>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 <jwise@physics.gatech.edu> 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
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" <nathan12343@gmail.com> 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" <stuart@mumford.me.uk> wrote:
+1 On 26 Nov 2013 15:33, "Britton Smith" <brittonsmith@gmail.com> 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 <jzuhone@gmail.com> 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 <samskillman@gmail.com> wrote:
+1
On Tue, Nov 26, 2013 at 6:38 AM, j s oishi <jsoishi@gmail.com> wrote:
+1. Let's do this.
On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk@gmail.com>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 <jwise@physics.gatech.edu> 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
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? On Tue, Nov 26, 2013 at 5:49 PM, Matthew Turk <matthewturk@gmail.com> 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" <nathan12343@gmail.com> 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" <stuart@mumford.me.uk> wrote:
+1 On 26 Nov 2013 15:33, "Britton Smith" <brittonsmith@gmail.com> 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 <jzuhone@gmail.com> 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 <samskillman@gmail.com> wrote:
+1
On Tue, Nov 26, 2013 at 6:38 AM, j s oishi <jsoishi@gmail.com> wrote:
+1. Let's do this.
On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk@gmail.com>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 <jwise@physics.gatech.edu> 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
_______________________________________________ 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 <brittonsmith@gmail.com> 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 <matthewturk@gmail.com> 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" <nathan12343@gmail.com> 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" <stuart@mumford.me.uk> wrote:
+1
On 26 Nov 2013 15:33, "Britton Smith" <brittonsmith@gmail.com> 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 <jzuhone@gmail.com> 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 <samskillman@gmail.com> wrote:
+1
On Tue, Nov 26, 2013 at 6:38 AM, j s oishi <jsoishi@gmail.com> wrote:
+1. Let's do this.
On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk@gmail.com> 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 <jwise@physics.gatech.edu> 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 <jzuhone@gmail.com> wrote:
On Nov 26, 2013, at 3:05 PM, Britton Smith <brittonsmith@gmail.com> 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
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 <chummels@gmail.com> 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 favor.
Cameron
On Tue, Nov 26, 2013 at 1:15 PM, John ZuHone <jzuhone@gmail.com> wrote:
On Nov 26, 2013, at 3:05 PM, Britton Smith <brittonsmith@gmail.com> 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
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 <jzuhone@gmail.com> 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 <chummels@gmail.com> 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 <jzuhone@gmail.com> wrote:
On Nov 26, 2013, at 3:05 PM, Britton Smith <brittonsmith@gmail.com> 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
Ok, I think it's settled. Matt, would you care to issue the PR for all of the yt-3.0 repo into the yt-3.0 branch of yt? On Tue, Nov 26, 2013 at 8:26 PM, Matthew Turk <matthewturk@gmail.com> wrote:
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 <jzuhone@gmail.com> 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 <chummels@gmail.com> 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 <jzuhone@gmail.com> wrote:
On Nov 26, 2013, at 3:05 PM, Britton Smith <brittonsmith@gmail.com>
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
_______________________________________________ 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 <jwise@physics.gatech.edu> 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
participants (11)
-
Britton Smith -
Cameron Hummels -
Chris Malone -
j s oishi -
John Wise -
John ZuHone -
Kacper Kowalik -
Matthew Turk -
Nathan Goldbaum -
Sam Skillman -
Stuart Mumford