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

Matthew Turk matthewturk at gmail.com
Thu Mar 13 06:55:15 PDT 2014


Hi Britton,

Okay, done.

There are now three bookmarks that will get updated in the main
yt_analysis/yt repository.

development: this is the yt-3.0 branch that does not include unitrefactor
experimental: this is the yt-3.0 branch that does include unitrefactor
and rebranding
@: this is yt-2.x

stable branch is still the stable release.  The differences between @
and stable are quite minimal right now.  I've also tagged a yt-3.0a4
which is pre-unitrefactor/rebranding.

Also, this was 1130 changesets.

-Matt

On Thu, Mar 13, 2014 at 9:13 AM, Britton Smith <brittonsmith at gmail.com> wrote:
> Great, I think this has the requisite support.  Matt, would you care to do
> the honors of pushing both the rebranding and unitrefactor PRs to this new
> "experimental" bookmark in yt_analysis?
>
> Britton
>
>
> On Thu, Mar 13, 2014 at 12:22 AM, Anthony Scopatz <scopatz at gmail.com> wrote:
>>
>> +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
>>>
>>
>>
>> _______________________________________________
>> 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
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list