spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matei Zaharia <>
Subject Re: [RESULT] [VOTE] Designating maintainers for some Spark components
Date Mon, 01 Dec 2014 02:39:11 GMT
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


> On Nov 8, 2014, at 7:28 PM, Matei Zaharia <> 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 (,
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
> 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
> - 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:
For additional commands, e-mail:

View raw message