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

Matthew Turk matthewturk at gmail.com
Wed Mar 12 13:32:32 PDT 2014


Okay, seems like we have broad consensus, but I want to wait a day or
two before doing anything to ensure all sides are heard from.

But, one last outstanding question: can we merge the rebranding PR in
to the unitrefactor work?

https://bitbucket.org/MatthewTurk/yt/pull-request/85/rebranding

On Wed, Mar 12, 2014 at 12:58 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> On Wed, Mar 12, 2014 at 12:56 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
>> +1
>>
>> The documentation has also come a long way since this topic was last
>> discussed on the list.
>
> I agree, and I think it's nearing the "mergable" state.  Not
> releasable, but mergable.
>
>>
>>
>> On Wednesday, March 12, 2014, Sam Skillman <samskillman at gmail.com> wrote:
>>>
>>> +1
>>>
>>> On Mar 12, 2014 7:39 AM, "John ZuHone" <jzuhone at gmail.com> wrote:
>>>
>>> +1
>>>
>>> On Mar 12, 2014, at 9:11 AM, Matthew Turk <matthewturk at gmail.com> wrote:
>>>
>>> > On Wed, Mar 12, 2014 at 9: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?
>>> >
>>> > +1, for all of these reasons.
>>> >
>>> > I'm really keen to get things merged in, but nervous -- for the
>>> > reasons you note.
>>> >
>>> > -Matt
>>> >
>>> >>
>>> >> Britton
>>> >>
>>> >> _______________________________________________
>>> >> yt-dev mailing list
>>> >> yt-dev at lists.spacepope.org
>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >>
>>> > _______________________________________________
>>> > yt-dev mailing list
>>> > yt-dev at lists.spacepope.org
>>> >
>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>



More information about the yt-dev mailing list