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 Sat, 08 Nov 2014 01:56:23 GMT
Sorry for my last email, I misunderstood the proposal here, all the
committer still have equal -1 to all the code changes.

Also, as mentioned in the proposal, the sign off only happens to
public API and architect, something like discussion about code style
things are still the same.

So, I'd revert my vote to +1. Sorry for this.


On Fri, Nov 7, 2014 at 3:18 PM, Davies Liu <> wrote:
> -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.
> Davies
> 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