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+Star >ted+Guide > > >-- Jimmy
