Yeah Kyo I was trying to remove the need to debate and to move forward with code where we can.
Sent from my iPhone > On May 12, 2015, at 12:37 PM, Lee, Kyo (329C-Caltech) > <huikyo....@jpl.nasa.gov> wrote: > > 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 >
