I’d love to know what is our *current* process before discussing changing it.
Is there a link, or are new folks expected to read through every email from the
past 5 years to establish context?
> On Oct 25, 2019, at 11:49 AM, Kirk Lund wrote:
>
> We've been operating under a different process
We've been operating under a different process than what you are quoting --
I'm not saying that our current process is correct (or even wrong), however
it has been different than the quoted process in some ways.
We previously reached consensus for our own process during the first couple
years of t
Successful Apache projects value a broad and collaborative community over the
details of the code itself. I don’t think the goal is to hammer out rules like
“you can’t merge if someone has requested changes” or “anyone has the right to
overrule someone’s request for changes”.
Think of “reque
@Owen I'm fine with following the "requesting changes is the same as -1"
rule, but I don't think there is consensus from the whole community on this
yet. I was previously told that contributors should make every effort to
address the requested changes, but unless a committer actually comments
"-1"
>
> @Owen It's unclear to me whether "requesting changes" is the same thing as
> a -1 vote. I had previously discussed this with some other committers who
> were under the impression that they were not the same thing.
>
If that’s not a -1, what is?
Many apache projects started out long ago when
Edit: Helena has mentioned that a review can be dismissed.
[spelling mistake]
On Thu, Oct 24, 2019 at 4:35 PM Nabarun Nag wrote:
> Hi Aaron / Kirk,
>
> Thank you for the update. As Owen has mentioned that if there is a change
> request from someone with write permission to the branch, we shoul
Hi Aaron / Kirk,
Thank you for the update. As Owen has mentioned that if there is a change
request from someone with write permission to the branch, we should address
it, or request a re-review.
In the "rogue developer" case which Kirk mentioned, and I hope that this
does not happen in the Apache
@Naba That's the one. It was approved shortly after I sent that message
though. It should be reproducible by requesting changes on a PR with no
other reviews.
@Owen It's unclear to me whether "requesting changes" is the same thing as
a -1 vote. I had previously discussed this with some other commi
@Aaron : which PR are you referring to? I can only see "GEODE-7326: Add
cache gets timers" which can be merged? I can get some more idea when I can
see whats going on.
Regards
Naba
@Kirk : let me run some experiments.
Regards
Naba
On Thu, Oct 24, 2019 at 2:57 PM Helena Bales wrote:
> To Kirk
From https://www.apache.org/foundation/voting.html
"A code-modification proposal may be stopped dead in its tracks by a -1 vote by
a qualified voter."
So I think this is consistent with Apache guidelines...
> On Oct 24, 2019, at 2:51 PM, Kirk Lund wrote:
>
> One side effect is that any single
To Kirk's point, there is actually a way to dismiss requests for review.
Info here:
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review
There's instructions in there for how to dismiss a request for changes. Not
everyone can do that, so if
Thanks, Naba. Are we now blocking merges for PRs that have
changes requested?
I have a PR right now where instead of the merge button it has the message,
"Merging can be performed automatically once the requested changes are
addressed." It also happens to not have any approvals, so it's possible
t
One side effect is that any single request for changes will now completely
block merging the PR. I'm not certain this was intentional? One rogue
developer could block the merging of any or every PR. I'm not sure one
person should have that much power...
On Thu, Oct 24, 2019 at 2:25 PM Nabarun Nag
Hi, Geode dev Community,
This is an announcement that the GitHub branch protection rules are *now
active* on develop branch for Apache Geode.
The following rules are currently active :
- Require pull request reviews before merging - at least 1
- Require status checks to pass before merging
[
14 matches
Mail list logo
