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

Nathan Goldbaum nathan12343 at gmail.com
Tue Nov 26 09:40:49 PST 2013


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


More information about the yt-dev mailing list