Hi Tison, thanks for the clarification.
You are right, the voting document says that only PPMC members have vetoing rights. I think this answer my initial question, i.e: - vetos on code changes exist, as per Apache Voting Process - PPMC members can veto code changes - including proposals like the ones I described before Thank you to you all for the clarification and the other comments which have been very helpful. Have a great day. Regards P. On Wed, Mar 12, 2025 at 8:58 AM tison <wander4...@gmail.com> wrote: > Hi Paolo, > > Perhaps the wording in the voting process [1] page is not accurate. In > my understanding, the "Binding votes" part is appled for all the three > vote types. It writes: > > > Who can vote is, to some extent, a community-specific thing. > > > > PMC members have formally binding votes, but in general communities > encourage all their members to vote, even if their votes are only advisory. > > [1] https://www.apache.org/foundation/voting.html > > This is also true for "Votes on code modifications." So, "a negative > vote constitutes a veto" means "a negative _binding_ vote constitutes > a veto." > > Back to the divergent discussion on features, I second what Dave says. > > In my experience, the proposer can first initialize a discussion, > receive comments, and try to resolve concerns, whether or not it's > from a PPMC member. When all the concerns are well considered, the > proposal can start a vote of the proposal, with a section mentioning > all the discussed topics. > > For reference, Flink documents their discarded proposal at [2] > ("Discarded"). You can read their discussion to see the lifecycle of a > rejected proposal in that community. > > [2] > https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals > > Best, > tison. > > Paolo Bizzarri <pibi...@gmail.com> 于2025年3月12日周三 15:39写道： > > > > On Wed, Mar 12, 2025 at 1:02 AM Dave Fisher <w...@apache.org> wrote: > > > > Hi Dave, first thank you for your reply. > > > > > > > > > I’m not part of your community, so it is possible I’m misreading > this, > > > but I see some issues from a casual glance. IMO, the two proposals > need to > > > be discussed further and consensus reached before moving forward. > Calling > > > for a vote without discussion, like the second proposal, is not how > things > > > are done in ASF projects. > > > > > > It looks like some community problems have been identified, discussed a > > > lot with no consensus, then complex proposals were created by a couple > of > > > committers, these proposals were not discussed and instead pushed to a > > > vote. I am not surprised that a number of community members responded > with > > > a -1. > > > > > > I think that rather than have an abstract battle on how to vote the > > > proposers should do some work by adding to this examples repository. > If it > > > accomplishes what the proposers think it will then having it will help > > > convince the rest of the community, and then the rest of the work can > > > continue. > > > > > > > > I agree not having an abstract battle, but at the same time I would like > to > > have a clarification on which is the Apache rules for votes like this. > > Looking at the Apache document on voting, it seem clear to me that -1 is > a > > veto on code changes. > > > > Alex Porcelli said that this is not the case, but I can't find an Apache > > docs saying this. Brian Profitt, one of our mentors, suggested to ask the > > IPMC mailing list and here I am asking. > > > > I can discuss on the specific case, but I would prefer to have first a > > solid foundation on what are the agreed default Apache rules on these > > topics and where they are documented. > > > > Regards > > > > P. > > > > > > > > > Best, > > > Dave > > > > > > > > > > > Kind Regards, > > > > Justin > > > > > > > >> On 12 Mar 2025, at 7:48 AM, Paolo Bizzarri <pibi...@gmail.com> > wrote: > > > >> > > > >> Hello, > > > >> > > > >> this is Paolo Bizzarri. I am part of the Apache Kie project. > > > >> > > > >> I am looking for clarifications about the official policy of Apache > > > >> foundation about code changes and vetoes. > > > >> > > > >> As per this document in the Apache web site, a -1 to a proposal for > a > > > code > > > >> change is a veto - i.e. it "kills the proposals" > > > >> > > > >> > > > > https://www.apache.org/foundation/voting.html#:~:text=Votes%20On%20Code%20Modification,approve%20of%20this%20change.%27 > > > >> > > > >> However we got two proposals that are getting pushed through even in > > > >> presence of -1 > > > >> > > > >> https://lists.apache.org/thread/drojdtvz6xx1zo35ggjm75xdngnfcl21 > > > >> > > > >> and > > > >> > > > >> https://lists.apache.org/thread/c09l9xq0d8jz7th6k23gf5svoky06955 > > > >> > > > >> I got an answer from Alex Porcelly stating that "-1 are not vetos on > > > >> proposals" which seems wrong to me. These are code changes and so > the > > > rules > > > >> for vetoes should apply. > > > >> > > > >> Otherwise I could make a proposal like "put all passwords in plain > text > > > in > > > >> the code" and then pretend that the PR cannot be vetoed because the > > > >> corresponding proposal has already been approved, so there is > consensus. > > > >> > > > >> https://lists.apache.org/thread/r37j54k3fyg5h18d4xdlb43ff9wcq96b > > > >> > > > >> Can you clarify and provide an answer that I can forward to the kie > > > mailing > > > >> list? > > > >> > > > >> I understand that some projects have defined less restricting veto > > > >> policies, but I understand also that this is a matter of internal > rules > > > - > > > >> i.e. a way for the community of a project to decide how to work. My > > > >> understanding is that in the absence of such a decision, the Apache > > > default > > > >> rules apply. > > > >> > > > >> Regards > > > >> > > > >> Paolo Bizzarri > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
