Tiago, I appreciate your interpretation of the rules of Apache voting.
However, this is your interpretation, so no, it cannot represent any basis for discussing if the proposal can be vetoed or not. As noted by Brian, the interpretation of the rules reside in the Apache itself - in our case, through the IPMC. On a side note, I think your interpretation is fundamentally wrong, but this is again my irrelevant opinion. Later I will write to IPMC ml and ask for their - more relevant and binding - opinion. Regards P. On Tue, Mar 11, 2025 at 4:27 PM Tiago Bento <tiagobe...@apache.org> wrote: > Paolo, > > Voted proposals form a "contract" between the members of a community, > and there's no veto for such cases. The veto for code modifications is > there to prevent unsafe/broken/non-conforming code from going in, the > way I see it, not to prevent contracts from being formed between the > majority of the members of a project. > > Everything we do ends up being code somehow, so there wouldn't be a > need to discriminate so clearly that vetoes only apply for code > modifications. > > E.g., If you see someone going against a voted proposal in the form of > a PR, a veto applies, because merging it would be breaking the > "contract". > > Regards, > > Tiago Bento > > On Tue, Mar 11, 2025 at 9:07 AM Toni Rikkola <trikk...@redhat.com> wrote: > > > > Yeah, that is also true :) > > Anyway I see these types of situations as swapping one problem to > another, > > but is the new problem better? Time will show. > > > > Toni > > > > On Tue, Mar 11, 2025 at 2:59 PM Francisco Javier Tirado Sarti < > > ftira...@redhat.com> wrote: > > > > > Toni, > > > We will see if nothing is really broken once the task is completed ;) > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > >
