You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Paolo Bizzarri <pi...@gmail.com> on 2025/03/11 20:48:24 UTC
Clarification on the -1 policy for code changes
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
Re: Clarification on the -1 policy for code changes
Posted by Alex Porcelli <po...@apache.org>.
Adding some context to this discussion:
- Apache KIE mentor Brian has provided guidance on similar matters
before [1][2].
- A guideline is already in place to define how discussions,
proposals, and votes should work [3], and it was formally approved
[4].
Regarding the proposals in question, they strictly involve moving code
from one repository to another. There is no impact on the software
itself—only on contributors working within the project.
The example given—storing passwords in plain text—seems extreme. Any
change with serious implications for users would be subject to review
and could be vetoed based on existing guidance [2]. Approved proposals
do not grant a "blank check"; changes must still be scrutinized.
Ultimately, I believe that in any open-source project, any proposal
will lead to code changes, in a way or another.
-
Alex
[1] - https://lists.apache.org/thread/1vrtdv4jy3db8wj86bgd3w6ofd0w5zb8
[2] - https://lists.apache.org/thread/sofswb9ol7srncj6fqwz1ohtq2x550ky
[3] - https://cwiki.apache.org/confluence/display/KIE/%5BPROPOSAL%5D+Community+guideline+to+define+discussion%2C+proposal+and+vote
[4] - https://lists.apache.org/thread/2vmnnnlx89f6tg4m4td46ofm7sk5mv76
On Tue, Mar 11, 2025 at 4:48 PM Paolo Bizzarri <pi...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Clarification on the -1 policy for code changes
Posted by Paolo Bizzarri <pi...@gmail.com>.
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 <wa...@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 <pi...@gmail.com> 于2025年3月12日周三 15:39写道：
> >
> > On Wed, Mar 12, 2025 at 1:02 AM Dave Fisher <wa...@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 <pi...@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-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Clarification on the -1 policy for code changes
Posted by tison <wa...@gmail.com>.
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 <pi...@gmail.com> 于2025年3月12日周三 15:39写道：
>
> On Wed, Mar 12, 2025 at 1:02 AM Dave Fisher <wa...@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 <pi...@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-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Clarification on the -1 policy for code changes
Posted by Paolo Bizzarri <pi...@gmail.com>.
On Wed, Mar 12, 2025 at 1:02 AM Dave Fisher <wa...@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 <pi...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Clarification on the -1 policy for code changes
Posted by Dave Fisher <wa...@apache.org>.
Hi,
> On Mar 11, 2025, at 4:23 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> Looking at the first propopal, I was surprised to discover https://www.kie.org/ - having a domain name like this is not in line with ASF trademark policy, nor is having a domain name like https://kogito.kie.org/. There are other trademark issues with those site(s), I trust the PPMC is aware of this and is taking steps to fix this before graduation?
While these issues may be true, let’s not spread the flow by adding something else.
> 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.
Best,
Dave
>
> Kind Regards,
> Justin
>
>> On 12 Mar 2025, at 7:48 AM, Paolo Bizzarri <pi...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Clarification on the -1 policy for code changes
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Looking at the first propopal, I was surprised to discover https://www.kie.org/ - having a domain name like this is not in line with ASF trademark policy, nor is having a domain name like https://kogito.kie.org/. There are other trademark issues with those site(s), I trust the PPMC is aware of this and is taking steps to fix this before graduation?
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.
Kind Regards,
Justin
> On 12 Mar 2025, at 7:48 AM, Paolo Bizzarri <pi...@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