Toni There were multiple technical objections, repeated again and again. I won't go through them again, but let's say that there were no -1 "just in case". I hope we can agree at least on that.
There was and there is no "consensus", there is just people tired of discussing and seeing their objections ignored or answered by people in a patronizing way. You linked Apache Kafka rules. I appreciate that they have decided something together, but again, this is not Apache Kafka. This is Apache Kie. And unless we decide that Kafka rules are our rules, they are somehwat irrelevant. Good as ideas, good as a starting point but again, WE, as a community, have to decide to adopt those rules. or not. And on a side note - consensus means that we all agree on something relevant for the topic and there is a status where there is no consensus, otherwise the word is meaningless. Let's try not to redefine words. Regards P. On Tue, Mar 11, 2025 at 4:19 PM Toni Rikkola <trikk...@redhat.com> wrote: > It says: > > "To prevent vetoes from being used capriciously, the voter must provide > with the veto a technical justification showing why the change is bad > (opens a security exposure, negatively affects performance, etc. ). A veto > without a justification is invalid and has no weight." > > But it is up to the project to find consensus with the methods they select. > For example Kafka has presets for voting and what type of voting is > required for each change type. > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=34019842#Bylaws-Actions > > So now the question is what does this community think justifies a veto? > > --- > > "At least we should have tried to discuss the objections and move to some > form of consensus." > > Yes! The method where we go directly to a vote is not optimal for a healthy > community, but I was under the impression we still formed a consensus. > Consensus does not mean we all agree. It means we agree on how we disagree. > > Toni > > On Tue, Mar 11, 2025 at 3:15 PM Paolo Bizzarri <pibi...@gmail.com> wrote: > > > Tony, > > > > thank you for your reply. > > > > The Apache policy however DOES NOT says this. > > > > https://www.apache.org/foundation/voting.html > > > > At least we should have tried to discuss the objections and move to some > > form of consensus. > > > > I can't see how htis has happened. > > > > Probably I am missing something fundamental. > > > > Regards > > > > P. > > > > > > On Tue, Mar 11, 2025 at 1:47 PM Toni Rikkola <trikk...@redhat.com> > wrote: > > > > > Hello, > > > > > > For everything that has been proposed there has not been a clear > security > > > risk or performance issue, so following the original Apache guideline > -1 > > is > > > a vote against it, not a veto. Every +1 has a justification on the same > > > level as the -1 have. Both sides have had pros and cons, but neither > > > solution breaks anything for the project. We might be swapping one > > problem > > > to another, but that is I guess how the world works. > > > > > > Toni > > > > > > On Tue, Mar 11, 2025 at 12:39 PM Paolo Bizzarri <pibi...@gmail.com> > > wrote: > > > > > > > Hi Alex, > > > > > > > > thank you for the answer. > > > > > > > > this is surprising to me, since these are clearly code modifications > > and > > > > they should fall under the rules for code modifications. > > > > > > > > https://www.apache.org/foundation/voting.html > > > > > > > > I will speak with the mentors. > > > > > > > > Regards > > > > > > > > P. > > > > > > > > On Tue, Mar 11, 2025 at 11:15 AM Alex Porcelli <porce...@apache.org> > > > > wrote: > > > > > > > > > Paolo, > > > > > > > > > > Both proposals passed, as for proposals -1 see not veto. > > > > > > > > > > The first proposal is already under development. > > > > > > > > > > Please reach out to mentors to clarify about Apache policies. > > > > > > > > > > - > > > > > Alex > > > > > > > > > > On Tue, Mar 11, 2025 at 4:33 AM Paolo Bizzarri <pibi...@gmail.com> > > > > wrote: > > > > > > > > > > > I am talking about > > > > > > > > > > > > - Including Docs, Examples, and Website(s) in Apache KIE 10.1 and > > > > beyond > > > > > > > > > > > > and > > > > > > > > > > > > - Removing `build-chain`, the custom Jenkins framework, and > > > structuring > > > > > the > > > > > > codebase in a duo-repo setup for 10.2 onwards > > > > > > > > > > > > My understanding is that both these two proposals have been > > rejected, > > > > > since > > > > > > they had got both binding -1 and these are the Apache rules. > > > > > > > > > > > > But there was no explicit mention that they got rejected and > people > > > > got a > > > > > > bit uncertain. > > > > > > > > > > > > Can we confirm? > > > > > > > > > > > > Thank you. > > > > > > > > > > > > P. > > > > > > > > > > > > > > > > > > > > >
