spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davies Liu <>
Subject Re: [VOTE] Designating maintainers for some Spark components
Date Fri, 07 Nov 2014 23:18:38 GMT
-1 (not binding, +1 for maintainer, -1 for sign off)

Agree with Greg and Vinod. In the beginning, everything is better
(more efficient, more focus), but after some time, fighting begins.

Code style is the most hot topic to fight (we already saw it in some
PRs). If two committers (one of them is maintainer) have not got a
agreement on code style, before this process, they will ask comments
from other committers, but after this process, the maintainer have
higher priority to -1, then maintainer will keep his/her personal
preference, it's hard to make a agreement. Finally, different
components will have different code style (or others).

Right now, maintainers are kind of first contact or best contacts, the
best person to review the PR in that component. We could announce it,
then new contributors can easily find the right one to review.

My 2 cents.


On Thu, Nov 6, 2014 at 11:43 PM, Vinod Kumar Vavilapalli
<> wrote:
>> With the maintainer model, the process is as follows:
>> - Any committer could review the patch and merge it, but they would need to forward
it to me (or another core API maintainer) to make sure we also approve
>> - At any point during this process, I could come in and -1 it, or give feedback
>> - In addition, any other committer beyond me is still allowed to -1 this patch
>> The only change in this model is that committers are responsible to forward patches
in these areas to certain other committers. If every committer had perfect oversight of the
project, they could have also seen every patch to their component on their own, but this list
ensures that they see it even if they somehow overlooked it.
> Having done the job of playing an informal 'maintainer' of a project myself, this is
what I think you really need:
> The so called 'maintainers' do one of the below
>  - Actively poll the lists and watch over contributions. And follow what is repeated
often around here: Trust but verify.
>  - Setup automated mechanisms to send all bug-tracker updates of a specific component
to a list that people can subscribe to
> And/or
>  - Individual contributors send review requests to unofficial 'maintainers' over dev-lists
or through tools. Like many projects do with review boards and other tools.
> Note that none of the above is a required step. It must not be, that's the point. But
once set as a convention, they will all help you address your concerns with project scalability.
> Anything else that you add is bestowing privileges to a select few and forming dictatorships.
And contrary to what the proposal claims, this is neither scalable nor confirming to Apache
governance rules.
> +Vinod

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message