spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matei Zaharia <matei.zaha...@gmail.com>
Subject [RESULT] [VOTE] Designating maintainers for some Spark components
Date Sun, 09 Nov 2014 03:28:20 GMT
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


Mime
View raw message