spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prashant Sharma <>
Subject Re: [VOTE] Update the committer guidelines to clarify when to commit changes.
Date Mon, 03 Aug 2020 04:33:09 GMT

On Fri, Jul 31, 2020 at 10:18 PM Xiao Li <> wrote:

> +1
> Xiao
> On Fri, Jul 31, 2020 at 9:32 AM Mridul Muralidharan <>
> wrote:
>> +1
>> Thanks,
>> Mridul
>> On Thu, Jul 30, 2020 at 4:49 PM Holden Karau <>
>> wrote:
>>> Hi Spark Developers,
>>> After the discussion of the proposal to amend Spark committer
>>> guidelines, it appears folks are generally in agreement on policy
>>> clarifications. (See
>>> as well as some on the private@ list for PMC.) Therefore, I am calling
>>> for a majority VOTE, which will last at least 72 hours. See the ASF voting
>>> rules for procedural changes at
>>> The proposal is to add a new section entitled “When to Commit” to the
>>> Spark committer guidelines, currently at
>>> PRs shall not be merged during active, on-topic discussion unless they
>>> address issues such as critical security fixes of a public vulnerability.
>>> Under extenuating circumstances, PRs may be merged during active, off-topic
>>> discussion and the discussion directed to a more appropriate venue. Time
>>> should be given prior to merging for those involved with the conversation
>>> to explain if they believe they are on-topic.
>>> Lazy consensus requires giving time for discussion to settle while
>>> understanding that people may not be working on Spark as their full-time
>>> job and may take holidays. It is believed that by doing this, we can limit
>>> how often people feel the need to exercise their veto.
>>> All -1s with justification merit discussion.  A -1 from a non-committer
>>> can be overridden only with input from multiple committers, and suitable
>>> time must be offered for any committer to raise concerns. A -1 from a
>>> committer who cannot be reached requires a consensus vote of the PMC under
>>> ASF voting rules to determine the next steps within the ASF guidelines for
>>> code vetoes ( ).
>>> These policies serve to reiterate the core principle that code must not
>>> be merged with a pending veto or before a consensus has been reached (lazy
>>> or otherwise).
>>> It is the PMC’s hope that vetoes continue to be infrequent, and when
>>> they occur, that all parties will take the time to build consensus prior to
>>> additional feature work.
>>> Being a committer means exercising your judgement while working in a
>>> community of people with diverse views. There is nothing wrong in getting a
>>> second (or third or fourth) opinion when you are uncertain. Thank you for
>>> your dedication to the Spark project; it is appreciated by the developers
>>> and users of Spark.
>>> It is hoped that these guidelines do not slow down development; rather,
>>> by removing some of the uncertainty, the goal is to make it easier for us
>>> to reach consensus. If you have ideas on how to improve these guidelines or
>>> other Spark project operating procedures, you should reach out on the dev@
>>> list to start the discussion.
>>> I want to thank everyone who has been involved with the discussion
>>> leading to this proposal and those of you who take the time to vote on
>>> this. I look forward to our continued collaboration in building Apache
>>> Spark.
>>> I believe we share the goal of creating a welcoming community around the
>>> project. On a personal note, it is my belief that consistently applying
>>> this policy around commits can help to make a more accessible and welcoming
>>> community.
>>> Kind Regards,
>>> Holden
>>> --
>>> Twitter:
>>> Books (Learning Spark, High Performance Spark, etc.):
>>>  <>
>>> YouTube Live Streams:
> --
> <>

View raw message