You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@climate.apache.org by Michael Joyce <jo...@apache.org> on 2013/08/16 18:31:54 UTC
JIRA component names
Some of our JIRA components are very JPL/RCMES-centric. What does everyone
think of switching these over to something more generic? Ideas on names?
-- Joyce
Re: JIRA component names
Posted by Michael Joyce <jo...@apache.org>.
Awesome Cam, thanks for making all these changes!
-- Joyce
On Wed, Aug 21, 2013 at 7:19 AM, Cameron Goodale <go...@apache.org> wrote:
> Hey Team,
>
> I have made the changes to JIRA, and I setup a reminder 6 months from now
> to take a quick survey of how the new components are working out.
>
> Thanks for the input on this.
>
> Side Note: My take on the Component Lead is a New JIRA would be assigned
> to the Component Lead if an Assignee isn't selected. If that happens it is
> the Component Lead's responsibility to review the issue and either do the
> work, or re-assign it to the person most capable to work on the issue. If
> someone puts an Assignee on an issue, then the Component Lead (or Project
> Lead) will not be assigned.
>
> I will start another DISCUSS thread in 6 months, so in the meantime please
> take the new components for a spin.
>
> Best Regards,
>
>
> Cameron
>
>
> On Tue, Aug 20, 2013 at 1:21 PM, Khudikyan, Shakeh E (398J) <
> Shakeh.E.Khudikyan@jpl.nasa.gov> wrote:
>
> > +1
> >
> > Shakeh
> >
> >
> >
> >
> > On 8/20/13 11:06 AM, "Cameron Goodale" <go...@apache.org> wrote:
> >
> > >Here is the current state of component names:
> > >
> > >Current list we won't change:
> > >------------------------------------------
> > >build process
> > >general
> > >metrics
> > >visualization
> > >website
> > >
> > >New Components to Add:
> > >-----------------------------------------
> > >documentation
> > >dataset
> > >
> > >
> > >The 4 Contentious Components still being discussed: (with my attempt to
> > >please the commenters thus far)
> >
> >--------------------------------------------------------------------------
> > >-------
> > >rcmed -> data sources
> > >rcmet -> analysis
> > >rcmet ui -> webapp (this would include ui, middleware, etc...)
> > >regridding -> data processing (loosely maps to dataset_processor, but
> > >would encompass ensemble, temporal and spatial regrid)
> > >
> > >I also agree with Mike J. that JIRA has functionality to map components
> to
> > >Component Leads which might be a nice way to help divide up the work,
> and
> > >I
> > >feel there is a tension between component labels that are Core Developer
> > >Friendly (map to a module of code - dataset_processor) and New User
> > >Friendly (map to a set of functionality they understand - regridding).
> We
> > >can always have both, but run the risk of too many options.
> > >
> > >We can also setup the new components in the list, put them into use and
> > >revisit this issue in 6 months and see what components are used and
> which
> > >are not. Call it a "Try and Wait" approach to this.
> > >
> > >
> > >
> > >-Cameron
> > >
> > >
> > >
> > >
> > >On Tue, Aug 20, 2013 at 8:03 AM, Ramirez, Paul M (398J) <
> > >paul.m.ramirez@jpl.nasa.gov> wrote:
> > >
> > >> All,
> > >>
> > >> Seems to me there is a simple high level web-ui, command line, and
> API.
> > >> Potentially, there is services too but at the moment that would
> reflect
> > >> the services to support the web UI. There should also be something
> that
> > >> links issues to build so we can group together updates to any build
> > >> scripts, packaging, and distribution to somewhere like pypi.
> > >>
> > >> I think if we get too specific then if there are shifts we have to go
> > >> change our labels again (imo).
> > >>
> > >> --Paul
> > >>
> > >> On 8/20/13 7:42 AM, "Michael Joyce" <jo...@apache.org> wrote:
> > >>
> > >> >Chris,
> > >> >
> > >> >1) Regridding is far too specific with regards to what
> > >>dataset_processor
> > >> >actually does in my opinion. Visualization vs plotting, I like
> > >> >visualization better personally.
> > >> >
> > >> >2) Again, "pipeline" seems too generic. Even "rcmet" is too generic
> in
> > >>my
> > >> >opinion. I think it's a sign that something is wrong when the vast
> > >> >majority
> > >> >of our issues are falling under a single component. Too me that says
> > >>that
> > >> >we need to break that component into smaller, more specific
> components.
> > >> >(Unless, of course, all the work is actually being done on just one
> > >> >specific component).
> > >> >
> > >> >I think the more important question is, what are we using these
> labels
> > >> >for?
> > >> >Are they for accurately describing issues for committers/contributors
> > >>or
> > >> >are we trying to make it easy for people making JIRAs to label the
> > >> >problem?
> > >> >Most people who don't actively participate on the project are
> > >>(probably)
> > >> >going to label their issue as "general" since they have no idea what
> is
> > >> >broken. If that's the case, then our components should be useful for
> > >>the
> > >> >people on the project and thus specific. We should also exploit
> > >>component
> > >> >leads so that issues can be filtered to people on the project who are
> > >>most
> > >> >capable of dealing with/delegating the issue.
> > >> >
> > >> >TLDR: I like specific, descriptive component names over generic
> > >> >catch-alls.
> > >> >One generic component is good for people making issues that have no
> > >>idea
> > >> >what is wrong; These can adjusted once someone has looked at the
> > >>problem.
> > >> >Let's exploit component leads to make all of our lives easier!
> > >> >
> > >> >Thoughts?
> > >> >
> > >> >
> > >> >-- Joyce
> > >> >
> > >> >
> > >> >On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) <
> > >> >chris.a.mattmann@jpl.nasa.gov> wrote:
> > >> >
> > >> >> Cam, I am +1 for this remapping, with the caveats:
> > >> >>
> > >> >> 1. regridding is much more understood in the community than dataset
> > >> >> processor.
> > >> >> Same goes for viz (compared to plotting). So dunno on those.
> > >> >>
> > >> >> 2. I can see your point about rcmet, but don't we have a concept of
> > >> >> end-to-end
> > >> >> regrid->analysis->viz pipeline? Wouldn't something like pipeline or
> > >> >>maybe
> > >> >> even
> > >> >> analysis make more sense than simply having no component? To me
> some
> > >> >> component is
> > >> >> better than none.
> > >> >>
> > >> >> Bump it to the top of my list anytime.
> > >> >>
> > >> >> Cheers,
> > >> >> Chris
> > >> >>
> > >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> Chris Mattmann, Ph.D.
> > >> >> Senior Computer Scientist
> > >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > >> >> Office: 171-266B, Mailstop: 171-246
> > >> >> Email: chris.a.mattmann@nasa.gov
> > >> >> WWW: http://sunset.usc.edu/~mattmann/
> > >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> Adjunct Assistant Professor, Computer Science Department
> > >> >> University of Southern California, Los Angeles, CA 90089 USA
> > >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> -----Original Message-----
> > >> >> From: Cameron Goodale <go...@apache.org>
> > >> >> Reply-To: "dev@climate.incubator.apache.org"
> > >> >> <de...@climate.incubator.apache.org>
> > >> >> Date: Monday, August 19, 2013 7:21 PM
> > >> >> To: "dev@climate.incubator.apache.org"
> > >> >><de...@climate.incubator.apache.org>
> > >> >> Subject: Re: JIRA component names
> > >> >>
> > >> >> >Hey Guys,
> > >> >> >
> > >> >> >I am going to take a crack and the task of mapping A1 -> B1 that
> > >>Chris
> > >> >> >mentioned since I have been making JIRAs and wishing for some
> other
> > >> >> >components in the list. Since the new OCW refactoring introduces
> > >>some
> > >> >>new
> > >> >> >software modules/components i think it makes sense to align JIRA
> > >>issues
> > >> >> >with each area of the code. This helps map issues to modules in
> the
> > >> >>code,
> > >> >> >items tasks that touch large sweeping parts of the code should go
> > >>under
> > >> >> >'general' and they need a closer look since they are probably
> > >>taking on
> > >> >> >too
> > >> >> >much work and need sub-tasks or should be broken into smaller
> > >>chunks.
> > >> >> >
> > >> >> >rcmed -> data_source (this would also relate to ESG work or
> > >> >>developing an
> > >> >> >interface to OpenDAP moving forward)
> > >> >> >rcmet -> None (just drop this from the OCW issue tracker. RCMET
> is
> > >>a
> > >> >>JPL
> > >> >> >project that is built on OCW)
> > >> >> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle.
> > >> >>Webapp is
> > >> >> >generic enough that we can change to Ember.js and CherryPy if we
> > >>like)
> > >> >> >regridding -> dataset_processor (map to the module that does this
> > >> >> >function)
> > >> >> >visualization -> plotting (map to the module that does this
> > >>function)
> > >> >> >documentation -> NEW Component
> > >> >> >dataset -> NEW Component
> > >> >> >
> > >> >> >A note about rcmet above:
> > >> >> >
> > >> >> >Here are 14 open issues with rcmet as the component and what I
> > >>think a
> > >> >> >reasonable mapping could be:
> > >> >> >
> > >> >> >(general) CLIMATE-261 Consolidate Code that converts a String
> into
> > >>a
> > >> >> >Datetime Object
> > >> >> >(general) CLIMATE-259 Create branch to refactor updates to
> > >> >>ui/services to
> > >> >> >support multiple metrics/plotting
> > >> >> >(documentation) CLIMATE-258 Improve Evaluation documentation
> > >> >> >(dataset) CLIMATE-219 Add name attribute to Dataset
> > >> >> >(metrics) CLIMATE-218 Update metric handling in Evaluation to
> > >>coincide
> > >> >> >with new Metric definition
> > >> >> >(general) CLIMATE-217 Add metrics.py for OCW refactoring
> > >> >> >(general) CLIMATE-214 Add evaluation.py to OCW
> > >> >> >(dataset_processor) CLIMATE-179 Add support for
> > >>Observation/Reference
> > >> >> >option when doing Spatial Regridding
> > >> >> >(general) CLIMATE-137 OCW refactoring code
> > >> >> >(general) CLIMATE-50 RCMET needs to use a logger instead of
> prints
> > >> >> >(general) CLIMATE-49 Add the 'obs' regrid option into
> > >> >> >toolkit.do_data_prep.prep_data function
> > >> >> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class
> > >>needs
> > >> >>to
> > >> >> >be refactored - Not an issue with OCW Dataset Class
> > >> >> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support
> > >> >> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
> > >> >> >
> > >> >> >Thanks for allowing me to bump this thread to top of your inbox.
> > >> >> >
> > >> >> >-Cam
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
> > >> >> >chris.a.mattmann@jpl.nasa.gov> wrote:
> > >> >> >
> > >> >> >> Perfect
> > >> >> >>
> > >> >> >> Sent from my iPhone
> > >> >> >>
> > >> >> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <joyce@apache.org
> >
> > >> >>wrote:
> > >> >> >>
> > >> >> >> > If people need to catch up on the refactoring that's been
> > >>occurring
> > >> >> >>they
> > >> >> >> > can find the original proposal for refactoring at [1]. The
> full
> > >> >>thread
> > >> >> >> > where this was discussed can be found in the mail archives at
> > >>[2].
> > >> >>The
> > >> >> >> wiki
> > >> >> >> > entry that Mazi made detailing proposed package layouts
> > >>(including
> > >> >>the
> > >> >> >> one
> > >> >> >> > we ultimately went with) is available at [3].
> > >> >> >> >
> > >> >> >> > To summate:
> > >> >> >> >
> > >> >> >> > The old code (which was called RCMET) is being refactored into
> > >>the
> > >> >>ocw
> > >> >> >> > package with the intention of making the code base more
> > >> >>maintainable
> > >> >> >>and
> > >> >> >> > the API nice and pretty.
> > >> >> >> >
> > >> >> >> > Hopefully this is sufficiently verbose. I don't have the time
> > >>to go
> > >> >> >>into
> > >> >> >> > more detail at the moment. If anyone is confused feel free to
> > >>ask
> > >> >>away
> > >> >> >> and
> > >> >> >> > I'll try to elaborate later!!
> > >> >> >> >
> > >> >> >> > Thanks
> > >> >> >> > Mike
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > [1]: http://s.apache.org/RKI
> > >> >> >> > [2]:
> > >> >> >> >
> > >> >> >>
> > >> >> >>
> > >> >>
> > >> >>
> > >>
> > >>
> >
> https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mb
> > >> >> >>ox/browser
> > >> >> >> > [3]:
> > >> >> >> >
> > >> >> >>
> > >> >> >>
> > >> >>
> > >> >>
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbenc
> > >> >> >>h+API+summary
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > -- Joyce
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
> > >> >> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
> > >> >> >> >
> > >> >> >> >> Can you detail "the refactoring" so everyone on the list here
> > >> >>knows
> > >> >> >>what
> > >> >> >> >> you are talking about?
> > >> >> >> >>
> > >> >> >> >> A few paragraphs would be great, Mike, thanks.
> > >> >> >> >>
> > >> >> >> >> Cheers,
> > >> >> >> >> Chris
> > >> >> >> >>
> > >> >> >> >>
> > >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >> >> Chris Mattmann, Ph.D.
> > >> >> >> >> Senior Computer Scientist
> > >> >> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > >> >> >> >> Office: 171-266B, Mailstop: 171-246
> > >> >> >> >> Email: chris.a.mattmann@nasa.gov
> > >> >> >> >> WWW: http://sunset.usc.edu/~mattmann/
> > >> >> >> >>
> > >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >> >> Adjunct Assistant Professor, Computer Science Department
> > >> >> >> >> University of Southern California, Los Angeles, CA 90089 USA
> > >> >> >> >>
> > >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >> -----Original Message-----
> > >> >> >> >> From: Michael Joyce <jo...@apache.org>
> > >> >> >> >> Reply-To: "dev@climate.incubator.apache.org"
> > >> >> >> >> <de...@climate.incubator.apache.org>
> > >> >> >> >> Date: Friday, August 16, 2013 10:07 AM
> > >> >> >> >> To: dev <de...@climate.incubator.apache.org>
> > >> >> >> >> Subject: Re: JIRA component names
> > >> >> >> >>
> > >> >> >> >>> The 3 that caught my eye were:
> > >> >> >> >>>
> > >> >> >> >>> rcmet
> > >> >> >> >>> rcmet ui
> > >> >> >> >>> rcmet
> > >> >> >> >>>
> > >> >> >> >>> As to what they should be instead I don't know. 'rcmet ui'
> > >>could
> > >> >> >> easily be
> > >> >> >> >>> 'ocw ui' without loss of clarity. With the refactoring I
> don't
> > >> >>know
> > >> >> >> what
> > >> >> >> >>> we
> > >> >> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs
> > >>to be
> > >> >> >> there at
> > >> >> >> >>> all, so I don't know if we need to think of an alternative.
> > >> >> >> >>>
> > >> >> >> >>>
> > >> >> >> >>>
> > >> >> >> >>> -- Joyce
> > >> >> >> >>>
> > >> >> >> >>>
> > >> >> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
> > >> >> >> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
> > >> >> >> >>>
> > >> >> >> >>>> Can you be more specific and propose e.g., :
> > >> >> >> >>>>
> > >> >> >> >>>> A1->B1
> > >> >> >> >>>> A2->B2
> > >> >> >> >>>> ..
> > >> >> >> >>>>
> > >> >> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is
> the
> > >>new
> > >> >> >> >>>> proposed one?
> > >> >> >> >>>>
> > >> >> >> >>>> Cheers,
> > >> >> >> >>>> Chris
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >> >>>> Chris Mattmann, Ph.D.
> > >> >> >> >>>> Senior Computer Scientist
> > >> >> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > >> >> >> >>>> Office: 171-266B, Mailstop: 171-246
> > >> >> >> >>>> Email: chris.a.mattmann@nasa.gov
> > >> >> >> >>>> WWW: http://sunset.usc.edu/~mattmann/
> > >> >> >> >>>>
> > >> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >> >>>> Adjunct Assistant Professor, Computer Science Department
> > >> >> >> >>>> University of Southern California, Los Angeles, CA 90089
> USA
> > >> >> >> >>>>
> > >> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >> >> >>>> -----Original Message-----
> > >> >> >> >>>> From: Michael Joyce <jo...@apache.org>
> > >> >> >> >>>> Reply-To: "dev@climate.incubator.apache.org"
> > >> >> >> >>>> <de...@climate.incubator.apache.org>
> > >> >> >> >>>> Date: Friday, August 16, 2013 9:31 AM
> > >> >> >> >>>> To: dev <de...@climate.incubator.apache.org>
> > >> >> >> >>>> Subject: JIRA component names
> > >> >> >> >>>>
> > >> >> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric.
> What
> > >> >>does
> > >> >> >> >>>> everyone
> > >> >> >> >>>>> think of switching these over to something more generic?
> > >>Ideas
> > >> >>on
> > >> >> >> >>>> names?
> > >> >> >> >>>>>
> > >> >> >> >>>>> -- Joyce
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >>
> > >> >>
> > >> >>
> > >>
> > >>
> >
> >
>
Re: JIRA component names
Posted by Cameron Goodale <go...@apache.org>.
Hey Team,
I have made the changes to JIRA, and I setup a reminder 6 months from now
to take a quick survey of how the new components are working out.
Thanks for the input on this.
Side Note: My take on the Component Lead is a New JIRA would be assigned
to the Component Lead if an Assignee isn't selected. If that happens it is
the Component Lead's responsibility to review the issue and either do the
work, or re-assign it to the person most capable to work on the issue. If
someone puts an Assignee on an issue, then the Component Lead (or Project
Lead) will not be assigned.
I will start another DISCUSS thread in 6 months, so in the meantime please
take the new components for a spin.
Best Regards,
Cameron
On Tue, Aug 20, 2013 at 1:21 PM, Khudikyan, Shakeh E (398J) <
Shakeh.E.Khudikyan@jpl.nasa.gov> wrote:
> +1
>
> Shakeh
>
>
>
>
> On 8/20/13 11:06 AM, "Cameron Goodale" <go...@apache.org> wrote:
>
> >Here is the current state of component names:
> >
> >Current list we won't change:
> >------------------------------------------
> >build process
> >general
> >metrics
> >visualization
> >website
> >
> >New Components to Add:
> >-----------------------------------------
> >documentation
> >dataset
> >
> >
> >The 4 Contentious Components still being discussed: (with my attempt to
> >please the commenters thus far)
> >--------------------------------------------------------------------------
> >-------
> >rcmed -> data sources
> >rcmet -> analysis
> >rcmet ui -> webapp (this would include ui, middleware, etc...)
> >regridding -> data processing (loosely maps to dataset_processor, but
> >would encompass ensemble, temporal and spatial regrid)
> >
> >I also agree with Mike J. that JIRA has functionality to map components to
> >Component Leads which might be a nice way to help divide up the work, and
> >I
> >feel there is a tension between component labels that are Core Developer
> >Friendly (map to a module of code - dataset_processor) and New User
> >Friendly (map to a set of functionality they understand - regridding). We
> >can always have both, but run the risk of too many options.
> >
> >We can also setup the new components in the list, put them into use and
> >revisit this issue in 6 months and see what components are used and which
> >are not. Call it a "Try and Wait" approach to this.
> >
> >
> >
> >-Cameron
> >
> >
> >
> >
> >On Tue, Aug 20, 2013 at 8:03 AM, Ramirez, Paul M (398J) <
> >paul.m.ramirez@jpl.nasa.gov> wrote:
> >
> >> All,
> >>
> >> Seems to me there is a simple high level web-ui, command line, and API.
> >> Potentially, there is services too but at the moment that would reflect
> >> the services to support the web UI. There should also be something that
> >> links issues to build so we can group together updates to any build
> >> scripts, packaging, and distribution to somewhere like pypi.
> >>
> >> I think if we get too specific then if there are shifts we have to go
> >> change our labels again (imo).
> >>
> >> --Paul
> >>
> >> On 8/20/13 7:42 AM, "Michael Joyce" <jo...@apache.org> wrote:
> >>
> >> >Chris,
> >> >
> >> >1) Regridding is far too specific with regards to what
> >>dataset_processor
> >> >actually does in my opinion. Visualization vs plotting, I like
> >> >visualization better personally.
> >> >
> >> >2) Again, "pipeline" seems too generic. Even "rcmet" is too generic in
> >>my
> >> >opinion. I think it's a sign that something is wrong when the vast
> >> >majority
> >> >of our issues are falling under a single component. Too me that says
> >>that
> >> >we need to break that component into smaller, more specific components.
> >> >(Unless, of course, all the work is actually being done on just one
> >> >specific component).
> >> >
> >> >I think the more important question is, what are we using these labels
> >> >for?
> >> >Are they for accurately describing issues for committers/contributors
> >>or
> >> >are we trying to make it easy for people making JIRAs to label the
> >> >problem?
> >> >Most people who don't actively participate on the project are
> >>(probably)
> >> >going to label their issue as "general" since they have no idea what is
> >> >broken. If that's the case, then our components should be useful for
> >>the
> >> >people on the project and thus specific. We should also exploit
> >>component
> >> >leads so that issues can be filtered to people on the project who are
> >>most
> >> >capable of dealing with/delegating the issue.
> >> >
> >> >TLDR: I like specific, descriptive component names over generic
> >> >catch-alls.
> >> >One generic component is good for people making issues that have no
> >>idea
> >> >what is wrong; These can adjusted once someone has looked at the
> >>problem.
> >> >Let's exploit component leads to make all of our lives easier!
> >> >
> >> >Thoughts?
> >> >
> >> >
> >> >-- Joyce
> >> >
> >> >
> >> >On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) <
> >> >chris.a.mattmann@jpl.nasa.gov> wrote:
> >> >
> >> >> Cam, I am +1 for this remapping, with the caveats:
> >> >>
> >> >> 1. regridding is much more understood in the community than dataset
> >> >> processor.
> >> >> Same goes for viz (compared to plotting). So dunno on those.
> >> >>
> >> >> 2. I can see your point about rcmet, but don't we have a concept of
> >> >> end-to-end
> >> >> regrid->analysis->viz pipeline? Wouldn't something like pipeline or
> >> >>maybe
> >> >> even
> >> >> analysis make more sense than simply having no component? To me some
> >> >> component is
> >> >> better than none.
> >> >>
> >> >> Bump it to the top of my list anytime.
> >> >>
> >> >> Cheers,
> >> >> Chris
> >> >>
> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> Chris Mattmann, Ph.D.
> >> >> Senior Computer Scientist
> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> >> Office: 171-266B, Mailstop: 171-246
> >> >> Email: chris.a.mattmann@nasa.gov
> >> >> WWW: http://sunset.usc.edu/~mattmann/
> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> Adjunct Assistant Professor, Computer Science Department
> >> >> University of Southern California, Los Angeles, CA 90089 USA
> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >> From: Cameron Goodale <go...@apache.org>
> >> >> Reply-To: "dev@climate.incubator.apache.org"
> >> >> <de...@climate.incubator.apache.org>
> >> >> Date: Monday, August 19, 2013 7:21 PM
> >> >> To: "dev@climate.incubator.apache.org"
> >> >><de...@climate.incubator.apache.org>
> >> >> Subject: Re: JIRA component names
> >> >>
> >> >> >Hey Guys,
> >> >> >
> >> >> >I am going to take a crack and the task of mapping A1 -> B1 that
> >>Chris
> >> >> >mentioned since I have been making JIRAs and wishing for some other
> >> >> >components in the list. Since the new OCW refactoring introduces
> >>some
> >> >>new
> >> >> >software modules/components i think it makes sense to align JIRA
> >>issues
> >> >> >with each area of the code. This helps map issues to modules in the
> >> >>code,
> >> >> >items tasks that touch large sweeping parts of the code should go
> >>under
> >> >> >'general' and they need a closer look since they are probably
> >>taking on
> >> >> >too
> >> >> >much work and need sub-tasks or should be broken into smaller
> >>chunks.
> >> >> >
> >> >> >rcmed -> data_source (this would also relate to ESG work or
> >> >>developing an
> >> >> >interface to OpenDAP moving forward)
> >> >> >rcmet -> None (just drop this from the OCW issue tracker. RCMET is
> >>a
> >> >>JPL
> >> >> >project that is built on OCW)
> >> >> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle.
> >> >>Webapp is
> >> >> >generic enough that we can change to Ember.js and CherryPy if we
> >>like)
> >> >> >regridding -> dataset_processor (map to the module that does this
> >> >> >function)
> >> >> >visualization -> plotting (map to the module that does this
> >>function)
> >> >> >documentation -> NEW Component
> >> >> >dataset -> NEW Component
> >> >> >
> >> >> >A note about rcmet above:
> >> >> >
> >> >> >Here are 14 open issues with rcmet as the component and what I
> >>think a
> >> >> >reasonable mapping could be:
> >> >> >
> >> >> >(general) CLIMATE-261 Consolidate Code that converts a String into
> >>a
> >> >> >Datetime Object
> >> >> >(general) CLIMATE-259 Create branch to refactor updates to
> >> >>ui/services to
> >> >> >support multiple metrics/plotting
> >> >> >(documentation) CLIMATE-258 Improve Evaluation documentation
> >> >> >(dataset) CLIMATE-219 Add name attribute to Dataset
> >> >> >(metrics) CLIMATE-218 Update metric handling in Evaluation to
> >>coincide
> >> >> >with new Metric definition
> >> >> >(general) CLIMATE-217 Add metrics.py for OCW refactoring
> >> >> >(general) CLIMATE-214 Add evaluation.py to OCW
> >> >> >(dataset_processor) CLIMATE-179 Add support for
> >>Observation/Reference
> >> >> >option when doing Spatial Regridding
> >> >> >(general) CLIMATE-137 OCW refactoring code
> >> >> >(general) CLIMATE-50 RCMET needs to use a logger instead of prints
> >> >> >(general) CLIMATE-49 Add the 'obs' regrid option into
> >> >> >toolkit.do_data_prep.prep_data function
> >> >> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class
> >>needs
> >> >>to
> >> >> >be refactored - Not an issue with OCW Dataset Class
> >> >> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support
> >> >> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
> >> >> >
> >> >> >Thanks for allowing me to bump this thread to top of your inbox.
> >> >> >
> >> >> >-Cam
> >> >> >
> >> >> >
> >> >> >
> >> >> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
> >> >> >chris.a.mattmann@jpl.nasa.gov> wrote:
> >> >> >
> >> >> >> Perfect
> >> >> >>
> >> >> >> Sent from my iPhone
> >> >> >>
> >> >> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org>
> >> >>wrote:
> >> >> >>
> >> >> >> > If people need to catch up on the refactoring that's been
> >>occurring
> >> >> >>they
> >> >> >> > can find the original proposal for refactoring at [1]. The full
> >> >>thread
> >> >> >> > where this was discussed can be found in the mail archives at
> >>[2].
> >> >>The
> >> >> >> wiki
> >> >> >> > entry that Mazi made detailing proposed package layouts
> >>(including
> >> >>the
> >> >> >> one
> >> >> >> > we ultimately went with) is available at [3].
> >> >> >> >
> >> >> >> > To summate:
> >> >> >> >
> >> >> >> > The old code (which was called RCMET) is being refactored into
> >>the
> >> >>ocw
> >> >> >> > package with the intention of making the code base more
> >> >>maintainable
> >> >> >>and
> >> >> >> > the API nice and pretty.
> >> >> >> >
> >> >> >> > Hopefully this is sufficiently verbose. I don't have the time
> >>to go
> >> >> >>into
> >> >> >> > more detail at the moment. If anyone is confused feel free to
> >>ask
> >> >>away
> >> >> >> and
> >> >> >> > I'll try to elaborate later!!
> >> >> >> >
> >> >> >> > Thanks
> >> >> >> > Mike
> >> >> >> >
> >> >> >> >
> >> >> >> > [1]: http://s.apache.org/RKI
> >> >> >> > [2]:
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
> https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mb
> >> >> >>ox/browser
> >> >> >> > [3]:
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbenc
> >> >> >>h+API+summary
> >> >> >> >
> >> >> >> >
> >> >> >> > -- Joyce
> >> >> >> >
> >> >> >> >
> >> >> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
> >> >> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
> >> >> >> >
> >> >> >> >> Can you detail "the refactoring" so everyone on the list here
> >> >>knows
> >> >> >>what
> >> >> >> >> you are talking about?
> >> >> >> >>
> >> >> >> >> A few paragraphs would be great, Mike, thanks.
> >> >> >> >>
> >> >> >> >> Cheers,
> >> >> >> >> Chris
> >> >> >> >>
> >> >> >> >>
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >> >> Chris Mattmann, Ph.D.
> >> >> >> >> Senior Computer Scientist
> >> >> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> >> >> >> Office: 171-266B, Mailstop: 171-246
> >> >> >> >> Email: chris.a.mattmann@nasa.gov
> >> >> >> >> WWW: http://sunset.usc.edu/~mattmann/
> >> >> >> >>
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >> >> Adjunct Assistant Professor, Computer Science Department
> >> >> >> >> University of Southern California, Los Angeles, CA 90089 USA
> >> >> >> >>
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> -----Original Message-----
> >> >> >> >> From: Michael Joyce <jo...@apache.org>
> >> >> >> >> Reply-To: "dev@climate.incubator.apache.org"
> >> >> >> >> <de...@climate.incubator.apache.org>
> >> >> >> >> Date: Friday, August 16, 2013 10:07 AM
> >> >> >> >> To: dev <de...@climate.incubator.apache.org>
> >> >> >> >> Subject: Re: JIRA component names
> >> >> >> >>
> >> >> >> >>> The 3 that caught my eye were:
> >> >> >> >>>
> >> >> >> >>> rcmet
> >> >> >> >>> rcmet ui
> >> >> >> >>> rcmet
> >> >> >> >>>
> >> >> >> >>> As to what they should be instead I don't know. 'rcmet ui'
> >>could
> >> >> >> easily be
> >> >> >> >>> 'ocw ui' without loss of clarity. With the refactoring I don't
> >> >>know
> >> >> >> what
> >> >> >> >>> we
> >> >> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs
> >>to be
> >> >> >> there at
> >> >> >> >>> all, so I don't know if we need to think of an alternative.
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> -- Joyce
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
> >> >> >> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
> >> >> >> >>>
> >> >> >> >>>> Can you be more specific and propose e.g., :
> >> >> >> >>>>
> >> >> >> >>>> A1->B1
> >> >> >> >>>> A2->B2
> >> >> >> >>>> ..
> >> >> >> >>>>
> >> >> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is the
> >>new
> >> >> >> >>>> proposed one?
> >> >> >> >>>>
> >> >> >> >>>> Cheers,
> >> >> >> >>>> Chris
> >> >> >> >>>>
> >> >> >> >>>>
> >> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >> >>>> Chris Mattmann, Ph.D.
> >> >> >> >>>> Senior Computer Scientist
> >> >> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> >> >> >>>> Office: 171-266B, Mailstop: 171-246
> >> >> >> >>>> Email: chris.a.mattmann@nasa.gov
> >> >> >> >>>> WWW: http://sunset.usc.edu/~mattmann/
> >> >> >> >>>>
> >> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >> >>>> Adjunct Assistant Professor, Computer Science Department
> >> >> >> >>>> University of Southern California, Los Angeles, CA 90089 USA
> >> >> >> >>>>
> >> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>> -----Original Message-----
> >> >> >> >>>> From: Michael Joyce <jo...@apache.org>
> >> >> >> >>>> Reply-To: "dev@climate.incubator.apache.org"
> >> >> >> >>>> <de...@climate.incubator.apache.org>
> >> >> >> >>>> Date: Friday, August 16, 2013 9:31 AM
> >> >> >> >>>> To: dev <de...@climate.incubator.apache.org>
> >> >> >> >>>> Subject: JIRA component names
> >> >> >> >>>>
> >> >> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric. What
> >> >>does
> >> >> >> >>>> everyone
> >> >> >> >>>>> think of switching these over to something more generic?
> >>Ideas
> >> >>on
> >> >> >> >>>> names?
> >> >> >> >>>>>
> >> >> >> >>>>> -- Joyce
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
>
>
Re: JIRA component names
Posted by Michael Joyce <jo...@apache.org>.
+1 Cam. I like everything there.
-- Joyce
On Tue, Aug 20, 2013 at 11:06 AM, Cameron Goodale <go...@apache.org>wrote:
> Here is the current state of component names:
>
> Current list we won't change:
> ------------------------------------------
> build process
> general
> metrics
> visualization
> website
>
> New Components to Add:
> -----------------------------------------
> documentation
> dataset
>
>
> The 4 Contentious Components still being discussed: (with my attempt to
> please the commenters thus far)
>
> ---------------------------------------------------------------------------------
> rcmed -> data sources
> rcmet -> analysis
> rcmet ui -> webapp (this would include ui, middleware, etc...)
> regridding -> data processing (loosely maps to dataset_processor, but
> would encompass ensemble, temporal and spatial regrid)
>
> I also agree with Mike J. that JIRA has functionality to map components to
> Component Leads which might be a nice way to help divide up the work, and I
> feel there is a tension between component labels that are Core Developer
> Friendly (map to a module of code - dataset_processor) and New User
> Friendly (map to a set of functionality they understand - regridding). We
> can always have both, but run the risk of too many options.
>
> We can also setup the new components in the list, put them into use and
> revisit this issue in 6 months and see what components are used and which
> are not. Call it a "Try and Wait" approach to this.
>
>
>
> -Cameron
>
>
>
>
> On Tue, Aug 20, 2013 at 8:03 AM, Ramirez, Paul M (398J) <
> paul.m.ramirez@jpl.nasa.gov> wrote:
>
> > All,
> >
> > Seems to me there is a simple high level web-ui, command line, and API.
> > Potentially, there is services too but at the moment that would reflect
> > the services to support the web UI. There should also be something that
> > links issues to build so we can group together updates to any build
> > scripts, packaging, and distribution to somewhere like pypi.
> >
> > I think if we get too specific then if there are shifts we have to go
> > change our labels again (imo).
> >
> > --Paul
> >
> > On 8/20/13 7:42 AM, "Michael Joyce" <jo...@apache.org> wrote:
> >
> > >Chris,
> > >
> > >1) Regridding is far too specific with regards to what dataset_processor
> > >actually does in my opinion. Visualization vs plotting, I like
> > >visualization better personally.
> > >
> > >2) Again, "pipeline" seems too generic. Even "rcmet" is too generic in
> my
> > >opinion. I think it's a sign that something is wrong when the vast
> > >majority
> > >of our issues are falling under a single component. Too me that says
> that
> > >we need to break that component into smaller, more specific components.
> > >(Unless, of course, all the work is actually being done on just one
> > >specific component).
> > >
> > >I think the more important question is, what are we using these labels
> > >for?
> > >Are they for accurately describing issues for committers/contributors or
> > >are we trying to make it easy for people making JIRAs to label the
> > >problem?
> > >Most people who don't actively participate on the project are (probably)
> > >going to label their issue as "general" since they have no idea what is
> > >broken. If that's the case, then our components should be useful for the
> > >people on the project and thus specific. We should also exploit
> component
> > >leads so that issues can be filtered to people on the project who are
> most
> > >capable of dealing with/delegating the issue.
> > >
> > >TLDR: I like specific, descriptive component names over generic
> > >catch-alls.
> > >One generic component is good for people making issues that have no idea
> > >what is wrong; These can adjusted once someone has looked at the
> problem.
> > >Let's exploit component leads to make all of our lives easier!
> > >
> > >Thoughts?
> > >
> > >
> > >-- Joyce
> > >
> > >
> > >On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) <
> > >chris.a.mattmann@jpl.nasa.gov> wrote:
> > >
> > >> Cam, I am +1 for this remapping, with the caveats:
> > >>
> > >> 1. regridding is much more understood in the community than dataset
> > >> processor.
> > >> Same goes for viz (compared to plotting). So dunno on those.
> > >>
> > >> 2. I can see your point about rcmet, but don't we have a concept of
> > >> end-to-end
> > >> regrid->analysis->viz pipeline? Wouldn't something like pipeline or
> > >>maybe
> > >> even
> > >> analysis make more sense than simply having no component? To me some
> > >> component is
> > >> better than none.
> > >>
> > >> Bump it to the top of my list anytime.
> > >>
> > >> Cheers,
> > >> Chris
> > >>
> > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> Chris Mattmann, Ph.D.
> > >> Senior Computer Scientist
> > >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > >> Office: 171-266B, Mailstop: 171-246
> > >> Email: chris.a.mattmann@nasa.gov
> > >> WWW: http://sunset.usc.edu/~mattmann/
> > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> Adjunct Assistant Professor, Computer Science Department
> > >> University of Southern California, Los Angeles, CA 90089 USA
> > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Cameron Goodale <go...@apache.org>
> > >> Reply-To: "dev@climate.incubator.apache.org"
> > >> <de...@climate.incubator.apache.org>
> > >> Date: Monday, August 19, 2013 7:21 PM
> > >> To: "dev@climate.incubator.apache.org"
> > >><de...@climate.incubator.apache.org>
> > >> Subject: Re: JIRA component names
> > >>
> > >> >Hey Guys,
> > >> >
> > >> >I am going to take a crack and the task of mapping A1 -> B1 that
> Chris
> > >> >mentioned since I have been making JIRAs and wishing for some other
> > >> >components in the list. Since the new OCW refactoring introduces
> some
> > >>new
> > >> >software modules/components i think it makes sense to align JIRA
> issues
> > >> >with each area of the code. This helps map issues to modules in the
> > >>code,
> > >> >items tasks that touch large sweeping parts of the code should go
> under
> > >> >'general' and they need a closer look since they are probably taking
> on
> > >> >too
> > >> >much work and need sub-tasks or should be broken into smaller chunks.
> > >> >
> > >> >rcmed -> data_source (this would also relate to ESG work or
> > >>developing an
> > >> >interface to OpenDAP moving forward)
> > >> >rcmet -> None (just drop this from the OCW issue tracker. RCMET is a
> > >>JPL
> > >> >project that is built on OCW)
> > >> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle.
> > >>Webapp is
> > >> >generic enough that we can change to Ember.js and CherryPy if we
> like)
> > >> >regridding -> dataset_processor (map to the module that does this
> > >> >function)
> > >> >visualization -> plotting (map to the module that does this function)
> > >> >documentation -> NEW Component
> > >> >dataset -> NEW Component
> > >> >
> > >> >A note about rcmet above:
> > >> >
> > >> >Here are 14 open issues with rcmet as the component and what I think
> a
> > >> >reasonable mapping could be:
> > >> >
> > >> >(general) CLIMATE-261 Consolidate Code that converts a String into a
> > >> >Datetime Object
> > >> >(general) CLIMATE-259 Create branch to refactor updates to
> > >>ui/services to
> > >> >support multiple metrics/plotting
> > >> >(documentation) CLIMATE-258 Improve Evaluation documentation
> > >> >(dataset) CLIMATE-219 Add name attribute to Dataset
> > >> >(metrics) CLIMATE-218 Update metric handling in Evaluation to
> coincide
> > >> >with new Metric definition
> > >> >(general) CLIMATE-217 Add metrics.py for OCW refactoring
> > >> >(general) CLIMATE-214 Add evaluation.py to OCW
> > >> >(dataset_processor) CLIMATE-179 Add support for Observation/Reference
> > >> >option when doing Spatial Regridding
> > >> >(general) CLIMATE-137 OCW refactoring code
> > >> >(general) CLIMATE-50 RCMET needs to use a logger instead of prints
> > >> >(general) CLIMATE-49 Add the 'obs' regrid option into
> > >> >toolkit.do_data_prep.prep_data function
> > >> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class
> needs
> > >>to
> > >> >be refactored - Not an issue with OCW Dataset Class
> > >> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support
> > >> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
> > >> >
> > >> >Thanks for allowing me to bump this thread to top of your inbox.
> > >> >
> > >> >-Cam
> > >> >
> > >> >
> > >> >
> > >> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
> > >> >chris.a.mattmann@jpl.nasa.gov> wrote:
> > >> >
> > >> >> Perfect
> > >> >>
> > >> >> Sent from my iPhone
> > >> >>
> > >> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org>
> > >>wrote:
> > >> >>
> > >> >> > If people need to catch up on the refactoring that's been
> occurring
> > >> >>they
> > >> >> > can find the original proposal for refactoring at [1]. The full
> > >>thread
> > >> >> > where this was discussed can be found in the mail archives at
> [2].
> > >>The
> > >> >> wiki
> > >> >> > entry that Mazi made detailing proposed package layouts
> (including
> > >>the
> > >> >> one
> > >> >> > we ultimately went with) is available at [3].
> > >> >> >
> > >> >> > To summate:
> > >> >> >
> > >> >> > The old code (which was called RCMET) is being refactored into
> the
> > >>ocw
> > >> >> > package with the intention of making the code base more
> > >>maintainable
> > >> >>and
> > >> >> > the API nice and pretty.
> > >> >> >
> > >> >> > Hopefully this is sufficiently verbose. I don't have the time to
> go
> > >> >>into
> > >> >> > more detail at the moment. If anyone is confused feel free to ask
> > >>away
> > >> >> and
> > >> >> > I'll try to elaborate later!!
> > >> >> >
> > >> >> > Thanks
> > >> >> > Mike
> > >> >> >
> > >> >> >
> > >> >> > [1]: http://s.apache.org/RKI
> > >> >> > [2]:
> > >> >> >
> > >> >>
> > >> >>
> > >>
> > >>
> >
> https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mb
> > >> >>ox/browser
> > >> >> > [3]:
> > >> >> >
> > >> >>
> > >> >>
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbenc
> > >> >>h+API+summary
> > >> >> >
> > >> >> >
> > >> >> > -- Joyce
> > >> >> >
> > >> >> >
> > >> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
> > >> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
> > >> >> >
> > >> >> >> Can you detail "the refactoring" so everyone on the list here
> > >>knows
> > >> >>what
> > >> >> >> you are talking about?
> > >> >> >>
> > >> >> >> A few paragraphs would be great, Mike, thanks.
> > >> >> >>
> > >> >> >> Cheers,
> > >> >> >> Chris
> > >> >> >>
> > >> >> >>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >> Chris Mattmann, Ph.D.
> > >> >> >> Senior Computer Scientist
> > >> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > >> >> >> Office: 171-266B, Mailstop: 171-246
> > >> >> >> Email: chris.a.mattmann@nasa.gov
> > >> >> >> WWW: http://sunset.usc.edu/~mattmann/
> > >> >> >>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >> Adjunct Assistant Professor, Computer Science Department
> > >> >> >> University of Southern California, Los Angeles, CA 90089 USA
> > >> >> >>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >> -----Original Message-----
> > >> >> >> From: Michael Joyce <jo...@apache.org>
> > >> >> >> Reply-To: "dev@climate.incubator.apache.org"
> > >> >> >> <de...@climate.incubator.apache.org>
> > >> >> >> Date: Friday, August 16, 2013 10:07 AM
> > >> >> >> To: dev <de...@climate.incubator.apache.org>
> > >> >> >> Subject: Re: JIRA component names
> > >> >> >>
> > >> >> >>> The 3 that caught my eye were:
> > >> >> >>>
> > >> >> >>> rcmet
> > >> >> >>> rcmet ui
> > >> >> >>> rcmet
> > >> >> >>>
> > >> >> >>> As to what they should be instead I don't know. 'rcmet ui'
> could
> > >> >> easily be
> > >> >> >>> 'ocw ui' without loss of clarity. With the refactoring I don't
> > >>know
> > >> >> what
> > >> >> >>> we
> > >> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs to
> be
> > >> >> there at
> > >> >> >>> all, so I don't know if we need to think of an alternative.
> > >> >> >>>
> > >> >> >>>
> > >> >> >>>
> > >> >> >>> -- Joyce
> > >> >> >>>
> > >> >> >>>
> > >> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
> > >> >> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
> > >> >> >>>
> > >> >> >>>> Can you be more specific and propose e.g., :
> > >> >> >>>>
> > >> >> >>>> A1->B1
> > >> >> >>>> A2->B2
> > >> >> >>>> ..
> > >> >> >>>>
> > >> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is the
> new
> > >> >> >>>> proposed one?
> > >> >> >>>>
> > >> >> >>>> Cheers,
> > >> >> >>>> Chris
> > >> >> >>>>
> > >> >> >>>>
> > >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >>>> Chris Mattmann, Ph.D.
> > >> >> >>>> Senior Computer Scientist
> > >> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > >> >> >>>> Office: 171-266B, Mailstop: 171-246
> > >> >> >>>> Email: chris.a.mattmann@nasa.gov
> > >> >> >>>> WWW: http://sunset.usc.edu/~mattmann/
> > >> >> >>>>
> > >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >>>> Adjunct Assistant Professor, Computer Science Department
> > >> >> >>>> University of Southern California, Los Angeles, CA 90089 USA
> > >> >> >>>>
> > >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>>> -----Original Message-----
> > >> >> >>>> From: Michael Joyce <jo...@apache.org>
> > >> >> >>>> Reply-To: "dev@climate.incubator.apache.org"
> > >> >> >>>> <de...@climate.incubator.apache.org>
> > >> >> >>>> Date: Friday, August 16, 2013 9:31 AM
> > >> >> >>>> To: dev <de...@climate.incubator.apache.org>
> > >> >> >>>> Subject: JIRA component names
> > >> >> >>>>
> > >> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric. What
> > >>does
> > >> >> >>>> everyone
> > >> >> >>>>> think of switching these over to something more generic?
> Ideas
> > >>on
> > >> >> >>>> names?
> > >> >> >>>>>
> > >> >> >>>>> -- Joyce
> > >> >> >>
> > >> >> >>
> > >> >>
> > >>
> > >>
> >
> >
>
Re: JIRA component names
Posted by "Khudikyan, Shakeh E (398J)" <Sh...@jpl.nasa.gov>.
+1
Shakeh
On 8/20/13 11:06 AM, "Cameron Goodale" <go...@apache.org> wrote:
>Here is the current state of component names:
>
>Current list we won't change:
>------------------------------------------
>build process
>general
>metrics
>visualization
>website
>
>New Components to Add:
>-----------------------------------------
>documentation
>dataset
>
>
>The 4 Contentious Components still being discussed: (with my attempt to
>please the commenters thus far)
>--------------------------------------------------------------------------
>-------
>rcmed -> data sources
>rcmet -> analysis
>rcmet ui -> webapp (this would include ui, middleware, etc...)
>regridding -> data processing (loosely maps to dataset_processor, but
>would encompass ensemble, temporal and spatial regrid)
>
>I also agree with Mike J. that JIRA has functionality to map components to
>Component Leads which might be a nice way to help divide up the work, and
>I
>feel there is a tension between component labels that are Core Developer
>Friendly (map to a module of code - dataset_processor) and New User
>Friendly (map to a set of functionality they understand - regridding). We
>can always have both, but run the risk of too many options.
>
>We can also setup the new components in the list, put them into use and
>revisit this issue in 6 months and see what components are used and which
>are not. Call it a "Try and Wait" approach to this.
>
>
>
>-Cameron
>
>
>
>
>On Tue, Aug 20, 2013 at 8:03 AM, Ramirez, Paul M (398J) <
>paul.m.ramirez@jpl.nasa.gov> wrote:
>
>> All,
>>
>> Seems to me there is a simple high level web-ui, command line, and API.
>> Potentially, there is services too but at the moment that would reflect
>> the services to support the web UI. There should also be something that
>> links issues to build so we can group together updates to any build
>> scripts, packaging, and distribution to somewhere like pypi.
>>
>> I think if we get too specific then if there are shifts we have to go
>> change our labels again (imo).
>>
>> --Paul
>>
>> On 8/20/13 7:42 AM, "Michael Joyce" <jo...@apache.org> wrote:
>>
>> >Chris,
>> >
>> >1) Regridding is far too specific with regards to what
>>dataset_processor
>> >actually does in my opinion. Visualization vs plotting, I like
>> >visualization better personally.
>> >
>> >2) Again, "pipeline" seems too generic. Even "rcmet" is too generic in
>>my
>> >opinion. I think it's a sign that something is wrong when the vast
>> >majority
>> >of our issues are falling under a single component. Too me that says
>>that
>> >we need to break that component into smaller, more specific components.
>> >(Unless, of course, all the work is actually being done on just one
>> >specific component).
>> >
>> >I think the more important question is, what are we using these labels
>> >for?
>> >Are they for accurately describing issues for committers/contributors
>>or
>> >are we trying to make it easy for people making JIRAs to label the
>> >problem?
>> >Most people who don't actively participate on the project are
>>(probably)
>> >going to label their issue as "general" since they have no idea what is
>> >broken. If that's the case, then our components should be useful for
>>the
>> >people on the project and thus specific. We should also exploit
>>component
>> >leads so that issues can be filtered to people on the project who are
>>most
>> >capable of dealing with/delegating the issue.
>> >
>> >TLDR: I like specific, descriptive component names over generic
>> >catch-alls.
>> >One generic component is good for people making issues that have no
>>idea
>> >what is wrong; These can adjusted once someone has looked at the
>>problem.
>> >Let's exploit component leads to make all of our lives easier!
>> >
>> >Thoughts?
>> >
>> >
>> >-- Joyce
>> >
>> >
>> >On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) <
>> >chris.a.mattmann@jpl.nasa.gov> wrote:
>> >
>> >> Cam, I am +1 for this remapping, with the caveats:
>> >>
>> >> 1. regridding is much more understood in the community than dataset
>> >> processor.
>> >> Same goes for viz (compared to plotting). So dunno on those.
>> >>
>> >> 2. I can see your point about rcmet, but don't we have a concept of
>> >> end-to-end
>> >> regrid->analysis->viz pipeline? Wouldn't something like pipeline or
>> >>maybe
>> >> even
>> >> analysis make more sense than simply having no component? To me some
>> >> component is
>> >> better than none.
>> >>
>> >> Bump it to the top of my list anytime.
>> >>
>> >> Cheers,
>> >> Chris
>> >>
>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> Chris Mattmann, Ph.D.
>> >> Senior Computer Scientist
>> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> Office: 171-266B, Mailstop: 171-246
>> >> Email: chris.a.mattmann@nasa.gov
>> >> WWW: http://sunset.usc.edu/~mattmann/
>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> Adjunct Assistant Professor, Computer Science Department
>> >> University of Southern California, Los Angeles, CA 90089 USA
>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Cameron Goodale <go...@apache.org>
>> >> Reply-To: "dev@climate.incubator.apache.org"
>> >> <de...@climate.incubator.apache.org>
>> >> Date: Monday, August 19, 2013 7:21 PM
>> >> To: "dev@climate.incubator.apache.org"
>> >><de...@climate.incubator.apache.org>
>> >> Subject: Re: JIRA component names
>> >>
>> >> >Hey Guys,
>> >> >
>> >> >I am going to take a crack and the task of mapping A1 -> B1 that
>>Chris
>> >> >mentioned since I have been making JIRAs and wishing for some other
>> >> >components in the list. Since the new OCW refactoring introduces
>>some
>> >>new
>> >> >software modules/components i think it makes sense to align JIRA
>>issues
>> >> >with each area of the code. This helps map issues to modules in the
>> >>code,
>> >> >items tasks that touch large sweeping parts of the code should go
>>under
>> >> >'general' and they need a closer look since they are probably
>>taking on
>> >> >too
>> >> >much work and need sub-tasks or should be broken into smaller
>>chunks.
>> >> >
>> >> >rcmed -> data_source (this would also relate to ESG work or
>> >>developing an
>> >> >interface to OpenDAP moving forward)
>> >> >rcmet -> None (just drop this from the OCW issue tracker. RCMET is
>>a
>> >>JPL
>> >> >project that is built on OCW)
>> >> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle.
>> >>Webapp is
>> >> >generic enough that we can change to Ember.js and CherryPy if we
>>like)
>> >> >regridding -> dataset_processor (map to the module that does this
>> >> >function)
>> >> >visualization -> plotting (map to the module that does this
>>function)
>> >> >documentation -> NEW Component
>> >> >dataset -> NEW Component
>> >> >
>> >> >A note about rcmet above:
>> >> >
>> >> >Here are 14 open issues with rcmet as the component and what I
>>think a
>> >> >reasonable mapping could be:
>> >> >
>> >> >(general) CLIMATE-261 Consolidate Code that converts a String into
>>a
>> >> >Datetime Object
>> >> >(general) CLIMATE-259 Create branch to refactor updates to
>> >>ui/services to
>> >> >support multiple metrics/plotting
>> >> >(documentation) CLIMATE-258 Improve Evaluation documentation
>> >> >(dataset) CLIMATE-219 Add name attribute to Dataset
>> >> >(metrics) CLIMATE-218 Update metric handling in Evaluation to
>>coincide
>> >> >with new Metric definition
>> >> >(general) CLIMATE-217 Add metrics.py for OCW refactoring
>> >> >(general) CLIMATE-214 Add evaluation.py to OCW
>> >> >(dataset_processor) CLIMATE-179 Add support for
>>Observation/Reference
>> >> >option when doing Spatial Regridding
>> >> >(general) CLIMATE-137 OCW refactoring code
>> >> >(general) CLIMATE-50 RCMET needs to use a logger instead of prints
>> >> >(general) CLIMATE-49 Add the 'obs' regrid option into
>> >> >toolkit.do_data_prep.prep_data function
>> >> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class
>>needs
>> >>to
>> >> >be refactored - Not an issue with OCW Dataset Class
>> >> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support
>> >> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
>> >> >
>> >> >Thanks for allowing me to bump this thread to top of your inbox.
>> >> >
>> >> >-Cam
>> >> >
>> >> >
>> >> >
>> >> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
>> >> >chris.a.mattmann@jpl.nasa.gov> wrote:
>> >> >
>> >> >> Perfect
>> >> >>
>> >> >> Sent from my iPhone
>> >> >>
>> >> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org>
>> >>wrote:
>> >> >>
>> >> >> > If people need to catch up on the refactoring that's been
>>occurring
>> >> >>they
>> >> >> > can find the original proposal for refactoring at [1]. The full
>> >>thread
>> >> >> > where this was discussed can be found in the mail archives at
>>[2].
>> >>The
>> >> >> wiki
>> >> >> > entry that Mazi made detailing proposed package layouts
>>(including
>> >>the
>> >> >> one
>> >> >> > we ultimately went with) is available at [3].
>> >> >> >
>> >> >> > To summate:
>> >> >> >
>> >> >> > The old code (which was called RCMET) is being refactored into
>>the
>> >>ocw
>> >> >> > package with the intention of making the code base more
>> >>maintainable
>> >> >>and
>> >> >> > the API nice and pretty.
>> >> >> >
>> >> >> > Hopefully this is sufficiently verbose. I don't have the time
>>to go
>> >> >>into
>> >> >> > more detail at the moment. If anyone is confused feel free to
>>ask
>> >>away
>> >> >> and
>> >> >> > I'll try to elaborate later!!
>> >> >> >
>> >> >> > Thanks
>> >> >> > Mike
>> >> >> >
>> >> >> >
>> >> >> > [1]: http://s.apache.org/RKI
>> >> >> > [2]:
>> >> >> >
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mb
>> >> >>ox/browser
>> >> >> > [3]:
>> >> >> >
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbenc
>> >> >>h+API+summary
>> >> >> >
>> >> >> >
>> >> >> > -- Joyce
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
>> >> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
>> >> >> >
>> >> >> >> Can you detail "the refactoring" so everyone on the list here
>> >>knows
>> >> >>what
>> >> >> >> you are talking about?
>> >> >> >>
>> >> >> >> A few paragraphs would be great, Mike, thanks.
>> >> >> >>
>> >> >> >> Cheers,
>> >> >> >> Chris
>> >> >> >>
>> >> >> >>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >> Chris Mattmann, Ph.D.
>> >> >> >> Senior Computer Scientist
>> >> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> >> >> Office: 171-266B, Mailstop: 171-246
>> >> >> >> Email: chris.a.mattmann@nasa.gov
>> >> >> >> WWW: http://sunset.usc.edu/~mattmann/
>> >> >> >>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >> Adjunct Assistant Professor, Computer Science Department
>> >> >> >> University of Southern California, Los Angeles, CA 90089 USA
>> >> >> >>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> -----Original Message-----
>> >> >> >> From: Michael Joyce <jo...@apache.org>
>> >> >> >> Reply-To: "dev@climate.incubator.apache.org"
>> >> >> >> <de...@climate.incubator.apache.org>
>> >> >> >> Date: Friday, August 16, 2013 10:07 AM
>> >> >> >> To: dev <de...@climate.incubator.apache.org>
>> >> >> >> Subject: Re: JIRA component names
>> >> >> >>
>> >> >> >>> The 3 that caught my eye were:
>> >> >> >>>
>> >> >> >>> rcmet
>> >> >> >>> rcmet ui
>> >> >> >>> rcmet
>> >> >> >>>
>> >> >> >>> As to what they should be instead I don't know. 'rcmet ui'
>>could
>> >> >> easily be
>> >> >> >>> 'ocw ui' without loss of clarity. With the refactoring I don't
>> >>know
>> >> >> what
>> >> >> >>> we
>> >> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs
>>to be
>> >> >> there at
>> >> >> >>> all, so I don't know if we need to think of an alternative.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> -- Joyce
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
>> >> >> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
>> >> >> >>>
>> >> >> >>>> Can you be more specific and propose e.g., :
>> >> >> >>>>
>> >> >> >>>> A1->B1
>> >> >> >>>> A2->B2
>> >> >> >>>> ..
>> >> >> >>>>
>> >> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is the
>>new
>> >> >> >>>> proposed one?
>> >> >> >>>>
>> >> >> >>>> Cheers,
>> >> >> >>>> Chris
>> >> >> >>>>
>> >> >> >>>>
>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >>>> Chris Mattmann, Ph.D.
>> >> >> >>>> Senior Computer Scientist
>> >> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> >> >>>> Office: 171-266B, Mailstop: 171-246
>> >> >> >>>> Email: chris.a.mattmann@nasa.gov
>> >> >> >>>> WWW: http://sunset.usc.edu/~mattmann/
>> >> >> >>>>
>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >>>> Adjunct Assistant Professor, Computer Science Department
>> >> >> >>>> University of Southern California, Los Angeles, CA 90089 USA
>> >> >> >>>>
>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> -----Original Message-----
>> >> >> >>>> From: Michael Joyce <jo...@apache.org>
>> >> >> >>>> Reply-To: "dev@climate.incubator.apache.org"
>> >> >> >>>> <de...@climate.incubator.apache.org>
>> >> >> >>>> Date: Friday, August 16, 2013 9:31 AM
>> >> >> >>>> To: dev <de...@climate.incubator.apache.org>
>> >> >> >>>> Subject: JIRA component names
>> >> >> >>>>
>> >> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric. What
>> >>does
>> >> >> >>>> everyone
>> >> >> >>>>> think of switching these over to something more generic?
>>Ideas
>> >>on
>> >> >> >>>> names?
>> >> >> >>>>>
>> >> >> >>>>> -- Joyce
>> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> >>
>>
>>
Re: JIRA component names
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
Yeah in general component leads for me have worked on smaller projects
just for
the auto-assign feature alone -- but in general I am not a huge fan b/c it
tends
to imply to newcomers that components have ownership over them instead of
the entire
code base having shared ownership by the PMC.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: <Ramirez>, "Paul M (398J)" <pa...@jpl.nasa.gov>
Reply-To: "dev@climate.incubator.apache.org"
<de...@climate.incubator.apache.org>
Date: Tuesday, August 20, 2013 11:49 AM
To: "dev@climate.incubator.apache.org" <de...@climate.incubator.apache.org>
Subject: Re: JIRA component names
>
>+1, I'd recommend addition of command line interface (cli).
>
>Here is a stab at component leads too:
>
>Build Process (Mike)
>Metrics (Kyo)
>Viz (Alex)
>Website (Andrew)
>Data Sources (Mazi)
>Analysis (Cameron/Mike)
>Webapp (Andrew/Shakeh/Mike)
>Documentation (Paul - volunteering myself but really this is an all)
>CLI (Mazi)
>
>This somewhat seems aligned with what has already been going on from my
>perspective. Component leads is cool but too many could make a diffused
>team (i.e. Ignoring issues because its someone else's problem). That said,
>+1 to give it a whirl.
>
>
>
>--Paul
>
>
>
>On 8/20/13 11:35 AM, "Mattmann, Chris A (398J)"
><ch...@jpl.nasa.gov> wrote:
>
>>LGTM..
>>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>Chris Mattmann, Ph.D.
>>Senior Computer Scientist
>>NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>Office: 171-266B, Mailstop: 171-246
>>Email: chris.a.mattmann@nasa.gov
>>WWW: http://sunset.usc.edu/~mattmann/
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>Adjunct Assistant Professor, Computer Science Department
>>University of Southern California, Los Angeles, CA 90089 USA
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: Cameron Goodale <go...@apache.org>
>>Reply-To: "dev@climate.incubator.apache.org"
>><de...@climate.incubator.apache.org>
>>Date: Tuesday, August 20, 2013 11:06 AM
>>To: "dev@climate.incubator.apache.org" <de...@climate.incubator.apache.org>
>>Subject: Re: JIRA component names
>>
>>>Here is the current state of component names:
>>>
>>>Current list we won't change:
>>>------------------------------------------
>>>build process
>>>general
>>>metrics
>>>visualization
>>>website
>>>
>>>New Components to Add:
>>>-----------------------------------------
>>>documentation
>>>dataset
>>>
>>>
>>>The 4 Contentious Components still being discussed: (with my attempt to
>>>please the commenters thus far)
>>>------------------------------------------------------------------------
>>>-
>>>-
>>>-------
>>>rcmed -> data sources
>>>rcmet -> analysis
>>>rcmet ui -> webapp (this would include ui, middleware, etc...)
>>>regridding -> data processing (loosely maps to dataset_processor, but
>>>would encompass ensemble, temporal and spatial regrid)
>>>
>>>I also agree with Mike J. that JIRA has functionality to map components
>>>to
>>>Component Leads which might be a nice way to help divide up the work,
>>>and
>>>I
>>>feel there is a tension between component labels that are Core Developer
>>>Friendly (map to a module of code - dataset_processor) and New User
>>>Friendly (map to a set of functionality they understand - regridding).
>>>We
>>>can always have both, but run the risk of too many options.
>>>
>>>We can also setup the new components in the list, put them into use and
>>>revisit this issue in 6 months and see what components are used and
>>>which
>>>are not. Call it a "Try and Wait" approach to this.
>>>
>>>
>>>
>>>-Cameron
>>>
>>>
>>>
>>>
>>>On Tue, Aug 20, 2013 at 8:03 AM, Ramirez, Paul M (398J) <
>>>paul.m.ramirez@jpl.nasa.gov> wrote:
>>>
>>>> All,
>>>>
>>>> Seems to me there is a simple high level web-ui, command line, and
>>>>API.
>>>> Potentially, there is services too but at the moment that would
>>>>reflect
>>>> the services to support the web UI. There should also be something
>>>>that
>>>> links issues to build so we can group together updates to any build
>>>> scripts, packaging, and distribution to somewhere like pypi.
>>>>
>>>> I think if we get too specific then if there are shifts we have to go
>>>> change our labels again (imo).
>>>>
>>>> --Paul
>>>>
>>>> On 8/20/13 7:42 AM, "Michael Joyce" <jo...@apache.org> wrote:
>>>>
>>>> >Chris,
>>>> >
>>>> >1) Regridding is far too specific with regards to what
>>>>dataset_processor
>>>> >actually does in my opinion. Visualization vs plotting, I like
>>>> >visualization better personally.
>>>> >
>>>> >2) Again, "pipeline" seems too generic. Even "rcmet" is too generic
>>>>in
>>>>my
>>>> >opinion. I think it's a sign that something is wrong when the vast
>>>> >majority
>>>> >of our issues are falling under a single component. Too me that says
>>>>that
>>>> >we need to break that component into smaller, more specific
>>>>components.
>>>> >(Unless, of course, all the work is actually being done on just one
>>>> >specific component).
>>>> >
>>>> >I think the more important question is, what are we using these
>>>>labels
>>>> >for?
>>>> >Are they for accurately describing issues for committers/contributors
>>>>or
>>>> >are we trying to make it easy for people making JIRAs to label the
>>>> >problem?
>>>> >Most people who don't actively participate on the project are
>>>>(probably)
>>>> >going to label their issue as "general" since they have no idea what
>>>>is
>>>> >broken. If that's the case, then our components should be useful for
>>>>the
>>>> >people on the project and thus specific. We should also exploit
>>>>component
>>>> >leads so that issues can be filtered to people on the project who are
>>>>most
>>>> >capable of dealing with/delegating the issue.
>>>> >
>>>> >TLDR: I like specific, descriptive component names over generic
>>>> >catch-alls.
>>>> >One generic component is good for people making issues that have no
>>>>idea
>>>> >what is wrong; These can adjusted once someone has looked at the
>>>>problem.
>>>> >Let's exploit component leads to make all of our lives easier!
>>>> >
>>>> >Thoughts?
>>>> >
>>>> >
>>>> >-- Joyce
>>>> >
>>>> >
>>>> >On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) <
>>>> >chris.a.mattmann@jpl.nasa.gov> wrote:
>>>> >
>>>> >> Cam, I am +1 for this remapping, with the caveats:
>>>> >>
>>>> >> 1. regridding is much more understood in the community than dataset
>>>> >> processor.
>>>> >> Same goes for viz (compared to plotting). So dunno on those.
>>>> >>
>>>> >> 2. I can see your point about rcmet, but don't we have a concept of
>>>> >> end-to-end
>>>> >> regrid->analysis->viz pipeline? Wouldn't something like pipeline or
>>>> >>maybe
>>>> >> even
>>>> >> analysis make more sense than simply having no component? To me
>>>>some
>>>> >> component is
>>>> >> better than none.
>>>> >>
>>>> >> Bump it to the top of my list anytime.
>>>> >>
>>>> >> Cheers,
>>>> >> Chris
>>>> >>
>>>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> >> Chris Mattmann, Ph.D.
>>>> >> Senior Computer Scientist
>>>> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>> >> Office: 171-266B, Mailstop: 171-246
>>>> >> Email: chris.a.mattmann@nasa.gov
>>>> >> WWW: http://sunset.usc.edu/~mattmann/
>>>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> >> Adjunct Assistant Professor, Computer Science Department
>>>> >> University of Southern California, Los Angeles, CA 90089 USA
>>>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> -----Original Message-----
>>>> >> From: Cameron Goodale <go...@apache.org>
>>>> >> Reply-To: "dev@climate.incubator.apache.org"
>>>> >> <de...@climate.incubator.apache.org>
>>>> >> Date: Monday, August 19, 2013 7:21 PM
>>>> >> To: "dev@climate.incubator.apache.org"
>>>> >><de...@climate.incubator.apache.org>
>>>> >> Subject: Re: JIRA component names
>>>> >>
>>>> >> >Hey Guys,
>>>> >> >
>>>> >> >I am going to take a crack and the task of mapping A1 -> B1 that
>>>>Chris
>>>> >> >mentioned since I have been making JIRAs and wishing for some
>>>>other
>>>> >> >components in the list. Since the new OCW refactoring introduces
>>>>some
>>>> >>new
>>>> >> >software modules/components i think it makes sense to align JIRA
>>>>issues
>>>> >> >with each area of the code. This helps map issues to modules in
>>>>the
>>>> >>code,
>>>> >> >items tasks that touch large sweeping parts of the code should go
>>>>under
>>>> >> >'general' and they need a closer look since they are probably
>>>>taking on
>>>> >> >too
>>>> >> >much work and need sub-tasks or should be broken into smaller
>>>>chunks.
>>>> >> >
>>>> >> >rcmed -> data_source (this would also relate to ESG work or
>>>> >>developing an
>>>> >> >interface to OpenDAP moving forward)
>>>> >> >rcmet -> None (just drop this from the OCW issue tracker. RCMET
>>>>is
>>>>a
>>>> >>JPL
>>>> >> >project that is built on OCW)
>>>> >> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle.
>>>> >>Webapp is
>>>> >> >generic enough that we can change to Ember.js and CherryPy if we
>>>>like)
>>>> >> >regridding -> dataset_processor (map to the module that does this
>>>> >> >function)
>>>> >> >visualization -> plotting (map to the module that does this
>>>>function)
>>>> >> >documentation -> NEW Component
>>>> >> >dataset -> NEW Component
>>>> >> >
>>>> >> >A note about rcmet above:
>>>> >> >
>>>> >> >Here are 14 open issues with rcmet as the component and what I
>>>>think a
>>>> >> >reasonable mapping could be:
>>>> >> >
>>>> >> >(general) CLIMATE-261 Consolidate Code that converts a String
>>>>into
>>>>a
>>>> >> >Datetime Object
>>>> >> >(general) CLIMATE-259 Create branch to refactor updates to
>>>> >>ui/services to
>>>> >> >support multiple metrics/plotting
>>>> >> >(documentation) CLIMATE-258 Improve Evaluation documentation
>>>> >> >(dataset) CLIMATE-219 Add name attribute to Dataset
>>>> >> >(metrics) CLIMATE-218 Update metric handling in Evaluation to
>>>>coincide
>>>> >> >with new Metric definition
>>>> >> >(general) CLIMATE-217 Add metrics.py for OCW refactoring
>>>> >> >(general) CLIMATE-214 Add evaluation.py to OCW
>>>> >> >(dataset_processor) CLIMATE-179 Add support for
>>>>Observation/Reference
>>>> >> >option when doing Spatial Regridding
>>>> >> >(general) CLIMATE-137 OCW refactoring code
>>>> >> >(general) CLIMATE-50 RCMET needs to use a logger instead of
>>>>prints
>>>> >> >(general) CLIMATE-49 Add the 'obs' regrid option into
>>>> >> >toolkit.do_data_prep.prep_data function
>>>> >> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class
>>>>needs
>>>> >>to
>>>> >> >be refactored - Not an issue with OCW Dataset Class
>>>> >> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support
>>>> >> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
>>>> >> >
>>>> >> >Thanks for allowing me to bump this thread to top of your inbox.
>>>> >> >
>>>> >> >-Cam
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
>>>> >> >chris.a.mattmann@jpl.nasa.gov> wrote:
>>>> >> >
>>>> >> >> Perfect
>>>> >> >>
>>>> >> >> Sent from my iPhone
>>>> >> >>
>>>> >> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org>
>>>> >>wrote:
>>>> >> >>
>>>> >> >> > If people need to catch up on the refactoring that's been
>>>>occurring
>>>> >> >>they
>>>> >> >> > can find the original proposal for refactoring at [1]. The
>>>>full
>>>> >>thread
>>>> >> >> > where this was discussed can be found in the mail archives at
>>>>[2].
>>>> >>The
>>>> >> >> wiki
>>>> >> >> > entry that Mazi made detailing proposed package layouts
>>>>(including
>>>> >>the
>>>> >> >> one
>>>> >> >> > we ultimately went with) is available at [3].
>>>> >> >> >
>>>> >> >> > To summate:
>>>> >> >> >
>>>> >> >> > The old code (which was called RCMET) is being refactored into
>>>>the
>>>> >>ocw
>>>> >> >> > package with the intention of making the code base more
>>>> >>maintainable
>>>> >> >>and
>>>> >> >> > the API nice and pretty.
>>>> >> >> >
>>>> >> >> > Hopefully this is sufficiently verbose. I don't have the time
>>>>to go
>>>> >> >>into
>>>> >> >> > more detail at the moment. If anyone is confused feel free to
>>>>ask
>>>> >>away
>>>> >> >> and
>>>> >> >> > I'll try to elaborate later!!
>>>> >> >> >
>>>> >> >> > Thanks
>>>> >> >> > Mike
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > [1]: http://s.apache.org/RKI
>>>> >> >> > [2]:
>>>> >> >> >
>>>> >> >>
>>>> >> >>
>>>> >>
>>>> >>
>>>>
>>>>https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.
>>>>m
>>>>b
>>>> >> >>ox/browser
>>>> >> >> > [3]:
>>>> >> >> >
>>>> >> >>
>>>> >> >>
>>>> >>
>>>> >>
>>>>
>>>>https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbe
>>>>n
>>>>c
>>>> >> >>h+API+summary
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > -- Joyce
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
>>>> >> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
>>>> >> >> >
>>>> >> >> >> Can you detail "the refactoring" so everyone on the list here
>>>> >>knows
>>>> >> >>what
>>>> >> >> >> you are talking about?
>>>> >> >> >>
>>>> >> >> >> A few paragraphs would be great, Mike, thanks.
>>>> >> >> >>
>>>> >> >> >> Cheers,
>>>> >> >> >> Chris
>>>> >> >> >>
>>>> >> >> >>
>>>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> >> >> >> Chris Mattmann, Ph.D.
>>>> >> >> >> Senior Computer Scientist
>>>> >> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>> >> >> >> Office: 171-266B, Mailstop: 171-246
>>>> >> >> >> Email: chris.a.mattmann@nasa.gov
>>>> >> >> >> WWW: http://sunset.usc.edu/~mattmann/
>>>> >> >> >>
>>>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> >> >> >> Adjunct Assistant Professor, Computer Science Department
>>>> >> >> >> University of Southern California, Los Angeles, CA 90089 USA
>>>> >> >> >>
>>>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >> -----Original Message-----
>>>> >> >> >> From: Michael Joyce <jo...@apache.org>
>>>> >> >> >> Reply-To: "dev@climate.incubator.apache.org"
>>>> >> >> >> <de...@climate.incubator.apache.org>
>>>> >> >> >> Date: Friday, August 16, 2013 10:07 AM
>>>> >> >> >> To: dev <de...@climate.incubator.apache.org>
>>>> >> >> >> Subject: Re: JIRA component names
>>>> >> >> >>
>>>> >> >> >>> The 3 that caught my eye were:
>>>> >> >> >>>
>>>> >> >> >>> rcmet
>>>> >> >> >>> rcmet ui
>>>> >> >> >>> rcmet
>>>> >> >> >>>
>>>> >> >> >>> As to what they should be instead I don't know. 'rcmet ui'
>>>>could
>>>> >> >> easily be
>>>> >> >> >>> 'ocw ui' without loss of clarity. With the refactoring I
>>>>don't
>>>> >>know
>>>> >> >> what
>>>> >> >> >>> we
>>>> >> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs
>>>>to be
>>>> >> >> there at
>>>> >> >> >>> all, so I don't know if we need to think of an alternative.
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>> -- Joyce
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
>>>> >> >> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
>>>> >> >> >>>
>>>> >> >> >>>> Can you be more specific and propose e.g., :
>>>> >> >> >>>>
>>>> >> >> >>>> A1->B1
>>>> >> >> >>>> A2->B2
>>>> >> >> >>>> ..
>>>> >> >> >>>>
>>>> >> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is
>>>>the
>>>>new
>>>> >> >> >>>> proposed one?
>>>> >> >> >>>>
>>>> >> >> >>>> Cheers,
>>>> >> >> >>>> Chris
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> >> >> >>>> Chris Mattmann, Ph.D.
>>>> >> >> >>>> Senior Computer Scientist
>>>> >> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>> >> >> >>>> Office: 171-266B, Mailstop: 171-246
>>>> >> >> >>>> Email: chris.a.mattmann@nasa.gov
>>>> >> >> >>>> WWW: http://sunset.usc.edu/~mattmann/
>>>> >> >> >>>>
>>>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> >> >> >>>> Adjunct Assistant Professor, Computer Science Department
>>>> >> >> >>>> University of Southern California, Los Angeles, CA 90089
>>>>USA
>>>> >> >> >>>>
>>>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>> -----Original Message-----
>>>> >> >> >>>> From: Michael Joyce <jo...@apache.org>
>>>> >> >> >>>> Reply-To: "dev@climate.incubator.apache.org"
>>>> >> >> >>>> <de...@climate.incubator.apache.org>
>>>> >> >> >>>> Date: Friday, August 16, 2013 9:31 AM
>>>> >> >> >>>> To: dev <de...@climate.incubator.apache.org>
>>>> >> >> >>>> Subject: JIRA component names
>>>> >> >> >>>>
>>>> >> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric.
>>>>What
>>>> >>does
>>>> >> >> >>>> everyone
>>>> >> >> >>>>> think of switching these over to something more generic?
>>>>Ideas
>>>> >>on
>>>> >> >> >>>> names?
>>>> >> >> >>>>>
>>>> >> >> >>>>> -- Joyce
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >>
>>>> >>
>>>> >>
>>>>
>>>>
>>
>
Re: JIRA component names
Posted by "Ramirez, Paul M (398J)" <pa...@jpl.nasa.gov>.
+1, I'd recommend addition of command line interface (cli).
Here is a stab at component leads too:
Build Process (Mike)
Metrics (Kyo)
Viz (Alex)
Website (Andrew)
Data Sources (Mazi)
Analysis (Cameron/Mike)
Webapp (Andrew/Shakeh/Mike)
Documentation (Paul - volunteering myself but really this is an all)
CLI (Mazi)
This somewhat seems aligned with what has already been going on from my
perspective. Component leads is cool but too many could make a diffused
team (i.e. Ignoring issues because its someone else's problem). That said,
+1 to give it a whirl.
--Paul
On 8/20/13 11:35 AM, "Mattmann, Chris A (398J)"
<ch...@jpl.nasa.gov> wrote:
>LGTM..
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Chris Mattmann, Ph.D.
>Senior Computer Scientist
>NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>Office: 171-266B, Mailstop: 171-246
>Email: chris.a.mattmann@nasa.gov
>WWW: http://sunset.usc.edu/~mattmann/
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Adjunct Assistant Professor, Computer Science Department
>University of Southern California, Los Angeles, CA 90089 USA
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
>
>-----Original Message-----
>From: Cameron Goodale <go...@apache.org>
>Reply-To: "dev@climate.incubator.apache.org"
><de...@climate.incubator.apache.org>
>Date: Tuesday, August 20, 2013 11:06 AM
>To: "dev@climate.incubator.apache.org" <de...@climate.incubator.apache.org>
>Subject: Re: JIRA component names
>
>>Here is the current state of component names:
>>
>>Current list we won't change:
>>------------------------------------------
>>build process
>>general
>>metrics
>>visualization
>>website
>>
>>New Components to Add:
>>-----------------------------------------
>>documentation
>>dataset
>>
>>
>>The 4 Contentious Components still being discussed: (with my attempt to
>>please the commenters thus far)
>>-------------------------------------------------------------------------
>>-
>>-------
>>rcmed -> data sources
>>rcmet -> analysis
>>rcmet ui -> webapp (this would include ui, middleware, etc...)
>>regridding -> data processing (loosely maps to dataset_processor, but
>>would encompass ensemble, temporal and spatial regrid)
>>
>>I also agree with Mike J. that JIRA has functionality to map components
>>to
>>Component Leads which might be a nice way to help divide up the work, and
>>I
>>feel there is a tension between component labels that are Core Developer
>>Friendly (map to a module of code - dataset_processor) and New User
>>Friendly (map to a set of functionality they understand - regridding).
>>We
>>can always have both, but run the risk of too many options.
>>
>>We can also setup the new components in the list, put them into use and
>>revisit this issue in 6 months and see what components are used and which
>>are not. Call it a "Try and Wait" approach to this.
>>
>>
>>
>>-Cameron
>>
>>
>>
>>
>>On Tue, Aug 20, 2013 at 8:03 AM, Ramirez, Paul M (398J) <
>>paul.m.ramirez@jpl.nasa.gov> wrote:
>>
>>> All,
>>>
>>> Seems to me there is a simple high level web-ui, command line, and API.
>>> Potentially, there is services too but at the moment that would reflect
>>> the services to support the web UI. There should also be something that
>>> links issues to build so we can group together updates to any build
>>> scripts, packaging, and distribution to somewhere like pypi.
>>>
>>> I think if we get too specific then if there are shifts we have to go
>>> change our labels again (imo).
>>>
>>> --Paul
>>>
>>> On 8/20/13 7:42 AM, "Michael Joyce" <jo...@apache.org> wrote:
>>>
>>> >Chris,
>>> >
>>> >1) Regridding is far too specific with regards to what
>>>dataset_processor
>>> >actually does in my opinion. Visualization vs plotting, I like
>>> >visualization better personally.
>>> >
>>> >2) Again, "pipeline" seems too generic. Even "rcmet" is too generic in
>>>my
>>> >opinion. I think it's a sign that something is wrong when the vast
>>> >majority
>>> >of our issues are falling under a single component. Too me that says
>>>that
>>> >we need to break that component into smaller, more specific
>>>components.
>>> >(Unless, of course, all the work is actually being done on just one
>>> >specific component).
>>> >
>>> >I think the more important question is, what are we using these labels
>>> >for?
>>> >Are they for accurately describing issues for committers/contributors
>>>or
>>> >are we trying to make it easy for people making JIRAs to label the
>>> >problem?
>>> >Most people who don't actively participate on the project are
>>>(probably)
>>> >going to label their issue as "general" since they have no idea what
>>>is
>>> >broken. If that's the case, then our components should be useful for
>>>the
>>> >people on the project and thus specific. We should also exploit
>>>component
>>> >leads so that issues can be filtered to people on the project who are
>>>most
>>> >capable of dealing with/delegating the issue.
>>> >
>>> >TLDR: I like specific, descriptive component names over generic
>>> >catch-alls.
>>> >One generic component is good for people making issues that have no
>>>idea
>>> >what is wrong; These can adjusted once someone has looked at the
>>>problem.
>>> >Let's exploit component leads to make all of our lives easier!
>>> >
>>> >Thoughts?
>>> >
>>> >
>>> >-- Joyce
>>> >
>>> >
>>> >On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) <
>>> >chris.a.mattmann@jpl.nasa.gov> wrote:
>>> >
>>> >> Cam, I am +1 for this remapping, with the caveats:
>>> >>
>>> >> 1. regridding is much more understood in the community than dataset
>>> >> processor.
>>> >> Same goes for viz (compared to plotting). So dunno on those.
>>> >>
>>> >> 2. I can see your point about rcmet, but don't we have a concept of
>>> >> end-to-end
>>> >> regrid->analysis->viz pipeline? Wouldn't something like pipeline or
>>> >>maybe
>>> >> even
>>> >> analysis make more sense than simply having no component? To me some
>>> >> component is
>>> >> better than none.
>>> >>
>>> >> Bump it to the top of my list anytime.
>>> >>
>>> >> Cheers,
>>> >> Chris
>>> >>
>>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> >> Chris Mattmann, Ph.D.
>>> >> Senior Computer Scientist
>>> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>> >> Office: 171-266B, Mailstop: 171-246
>>> >> Email: chris.a.mattmann@nasa.gov
>>> >> WWW: http://sunset.usc.edu/~mattmann/
>>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> >> Adjunct Assistant Professor, Computer Science Department
>>> >> University of Southern California, Los Angeles, CA 90089 USA
>>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Cameron Goodale <go...@apache.org>
>>> >> Reply-To: "dev@climate.incubator.apache.org"
>>> >> <de...@climate.incubator.apache.org>
>>> >> Date: Monday, August 19, 2013 7:21 PM
>>> >> To: "dev@climate.incubator.apache.org"
>>> >><de...@climate.incubator.apache.org>
>>> >> Subject: Re: JIRA component names
>>> >>
>>> >> >Hey Guys,
>>> >> >
>>> >> >I am going to take a crack and the task of mapping A1 -> B1 that
>>>Chris
>>> >> >mentioned since I have been making JIRAs and wishing for some other
>>> >> >components in the list. Since the new OCW refactoring introduces
>>>some
>>> >>new
>>> >> >software modules/components i think it makes sense to align JIRA
>>>issues
>>> >> >with each area of the code. This helps map issues to modules in
>>>the
>>> >>code,
>>> >> >items tasks that touch large sweeping parts of the code should go
>>>under
>>> >> >'general' and they need a closer look since they are probably
>>>taking on
>>> >> >too
>>> >> >much work and need sub-tasks or should be broken into smaller
>>>chunks.
>>> >> >
>>> >> >rcmed -> data_source (this would also relate to ESG work or
>>> >>developing an
>>> >> >interface to OpenDAP moving forward)
>>> >> >rcmet -> None (just drop this from the OCW issue tracker. RCMET is
>>>a
>>> >>JPL
>>> >> >project that is built on OCW)
>>> >> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle.
>>> >>Webapp is
>>> >> >generic enough that we can change to Ember.js and CherryPy if we
>>>like)
>>> >> >regridding -> dataset_processor (map to the module that does this
>>> >> >function)
>>> >> >visualization -> plotting (map to the module that does this
>>>function)
>>> >> >documentation -> NEW Component
>>> >> >dataset -> NEW Component
>>> >> >
>>> >> >A note about rcmet above:
>>> >> >
>>> >> >Here are 14 open issues with rcmet as the component and what I
>>>think a
>>> >> >reasonable mapping could be:
>>> >> >
>>> >> >(general) CLIMATE-261 Consolidate Code that converts a String into
>>>a
>>> >> >Datetime Object
>>> >> >(general) CLIMATE-259 Create branch to refactor updates to
>>> >>ui/services to
>>> >> >support multiple metrics/plotting
>>> >> >(documentation) CLIMATE-258 Improve Evaluation documentation
>>> >> >(dataset) CLIMATE-219 Add name attribute to Dataset
>>> >> >(metrics) CLIMATE-218 Update metric handling in Evaluation to
>>>coincide
>>> >> >with new Metric definition
>>> >> >(general) CLIMATE-217 Add metrics.py for OCW refactoring
>>> >> >(general) CLIMATE-214 Add evaluation.py to OCW
>>> >> >(dataset_processor) CLIMATE-179 Add support for
>>>Observation/Reference
>>> >> >option when doing Spatial Regridding
>>> >> >(general) CLIMATE-137 OCW refactoring code
>>> >> >(general) CLIMATE-50 RCMET needs to use a logger instead of prints
>>> >> >(general) CLIMATE-49 Add the 'obs' regrid option into
>>> >> >toolkit.do_data_prep.prep_data function
>>> >> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class
>>>needs
>>> >>to
>>> >> >be refactored - Not an issue with OCW Dataset Class
>>> >> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support
>>> >> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
>>> >> >
>>> >> >Thanks for allowing me to bump this thread to top of your inbox.
>>> >> >
>>> >> >-Cam
>>> >> >
>>> >> >
>>> >> >
>>> >> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
>>> >> >chris.a.mattmann@jpl.nasa.gov> wrote:
>>> >> >
>>> >> >> Perfect
>>> >> >>
>>> >> >> Sent from my iPhone
>>> >> >>
>>> >> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org>
>>> >>wrote:
>>> >> >>
>>> >> >> > If people need to catch up on the refactoring that's been
>>>occurring
>>> >> >>they
>>> >> >> > can find the original proposal for refactoring at [1]. The full
>>> >>thread
>>> >> >> > where this was discussed can be found in the mail archives at
>>>[2].
>>> >>The
>>> >> >> wiki
>>> >> >> > entry that Mazi made detailing proposed package layouts
>>>(including
>>> >>the
>>> >> >> one
>>> >> >> > we ultimately went with) is available at [3].
>>> >> >> >
>>> >> >> > To summate:
>>> >> >> >
>>> >> >> > The old code (which was called RCMET) is being refactored into
>>>the
>>> >>ocw
>>> >> >> > package with the intention of making the code base more
>>> >>maintainable
>>> >> >>and
>>> >> >> > the API nice and pretty.
>>> >> >> >
>>> >> >> > Hopefully this is sufficiently verbose. I don't have the time
>>>to go
>>> >> >>into
>>> >> >> > more detail at the moment. If anyone is confused feel free to
>>>ask
>>> >>away
>>> >> >> and
>>> >> >> > I'll try to elaborate later!!
>>> >> >> >
>>> >> >> > Thanks
>>> >> >> > Mike
>>> >> >> >
>>> >> >> >
>>> >> >> > [1]: http://s.apache.org/RKI
>>> >> >> > [2]:
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >>
>>> >>
>>>
>>>https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.m
>>>b
>>> >> >>ox/browser
>>> >> >> > [3]:
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >>
>>> >>
>>>
>>>https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workben
>>>c
>>> >> >>h+API+summary
>>> >> >> >
>>> >> >> >
>>> >> >> > -- Joyce
>>> >> >> >
>>> >> >> >
>>> >> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
>>> >> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
>>> >> >> >
>>> >> >> >> Can you detail "the refactoring" so everyone on the list here
>>> >>knows
>>> >> >>what
>>> >> >> >> you are talking about?
>>> >> >> >>
>>> >> >> >> A few paragraphs would be great, Mike, thanks.
>>> >> >> >>
>>> >> >> >> Cheers,
>>> >> >> >> Chris
>>> >> >> >>
>>> >> >> >>
>>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> >> >> >> Chris Mattmann, Ph.D.
>>> >> >> >> Senior Computer Scientist
>>> >> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>> >> >> >> Office: 171-266B, Mailstop: 171-246
>>> >> >> >> Email: chris.a.mattmann@nasa.gov
>>> >> >> >> WWW: http://sunset.usc.edu/~mattmann/
>>> >> >> >>
>>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> >> >> >> Adjunct Assistant Professor, Computer Science Department
>>> >> >> >> University of Southern California, Los Angeles, CA 90089 USA
>>> >> >> >>
>>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> -----Original Message-----
>>> >> >> >> From: Michael Joyce <jo...@apache.org>
>>> >> >> >> Reply-To: "dev@climate.incubator.apache.org"
>>> >> >> >> <de...@climate.incubator.apache.org>
>>> >> >> >> Date: Friday, August 16, 2013 10:07 AM
>>> >> >> >> To: dev <de...@climate.incubator.apache.org>
>>> >> >> >> Subject: Re: JIRA component names
>>> >> >> >>
>>> >> >> >>> The 3 that caught my eye were:
>>> >> >> >>>
>>> >> >> >>> rcmet
>>> >> >> >>> rcmet ui
>>> >> >> >>> rcmet
>>> >> >> >>>
>>> >> >> >>> As to what they should be instead I don't know. 'rcmet ui'
>>>could
>>> >> >> easily be
>>> >> >> >>> 'ocw ui' without loss of clarity. With the refactoring I
>>>don't
>>> >>know
>>> >> >> what
>>> >> >> >>> we
>>> >> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs
>>>to be
>>> >> >> there at
>>> >> >> >>> all, so I don't know if we need to think of an alternative.
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> -- Joyce
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
>>> >> >> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
>>> >> >> >>>
>>> >> >> >>>> Can you be more specific and propose e.g., :
>>> >> >> >>>>
>>> >> >> >>>> A1->B1
>>> >> >> >>>> A2->B2
>>> >> >> >>>> ..
>>> >> >> >>>>
>>> >> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is the
>>>new
>>> >> >> >>>> proposed one?
>>> >> >> >>>>
>>> >> >> >>>> Cheers,
>>> >> >> >>>> Chris
>>> >> >> >>>>
>>> >> >> >>>>
>>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> >> >> >>>> Chris Mattmann, Ph.D.
>>> >> >> >>>> Senior Computer Scientist
>>> >> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>> >> >> >>>> Office: 171-266B, Mailstop: 171-246
>>> >> >> >>>> Email: chris.a.mattmann@nasa.gov
>>> >> >> >>>> WWW: http://sunset.usc.edu/~mattmann/
>>> >> >> >>>>
>>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> >> >> >>>> Adjunct Assistant Professor, Computer Science Department
>>> >> >> >>>> University of Southern California, Los Angeles, CA 90089 USA
>>> >> >> >>>>
>>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>>> -----Original Message-----
>>> >> >> >>>> From: Michael Joyce <jo...@apache.org>
>>> >> >> >>>> Reply-To: "dev@climate.incubator.apache.org"
>>> >> >> >>>> <de...@climate.incubator.apache.org>
>>> >> >> >>>> Date: Friday, August 16, 2013 9:31 AM
>>> >> >> >>>> To: dev <de...@climate.incubator.apache.org>
>>> >> >> >>>> Subject: JIRA component names
>>> >> >> >>>>
>>> >> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric.
>>>What
>>> >>does
>>> >> >> >>>> everyone
>>> >> >> >>>>> think of switching these over to something more generic?
>>>Ideas
>>> >>on
>>> >> >> >>>> names?
>>> >> >> >>>>>
>>> >> >> >>>>> -- Joyce
>>> >> >> >>
>>> >> >> >>
>>> >> >>
>>> >>
>>> >>
>>>
>>>
>
Re: JIRA component names
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
LGTM..
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Cameron Goodale <go...@apache.org>
Reply-To: "dev@climate.incubator.apache.org"
<de...@climate.incubator.apache.org>
Date: Tuesday, August 20, 2013 11:06 AM
To: "dev@climate.incubator.apache.org" <de...@climate.incubator.apache.org>
Subject: Re: JIRA component names
>Here is the current state of component names:
>
>Current list we won't change:
>------------------------------------------
>build process
>general
>metrics
>visualization
>website
>
>New Components to Add:
>-----------------------------------------
>documentation
>dataset
>
>
>The 4 Contentious Components still being discussed: (with my attempt to
>please the commenters thus far)
>--------------------------------------------------------------------------
>-------
>rcmed -> data sources
>rcmet -> analysis
>rcmet ui -> webapp (this would include ui, middleware, etc...)
>regridding -> data processing (loosely maps to dataset_processor, but
>would encompass ensemble, temporal and spatial regrid)
>
>I also agree with Mike J. that JIRA has functionality to map components to
>Component Leads which might be a nice way to help divide up the work, and
>I
>feel there is a tension between component labels that are Core Developer
>Friendly (map to a module of code - dataset_processor) and New User
>Friendly (map to a set of functionality they understand - regridding). We
>can always have both, but run the risk of too many options.
>
>We can also setup the new components in the list, put them into use and
>revisit this issue in 6 months and see what components are used and which
>are not. Call it a "Try and Wait" approach to this.
>
>
>
>-Cameron
>
>
>
>
>On Tue, Aug 20, 2013 at 8:03 AM, Ramirez, Paul M (398J) <
>paul.m.ramirez@jpl.nasa.gov> wrote:
>
>> All,
>>
>> Seems to me there is a simple high level web-ui, command line, and API.
>> Potentially, there is services too but at the moment that would reflect
>> the services to support the web UI. There should also be something that
>> links issues to build so we can group together updates to any build
>> scripts, packaging, and distribution to somewhere like pypi.
>>
>> I think if we get too specific then if there are shifts we have to go
>> change our labels again (imo).
>>
>> --Paul
>>
>> On 8/20/13 7:42 AM, "Michael Joyce" <jo...@apache.org> wrote:
>>
>> >Chris,
>> >
>> >1) Regridding is far too specific with regards to what
>>dataset_processor
>> >actually does in my opinion. Visualization vs plotting, I like
>> >visualization better personally.
>> >
>> >2) Again, "pipeline" seems too generic. Even "rcmet" is too generic in
>>my
>> >opinion. I think it's a sign that something is wrong when the vast
>> >majority
>> >of our issues are falling under a single component. Too me that says
>>that
>> >we need to break that component into smaller, more specific components.
>> >(Unless, of course, all the work is actually being done on just one
>> >specific component).
>> >
>> >I think the more important question is, what are we using these labels
>> >for?
>> >Are they for accurately describing issues for committers/contributors
>>or
>> >are we trying to make it easy for people making JIRAs to label the
>> >problem?
>> >Most people who don't actively participate on the project are
>>(probably)
>> >going to label their issue as "general" since they have no idea what is
>> >broken. If that's the case, then our components should be useful for
>>the
>> >people on the project and thus specific. We should also exploit
>>component
>> >leads so that issues can be filtered to people on the project who are
>>most
>> >capable of dealing with/delegating the issue.
>> >
>> >TLDR: I like specific, descriptive component names over generic
>> >catch-alls.
>> >One generic component is good for people making issues that have no
>>idea
>> >what is wrong; These can adjusted once someone has looked at the
>>problem.
>> >Let's exploit component leads to make all of our lives easier!
>> >
>> >Thoughts?
>> >
>> >
>> >-- Joyce
>> >
>> >
>> >On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) <
>> >chris.a.mattmann@jpl.nasa.gov> wrote:
>> >
>> >> Cam, I am +1 for this remapping, with the caveats:
>> >>
>> >> 1. regridding is much more understood in the community than dataset
>> >> processor.
>> >> Same goes for viz (compared to plotting). So dunno on those.
>> >>
>> >> 2. I can see your point about rcmet, but don't we have a concept of
>> >> end-to-end
>> >> regrid->analysis->viz pipeline? Wouldn't something like pipeline or
>> >>maybe
>> >> even
>> >> analysis make more sense than simply having no component? To me some
>> >> component is
>> >> better than none.
>> >>
>> >> Bump it to the top of my list anytime.
>> >>
>> >> Cheers,
>> >> Chris
>> >>
>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> Chris Mattmann, Ph.D.
>> >> Senior Computer Scientist
>> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> Office: 171-266B, Mailstop: 171-246
>> >> Email: chris.a.mattmann@nasa.gov
>> >> WWW: http://sunset.usc.edu/~mattmann/
>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> Adjunct Assistant Professor, Computer Science Department
>> >> University of Southern California, Los Angeles, CA 90089 USA
>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Cameron Goodale <go...@apache.org>
>> >> Reply-To: "dev@climate.incubator.apache.org"
>> >> <de...@climate.incubator.apache.org>
>> >> Date: Monday, August 19, 2013 7:21 PM
>> >> To: "dev@climate.incubator.apache.org"
>> >><de...@climate.incubator.apache.org>
>> >> Subject: Re: JIRA component names
>> >>
>> >> >Hey Guys,
>> >> >
>> >> >I am going to take a crack and the task of mapping A1 -> B1 that
>>Chris
>> >> >mentioned since I have been making JIRAs and wishing for some other
>> >> >components in the list. Since the new OCW refactoring introduces
>>some
>> >>new
>> >> >software modules/components i think it makes sense to align JIRA
>>issues
>> >> >with each area of the code. This helps map issues to modules in the
>> >>code,
>> >> >items tasks that touch large sweeping parts of the code should go
>>under
>> >> >'general' and they need a closer look since they are probably
>>taking on
>> >> >too
>> >> >much work and need sub-tasks or should be broken into smaller
>>chunks.
>> >> >
>> >> >rcmed -> data_source (this would also relate to ESG work or
>> >>developing an
>> >> >interface to OpenDAP moving forward)
>> >> >rcmet -> None (just drop this from the OCW issue tracker. RCMET is
>>a
>> >>JPL
>> >> >project that is built on OCW)
>> >> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle.
>> >>Webapp is
>> >> >generic enough that we can change to Ember.js and CherryPy if we
>>like)
>> >> >regridding -> dataset_processor (map to the module that does this
>> >> >function)
>> >> >visualization -> plotting (map to the module that does this
>>function)
>> >> >documentation -> NEW Component
>> >> >dataset -> NEW Component
>> >> >
>> >> >A note about rcmet above:
>> >> >
>> >> >Here are 14 open issues with rcmet as the component and what I
>>think a
>> >> >reasonable mapping could be:
>> >> >
>> >> >(general) CLIMATE-261 Consolidate Code that converts a String into
>>a
>> >> >Datetime Object
>> >> >(general) CLIMATE-259 Create branch to refactor updates to
>> >>ui/services to
>> >> >support multiple metrics/plotting
>> >> >(documentation) CLIMATE-258 Improve Evaluation documentation
>> >> >(dataset) CLIMATE-219 Add name attribute to Dataset
>> >> >(metrics) CLIMATE-218 Update metric handling in Evaluation to
>>coincide
>> >> >with new Metric definition
>> >> >(general) CLIMATE-217 Add metrics.py for OCW refactoring
>> >> >(general) CLIMATE-214 Add evaluation.py to OCW
>> >> >(dataset_processor) CLIMATE-179 Add support for
>>Observation/Reference
>> >> >option when doing Spatial Regridding
>> >> >(general) CLIMATE-137 OCW refactoring code
>> >> >(general) CLIMATE-50 RCMET needs to use a logger instead of prints
>> >> >(general) CLIMATE-49 Add the 'obs' regrid option into
>> >> >toolkit.do_data_prep.prep_data function
>> >> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class
>>needs
>> >>to
>> >> >be refactored - Not an issue with OCW Dataset Class
>> >> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support
>> >> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
>> >> >
>> >> >Thanks for allowing me to bump this thread to top of your inbox.
>> >> >
>> >> >-Cam
>> >> >
>> >> >
>> >> >
>> >> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
>> >> >chris.a.mattmann@jpl.nasa.gov> wrote:
>> >> >
>> >> >> Perfect
>> >> >>
>> >> >> Sent from my iPhone
>> >> >>
>> >> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org>
>> >>wrote:
>> >> >>
>> >> >> > If people need to catch up on the refactoring that's been
>>occurring
>> >> >>they
>> >> >> > can find the original proposal for refactoring at [1]. The full
>> >>thread
>> >> >> > where this was discussed can be found in the mail archives at
>>[2].
>> >>The
>> >> >> wiki
>> >> >> > entry that Mazi made detailing proposed package layouts
>>(including
>> >>the
>> >> >> one
>> >> >> > we ultimately went with) is available at [3].
>> >> >> >
>> >> >> > To summate:
>> >> >> >
>> >> >> > The old code (which was called RCMET) is being refactored into
>>the
>> >>ocw
>> >> >> > package with the intention of making the code base more
>> >>maintainable
>> >> >>and
>> >> >> > the API nice and pretty.
>> >> >> >
>> >> >> > Hopefully this is sufficiently verbose. I don't have the time
>>to go
>> >> >>into
>> >> >> > more detail at the moment. If anyone is confused feel free to
>>ask
>> >>away
>> >> >> and
>> >> >> > I'll try to elaborate later!!
>> >> >> >
>> >> >> > Thanks
>> >> >> > Mike
>> >> >> >
>> >> >> >
>> >> >> > [1]: http://s.apache.org/RKI
>> >> >> > [2]:
>> >> >> >
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mb
>> >> >>ox/browser
>> >> >> > [3]:
>> >> >> >
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbenc
>> >> >>h+API+summary
>> >> >> >
>> >> >> >
>> >> >> > -- Joyce
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
>> >> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
>> >> >> >
>> >> >> >> Can you detail "the refactoring" so everyone on the list here
>> >>knows
>> >> >>what
>> >> >> >> you are talking about?
>> >> >> >>
>> >> >> >> A few paragraphs would be great, Mike, thanks.
>> >> >> >>
>> >> >> >> Cheers,
>> >> >> >> Chris
>> >> >> >>
>> >> >> >>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >> Chris Mattmann, Ph.D.
>> >> >> >> Senior Computer Scientist
>> >> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> >> >> Office: 171-266B, Mailstop: 171-246
>> >> >> >> Email: chris.a.mattmann@nasa.gov
>> >> >> >> WWW: http://sunset.usc.edu/~mattmann/
>> >> >> >>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >> Adjunct Assistant Professor, Computer Science Department
>> >> >> >> University of Southern California, Los Angeles, CA 90089 USA
>> >> >> >>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> -----Original Message-----
>> >> >> >> From: Michael Joyce <jo...@apache.org>
>> >> >> >> Reply-To: "dev@climate.incubator.apache.org"
>> >> >> >> <de...@climate.incubator.apache.org>
>> >> >> >> Date: Friday, August 16, 2013 10:07 AM
>> >> >> >> To: dev <de...@climate.incubator.apache.org>
>> >> >> >> Subject: Re: JIRA component names
>> >> >> >>
>> >> >> >>> The 3 that caught my eye were:
>> >> >> >>>
>> >> >> >>> rcmet
>> >> >> >>> rcmet ui
>> >> >> >>> rcmet
>> >> >> >>>
>> >> >> >>> As to what they should be instead I don't know. 'rcmet ui'
>>could
>> >> >> easily be
>> >> >> >>> 'ocw ui' without loss of clarity. With the refactoring I don't
>> >>know
>> >> >> what
>> >> >> >>> we
>> >> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs
>>to be
>> >> >> there at
>> >> >> >>> all, so I don't know if we need to think of an alternative.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> -- Joyce
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
>> >> >> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
>> >> >> >>>
>> >> >> >>>> Can you be more specific and propose e.g., :
>> >> >> >>>>
>> >> >> >>>> A1->B1
>> >> >> >>>> A2->B2
>> >> >> >>>> ..
>> >> >> >>>>
>> >> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is the
>>new
>> >> >> >>>> proposed one?
>> >> >> >>>>
>> >> >> >>>> Cheers,
>> >> >> >>>> Chris
>> >> >> >>>>
>> >> >> >>>>
>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >>>> Chris Mattmann, Ph.D.
>> >> >> >>>> Senior Computer Scientist
>> >> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> >> >>>> Office: 171-266B, Mailstop: 171-246
>> >> >> >>>> Email: chris.a.mattmann@nasa.gov
>> >> >> >>>> WWW: http://sunset.usc.edu/~mattmann/
>> >> >> >>>>
>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >>>> Adjunct Assistant Professor, Computer Science Department
>> >> >> >>>> University of Southern California, Los Angeles, CA 90089 USA
>> >> >> >>>>
>> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> -----Original Message-----
>> >> >> >>>> From: Michael Joyce <jo...@apache.org>
>> >> >> >>>> Reply-To: "dev@climate.incubator.apache.org"
>> >> >> >>>> <de...@climate.incubator.apache.org>
>> >> >> >>>> Date: Friday, August 16, 2013 9:31 AM
>> >> >> >>>> To: dev <de...@climate.incubator.apache.org>
>> >> >> >>>> Subject: JIRA component names
>> >> >> >>>>
>> >> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric. What
>> >>does
>> >> >> >>>> everyone
>> >> >> >>>>> think of switching these over to something more generic?
>>Ideas
>> >>on
>> >> >> >>>> names?
>> >> >> >>>>>
>> >> >> >>>>> -- Joyce
>> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> >>
>>
>>
Re: JIRA component names
Posted by Cameron Goodale <go...@apache.org>.
Here is the current state of component names:
Current list we won't change:
------------------------------------------
build process
general
metrics
visualization
website
New Components to Add:
-----------------------------------------
documentation
dataset
The 4 Contentious Components still being discussed: (with my attempt to
please the commenters thus far)
---------------------------------------------------------------------------------
rcmed -> data sources
rcmet -> analysis
rcmet ui -> webapp (this would include ui, middleware, etc...)
regridding -> data processing (loosely maps to dataset_processor, but
would encompass ensemble, temporal and spatial regrid)
I also agree with Mike J. that JIRA has functionality to map components to
Component Leads which might be a nice way to help divide up the work, and I
feel there is a tension between component labels that are Core Developer
Friendly (map to a module of code - dataset_processor) and New User
Friendly (map to a set of functionality they understand - regridding). We
can always have both, but run the risk of too many options.
We can also setup the new components in the list, put them into use and
revisit this issue in 6 months and see what components are used and which
are not. Call it a "Try and Wait" approach to this.
-Cameron
On Tue, Aug 20, 2013 at 8:03 AM, Ramirez, Paul M (398J) <
paul.m.ramirez@jpl.nasa.gov> wrote:
> All,
>
> Seems to me there is a simple high level web-ui, command line, and API.
> Potentially, there is services too but at the moment that would reflect
> the services to support the web UI. There should also be something that
> links issues to build so we can group together updates to any build
> scripts, packaging, and distribution to somewhere like pypi.
>
> I think if we get too specific then if there are shifts we have to go
> change our labels again (imo).
>
> --Paul
>
> On 8/20/13 7:42 AM, "Michael Joyce" <jo...@apache.org> wrote:
>
> >Chris,
> >
> >1) Regridding is far too specific with regards to what dataset_processor
> >actually does in my opinion. Visualization vs plotting, I like
> >visualization better personally.
> >
> >2) Again, "pipeline" seems too generic. Even "rcmet" is too generic in my
> >opinion. I think it's a sign that something is wrong when the vast
> >majority
> >of our issues are falling under a single component. Too me that says that
> >we need to break that component into smaller, more specific components.
> >(Unless, of course, all the work is actually being done on just one
> >specific component).
> >
> >I think the more important question is, what are we using these labels
> >for?
> >Are they for accurately describing issues for committers/contributors or
> >are we trying to make it easy for people making JIRAs to label the
> >problem?
> >Most people who don't actively participate on the project are (probably)
> >going to label their issue as "general" since they have no idea what is
> >broken. If that's the case, then our components should be useful for the
> >people on the project and thus specific. We should also exploit component
> >leads so that issues can be filtered to people on the project who are most
> >capable of dealing with/delegating the issue.
> >
> >TLDR: I like specific, descriptive component names over generic
> >catch-alls.
> >One generic component is good for people making issues that have no idea
> >what is wrong; These can adjusted once someone has looked at the problem.
> >Let's exploit component leads to make all of our lives easier!
> >
> >Thoughts?
> >
> >
> >-- Joyce
> >
> >
> >On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) <
> >chris.a.mattmann@jpl.nasa.gov> wrote:
> >
> >> Cam, I am +1 for this remapping, with the caveats:
> >>
> >> 1. regridding is much more understood in the community than dataset
> >> processor.
> >> Same goes for viz (compared to plotting). So dunno on those.
> >>
> >> 2. I can see your point about rcmet, but don't we have a concept of
> >> end-to-end
> >> regrid->analysis->viz pipeline? Wouldn't something like pipeline or
> >>maybe
> >> even
> >> analysis make more sense than simply having no component? To me some
> >> component is
> >> better than none.
> >>
> >> Bump it to the top of my list anytime.
> >>
> >> Cheers,
> >> Chris
> >>
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> Chris Mattmann, Ph.D.
> >> Senior Computer Scientist
> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> Office: 171-266B, Mailstop: 171-246
> >> Email: chris.a.mattmann@nasa.gov
> >> WWW: http://sunset.usc.edu/~mattmann/
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> Adjunct Assistant Professor, Computer Science Department
> >> University of Southern California, Los Angeles, CA 90089 USA
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Cameron Goodale <go...@apache.org>
> >> Reply-To: "dev@climate.incubator.apache.org"
> >> <de...@climate.incubator.apache.org>
> >> Date: Monday, August 19, 2013 7:21 PM
> >> To: "dev@climate.incubator.apache.org"
> >><de...@climate.incubator.apache.org>
> >> Subject: Re: JIRA component names
> >>
> >> >Hey Guys,
> >> >
> >> >I am going to take a crack and the task of mapping A1 -> B1 that Chris
> >> >mentioned since I have been making JIRAs and wishing for some other
> >> >components in the list. Since the new OCW refactoring introduces some
> >>new
> >> >software modules/components i think it makes sense to align JIRA issues
> >> >with each area of the code. This helps map issues to modules in the
> >>code,
> >> >items tasks that touch large sweeping parts of the code should go under
> >> >'general' and they need a closer look since they are probably taking on
> >> >too
> >> >much work and need sub-tasks or should be broken into smaller chunks.
> >> >
> >> >rcmed -> data_source (this would also relate to ESG work or
> >>developing an
> >> >interface to OpenDAP moving forward)
> >> >rcmet -> None (just drop this from the OCW issue tracker. RCMET is a
> >>JPL
> >> >project that is built on OCW)
> >> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle.
> >>Webapp is
> >> >generic enough that we can change to Ember.js and CherryPy if we like)
> >> >regridding -> dataset_processor (map to the module that does this
> >> >function)
> >> >visualization -> plotting (map to the module that does this function)
> >> >documentation -> NEW Component
> >> >dataset -> NEW Component
> >> >
> >> >A note about rcmet above:
> >> >
> >> >Here are 14 open issues with rcmet as the component and what I think a
> >> >reasonable mapping could be:
> >> >
> >> >(general) CLIMATE-261 Consolidate Code that converts a String into a
> >> >Datetime Object
> >> >(general) CLIMATE-259 Create branch to refactor updates to
> >>ui/services to
> >> >support multiple metrics/plotting
> >> >(documentation) CLIMATE-258 Improve Evaluation documentation
> >> >(dataset) CLIMATE-219 Add name attribute to Dataset
> >> >(metrics) CLIMATE-218 Update metric handling in Evaluation to coincide
> >> >with new Metric definition
> >> >(general) CLIMATE-217 Add metrics.py for OCW refactoring
> >> >(general) CLIMATE-214 Add evaluation.py to OCW
> >> >(dataset_processor) CLIMATE-179 Add support for Observation/Reference
> >> >option when doing Spatial Regridding
> >> >(general) CLIMATE-137 OCW refactoring code
> >> >(general) CLIMATE-50 RCMET needs to use a logger instead of prints
> >> >(general) CLIMATE-49 Add the 'obs' regrid option into
> >> >toolkit.do_data_prep.prep_data function
> >> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class needs
> >>to
> >> >be refactored - Not an issue with OCW Dataset Class
> >> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support
> >> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
> >> >
> >> >Thanks for allowing me to bump this thread to top of your inbox.
> >> >
> >> >-Cam
> >> >
> >> >
> >> >
> >> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
> >> >chris.a.mattmann@jpl.nasa.gov> wrote:
> >> >
> >> >> Perfect
> >> >>
> >> >> Sent from my iPhone
> >> >>
> >> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org>
> >>wrote:
> >> >>
> >> >> > If people need to catch up on the refactoring that's been occurring
> >> >>they
> >> >> > can find the original proposal for refactoring at [1]. The full
> >>thread
> >> >> > where this was discussed can be found in the mail archives at [2].
> >>The
> >> >> wiki
> >> >> > entry that Mazi made detailing proposed package layouts (including
> >>the
> >> >> one
> >> >> > we ultimately went with) is available at [3].
> >> >> >
> >> >> > To summate:
> >> >> >
> >> >> > The old code (which was called RCMET) is being refactored into the
> >>ocw
> >> >> > package with the intention of making the code base more
> >>maintainable
> >> >>and
> >> >> > the API nice and pretty.
> >> >> >
> >> >> > Hopefully this is sufficiently verbose. I don't have the time to go
> >> >>into
> >> >> > more detail at the moment. If anyone is confused feel free to ask
> >>away
> >> >> and
> >> >> > I'll try to elaborate later!!
> >> >> >
> >> >> > Thanks
> >> >> > Mike
> >> >> >
> >> >> >
> >> >> > [1]: http://s.apache.org/RKI
> >> >> > [2]:
> >> >> >
> >> >>
> >> >>
> >>
> >>
> https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mb
> >> >>ox/browser
> >> >> > [3]:
> >> >> >
> >> >>
> >> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbenc
> >> >>h+API+summary
> >> >> >
> >> >> >
> >> >> > -- Joyce
> >> >> >
> >> >> >
> >> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
> >> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
> >> >> >
> >> >> >> Can you detail "the refactoring" so everyone on the list here
> >>knows
> >> >>what
> >> >> >> you are talking about?
> >> >> >>
> >> >> >> A few paragraphs would be great, Mike, thanks.
> >> >> >>
> >> >> >> Cheers,
> >> >> >> Chris
> >> >> >>
> >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >> Chris Mattmann, Ph.D.
> >> >> >> Senior Computer Scientist
> >> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> >> >> Office: 171-266B, Mailstop: 171-246
> >> >> >> Email: chris.a.mattmann@nasa.gov
> >> >> >> WWW: http://sunset.usc.edu/~mattmann/
> >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >> Adjunct Assistant Professor, Computer Science Department
> >> >> >> University of Southern California, Los Angeles, CA 90089 USA
> >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> -----Original Message-----
> >> >> >> From: Michael Joyce <jo...@apache.org>
> >> >> >> Reply-To: "dev@climate.incubator.apache.org"
> >> >> >> <de...@climate.incubator.apache.org>
> >> >> >> Date: Friday, August 16, 2013 10:07 AM
> >> >> >> To: dev <de...@climate.incubator.apache.org>
> >> >> >> Subject: Re: JIRA component names
> >> >> >>
> >> >> >>> The 3 that caught my eye were:
> >> >> >>>
> >> >> >>> rcmet
> >> >> >>> rcmet ui
> >> >> >>> rcmet
> >> >> >>>
> >> >> >>> As to what they should be instead I don't know. 'rcmet ui' could
> >> >> easily be
> >> >> >>> 'ocw ui' without loss of clarity. With the refactoring I don't
> >>know
> >> >> what
> >> >> >>> we
> >> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs to be
> >> >> there at
> >> >> >>> all, so I don't know if we need to think of an alternative.
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> -- Joyce
> >> >> >>>
> >> >> >>>
> >> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
> >> >> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
> >> >> >>>
> >> >> >>>> Can you be more specific and propose e.g., :
> >> >> >>>>
> >> >> >>>> A1->B1
> >> >> >>>> A2->B2
> >> >> >>>> ..
> >> >> >>>>
> >> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is the new
> >> >> >>>> proposed one?
> >> >> >>>>
> >> >> >>>> Cheers,
> >> >> >>>> Chris
> >> >> >>>>
> >> >> >>>>
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >>>> Chris Mattmann, Ph.D.
> >> >> >>>> Senior Computer Scientist
> >> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> >> >>>> Office: 171-266B, Mailstop: 171-246
> >> >> >>>> Email: chris.a.mattmann@nasa.gov
> >> >> >>>> WWW: http://sunset.usc.edu/~mattmann/
> >> >> >>>>
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >>>> Adjunct Assistant Professor, Computer Science Department
> >> >> >>>> University of Southern California, Los Angeles, CA 90089 USA
> >> >> >>>>
> >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> -----Original Message-----
> >> >> >>>> From: Michael Joyce <jo...@apache.org>
> >> >> >>>> Reply-To: "dev@climate.incubator.apache.org"
> >> >> >>>> <de...@climate.incubator.apache.org>
> >> >> >>>> Date: Friday, August 16, 2013 9:31 AM
> >> >> >>>> To: dev <de...@climate.incubator.apache.org>
> >> >> >>>> Subject: JIRA component names
> >> >> >>>>
> >> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric. What
> >>does
> >> >> >>>> everyone
> >> >> >>>>> think of switching these over to something more generic? Ideas
> >>on
> >> >> >>>> names?
> >> >> >>>>>
> >> >> >>>>> -- Joyce
> >> >> >>
> >> >> >>
> >> >>
> >>
> >>
>
>
Re: JIRA component names
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
Mike,
-----Original Message-----
From: Michael Joyce <jo...@apache.org>
Reply-To: "dev@climate.incubator.apache.org"
<de...@climate.incubator.apache.org>
Date: Tuesday, August 20, 2013 7:42 AM
To: dev <de...@climate.incubator.apache.org>
Subject: Re: JIRA component names
>Chris,
>
>1) Regridding is far too specific with regards to what dataset_processor
>actually does in my opinion. Visualization vs plotting, I like
>visualization better personally.
What does dataset processor do? Doesn't it do regridding? And I think it's
better to be specific rather than general.
>
>2) Again, "pipeline" seems too generic. Even "rcmet" is too generic in my
>opinion. I think it's a sign that something is wrong when the vast
>majority
>of our issues are falling under a single component. Too me that says that
>we need to break that component into smaller, more specific components.
>(Unless, of course, all the work is actually being done on just one
>specific component).
Yeah agree -- I was just throwing pipeline out there as like a combination
of
e.g., regridding, metrics computation, and then viz to indicate that we
have
components that try to do all three (e.g., the command line interface for
example; or the [branched, but now in trunk] bottle web services that
expose
the end to end pipeline. So pipeline or not, we have components that do
that
so to me it's more of an issue of being specific rather than general.
>
>I think the more important question is, what are we using these labels
>for?
>Are they for accurately describing issues for committers/contributors or
>are we trying to make it easy for people making JIRAs to label the
>problem?
Both. We should be using hem to do both, I believe.
>Most people who don't actively participate on the project are (probably)
>going to label their issue as "general" since they have no idea what is
>broken.
Dunno -- it depends on the level of sophistication of the user. I could see
someone from CORDEX who knows what regridding is to label their (perceived)
JIRA issue as regridding, rather than genera; on the other hand, if there
is
a catch all component I could see that being used or even no component at
all.
> If that's the case, then our components should be useful for the
>people on the project and thus specific. We should also exploit component
>leads so that issues can be filtered to people on the project who are most
>capable of dealing with/delegating the issue.
The code has shared stewardship -- and I doubt that component leads
will solve the problem of filtering the issue to the right person -- I
think
it may help though it's just not the silver bullet.
>
>TLDR: I like specific, descriptive component names over generic
>catch-alls.
>One generic component is good for people making issues that have no idea
>what is wrong; These can adjusted once someone has looked at the problem.
>Let's exploit component leads to make all of our lives easier!
Yeah I don't think I was debating whether components are good, just
figuring out
the right level of granularity. Cam made some updates, we'll see how they
go and
revisit in a while to see if they are useful. Data points and specifics
usually
help when evaluating things so we'll get some and see how it goes.
Cheers,
Chris
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) <
>chris.a.mattmann@jpl.nasa.gov> wrote:
>
>> Cam, I am +1 for this remapping, with the caveats:
>>
>> 1. regridding is much more understood in the community than dataset
>> processor.
>> Same goes for viz (compared to plotting). So dunno on those.
>>
>> 2. I can see your point about rcmet, but don't we have a concept of
>> end-to-end
>> regrid->analysis->viz pipeline? Wouldn't something like pipeline or
>>maybe
>> even
>> analysis make more sense than simply having no component? To me some
>> component is
>> better than none.
>>
>> Bump it to the top of my list anytime.
>>
>> Cheers,
>> Chris
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW: http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Cameron Goodale <go...@apache.org>
>> Reply-To: "dev@climate.incubator.apache.org"
>> <de...@climate.incubator.apache.org>
>> Date: Monday, August 19, 2013 7:21 PM
>> To: "dev@climate.incubator.apache.org"
>><de...@climate.incubator.apache.org>
>> Subject: Re: JIRA component names
>>
>> >Hey Guys,
>> >
>> >I am going to take a crack and the task of mapping A1 -> B1 that Chris
>> >mentioned since I have been making JIRAs and wishing for some other
>> >components in the list. Since the new OCW refactoring introduces some
>>new
>> >software modules/components i think it makes sense to align JIRA issues
>> >with each area of the code. This helps map issues to modules in the
>>code,
>> >items tasks that touch large sweeping parts of the code should go under
>> >'general' and they need a closer look since they are probably taking on
>> >too
>> >much work and need sub-tasks or should be broken into smaller chunks.
>> >
>> >rcmed -> data_source (this would also relate to ESG work or
>>developing an
>> >interface to OpenDAP moving forward)
>> >rcmet -> None (just drop this from the OCW issue tracker. RCMET is a
>>JPL
>> >project that is built on OCW)
>> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle.
>>Webapp is
>> >generic enough that we can change to Ember.js and CherryPy if we like)
>> >regridding -> dataset_processor (map to the module that does this
>> >function)
>> >visualization -> plotting (map to the module that does this function)
>> >documentation -> NEW Component
>> >dataset -> NEW Component
>> >
>> >A note about rcmet above:
>> >
>> >Here are 14 open issues with rcmet as the component and what I think a
>> >reasonable mapping could be:
>> >
>> >(general) CLIMATE-261 Consolidate Code that converts a String into a
>> >Datetime Object
>> >(general) CLIMATE-259 Create branch to refactor updates to
>>ui/services to
>> >support multiple metrics/plotting
>> >(documentation) CLIMATE-258 Improve Evaluation documentation
>> >(dataset) CLIMATE-219 Add name attribute to Dataset
>> >(metrics) CLIMATE-218 Update metric handling in Evaluation to coincide
>> >with new Metric definition
>> >(general) CLIMATE-217 Add metrics.py for OCW refactoring
>> >(general) CLIMATE-214 Add evaluation.py to OCW
>> >(dataset_processor) CLIMATE-179 Add support for Observation/Reference
>> >option when doing Spatial Regridding
>> >(general) CLIMATE-137 OCW refactoring code
>> >(general) CLIMATE-50 RCMET needs to use a logger instead of prints
>> >(general) CLIMATE-49 Add the 'obs' regrid option into
>> >toolkit.do_data_prep.prep_data function
>> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class needs
>>to
>> >be refactored - Not an issue with OCW Dataset Class
>> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support
>> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
>> >
>> >Thanks for allowing me to bump this thread to top of your inbox.
>> >
>> >-Cam
>> >
>> >
>> >
>> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
>> >chris.a.mattmann@jpl.nasa.gov> wrote:
>> >
>> >> Perfect
>> >>
>> >> Sent from my iPhone
>> >>
>> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org>
>>wrote:
>> >>
>> >> > If people need to catch up on the refactoring that's been occurring
>> >>they
>> >> > can find the original proposal for refactoring at [1]. The full
>>thread
>> >> > where this was discussed can be found in the mail archives at [2].
>>The
>> >> wiki
>> >> > entry that Mazi made detailing proposed package layouts (including
>>the
>> >> one
>> >> > we ultimately went with) is available at [3].
>> >> >
>> >> > To summate:
>> >> >
>> >> > The old code (which was called RCMET) is being refactored into the
>>ocw
>> >> > package with the intention of making the code base more
>>maintainable
>> >>and
>> >> > the API nice and pretty.
>> >> >
>> >> > Hopefully this is sufficiently verbose. I don't have the time to go
>> >>into
>> >> > more detail at the moment. If anyone is confused feel free to ask
>>away
>> >> and
>> >> > I'll try to elaborate later!!
>> >> >
>> >> > Thanks
>> >> > Mike
>> >> >
>> >> >
>> >> > [1]: http://s.apache.org/RKI
>> >> > [2]:
>> >> >
>> >>
>> >>
>>
>>https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mb
>> >>ox/browser
>> >> > [3]:
>> >> >
>> >>
>> >>
>>
>>https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbenc
>> >>h+API+summary
>> >> >
>> >> >
>> >> > -- Joyce
>> >> >
>> >> >
>> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
>> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
>> >> >
>> >> >> Can you detail "the refactoring" so everyone on the list here
>>knows
>> >>what
>> >> >> you are talking about?
>> >> >>
>> >> >> A few paragraphs would be great, Mike, thanks.
>> >> >>
>> >> >> Cheers,
>> >> >> Chris
>> >> >>
>> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> Chris Mattmann, Ph.D.
>> >> >> Senior Computer Scientist
>> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> >> Office: 171-266B, Mailstop: 171-246
>> >> >> Email: chris.a.mattmann@nasa.gov
>> >> >> WWW: http://sunset.usc.edu/~mattmann/
>> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> Adjunct Assistant Professor, Computer Science Department
>> >> >> University of Southern California, Los Angeles, CA 90089 USA
>> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: Michael Joyce <jo...@apache.org>
>> >> >> Reply-To: "dev@climate.incubator.apache.org"
>> >> >> <de...@climate.incubator.apache.org>
>> >> >> Date: Friday, August 16, 2013 10:07 AM
>> >> >> To: dev <de...@climate.incubator.apache.org>
>> >> >> Subject: Re: JIRA component names
>> >> >>
>> >> >>> The 3 that caught my eye were:
>> >> >>>
>> >> >>> rcmet
>> >> >>> rcmet ui
>> >> >>> rcmet
>> >> >>>
>> >> >>> As to what they should be instead I don't know. 'rcmet ui' could
>> >> easily be
>> >> >>> 'ocw ui' without loss of clarity. With the refactoring I don't
>>know
>> >> what
>> >> >>> we
>> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs to be
>> >> there at
>> >> >>> all, so I don't know if we need to think of an alternative.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> -- Joyce
>> >> >>>
>> >> >>>
>> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
>> >> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
>> >> >>>
>> >> >>>> Can you be more specific and propose e.g., :
>> >> >>>>
>> >> >>>> A1->B1
>> >> >>>> A2->B2
>> >> >>>> ..
>> >> >>>>
>> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is the new
>> >> >>>> proposed one?
>> >> >>>>
>> >> >>>> Cheers,
>> >> >>>> Chris
>> >> >>>>
>> >> >>>>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >>>> Chris Mattmann, Ph.D.
>> >> >>>> Senior Computer Scientist
>> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> >>>> Office: 171-266B, Mailstop: 171-246
>> >> >>>> Email: chris.a.mattmann@nasa.gov
>> >> >>>> WWW: http://sunset.usc.edu/~mattmann/
>> >> >>>>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >>>> Adjunct Assistant Professor, Computer Science Department
>> >> >>>> University of Southern California, Los Angeles, CA 90089 USA
>> >> >>>>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> -----Original Message-----
>> >> >>>> From: Michael Joyce <jo...@apache.org>
>> >> >>>> Reply-To: "dev@climate.incubator.apache.org"
>> >> >>>> <de...@climate.incubator.apache.org>
>> >> >>>> Date: Friday, August 16, 2013 9:31 AM
>> >> >>>> To: dev <de...@climate.incubator.apache.org>
>> >> >>>> Subject: JIRA component names
>> >> >>>>
>> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric. What
>>does
>> >> >>>> everyone
>> >> >>>>> think of switching these over to something more generic? Ideas
>>on
>> >> >>>> names?
>> >> >>>>>
>> >> >>>>> -- Joyce
>> >> >>
>> >> >>
>> >>
>>
>>
Re: JIRA component names
Posted by "Ramirez, Paul M (398J)" <pa...@jpl.nasa.gov>.
All,
Seems to me there is a simple high level web-ui, command line, and API.
Potentially, there is services too but at the moment that would reflect
the services to support the web UI. There should also be something that
links issues to build so we can group together updates to any build
scripts, packaging, and distribution to somewhere like pypi.
I think if we get too specific then if there are shifts we have to go
change our labels again (imo).
--Paul
On 8/20/13 7:42 AM, "Michael Joyce" <jo...@apache.org> wrote:
>Chris,
>
>1) Regridding is far too specific with regards to what dataset_processor
>actually does in my opinion. Visualization vs plotting, I like
>visualization better personally.
>
>2) Again, "pipeline" seems too generic. Even "rcmet" is too generic in my
>opinion. I think it's a sign that something is wrong when the vast
>majority
>of our issues are falling under a single component. Too me that says that
>we need to break that component into smaller, more specific components.
>(Unless, of course, all the work is actually being done on just one
>specific component).
>
>I think the more important question is, what are we using these labels
>for?
>Are they for accurately describing issues for committers/contributors or
>are we trying to make it easy for people making JIRAs to label the
>problem?
>Most people who don't actively participate on the project are (probably)
>going to label their issue as "general" since they have no idea what is
>broken. If that's the case, then our components should be useful for the
>people on the project and thus specific. We should also exploit component
>leads so that issues can be filtered to people on the project who are most
>capable of dealing with/delegating the issue.
>
>TLDR: I like specific, descriptive component names over generic
>catch-alls.
>One generic component is good for people making issues that have no idea
>what is wrong; These can adjusted once someone has looked at the problem.
>Let's exploit component leads to make all of our lives easier!
>
>Thoughts?
>
>
>-- Joyce
>
>
>On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) <
>chris.a.mattmann@jpl.nasa.gov> wrote:
>
>> Cam, I am +1 for this remapping, with the caveats:
>>
>> 1. regridding is much more understood in the community than dataset
>> processor.
>> Same goes for viz (compared to plotting). So dunno on those.
>>
>> 2. I can see your point about rcmet, but don't we have a concept of
>> end-to-end
>> regrid->analysis->viz pipeline? Wouldn't something like pipeline or
>>maybe
>> even
>> analysis make more sense than simply having no component? To me some
>> component is
>> better than none.
>>
>> Bump it to the top of my list anytime.
>>
>> Cheers,
>> Chris
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW: http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Cameron Goodale <go...@apache.org>
>> Reply-To: "dev@climate.incubator.apache.org"
>> <de...@climate.incubator.apache.org>
>> Date: Monday, August 19, 2013 7:21 PM
>> To: "dev@climate.incubator.apache.org"
>><de...@climate.incubator.apache.org>
>> Subject: Re: JIRA component names
>>
>> >Hey Guys,
>> >
>> >I am going to take a crack and the task of mapping A1 -> B1 that Chris
>> >mentioned since I have been making JIRAs and wishing for some other
>> >components in the list. Since the new OCW refactoring introduces some
>>new
>> >software modules/components i think it makes sense to align JIRA issues
>> >with each area of the code. This helps map issues to modules in the
>>code,
>> >items tasks that touch large sweeping parts of the code should go under
>> >'general' and they need a closer look since they are probably taking on
>> >too
>> >much work and need sub-tasks or should be broken into smaller chunks.
>> >
>> >rcmed -> data_source (this would also relate to ESG work or
>>developing an
>> >interface to OpenDAP moving forward)
>> >rcmet -> None (just drop this from the OCW issue tracker. RCMET is a
>>JPL
>> >project that is built on OCW)
>> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle.
>>Webapp is
>> >generic enough that we can change to Ember.js and CherryPy if we like)
>> >regridding -> dataset_processor (map to the module that does this
>> >function)
>> >visualization -> plotting (map to the module that does this function)
>> >documentation -> NEW Component
>> >dataset -> NEW Component
>> >
>> >A note about rcmet above:
>> >
>> >Here are 14 open issues with rcmet as the component and what I think a
>> >reasonable mapping could be:
>> >
>> >(general) CLIMATE-261 Consolidate Code that converts a String into a
>> >Datetime Object
>> >(general) CLIMATE-259 Create branch to refactor updates to
>>ui/services to
>> >support multiple metrics/plotting
>> >(documentation) CLIMATE-258 Improve Evaluation documentation
>> >(dataset) CLIMATE-219 Add name attribute to Dataset
>> >(metrics) CLIMATE-218 Update metric handling in Evaluation to coincide
>> >with new Metric definition
>> >(general) CLIMATE-217 Add metrics.py for OCW refactoring
>> >(general) CLIMATE-214 Add evaluation.py to OCW
>> >(dataset_processor) CLIMATE-179 Add support for Observation/Reference
>> >option when doing Spatial Regridding
>> >(general) CLIMATE-137 OCW refactoring code
>> >(general) CLIMATE-50 RCMET needs to use a logger instead of prints
>> >(general) CLIMATE-49 Add the 'obs' regrid option into
>> >toolkit.do_data_prep.prep_data function
>> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class needs
>>to
>> >be refactored - Not an issue with OCW Dataset Class
>> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support
>> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
>> >
>> >Thanks for allowing me to bump this thread to top of your inbox.
>> >
>> >-Cam
>> >
>> >
>> >
>> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
>> >chris.a.mattmann@jpl.nasa.gov> wrote:
>> >
>> >> Perfect
>> >>
>> >> Sent from my iPhone
>> >>
>> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org>
>>wrote:
>> >>
>> >> > If people need to catch up on the refactoring that's been occurring
>> >>they
>> >> > can find the original proposal for refactoring at [1]. The full
>>thread
>> >> > where this was discussed can be found in the mail archives at [2].
>>The
>> >> wiki
>> >> > entry that Mazi made detailing proposed package layouts (including
>>the
>> >> one
>> >> > we ultimately went with) is available at [3].
>> >> >
>> >> > To summate:
>> >> >
>> >> > The old code (which was called RCMET) is being refactored into the
>>ocw
>> >> > package with the intention of making the code base more
>>maintainable
>> >>and
>> >> > the API nice and pretty.
>> >> >
>> >> > Hopefully this is sufficiently verbose. I don't have the time to go
>> >>into
>> >> > more detail at the moment. If anyone is confused feel free to ask
>>away
>> >> and
>> >> > I'll try to elaborate later!!
>> >> >
>> >> > Thanks
>> >> > Mike
>> >> >
>> >> >
>> >> > [1]: http://s.apache.org/RKI
>> >> > [2]:
>> >> >
>> >>
>> >>
>>
>>https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mb
>> >>ox/browser
>> >> > [3]:
>> >> >
>> >>
>> >>
>>
>>https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbenc
>> >>h+API+summary
>> >> >
>> >> >
>> >> > -- Joyce
>> >> >
>> >> >
>> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
>> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
>> >> >
>> >> >> Can you detail "the refactoring" so everyone on the list here
>>knows
>> >>what
>> >> >> you are talking about?
>> >> >>
>> >> >> A few paragraphs would be great, Mike, thanks.
>> >> >>
>> >> >> Cheers,
>> >> >> Chris
>> >> >>
>> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> Chris Mattmann, Ph.D.
>> >> >> Senior Computer Scientist
>> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> >> Office: 171-266B, Mailstop: 171-246
>> >> >> Email: chris.a.mattmann@nasa.gov
>> >> >> WWW: http://sunset.usc.edu/~mattmann/
>> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >> Adjunct Assistant Professor, Computer Science Department
>> >> >> University of Southern California, Los Angeles, CA 90089 USA
>> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: Michael Joyce <jo...@apache.org>
>> >> >> Reply-To: "dev@climate.incubator.apache.org"
>> >> >> <de...@climate.incubator.apache.org>
>> >> >> Date: Friday, August 16, 2013 10:07 AM
>> >> >> To: dev <de...@climate.incubator.apache.org>
>> >> >> Subject: Re: JIRA component names
>> >> >>
>> >> >>> The 3 that caught my eye were:
>> >> >>>
>> >> >>> rcmet
>> >> >>> rcmet ui
>> >> >>> rcmet
>> >> >>>
>> >> >>> As to what they should be instead I don't know. 'rcmet ui' could
>> >> easily be
>> >> >>> 'ocw ui' without loss of clarity. With the refactoring I don't
>>know
>> >> what
>> >> >>> we
>> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs to be
>> >> there at
>> >> >>> all, so I don't know if we need to think of an alternative.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> -- Joyce
>> >> >>>
>> >> >>>
>> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
>> >> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
>> >> >>>
>> >> >>>> Can you be more specific and propose e.g., :
>> >> >>>>
>> >> >>>> A1->B1
>> >> >>>> A2->B2
>> >> >>>> ..
>> >> >>>>
>> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is the new
>> >> >>>> proposed one?
>> >> >>>>
>> >> >>>> Cheers,
>> >> >>>> Chris
>> >> >>>>
>> >> >>>>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >>>> Chris Mattmann, Ph.D.
>> >> >>>> Senior Computer Scientist
>> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> >>>> Office: 171-266B, Mailstop: 171-246
>> >> >>>> Email: chris.a.mattmann@nasa.gov
>> >> >>>> WWW: http://sunset.usc.edu/~mattmann/
>> >> >>>>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >>>> Adjunct Assistant Professor, Computer Science Department
>> >> >>>> University of Southern California, Los Angeles, CA 90089 USA
>> >> >>>>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> -----Original Message-----
>> >> >>>> From: Michael Joyce <jo...@apache.org>
>> >> >>>> Reply-To: "dev@climate.incubator.apache.org"
>> >> >>>> <de...@climate.incubator.apache.org>
>> >> >>>> Date: Friday, August 16, 2013 9:31 AM
>> >> >>>> To: dev <de...@climate.incubator.apache.org>
>> >> >>>> Subject: JIRA component names
>> >> >>>>
>> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric. What
>>does
>> >> >>>> everyone
>> >> >>>>> think of switching these over to something more generic? Ideas
>>on
>> >> >>>> names?
>> >> >>>>>
>> >> >>>>> -- Joyce
>> >> >>
>> >> >>
>> >>
>>
>>
Re: JIRA component names
Posted by Michael Joyce <jo...@apache.org>.
Chris,
1) Regridding is far too specific with regards to what dataset_processor
actually does in my opinion. Visualization vs plotting, I like
visualization better personally.
2) Again, "pipeline" seems too generic. Even "rcmet" is too generic in my
opinion. I think it's a sign that something is wrong when the vast majority
of our issues are falling under a single component. Too me that says that
we need to break that component into smaller, more specific components.
(Unless, of course, all the work is actually being done on just one
specific component).
I think the more important question is, what are we using these labels for?
Are they for accurately describing issues for committers/contributors or
are we trying to make it easy for people making JIRAs to label the problem?
Most people who don't actively participate on the project are (probably)
going to label their issue as "general" since they have no idea what is
broken. If that's the case, then our components should be useful for the
people on the project and thus specific. We should also exploit component
leads so that issues can be filtered to people on the project who are most
capable of dealing with/delegating the issue.
TLDR: I like specific, descriptive component names over generic catch-alls.
One generic component is good for people making issues that have no idea
what is wrong; These can adjusted once someone has looked at the problem.
Let's exploit component leads to make all of our lives easier!
Thoughts?
-- Joyce
On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> Cam, I am +1 for this remapping, with the caveats:
>
> 1. regridding is much more understood in the community than dataset
> processor.
> Same goes for viz (compared to plotting). So dunno on those.
>
> 2. I can see your point about rcmet, but don't we have a concept of
> end-to-end
> regrid->analysis->viz pipeline? Wouldn't something like pipeline or maybe
> even
> analysis make more sense than simply having no component? To me some
> component is
> better than none.
>
> Bump it to the top of my list anytime.
>
> Cheers,
> Chris
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
>
> -----Original Message-----
> From: Cameron Goodale <go...@apache.org>
> Reply-To: "dev@climate.incubator.apache.org"
> <de...@climate.incubator.apache.org>
> Date: Monday, August 19, 2013 7:21 PM
> To: "dev@climate.incubator.apache.org" <de...@climate.incubator.apache.org>
> Subject: Re: JIRA component names
>
> >Hey Guys,
> >
> >I am going to take a crack and the task of mapping A1 -> B1 that Chris
> >mentioned since I have been making JIRAs and wishing for some other
> >components in the list. Since the new OCW refactoring introduces some new
> >software modules/components i think it makes sense to align JIRA issues
> >with each area of the code. This helps map issues to modules in the code,
> >items tasks that touch large sweeping parts of the code should go under
> >'general' and they need a closer look since they are probably taking on
> >too
> >much work and need sub-tasks or should be broken into smaller chunks.
> >
> >rcmed -> data_source (this would also relate to ESG work or developing an
> >interface to OpenDAP moving forward)
> >rcmet -> None (just drop this from the OCW issue tracker. RCMET is a JPL
> >project that is built on OCW)
> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle. Webapp is
> >generic enough that we can change to Ember.js and CherryPy if we like)
> >regridding -> dataset_processor (map to the module that does this
> >function)
> >visualization -> plotting (map to the module that does this function)
> >documentation -> NEW Component
> >dataset -> NEW Component
> >
> >A note about rcmet above:
> >
> >Here are 14 open issues with rcmet as the component and what I think a
> >reasonable mapping could be:
> >
> >(general) CLIMATE-261 Consolidate Code that converts a String into a
> >Datetime Object
> >(general) CLIMATE-259 Create branch to refactor updates to ui/services to
> >support multiple metrics/plotting
> >(documentation) CLIMATE-258 Improve Evaluation documentation
> >(dataset) CLIMATE-219 Add name attribute to Dataset
> >(metrics) CLIMATE-218 Update metric handling in Evaluation to coincide
> >with new Metric definition
> >(general) CLIMATE-217 Add metrics.py for OCW refactoring
> >(general) CLIMATE-214 Add evaluation.py to OCW
> >(dataset_processor) CLIMATE-179 Add support for Observation/Reference
> >option when doing Spatial Regridding
> >(general) CLIMATE-137 OCW refactoring code
> >(general) CLIMATE-50 RCMET needs to use a logger instead of prints
> >(general) CLIMATE-49 Add the 'obs' regrid option into
> >toolkit.do_data_prep.prep_data function
> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class needs to
> >be refactored - Not an issue with OCW Dataset Class
> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support
> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
> >
> >Thanks for allowing me to bump this thread to top of your inbox.
> >
> >-Cam
> >
> >
> >
> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
> >chris.a.mattmann@jpl.nasa.gov> wrote:
> >
> >> Perfect
> >>
> >> Sent from my iPhone
> >>
> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org> wrote:
> >>
> >> > If people need to catch up on the refactoring that's been occurring
> >>they
> >> > can find the original proposal for refactoring at [1]. The full thread
> >> > where this was discussed can be found in the mail archives at [2]. The
> >> wiki
> >> > entry that Mazi made detailing proposed package layouts (including the
> >> one
> >> > we ultimately went with) is available at [3].
> >> >
> >> > To summate:
> >> >
> >> > The old code (which was called RCMET) is being refactored into the ocw
> >> > package with the intention of making the code base more maintainable
> >>and
> >> > the API nice and pretty.
> >> >
> >> > Hopefully this is sufficiently verbose. I don't have the time to go
> >>into
> >> > more detail at the moment. If anyone is confused feel free to ask away
> >> and
> >> > I'll try to elaborate later!!
> >> >
> >> > Thanks
> >> > Mike
> >> >
> >> >
> >> > [1]: http://s.apache.org/RKI
> >> > [2]:
> >> >
> >>
> >>
> https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mb
> >>ox/browser
> >> > [3]:
> >> >
> >>
> >>
> https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbenc
> >>h+API+summary
> >> >
> >> >
> >> > -- Joyce
> >> >
> >> >
> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
> >> >
> >> >> Can you detail "the refactoring" so everyone on the list here knows
> >>what
> >> >> you are talking about?
> >> >>
> >> >> A few paragraphs would be great, Mike, thanks.
> >> >>
> >> >> Cheers,
> >> >> Chris
> >> >>
> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> Chris Mattmann, Ph.D.
> >> >> Senior Computer Scientist
> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> >> Office: 171-266B, Mailstop: 171-246
> >> >> Email: chris.a.mattmann@nasa.gov
> >> >> WWW: http://sunset.usc.edu/~mattmann/
> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> Adjunct Assistant Professor, Computer Science Department
> >> >> University of Southern California, Los Angeles, CA 90089 USA
> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >> From: Michael Joyce <jo...@apache.org>
> >> >> Reply-To: "dev@climate.incubator.apache.org"
> >> >> <de...@climate.incubator.apache.org>
> >> >> Date: Friday, August 16, 2013 10:07 AM
> >> >> To: dev <de...@climate.incubator.apache.org>
> >> >> Subject: Re: JIRA component names
> >> >>
> >> >>> The 3 that caught my eye were:
> >> >>>
> >> >>> rcmet
> >> >>> rcmet ui
> >> >>> rcmet
> >> >>>
> >> >>> As to what they should be instead I don't know. 'rcmet ui' could
> >> easily be
> >> >>> 'ocw ui' without loss of clarity. With the refactoring I don't know
> >> what
> >> >>> we
> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs to be
> >> there at
> >> >>> all, so I don't know if we need to think of an alternative.
> >> >>>
> >> >>>
> >> >>>
> >> >>> -- Joyce
> >> >>>
> >> >>>
> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
> >> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
> >> >>>
> >> >>>> Can you be more specific and propose e.g., :
> >> >>>>
> >> >>>> A1->B1
> >> >>>> A2->B2
> >> >>>> ..
> >> >>>>
> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is the new
> >> >>>> proposed one?
> >> >>>>
> >> >>>> Cheers,
> >> >>>> Chris
> >> >>>>
> >> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >>>> Chris Mattmann, Ph.D.
> >> >>>> Senior Computer Scientist
> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> >>>> Office: 171-266B, Mailstop: 171-246
> >> >>>> Email: chris.a.mattmann@nasa.gov
> >> >>>> WWW: http://sunset.usc.edu/~mattmann/
> >> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >>>> Adjunct Assistant Professor, Computer Science Department
> >> >>>> University of Southern California, Los Angeles, CA 90089 USA
> >> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> -----Original Message-----
> >> >>>> From: Michael Joyce <jo...@apache.org>
> >> >>>> Reply-To: "dev@climate.incubator.apache.org"
> >> >>>> <de...@climate.incubator.apache.org>
> >> >>>> Date: Friday, August 16, 2013 9:31 AM
> >> >>>> To: dev <de...@climate.incubator.apache.org>
> >> >>>> Subject: JIRA component names
> >> >>>>
> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric. What does
> >> >>>> everyone
> >> >>>>> think of switching these over to something more generic? Ideas on
> >> >>>> names?
> >> >>>>>
> >> >>>>> -- Joyce
> >> >>
> >> >>
> >>
>
>
Re: JIRA component names
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
Cam, I am +1 for this remapping, with the caveats:
1. regridding is much more understood in the community than dataset
processor.
Same goes for viz (compared to plotting). So dunno on those.
2. I can see your point about rcmet, but don't we have a concept of
end-to-end
regrid->analysis->viz pipeline? Wouldn't something like pipeline or maybe
even
analysis make more sense than simply having no component? To me some
component is
better than none.
Bump it to the top of my list anytime.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Cameron Goodale <go...@apache.org>
Reply-To: "dev@climate.incubator.apache.org"
<de...@climate.incubator.apache.org>
Date: Monday, August 19, 2013 7:21 PM
To: "dev@climate.incubator.apache.org" <de...@climate.incubator.apache.org>
Subject: Re: JIRA component names
>Hey Guys,
>
>I am going to take a crack and the task of mapping A1 -> B1 that Chris
>mentioned since I have been making JIRAs and wishing for some other
>components in the list. Since the new OCW refactoring introduces some new
>software modules/components i think it makes sense to align JIRA issues
>with each area of the code. This helps map issues to modules in the code,
>items tasks that touch large sweeping parts of the code should go under
>'general' and they need a closer look since they are probably taking on
>too
>much work and need sub-tasks or should be broken into smaller chunks.
>
>rcmed -> data_source (this would also relate to ESG work or developing an
>interface to OpenDAP moving forward)
>rcmet -> None (just drop this from the OCW issue tracker. RCMET is a JPL
>project that is built on OCW)
>rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle. Webapp is
>generic enough that we can change to Ember.js and CherryPy if we like)
>regridding -> dataset_processor (map to the module that does this
>function)
>visualization -> plotting (map to the module that does this function)
>documentation -> NEW Component
>dataset -> NEW Component
>
>A note about rcmet above:
>
>Here are 14 open issues with rcmet as the component and what I think a
>reasonable mapping could be:
>
>(general) CLIMATE-261 Consolidate Code that converts a String into a
>Datetime Object
>(general) CLIMATE-259 Create branch to refactor updates to ui/services to
>support multiple metrics/plotting
>(documentation) CLIMATE-258 Improve Evaluation documentation
>(dataset) CLIMATE-219 Add name attribute to Dataset
>(metrics) CLIMATE-218 Update metric handling in Evaluation to coincide
>with new Metric definition
>(general) CLIMATE-217 Add metrics.py for OCW refactoring
>(general) CLIMATE-214 Add evaluation.py to OCW
>(dataset_processor) CLIMATE-179 Add support for Observation/Reference
>option when doing Spatial Regridding
>(general) CLIMATE-137 OCW refactoring code
>(general) CLIMATE-50 RCMET needs to use a logger instead of prints
>(general) CLIMATE-49 Add the 'obs' regrid option into
>toolkit.do_data_prep.prep_data function
>(REMOVE) CLIMATE-47 precipFlag attribute within the Model class needs to
>be refactored - Not an issue with OCW Dataset Class
>(general) CLIMATE-8 CLIMATE-7 SubRegions Support
>(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
>
>Thanks for allowing me to bump this thread to top of your inbox.
>
>-Cam
>
>
>
>On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
>chris.a.mattmann@jpl.nasa.gov> wrote:
>
>> Perfect
>>
>> Sent from my iPhone
>>
>> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org> wrote:
>>
>> > If people need to catch up on the refactoring that's been occurring
>>they
>> > can find the original proposal for refactoring at [1]. The full thread
>> > where this was discussed can be found in the mail archives at [2]. The
>> wiki
>> > entry that Mazi made detailing proposed package layouts (including the
>> one
>> > we ultimately went with) is available at [3].
>> >
>> > To summate:
>> >
>> > The old code (which was called RCMET) is being refactored into the ocw
>> > package with the intention of making the code base more maintainable
>>and
>> > the API nice and pretty.
>> >
>> > Hopefully this is sufficiently verbose. I don't have the time to go
>>into
>> > more detail at the moment. If anyone is confused feel free to ask away
>> and
>> > I'll try to elaborate later!!
>> >
>> > Thanks
>> > Mike
>> >
>> >
>> > [1]: http://s.apache.org/RKI
>> > [2]:
>> >
>>
>>https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mb
>>ox/browser
>> > [3]:
>> >
>>
>>https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbenc
>>h+API+summary
>> >
>> >
>> > -- Joyce
>> >
>> >
>> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
>> > chris.a.mattmann@jpl.nasa.gov> wrote:
>> >
>> >> Can you detail "the refactoring" so everyone on the list here knows
>>what
>> >> you are talking about?
>> >>
>> >> A few paragraphs would be great, Mike, thanks.
>> >>
>> >> Cheers,
>> >> Chris
>> >>
>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> Chris Mattmann, Ph.D.
>> >> Senior Computer Scientist
>> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> Office: 171-266B, Mailstop: 171-246
>> >> Email: chris.a.mattmann@nasa.gov
>> >> WWW: http://sunset.usc.edu/~mattmann/
>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> Adjunct Assistant Professor, Computer Science Department
>> >> University of Southern California, Los Angeles, CA 90089 USA
>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Michael Joyce <jo...@apache.org>
>> >> Reply-To: "dev@climate.incubator.apache.org"
>> >> <de...@climate.incubator.apache.org>
>> >> Date: Friday, August 16, 2013 10:07 AM
>> >> To: dev <de...@climate.incubator.apache.org>
>> >> Subject: Re: JIRA component names
>> >>
>> >>> The 3 that caught my eye were:
>> >>>
>> >>> rcmet
>> >>> rcmet ui
>> >>> rcmet
>> >>>
>> >>> As to what they should be instead I don't know. 'rcmet ui' could
>> easily be
>> >>> 'ocw ui' without loss of clarity. With the refactoring I don't know
>> what
>> >>> we
>> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs to be
>> there at
>> >>> all, so I don't know if we need to think of an alternative.
>> >>>
>> >>>
>> >>>
>> >>> -- Joyce
>> >>>
>> >>>
>> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
>> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
>> >>>
>> >>>> Can you be more specific and propose e.g., :
>> >>>>
>> >>>> A1->B1
>> >>>> A2->B2
>> >>>> ..
>> >>>>
>> >>>> Where A is the set of "JPL/RCMES centric" names and B is the new
>> >>>> proposed one?
>> >>>>
>> >>>> Cheers,
>> >>>> Chris
>> >>>>
>> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >>>> Chris Mattmann, Ph.D.
>> >>>> Senior Computer Scientist
>> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >>>> Office: 171-266B, Mailstop: 171-246
>> >>>> Email: chris.a.mattmann@nasa.gov
>> >>>> WWW: http://sunset.usc.edu/~mattmann/
>> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >>>> Adjunct Assistant Professor, Computer Science Department
>> >>>> University of Southern California, Los Angeles, CA 90089 USA
>> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: Michael Joyce <jo...@apache.org>
>> >>>> Reply-To: "dev@climate.incubator.apache.org"
>> >>>> <de...@climate.incubator.apache.org>
>> >>>> Date: Friday, August 16, 2013 9:31 AM
>> >>>> To: dev <de...@climate.incubator.apache.org>
>> >>>> Subject: JIRA component names
>> >>>>
>> >>>>> Some of our JIRA components are very JPL/RCMES-centric. What does
>> >>>> everyone
>> >>>>> think of switching these over to something more generic? Ideas on
>> >>>> names?
>> >>>>>
>> >>>>> -- Joyce
>> >>
>> >>
>>
Re: JIRA component names
Posted by Cameron Goodale <go...@apache.org>.
Hey Guys,
I am going to take a crack and the task of mapping A1 -> B1 that Chris
mentioned since I have been making JIRAs and wishing for some other
components in the list. Since the new OCW refactoring introduces some new
software modules/components i think it makes sense to align JIRA issues
with each area of the code. This helps map issues to modules in the code,
items tasks that touch large sweeping parts of the code should go under
'general' and they need a closer look since they are probably taking on too
much work and need sub-tasks or should be broken into smaller chunks.
rcmed -> data_source (this would also relate to ESG work or developing an
interface to OpenDAP moving forward)
rcmet -> None (just drop this from the OCW issue tracker. RCMET is a JPL
project that is built on OCW)
rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle. Webapp is
generic enough that we can change to Ember.js and CherryPy if we like)
regridding -> dataset_processor (map to the module that does this function)
visualization -> plotting (map to the module that does this function)
documentation -> NEW Component
dataset -> NEW Component
A note about rcmet above:
Here are 14 open issues with rcmet as the component and what I think a
reasonable mapping could be:
(general) CLIMATE-261 Consolidate Code that converts a String into a
Datetime Object
(general) CLIMATE-259 Create branch to refactor updates to ui/services to
support multiple metrics/plotting
(documentation) CLIMATE-258 Improve Evaluation documentation
(dataset) CLIMATE-219 Add name attribute to Dataset
(metrics) CLIMATE-218 Update metric handling in Evaluation to coincide
with new Metric definition
(general) CLIMATE-217 Add metrics.py for OCW refactoring
(general) CLIMATE-214 Add evaluation.py to OCW
(dataset_processor) CLIMATE-179 Add support for Observation/Reference
option when doing Spatial Regridding
(general) CLIMATE-137 OCW refactoring code
(general) CLIMATE-50 RCMET needs to use a logger instead of prints
(general) CLIMATE-49 Add the 'obs' regrid option into
toolkit.do_data_prep.prep_data function
(REMOVE) CLIMATE-47 precipFlag attribute within the Model class needs to
be refactored - Not an issue with OCW Dataset Class
(general) CLIMATE-8 CLIMATE-7 SubRegions Support
(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function
Thanks for allowing me to bump this thread to top of your inbox.
-Cam
On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> Perfect
>
> Sent from my iPhone
>
> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org> wrote:
>
> > If people need to catch up on the refactoring that's been occurring they
> > can find the original proposal for refactoring at [1]. The full thread
> > where this was discussed can be found in the mail archives at [2]. The
> wiki
> > entry that Mazi made detailing proposed package layouts (including the
> one
> > we ultimately went with) is available at [3].
> >
> > To summate:
> >
> > The old code (which was called RCMET) is being refactored into the ocw
> > package with the intention of making the code base more maintainable and
> > the API nice and pretty.
> >
> > Hopefully this is sufficiently verbose. I don't have the time to go into
> > more detail at the moment. If anyone is confused feel free to ask away
> and
> > I'll try to elaborate later!!
> >
> > Thanks
> > Mike
> >
> >
> > [1]: http://s.apache.org/RKI
> > [2]:
> >
> https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mbox/browser
> > [3]:
> >
> https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbench+API+summary
> >
> >
> > -- Joyce
> >
> >
> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
> > chris.a.mattmann@jpl.nasa.gov> wrote:
> >
> >> Can you detail "the refactoring" so everyone on the list here knows what
> >> you are talking about?
> >>
> >> A few paragraphs would be great, Mike, thanks.
> >>
> >> Cheers,
> >> Chris
> >>
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> Chris Mattmann, Ph.D.
> >> Senior Computer Scientist
> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> Office: 171-266B, Mailstop: 171-246
> >> Email: chris.a.mattmann@nasa.gov
> >> WWW: http://sunset.usc.edu/~mattmann/
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> Adjunct Assistant Professor, Computer Science Department
> >> University of Southern California, Los Angeles, CA 90089 USA
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Michael Joyce <jo...@apache.org>
> >> Reply-To: "dev@climate.incubator.apache.org"
> >> <de...@climate.incubator.apache.org>
> >> Date: Friday, August 16, 2013 10:07 AM
> >> To: dev <de...@climate.incubator.apache.org>
> >> Subject: Re: JIRA component names
> >>
> >>> The 3 that caught my eye were:
> >>>
> >>> rcmet
> >>> rcmet ui
> >>> rcmet
> >>>
> >>> As to what they should be instead I don't know. 'rcmet ui' could
> easily be
> >>> 'ocw ui' without loss of clarity. With the refactoring I don't know
> what
> >>> we
> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs to be
> there at
> >>> all, so I don't know if we need to think of an alternative.
> >>>
> >>>
> >>>
> >>> -- Joyce
> >>>
> >>>
> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
> >>> chris.a.mattmann@jpl.nasa.gov> wrote:
> >>>
> >>>> Can you be more specific and propose e.g., :
> >>>>
> >>>> A1->B1
> >>>> A2->B2
> >>>> ..
> >>>>
> >>>> Where A is the set of "JPL/RCMES centric" names and B is the new
> >>>> proposed one?
> >>>>
> >>>> Cheers,
> >>>> Chris
> >>>>
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>> Chris Mattmann, Ph.D.
> >>>> Senior Computer Scientist
> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >>>> Office: 171-266B, Mailstop: 171-246
> >>>> Email: chris.a.mattmann@nasa.gov
> >>>> WWW: http://sunset.usc.edu/~mattmann/
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>> Adjunct Assistant Professor, Computer Science Department
> >>>> University of Southern California, Los Angeles, CA 90089 USA
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Michael Joyce <jo...@apache.org>
> >>>> Reply-To: "dev@climate.incubator.apache.org"
> >>>> <de...@climate.incubator.apache.org>
> >>>> Date: Friday, August 16, 2013 9:31 AM
> >>>> To: dev <de...@climate.incubator.apache.org>
> >>>> Subject: JIRA component names
> >>>>
> >>>>> Some of our JIRA components are very JPL/RCMES-centric. What does
> >>>> everyone
> >>>>> think of switching these over to something more generic? Ideas on
> >>>> names?
> >>>>>
> >>>>> -- Joyce
> >>
> >>
>
Re: JIRA component names
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
Perfect
Sent from my iPhone
On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <jo...@apache.org> wrote:
> If people need to catch up on the refactoring that's been occurring they
> can find the original proposal for refactoring at [1]. The full thread
> where this was discussed can be found in the mail archives at [2]. The wiki
> entry that Mazi made detailing proposed package layouts (including the one
> we ultimately went with) is available at [3].
>
> To summate:
>
> The old code (which was called RCMET) is being refactored into the ocw
> package with the intention of making the code base more maintainable and
> the API nice and pretty.
>
> Hopefully this is sufficiently verbose. I don't have the time to go into
> more detail at the moment. If anyone is confused feel free to ask away and
> I'll try to elaborate later!!
>
> Thanks
> Mike
>
>
> [1]: http://s.apache.org/RKI
> [2]:
> https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mbox/browser
> [3]:
> https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbench+API+summary
>
>
> -- Joyce
>
>
> On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
> chris.a.mattmann@jpl.nasa.gov> wrote:
>
>> Can you detail "the refactoring" so everyone on the list here knows what
>> you are talking about?
>>
>> A few paragraphs would be great, Mike, thanks.
>>
>> Cheers,
>> Chris
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW: http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Michael Joyce <jo...@apache.org>
>> Reply-To: "dev@climate.incubator.apache.org"
>> <de...@climate.incubator.apache.org>
>> Date: Friday, August 16, 2013 10:07 AM
>> To: dev <de...@climate.incubator.apache.org>
>> Subject: Re: JIRA component names
>>
>>> The 3 that caught my eye were:
>>>
>>> rcmet
>>> rcmet ui
>>> rcmet
>>>
>>> As to what they should be instead I don't know. 'rcmet ui' could easily be
>>> 'ocw ui' without loss of clarity. With the refactoring I don't know what
>>> we
>>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs to be there at
>>> all, so I don't know if we need to think of an alternative.
>>>
>>>
>>>
>>> -- Joyce
>>>
>>>
>>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
>>> chris.a.mattmann@jpl.nasa.gov> wrote:
>>>
>>>> Can you be more specific and propose e.g., :
>>>>
>>>> A1->B1
>>>> A2->B2
>>>> ..
>>>>
>>>> Where A is the set of "JPL/RCMES centric" names and B is the new
>>>> proposed one?
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> Chris Mattmann, Ph.D.
>>>> Senior Computer Scientist
>>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>> Office: 171-266B, Mailstop: 171-246
>>>> Email: chris.a.mattmann@nasa.gov
>>>> WWW: http://sunset.usc.edu/~mattmann/
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> Adjunct Assistant Professor, Computer Science Department
>>>> University of Southern California, Los Angeles, CA 90089 USA
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Michael Joyce <jo...@apache.org>
>>>> Reply-To: "dev@climate.incubator.apache.org"
>>>> <de...@climate.incubator.apache.org>
>>>> Date: Friday, August 16, 2013 9:31 AM
>>>> To: dev <de...@climate.incubator.apache.org>
>>>> Subject: JIRA component names
>>>>
>>>>> Some of our JIRA components are very JPL/RCMES-centric. What does
>>>> everyone
>>>>> think of switching these over to something more generic? Ideas on
>>>> names?
>>>>>
>>>>> -- Joyce
>>
>>
Re: JIRA component names
Posted by Michael Joyce <jo...@apache.org>.
If people need to catch up on the refactoring that's been occurring they
can find the original proposal for refactoring at [1]. The full thread
where this was discussed can be found in the mail archives at [2]. The wiki
entry that Mazi made detailing proposed package layouts (including the one
we ultimately went with) is available at [3].
To summate:
The old code (which was called RCMET) is being refactored into the ocw
package with the intention of making the code base more maintainable and
the API nice and pretty.
Hopefully this is sufficiently verbose. I don't have the time to go into
more detail at the moment. If anyone is confused feel free to ask away and
I'll try to elaborate later!!
Thanks
Mike
[1]: http://s.apache.org/RKI
[2]:
https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mbox/browser
[3]:
https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbench+API+summary
-- Joyce
On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> Can you detail "the refactoring" so everyone on the list here knows what
> you are talking about?
>
> A few paragraphs would be great, Mike, thanks.
>
> Cheers,
> Chris
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
>
> -----Original Message-----
> From: Michael Joyce <jo...@apache.org>
> Reply-To: "dev@climate.incubator.apache.org"
> <de...@climate.incubator.apache.org>
> Date: Friday, August 16, 2013 10:07 AM
> To: dev <de...@climate.incubator.apache.org>
> Subject: Re: JIRA component names
>
> >The 3 that caught my eye were:
> >
> >rcmet
> >rcmet ui
> >rcmet
> >
> >As to what they should be instead I don't know. 'rcmet ui' could easily be
> >'ocw ui' without loss of clarity. With the refactoring I don't know what
> >we
> >want to call 'rcmet' and 'rcmed' doesn't seem like it needs to be there at
> >all, so I don't know if we need to think of an alternative.
> >
> >
> >
> >-- Joyce
> >
> >
> >On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
> >chris.a.mattmann@jpl.nasa.gov> wrote:
> >
> >> Can you be more specific and propose e.g., :
> >>
> >> A1->B1
> >> A2->B2
> >> ..
> >>
> >> Where A is the set of "JPL/RCMES centric" names and B is the new
> >> proposed one?
> >>
> >> Cheers,
> >> Chris
> >>
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> Chris Mattmann, Ph.D.
> >> Senior Computer Scientist
> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> Office: 171-266B, Mailstop: 171-246
> >> Email: chris.a.mattmann@nasa.gov
> >> WWW: http://sunset.usc.edu/~mattmann/
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> Adjunct Assistant Professor, Computer Science Department
> >> University of Southern California, Los Angeles, CA 90089 USA
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Michael Joyce <jo...@apache.org>
> >> Reply-To: "dev@climate.incubator.apache.org"
> >> <de...@climate.incubator.apache.org>
> >> Date: Friday, August 16, 2013 9:31 AM
> >> To: dev <de...@climate.incubator.apache.org>
> >> Subject: JIRA component names
> >>
> >> >Some of our JIRA components are very JPL/RCMES-centric. What does
> >>everyone
> >> >think of switching these over to something more generic? Ideas on
> >>names?
> >> >
> >> >-- Joyce
> >>
> >>
>
>
Re: JIRA component names
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
Can you detail "the refactoring" so everyone on the list here knows what
you are talking about?
A few paragraphs would be great, Mike, thanks.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Michael Joyce <jo...@apache.org>
Reply-To: "dev@climate.incubator.apache.org"
<de...@climate.incubator.apache.org>
Date: Friday, August 16, 2013 10:07 AM
To: dev <de...@climate.incubator.apache.org>
Subject: Re: JIRA component names
>The 3 that caught my eye were:
>
>rcmet
>rcmet ui
>rcmet
>
>As to what they should be instead I don't know. 'rcmet ui' could easily be
>'ocw ui' without loss of clarity. With the refactoring I don't know what
>we
>want to call 'rcmet' and 'rcmed' doesn't seem like it needs to be there at
>all, so I don't know if we need to think of an alternative.
>
>
>
>-- Joyce
>
>
>On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
>chris.a.mattmann@jpl.nasa.gov> wrote:
>
>> Can you be more specific and propose e.g., :
>>
>> A1->B1
>> A2->B2
>> ..
>>
>> Where A is the set of "JPL/RCMES centric" names and B is the new
>> proposed one?
>>
>> Cheers,
>> Chris
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW: http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Michael Joyce <jo...@apache.org>
>> Reply-To: "dev@climate.incubator.apache.org"
>> <de...@climate.incubator.apache.org>
>> Date: Friday, August 16, 2013 9:31 AM
>> To: dev <de...@climate.incubator.apache.org>
>> Subject: JIRA component names
>>
>> >Some of our JIRA components are very JPL/RCMES-centric. What does
>>everyone
>> >think of switching these over to something more generic? Ideas on
>>names?
>> >
>> >-- Joyce
>>
>>
Re: JIRA component names
Posted by Michael Joyce <jo...@apache.org>.
The 3 that caught my eye were:
rcmet
rcmet ui
rcmet
As to what they should be instead I don't know. 'rcmet ui' could easily be
'ocw ui' without loss of clarity. With the refactoring I don't know what we
want to call 'rcmet' and 'rcmed' doesn't seem like it needs to be there at
all, so I don't know if we need to think of an alternative.
-- Joyce
On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> Can you be more specific and propose e.g., :
>
> A1->B1
> A2->B2
> ..
>
> Where A is the set of "JPL/RCMES centric" names and B is the new
> proposed one?
>
> Cheers,
> Chris
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
>
> -----Original Message-----
> From: Michael Joyce <jo...@apache.org>
> Reply-To: "dev@climate.incubator.apache.org"
> <de...@climate.incubator.apache.org>
> Date: Friday, August 16, 2013 9:31 AM
> To: dev <de...@climate.incubator.apache.org>
> Subject: JIRA component names
>
> >Some of our JIRA components are very JPL/RCMES-centric. What does everyone
> >think of switching these over to something more generic? Ideas on names?
> >
> >-- Joyce
>
>
Re: JIRA component names
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
Can you be more specific and propose e.g., :
A1->B1
A2->B2
..
Where A is the set of "JPL/RCMES centric" names and B is the new
proposed one?
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Michael Joyce <jo...@apache.org>
Reply-To: "dev@climate.incubator.apache.org"
<de...@climate.incubator.apache.org>
Date: Friday, August 16, 2013 9:31 AM
To: dev <de...@climate.incubator.apache.org>
Subject: JIRA component names
>Some of our JIRA components are very JPL/RCMES-centric. What does everyone
>think of switching these over to something more generic? Ideas on names?
>
>-- Joyce