[yt-dev] proposal for merging in the unitrefactor and rebranding

[Cameron Hummels]

+1

While in general, I would advocate that PRs only be accepted when they
include sufficient documentation, in this case, it sounds fair to merge
into the main 3.0 repo with the bookmark, as it will be a lot less
cumbersome to test and document things before removing the bookmark and
going gold.

Good work, everyone!

Cameron


On Wed, Mar 12, 2014 at 6:05 AM, Britton Smith <brittonsmith at gmail.com>wrote:

> Hi all,
>
> There are two major changes coming soon for yt-3.0 as we march our way to
> an official release.  These are the unitrefactor and the rebranding.  The
> unitrefactor adds symbolically expressed, convertible units to all fields
> and scalars in yt.  The rebranding is a rethinking of some of yt's
> conceptual entities (such as thinking of a "dataset" instead of a
> "parameter file", an "indexer" instead of a "hierarchy", etc.) and attempt
> to de-astro the infrastructure as we start to think about working with
> other sciences.  The unitrefactor also contains some rebranding efforts in
> the form of field renaming (e.g., "Density" becoming "density"), so these
> changes are somewhat linked.
>
> What we need to figure out is the process by which these changes are
> merged into the yt-3.0 branch of the main repo (yt_analysis).  In my
> opinion, the primary issues are the following:
>
> 1. Develop is cumbersome because it is taking place within Matt's fork,
> meaning that all contributors have to fork his fork and issue PRs to that.
>  This is annoying because one has to maintain two forks and because most
> people aren't getting notified of PRs issued to Matt's fork.
>
> 2. Experience has shown that the only way to identify all the bugs is by
> actually attempting to use the code to do Real Stuff.  What this means is
> we need all the frontends represented and people putting the various
> functionality and analysis modules to use.  I think for most people, having
> to pull changes in from an external repo and perform various mercurial
> magic just to test changes is a bridge to far.  We need to lower the
> barrier to entry.
>
> 3. There is still a good amount of documentation, testing, polishing, etc
> before this can be called stable.  Even though yt-3.0 is still officially
> Under Development, a number of people are using it to do actual things and
> so it is unreasonable to just land this on them without full documentation
> and with such a high likelihood that it will break things.
>
> *I propose that the unitrefactor and rebranding work be pulled into the
> main repository in an "experimental" bookmark.*  I think this will a)
> streamline development and make it more visible to everyone, b) lower the
> barrier to trying it out for people so we can actually get everything
> tested and working, and c) not disrupt the workflow of the current users of
> yt-3.0.  I also think this is the quickest way of satisfying everyone in
> terms of getting all of the necessary documentation written as it makes the
> development significantly more open and accessible.
>
> For more info on what needs to be done on both of these fronts and for
> yt-3.0 in general, see the trello boards: https://trello.com/yt_analysis
>
> Can we get a +/-1 on this?
>
> Britton
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140312/72a67ae1/attachment.htm>