am happy to give it a
shot as well.
From: Darrel Schneider
Sent: Thursday, October 29, 2020 14:33
To: dev@geode.apache.org
Subject: Re: PR process and etiquette
+1 for adding a CONTRIBUTING.MD file
From: Sarah Abbey
Sent: Thursday, October 29, 20
+1 for adding a CONTRIBUTING.MD file
From: Sarah Abbey
Sent: Thursday, October 29, 2020 2:07 PM
To: dev@geode.apache.org
Subject: Re: PR process and etiquette
Regarding knowing who to tag in a PR, because I am working on a very specific
aspect of Geode, it was
feel in
being able to provide a thorough review.
Donal
________________
From: Udo Kohlmeyer
Sent: Wednesday, October 28, 2020 5:50 PM
To: dev@geode.apache.org
Subject: Re: PR process and etiquette
So far I would like to thank everyone for their thoughts and input.
@Dave, I w
__
From: Udo Kohlmeyer
Sent: Wednesday, October 28, 2020 5:50 PM
To: dev@geode.apache.org
Subject: Re: PR process and etiquette
So far I would like to thank everyone for their thoughts and input.
@Dave, I would love to find a solution to the partial sign-off. I’ve been
experimenti
1:50 AM
To: dev@geode.apache.org
Subject: Re: PR process and etiquette
So far I would like to thank everyone for their thoughts and input.
@Dave, I would love to find a solution to the partial sign-off. I’ve been
experimenting with the “Projects” setting. I wonder if we cannot have a
“Documentation Chec
he project.
--Udo
From: Dave Barnes
Date: Thursday, October 29, 2020 at 4:20 AM
To: dev@geode.apache.org
Subject: Re: PR process and etiquette
Here's a common use case that we should address: A single PR may require
two reviews, one for code and another for docs,
anyone who is not a committer) to comment
here. Is there anything in particular that attracts or repulses you when it
comes to contributing to the project.
--Udo
From: Dave Barnes
Date: Thursday, October 29, 2020 at 4:20 AM
To: dev@geode.apache.org
Subject: Re: PR process and etiquette
Here
reducing cognitive load for the reviewers.
>
> Full documentation here<
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection
> >
>
>
>
> From: Bruce Schuchardt
> Date: Wednesday, October 28, 2020 at 8:10 AM
How about we make this a recommendation rather than a rule?
I'd like to also recommend that contributors consider prefixing the PR
title with "DRAFT: " while it is in draft. This just makes it easier to see
at a glance that it's a draft. When I change the PR to "ready for review" I
edit the title
Hi Owen - I wasn't aware that non-committers can't add reviewers to their PRs
but I don't see how using DRAFT mode helps with that. The idea that I can't
request a review until the commit checks all pass seems absurd to me.
On 10/28/20, 9:15 AM, "Owen Nichols" wrote:
Hey Bruce, please co
For the narrow goal of making it easier for non-committers to get reviewers for
their PRs, we could also consider defining a "reviewers wanted" label. However
it might not be very obvious to new committers that they need to click the gear
to look for that label, unless we also update the PR tem
I think exploring these additions to PR reviews would be pretty helpful. It’s
worth spending the extra time to get a PR right before merging.
Anthony
> On Oct 28, 2020, at 8:40 AM, Robert Houghton wrote:
>
> There are some pieces of Apache infrastructure we can control without needing
> tick
Hey Bruce, please consider that non-committers are not permitted to add
reviewers themselves, so a consistent convention to indicate when a PR has
moved from work-in-progress to ready-for-review will help alert the community
when to assign reviewers.
Currently, I see countless creative variatio
he.org
Subject: Re: PR process and etiquette
-1
While I often use the Draft option I don't see why we want to add even more
rules about how we use github. I think it's enough to put in a PR and then add
reviewers when you're ready for comments. Getting the stink-eye for putting up
a
-1
While I often use the Draft option I don't see why we want to add even more
rules about how we use github. I think it's enough to put in a PR and then add
reviewers when you're ready for comments. Getting the stink-eye for putting up
a non-Draft PR is just going to make it more difficult to
Oops, sorry for the confusion! I’ve been working through Mario’s PRs a lot
lately.
From: Alberto Gomez
Date: Wednesday, October 28, 2020 at 7:10 AM
To: "dev@geode.apache.org" , Blake Bender
Subject: Re: PR process and etiquette
+1 to draft PRs.
By the way @Blake Bender&
+1 to draft PRs.
By the way @Blake Bender<mailto:bbl...@vmware.com>, it's me the one having the
draft PR for GEODE-8318.
Alberto G.
From: Blake Bender
Sent: Wednesday, October 28, 2020 2:28 PM
To: dev@geode.apache.org
Subject: Re: PR process and et
or sharing that.
--Udo
From: Darrel Schneider
Date: Wednesday, October 28, 2020 at 3:32 PM
To: dev@geode.apache.org
Subject: Re: PR process and etiquette
+1 to your idea of using "draft" mode until things are green. Something to
be aware of is that if your pr branch h
Great information Darrel. Thank you for sharing that.
--Udo
From: Darrel Schneider
Date: Wednesday, October 28, 2020 at 3:32 PM
To: dev@geode.apache.org
Subject: Re: PR process and etiquette
+1 to your idea of using "draft" mode until things are green. Something to be
aware of is th
ly running and it is in draft
mode then try merging develop to your pr branch and resolve the conflicts.
From: Owen Nichols
Sent: Tuesday, October 27, 2020 6:03 PM
To: dev@geode.apache.org
Subject: Re: PR process and etiquette
+1 for using GitHub's draft sta
Great ideas Owen.
I do apologize for the BIG lump of text… stupid formatting of lack thereof…
--Udo
From: Owen Nichols
Date: Wednesday, October 28, 2020 at 12:03 PM
To: dev@geode.apache.org
Subject: Re: PR process and etiquette
+1 for using GitHub's draft status to indicate work-in-pro
+1 for using GitHub's draft status to indicate work-in-progress.
Many great suggestions here, however I generally prefer that we don't squash
commits at any point except the final Squash and Merge to develop. I find it
insightful to see how the work evolved. I also find that review comments ma
22 matches
Mail list logo
