On Wed, Jul 9, 2014 at 3:03 AM, Phil Steitz wrote:
> Any committer should be allowed to -1 a commit (with reasons) and whoever
> made the commit should have to either
> revert or answer the reasons and gain consensus...
That's my understanding of the "Vetos" section at
http://www.apache.org/
A practical example of a technical veto I've seen was when we added some
new optimisations that interacted badly with a pre-existing API in some
rare corner cases.
This actually went into a release and it wasn't until a particularly vocal
community member got round to upgrading that we became awar
I think the vetoing -1 from PMCs is mainly used for 'legal' reasons. If e.g.
some new committer adds code which he took from an external project and it's
license is not appropriate.
I've not yet seen -1 for purely technical reasons. This might happen. But
usually a consensus is reached after the
Hi,
> Ugh. That looks garbled to me. What exactly is a "code modification vote?"
> Any committer should be allowed to -1 a commit (with reasons)
Any committer can vote -1 it's just not normally binding (depending on project
guidelines), I certainly can't see it being ignored when it does hap
> On Jul 8, 2014, at 3:17 PM, Jim Jagielski wrote:
>
> The idea of CTR is that the repo that the commit is made
> to is not in the direct path to a release. Thus, one
> can commit to the repo/branch as a sort of shared sandbox.
Not necessarily. Some projects do CTR right up to release tags.
> On Jul 8, 2014, at 3:29 PM, Justin Mclean wrote:
>
> Hi,
>
>> Typically in the Apache projects, committers (folks elected by the project
>> who have commit
>> privileges) have binding vetoes.
>
> Actually the default is that only PMC members can veto code changes see under
> "Binding vote
Hi,
> Typically in the Apache projects, committers (folks elected by the project
> who have commit
> privileges) have binding vetoes.
Actually the default is that only PMC members can veto code changes see under
"Binding votes" from [1], but project guidelines may state otherwise.
Justin
1.
The idea of CTR is that the repo that the commit is made
to is not in the direct path to a release. Thus, one
can commit to the repo/branch as a sort of shared sandbox.
When a commit is proposed to enter into the release
path, that path is RTC, which means that the patch
must be proposed as a back
On Tue, Jul 8, 2014 at 3:24 PM, Eric Schultz
wrote:
> All,
>
> I'm trying to understand to the Apache Foundation model of voting in the
> commit-then-review system. If a project is running on a CTR system and
> someone says they dislike a piece of a previous commit, what happens? Does
> it require
All,
I'm trying to understand to the Apache Foundation model of voting in the
commit-then-review system. If a project is running on a CTR system and
someone says they dislike a piece of a previous commit, what happens? Does
it require consensus to remove the code or is the code removed if consensu
10 matches
Mail list logo
