+1 On Apr 4, 2014, at 3:31 PM, Nathan Goldbaum wrote:

Hi all,

This came up during the google hangout this morning and I think it's a good idea.

Right now there are four heads and three named branches in the yt_analysis/yt mercurial repository:

- "stable" This corresponds to the 2.6.2 stable release.

- "yt" This corresponds to the 2.7dev branch

- "development" This is on the yt-3.0 named branch, but before the unitrefactor and field refactor were merged in.

- "experimental" This is also on the yt-3.0 named branch, and incldues unitrefactor, field refactor, and many other changes added since the development workshop at UCSC.

I see a good reason to retain the "yt" development branch - there have several pull requests into it and many of our users are still using it for day-to-day work.

I don't see a good reason to keep the distinction between "development" and "experimental". There have been no pull requests into the "development" bookmark. There are also known bugs with respect to particle field detection on the "development" bookmark.

We wanted to keep the "development" bookmark as a way to easily update to a yt-3.0 release from before the time when unitrefactor and the field refactor were merged in.

I think that keeping a seperate head in the repository for this purpose is unnecessary - we could just have a named tag. For example, we could call it yt-3.0a5 and point it at the current development bookmark changeset (0d705d2ae8eb).

Benefits to doing this:

We would only have three heads in the main repo, each on a different named branch. This will make it easier to work with bitbucket, which has a UI optimized for named branches rather than bookmarks.

We will onboard more users to the new codebase, which is the way forward and represents the code that will actually be released for the final 3.0 release.

Possible issues:

The "bleeding edge" install script will build a version of yt including all the new features. Since documentation is still not up to snuff, there might be confusion due to innacurate or incomplete documentation.

I'd love to hear feedback about this - particularly if there are any strong objections.

-Nathan

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

+1 On Fri, Apr 4, 2014 at 6:33 PM, B.W. Keller wrote:

I also agree.

On Fri, Apr 4, 2014 at 3:42 PM, John ZuHone wrote:

...

+1

On Apr 4, 2014, at 3:31 PM, Nathan Goldbaum wrote:

...

Hi all,

This came up during the google hangout this morning and I think it's a good idea.

Right now there are four heads and three named branches in the yt_analysis/yt mercurial repository:

- "stable" This corresponds to the 2.6.2 stable release.

- "yt" This corresponds to the 2.7dev branch

- "development" This is on the yt-3.0 named branch, but before the unitrefactor and field refactor were merged in.

- "experimental" This is also on the yt-3.0 named branch, and incldues unitrefactor, field refactor, and many other changes added since the development workshop at UCSC.

I see a good reason to retain the "yt" development branch - there have several pull requests into it and many of our users are still using it for day-to-day work.

I don't see a good reason to keep the distinction between "development" and "experimental". There have been no pull requests into the "development" bookmark. There are also known bugs with respect to particle field detection on the "development" bookmark.

We wanted to keep the "development" bookmark as a way to easily update to a yt-3.0 release from before the time when unitrefactor and the field refactor were merged in.

I think that keeping a seperate head in the repository for this purpose is unnecessary - we could just have a named tag. For example, we could call it yt-3.0a5 and point it at the current development bookmark changeset (0d705d2ae8eb).

Benefits to doing this:

We would only have three heads in the main repo, each on a different named branch. This will make it easier to work with bitbucket, which has a UI optimized for named branches rather than bookmarks.

We will onboard more users to the new codebase, which is the way forward and represents the code that will actually be released for the final 3.0 release.

Possible issues:

The "bleeding edge" install script will build a version of yt including all the new features. Since documentation is still not up to snuff, there might be confusion due to innacurate or incomplete documentation.

I'd love to hear feedback about this - particularly if there are any strong objections.

-Nathan

_______________________________________________ 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

-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org

I'm also in favor of this. I think we should do this as soon as is reasonable, perhaps early next week. Tuesday? On Fri, Apr 4, 2014 at 10:33 PM, Sam Skillman wrote:

+1

On Apr 4, 2014 7:15 PM, "Cameron Hummels" wrote:

...

+1

On Fri, Apr 4, 2014 at 6:33 PM, B.W. Keller wrote:

...

I also agree.

On Fri, Apr 4, 2014 at 3:42 PM, John ZuHone wrote:

...

+1

On Apr 4, 2014, at 3:31 PM, Nathan Goldbaum wrote:

...

Hi all,

This came up during the google hangout this morning and I think it's a good idea.

Right now there are four heads and three named branches in the yt_analysis/yt mercurial repository:

- "stable" This corresponds to the 2.6.2 stable release.

- "yt" This corresponds to the 2.7dev branch

- "development" This is on the yt-3.0 named branch, but before the unitrefactor and field refactor were merged in.

- "experimental" This is also on the yt-3.0 named branch, and incldues unitrefactor, field refactor, and many other changes added since the development workshop at UCSC.

I see a good reason to retain the "yt" development branch - there have several pull requests into it and many of our users are still using it for day-to-day work.

I don't see a good reason to keep the distinction between "development" and "experimental". There have been no pull requests into the "development" bookmark. There are also known bugs with respect to particle field detection on the "development" bookmark.

We wanted to keep the "development" bookmark as a way to easily update to a yt-3.0 release from before the time when unitrefactor and the field refactor were merged in.

I think that keeping a seperate head in the repository for this purpose is unnecessary - we could just have a named tag. For example, we could call it yt-3.0a5 and point it at the current development bookmark changeset (0d705d2ae8eb).

Benefits to doing this:

We would only have three heads in the main repo, each on a different named branch. This will make it easier to work with bitbucket, which has a UI optimized for named branches rather than bookmarks.

We will onboard more users to the new codebase, which is the way forward and represents the code that will actually be released for the final 3.0 release.

Possible issues:

The "bleeding edge" install script will build a version of yt including all the new features. Since documentation is still not up to snuff, there might be confusion due to innacurate or incomplete documentation.

I'd love to hear feedback about this - particularly if there are any strong objections.

-Nathan

_______________________________________________ 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

-- 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

I agree with Britton. I think the experimental bookmark is a great idea. On Sun, Apr 6, 2014 at 2:49 AM, Britton Smith wrote:

I'm going to be a little bit pedantic and say that I am in favor of merging in the current contents of experimental into development because I think they have now been sufficiently vetted and are ready to be included. However, I am also in favor of retaining the model of having separate experimental and development bookmarks, even if right now the experimental bookmark will disappear for a while. The whole point of doing this in the first place was that we wanted to maintain usability for the people that were doing actual work with development while also having a staging area for everyone to easily collaborate on the unitrefactor and other new and experimental projects. To me, this has been a huge success and I would like to see us continue to use this model as we continue to work on large, disruptive changes. As long as we're not talking about never using an experimental bookmark again, I am in favor of this.

On Sat, Apr 5, 2014 at 5:00 PM, Matthew Turk wrote:

...

I'm also in favor of this. I think we should do this as soon as is reasonable, perhaps early next week. Tuesday?

...

+1

On Apr 4, 2014 7:15 PM, "Cameron Hummels" wrote:

...

+1

On Fri, Apr 4, 2014 at 6:33 PM, B.W. Keller

wrote:

...

...

I also agree.

On Fri, Apr 4, 2014 at 3:42 PM, John ZuHone

wrote:

...

...

+1

On Apr 4, 2014, at 3:31 PM, Nathan Goldbaum wrote:

> Hi all, > > This came up during the google hangout this morning and I think

it's a

...

> good idea. > > Right now there are four heads and three named branches in the > yt_analysis/yt mercurial repository: > > - "stable" > This corresponds to the 2.6.2 stable release. > > - "yt" > This corresponds to the 2.7dev branch > > - "development" > This is on the yt-3.0 named branch, but before the unitrefactor and > field refactor were merged in. > > - "experimental" > This is also on the yt-3.0 named branch, and incldues unitrefactor, > field refactor, and many other changes added since the development workshop > at UCSC. > > I see a good reason to retain the "yt" development branch - there have > several pull requests into it and many of our users are still using it for > day-to-day work. > > I don't see a good reason to keep the distinction between > "development" and "experimental". There have been no pull requests into the > "development" bookmark. There are also known bugs with respect to

...

...

...

...

> field detection on the "development" bookmark. > > We wanted to keep the "development" bookmark as a way to easily update > to a yt-3.0 release from before the time when unitrefactor and the field > refactor were merged in. > > I think that keeping a seperate head in the repository for this > purpose is unnecessary - we could just have a named tag. For example, we > could call it yt-3.0a5 and point it at the current development bookmark > changeset (0d705d2ae8eb). > > Benefits to doing this: > > We would only have three heads in the main repo, each on a different > named branch. This will make it easier to work with bitbucket, which has a > UI optimized for named branches rather than bookmarks. > > We will onboard more users to the new codebase, which is the way > forward and represents the code that will actually be released for

On Fri, Apr 4, 2014 at 10:33 PM, Sam Skillman wrote: particle the final

...

...

...

...

> 3.0 release. > > Possible issues: > > The "bleeding edge" install script will build a version of yt > including all the new features. Since documentation is still not up to > snuff, there might be confusion due to innacurate or incomplete > documentation. > > I'd love to hear feedback about this - particularly if there are any > strong objections. > > -Nathan > > _______________________________________________ > 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

-- 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

_______________________________________________ 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