spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kumar Vavilapalli <>
Subject Re: [VOTE] Designating maintainers for some Spark components
Date Fri, 07 Nov 2014 07:43:25 GMT
> 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

 - 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.


View raw message