[yt-dev] proposal to merge yt-3.0 development into main repo

Tue Nov 26 12:13:12 PST 2013

On Tue, Nov 26, 2013 at 3:05 PM, Britton Smith <brittonsmith at 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-for-when-we-should-move

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 at 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 at 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 at mumford.me.uk> wrote:
>>>>
>>>> +1
>>>>
>>>> On 26 Nov 2013 15:33, "Britton Smith" <brittonsmith at 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 at 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 at gmail.com> wrote:
>>>>
>>>> +1
>>>>
>>>>
>>>> On Tue, Nov 26, 2013 at 6:38 AM, j s oishi <jsoishi at gmail.com> wrote:
>>>>
>>>> +1. Let's do this.
>>>>
>>>>
>>>> On Tue, Nov 26, 2013 at 9:26 AM, Matthew Turk <matthewturk at 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 at 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 at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>