On Wed, Dec 10, 2014 at 8:42 PM, Joey Echeverria <[email protected]> wrote:
> > though I think it will VERY MUCH impede the speed at which any new > features / bug fixes can be accomplished. > > I don't agree, at least not in the long run. Also, I think a review is > only required before checking into the main development branch. If > we're using gitflow, then commits to feature branches should be > handled by who ever is managing that feature. That can mean doing > reviews as they come in or waiting until the feature is done and > reviewing it all at once. But having code reviews saves a lot of time > in the long run. > > Joey's sentiment lines up very well with my experience to date. CtR "feels" faster, but in the long run RtC results in better throughput for stable releases because code quality converges much faster. That quality means less time spent on support and fixes later. When combined with robust automated testing it makes it very easy to maintain rigor on a release cycle. > Another thing to consider is that over time, committers should be > spending less time working on new features/fixing bugs and more time > on growing the community and providing quality code reviews is one of > the best ways to do that. > > This is also an advantage that often is under appreciated about RtC. Having regular reviews means everyone gets more practiced at both giving and receiving them. That also makes the community better at recognizing review quality and gives you valuable information about how well a contributor interacts with the overall community. It really helps to distinguish among contributors who make good contributors because they are scratching itches they have and those that will make good committers because they're thinking in terms of the overall project. As a future PMC your two big jobs will be ensuring regular quality software releases and a healthy community. Hopefully the above makes it obvious that I think RtC helps both of those endeavors. A while back there was a thread about PMC vs committer status. My apologies for not having kept up on that discussion. I believe the last bit I saw was Joe stating that his intuition was to keep them separate. I think that's a very good idea, both because it gives the community more information about people's fit for the role and it provides a more distinguished advancement path in the project. Having the rigor of RtC also provides more information about PMC suitability since you can see how a committer focuses over time on strategic issues like community vs tactical issues like a specific patch. -- Sean
