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

Nathan Goldbaum nathan12343 at gmail.com
Wed Mar 12 13:52:42 PDT 2014


Did you fix the issue I reported about iterating over time series? If so, I
think it's good to go in.  I've been using it for day-to-day stuff all week
and have noticed no issues.

If there are issues present having more people using the code will
certainly shake them out more quickly.


On Wed, Mar 12, 2014 at 1:32 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> 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
> >>
> _______________________________________________
> 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/82db5c29/attachment.htm>


More information about the yt-dev mailing list