I'm +1 on merging into the 3.0 dev branch, but only after documentation exists for the features that are being introduced by this PR.  I know this isn't what people want to hear, but I think it will be much easier to support if people other than the main authors know how it works and how to use it.


On Thu, Feb 6, 2014 at 11:52 AM, John ZuHone <jzuhone@gmail.com> wrote:
+1 on merging into the 3.0 dev branch. 

-1 on separate branch. 

On Feb 6, 2014, at 1:45 PM, Sam Skillman <samskillman@gmail.com> wrote:

I am a +1 on this for all of the reasons you've stated.  I would be much more likely to contribute bugfixes/enhancements/docs as well as test/report issues if it was on the main branch, even if it means the 3.0 branch is less "stable" than it is currently.  I'd suggest we tag the last non-unitrefactor commit so that 3.0 users can have a easy way to revert to non-unitful yt if they way, but besides that I think we should go for it.

I'm -1 on a separate stable/dev branch for 3.0.

Sam


On Thu, Feb 6, 2014 at 10:34 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi all,

Over the past month or so development has been proceeding apace on the
unit refactor in Matt's fork of yt. We did this because Matt initially
opened the unitrefactor PR and at that time it was not ready for
merging.

However, thanks to everyone's hard work, unitrefactor is getting more
and more stable and I think it's time to think about merging it into
the main repo, even if there are open issues or some remaining bits of
functionality that haven't been updated yet.

With tons of development going on in Matt's fork, I think we're
possibly leaving out people who aren't watching his repo.
Additionally, since Matt is the only one who can merge pull requests
into his repo, we need to use a lot more of his attention to keep work
moving forward.

It's true that there is some functionality that still needs to be
ported and bugs that need to be fixed. Matt's trello board summarizes
most of the issues (BTW, I see a couple missing issues, would you be
open to adding more users to it?):

https://trello.com/b/yv7o0dTp/unit-refactor

One option would be to open a new named branch in the main repo, while
still keeping the current 3.0 tip in a 'stable' state. I'm less
inclined to go this route because I think unitrefactor is such a big
improvement over the current codebase, since many new features have
snuck in besides just adding units.

Another concern is that there aren't any docs yet.  That's definitely
true, but there aren't any docs for the current 3.0 tip either.  In
fact, now that there are a set of docs bundled in the repo in the
unitrefactor bookmark, merging should improve the documentation effort
for 3.0 going forward by making it more straightforward to enforce a
rule that things need to be documented before they get merged.

What do you all think?

-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