Re: [RESULT] [VOTE] Designating maintainers for some Spark components

[Matei Zaharia <ma...@gmail.com>]

An update on this: After adding the initial maintainer list, we got feedback to add more maintainers for some components, so we added four others (Josh Rosen for core API, Mark Hamstra for scheduler, Shivaram Venkataraman for MLlib and Xiangrui Meng for Python). We also decided to lower the "timeout" for waiting for a maintainer to a week. Hopefully this will provide more options for reviewing in these components.

The complete list is available at https://cwiki.apache.org/confluence/display/SPARK/Committers.

Matei

> On Nov 8, 2014, at 7:28 PM, Matei Zaharia <ma...@gmail.com> wrote:
> 
> Thanks everyone for voting on this. With all of the PMC votes being for, the vote passes, but there were some concerns that I wanted to address for everyone who brought them up, as well as in the wording we will use for this policy.
> 
> First, like every Apache project, Spark follows the Apache voting process (http://www.apache.org/foundation/voting.html), wherein all code changes are done by consensus. This means that any PMC member can block a code change on technical grounds, and thus that there is consensus when something goes in. It's absolutely true that every PMC member is responsible for the whole codebase, as Greg said (not least due to legal reasons, e.g. making sure it complies to licensing rules), and this idea will not change that. To make this clear, I will include that in the wording on the project page, to make sure new committers and other community members are all aware of it.
> 
> What the maintainer model does, instead, is to change the review process, by having a required review from some people on some types of code changes (assuming those people respond in time). Projects can have their own diverse review processes (e.g. some do commit-then-review and others do review-then-commit, some point people to specific reviewers, etc). This kind of process seems useful to try (and to refine) as the project grows. We will of course evaluate how it goes and respond to any problems.
> 
> So to summarize,
> 
> - Every committer is responsible for, and more than welcome to review and vote on, every code change. In fact all community members are welcome to do this, and lots are doing it.
> - Everyone has the same voting rights on these code changes (namely consensus as described at http://www.apache.org/foundation/voting.html)
> - Committers will be asked to run patches that are making architectural and API changes by the maintainers before merging.
> 
> In practice, none of this matters too much because we are not exactly a hot-well of discord ;), and even in the case of discord, the point of the ASF voting process is to create consensus. The goal is just to have a better structure for reviewing and minimize the chance of errors.
> 
> Here is a tally of the votes:
> 
> Binding votes (from PMC): 17 +1, no 0 or -1
> 
> Matei Zaharia
> Michael Armbrust
> Reynold Xin
> Patrick Wendell
> Andrew Or
> Prashant Sharma
> Mark Hamstra
> Xiangrui Meng
> Ankur Dave
> Imran Rashid
> Jason Dai
> Tom Graves
> Sean McNamara
> Nick Pentreath
> Josh Rosen
> Kay Ousterhout
> Tathagata Das
> 
> Non-binding votes: 18 +1, one +0, one -1
> 
> +1:
> Nan Zhu
> Nicholas Chammas
> Denny Lee
> Cheng Lian
> Timothy Chen
> Jeremy Freeman
> Cheng Hao
> Jackylk Likun
> Kousuke Saruta
> Reza Zadeh
> Xuefeng Wu
> Witgo
> Manoj Babu
> Ravindra Pesala
> Liquan Pei
> Kushal Datta
> Davies Liu
> Vaquar Khan
> 
> +0: Corey Nolet
> 
> -1: Greg Stein
> 
> I'll send another email when I have a more detailed writeup of this on the website.
> 
> Matei


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
For additional commands, e-mail: dev-help@spark.apache.org