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
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
On Tue, Jul 8, 2014 at 3:24 PM, Eric Schultz
eschu...@prplfoundation.org 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
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
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.
On Jul 8, 2014, at 3:17 PM, Jim Jagielski j...@jagunet.com 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
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
