LGTM.. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] 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 <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Tuesday, August 20, 2013 11:06 AM To: "[email protected]" <[email protected]> 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) < >[email protected]> 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" <[email protected]> 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) < >> >[email protected]> 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: [email protected] >> >> 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 <[email protected]> >> >> Reply-To: "[email protected]" >> >> <[email protected]> >> >> Date: Monday, August 19, 2013 7:21 PM >> >> To: "[email protected]" >> >><[email protected]> >> >> 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) < >> >> >[email protected]> wrote: >> >> > >> >> >> Perfect >> >> >> >> >> >> Sent from my iPhone >> >> >> >> >> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <[email protected]> >> >>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) < >> >> >> > [email protected]> 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: [email protected] >> >> >> >> 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 <[email protected]> >> >> >> >> Reply-To: "[email protected]" >> >> >> >> <[email protected]> >> >> >> >> Date: Friday, August 16, 2013 10:07 AM >> >> >> >> To: dev <[email protected]> >> >> >> >> 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) < >> >> >> >>> [email protected]> 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: [email protected] >> >> >> >>>> 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 <[email protected]> >> >> >> >>>> Reply-To: "[email protected]" >> >> >> >>>> <[email protected]> >> >> >> >>>> Date: Friday, August 16, 2013 9:31 AM >> >> >> >>>> To: dev <[email protected]> >> >> >> >>>> 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 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
