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

Britton Smith brittonsmith at gmail.com
Tue Nov 26 12:05:51 PST 2013


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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20131126/c25f8234/attachment.html>


More information about the yt-dev mailing list