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

[Anthony Scopatz]

+1


On Wed, Mar 12, 2014 at 6:08 PM, Cameron Hummels <chummels at gmail.com> wrote:

> +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
>
> _______________________________________________
> 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/20140312/30a88c90/attachment.html>