On Wed, Jul 22, 2020 at 7:39 AM Imran Rashid < iras...@apache.org > wrote:

> Hi Holden,
>
> thanks for leading this discussion, I'm in favor in general.  I have one
> specific question -- these two sections seem to contradict each other
> slightly:
>
> > If there is a -1 from a non-committer, multiple committers or the PMC
> should be consulted before moving forward.
> >
> >If the original person who cast the veto can not be reached in a
> reasonable time frame given likely holidays, it is up to the PMC to decide
> the next steps within the guidelines of the ASF. This must be decided by a
> consensus vote under the ASF voting rules.
>
> I think the intent here is that if a *committer* gives a -1, then the PMC
> has to have a consensus vote?  And if a non-committer gives a -1, then
> multiple committers should be consulted?  How about combining those two
> into something like
>
> "All -1s with justification merit discussion.  A -1 from a non-committer
> can be overridden only with input from multiple committers.  A -1 from a
> committer requires a consensus vote of the PMC under ASF voting rules".
>
I can work with that although it wasn’t quite what I was originally going
for. I didn’t intend to have committer -1s be eligible for override. I
believe committers have demonstrated sufficient merit; they are the same as
PMC member -1s in our project.

My aim was just if something weird happens (like say I had a pending -1
before my motorcycle crash last year) we go to the PMC and take a binding
vote on what to do, and most likely someone on the PMC will reach out to
the ASF for understanding around the guidelines.

What about:

All -1s with justification merit discussion.  A -1 from a non-committer can
be overridden only with input from multiple committers and suitable time
for any committer to raise concerns.  A -1 from a committer who can not be
reached requires a consensus vote of the PMC under ASF voting rules to
determine the next steps within the ASF guidelines for vetos.

>
>
> thanks,
> Imran
>
>
> On Tue, Jul 21, 2020 at 3:41 PM Holden Karau <hol...@pigscanfly.ca> wrote:
>
>> Hi Spark Developers,
>>
>> There has been a rather active discussion regarding the specific vetoes
>> that occured during Spark 3. From that I believe we are now mostly in
>> agreement that it would be best to clarify our rules around code vetoes &
>> merging in general. Personally I believe this change is important to help
>> improve the appearance of a level playing field in the project.
>>
>> Once discussion settles I'll run this by a copy editor, my grammar isn't
>> amazing, and bring forward for a vote.
>>
>> The current Spark committer guide is at https://spark.apache.org/
>> committers.html. I am proposing we add a section on when it is OK to
>> merge PRs directly above the section on how to merge PRs. The text I am
>> proposing to amend our committer guidelines with is:
>>
>> PRs shall not be merged during active on topic discussion except for
>> issues like 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.
>>
>> For the purposes of a -1 on code changes, a qualified voter includes all
>> PMC members and committers in the project. For a -1 to be a valid veto it
>> must include a technical reason. The reason can include things like the
>> change may introduce a maintenance burden or is not the direction of Spark.
>>
>> If there is a -1 from a non-committer, multiple committers or the PMC
>> should be consulted before moving forward.
>>
>>
>> If the original person who cast the veto can not be reached in a
>> reasonable time frame given likely holidays, it is up to the PMC to decide
>> the next steps within the guidelines of the ASF. This must be decided by a
>> consensus vote under the ASF voting rules.
>>
>> 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 all parties take the time to build consensus prior to additional
>> feature work.
>>
>>
>> Being a committer means exercising your judgement, while working in a
>> community with diverse views. There is nothing wrong in getting a second
>> (or 3rd or 4th) 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 that makes it easier for us to reach
>> consensus. If you have ideas on how to improve these guidelines, or other
>> parts of how the Spark project operates you should reach out on the dev@
>> list to start the discussion.
>>
>>
>>
>> Kind Regards,
>>
>> Holden
>>
>> --
>> Twitter: https://twitter.com/holdenkarau
>> Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/
>> 2MaRAG9  <https://amzn.to/2MaRAG9>
>> YouTube Live Streams: https://www.youtube.com/user/holdenkarau
>>
>

Reply via email to