> On 19 May 2016, at 16:34, Matei Zaharia <matei.zaha...@gmail.com> wrote: > > Hi folks, > > Around 1.5 years ago, Spark added a maintainer process for reviewing API and > architectural changes > (https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers) > to make sure these are seen by people who spent a lot of time on that > component. At the time, the worry was that changes might go unnoticed as the > project grows, but there were also concerns that this approach makes the > project harder to contribute to and less welcoming. Since implementing the > model, I think that a good number of developers concluded it doesn't make a > huge difference, so because of these concerns, it may be useful to remove it. > I've also heard that we should try to keep some other instructions for > contributors to find the "right" reviewers, so it would be great to see > suggestions on that. For my part, I'd personally prefer something > "automatic", such as easily tracking who reviewed each patch and having > people look at the commit history of the module they want to work on, instead > of a list that needs to be maintained separately. >
Putting on my ASF hat, I'm supportive of this. An Apache software project is a large, shared, body of code —and committers are expected to be trusted to be allowed to contribute through, and not to break things. That's in their own patches —and in their review of other's work. Having a nominated owner of a module is marking out bits of the code as territories, which can not only keep others out of it, it can actually put extra responsibility on the maintainer, who, because they are an effective choke point for patches for a module, have to try to keep up with an ever growing patch queue. Managing code review is a scale problem; any large OSS project, especially those on a RTC process, comes up against it. I'd love to seem some good Software Engineering research/papers in this area There is one forthcoming soon, "Why Should Architecture-Savvy Developers Write Code?". This looks at some of the development practises of various ASF projects (Hadoop, Hive, Pig, OFBiz, Camel, OpenJPA) and tries to see if there is a correlation in code quality between Linked-In proclaimed architects, code contributions and the (as inferred from JIRA) quality of those classes. Having seen the draft, I think everyone should find it interesting —even if I have a few issues with some of its classifications, at least based on the analysis of my bits. http://blog.ieeesoftware.org/2016/02/why-should-software-architects-write.html What I've not seen is anything looking at what makes both a good process for succouring quality contributions, but for doing so in a way which preserves quality, maintainability and an overall coherent architecture of a large system. If there are any, I'd love a copy. -Steve --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
