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.

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