Dear Chris, This debate just wastes my time. I am not simply talking about the advantages or disadvantages. The old one has serious problems. If anyones know the problem, that person would never use the module.
The module of the debate is too simple to spend my time to discuss. Anyone at JPL can write the code with same functionality within an hour. Thanks, Kyo On 5/12/15, 9:33 AM, "Mattmann, Chris A (3980)" <chris.a.mattm...@jpl.nasa.gov> wrote: >I don¹t think we should dictate everything be code reviewed. I¹ve >seen this directly lead to conversations that are relevant to >development being buried in Github. Take for example your and >Whitehall¹s conversation(s) with Kyo that I doubt anyone here has >ever seen since they aren¹t even commenting on the Github. Yes, >Github emails are sent to the dev list, my guess is that people >ignore them. > >On the code review issue - Kyo (or others) shouldn¹t have to endlessly >debate or discuss the advantages or disadvantages of this or that >before simply pushing code, and pushing tests. My general rule of >thumb is that there are CTR and RTC workflows and use cases for >both. RTC works great when it¹s possibly controversial or when you >really want someone¹s eyes on your code for review. However it¹s >also overhead that I do not believe is needed if a developer wants >to push forward and scratch his or her itch, in an area of the >codebase that they are working on. The codebase is factored out >enough reasonably well so that people can work on things in parallel >and independently. When in doubt, ask. > > >I¹m also pretty worried since anyone that looks at the Git and >project history over the last year can easily see that Mike has >pretty much been doing the bulk load of the pushing and code >committing here. Kim¹s stepped up recently as has Kyo, which is >3 people, which is great, but I¹m worried about a project with >a small number of active developers (really 1 major) imposing >RTC - I don¹t have time to look up citations but you are free >to scope these out over the ASF archives. RTC on smaller projects >just leads to barriers. We need to be flexible and make it inviting >for at the very least, our own developers to contribute to the project, >let along attracting new people. Ross was elected in December 2014, >which is great, but we need to do better. > >Cheers, >Chris > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >Chris Mattmann, Ph.D. >Chief Architect >Instrument Software and Science Data Systems Section (398) >NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >Office: 168-519, Mailstop: 168-527 >Email: chris.a.mattm...@nasa.gov >WWW: http://sunset.usc.edu/~mattmann/ >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >Adjunct Associate 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.apache.org" <dev@climate.apache.org> >Date: Tuesday, May 12, 2015 at 8:55 AM >To: "dev@climate.apache.org" <dev@climate.apache.org> >Subject: Project Workflow > >>Hi folks, >> >>Since this has been brought up a few times on various tickets I thought >>now >>would be a good time to go over our project workflow and make sure it's >>working for us. >> >>A general overview of the workflow that we use is available at [1]. A >>brief >>overview is that: >>- ALL changes are pushed up to Github for code review before being >>merged. >>- If no issues are raised within a reasonable amount of time (usually 72 >>hours is what I stick with) those changes can be merged. >> >>In general, I've been quite happy with this workflow. We have a low >>enough >>throughput that this isn't overwhelming and I think it's great that we >>can >>get together and review each other's code. I know I appreciate the >>opportunity for people to find issues with my code before we merge it. I >>think it would be beneficial to flesh out the docs a bit more on the >>workflow (for instance, how to run tests should be included in there, how >>long to wait for a merge, etc.). So community, what do we think of our >>workflow? Do we like it so far? Is it working for us? Are there pain >>points? What don't we like? Etc. >> >>[1] >>https://cwiki.apache.org/confluence/display/CLIMATE/Developer+Getting+Sta >>r >>ted+Guide >> >> >>-- Jimmy >
