You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Nabarun Nag <nn...@pivotal.io> on 2019/10/23 00:12:02 UTC
[REQUEST] Squash merge please
Hi Geode Committers,
A kind request for using squash commit instead of using merge.
This will really help us in our bisect operations when a
regression/flakiness in the product is introduced. We can automate and go
through fewer commits faster, avoiding commits like "spotless fix" and
"re-trigger precheck-in" or other minor commits in the merged branch.
Also, please use the commit format : (helps us to know who worked on it,
what is the history)
* GEODE-xxxx: <brief intro >
* explanation line 1 * explanation line 2*
This is not a rule or anything, but a request to help out your fellow
committers in quickly detecting a problem.
For inspiration, we can look into Apache Kafka / Spark where they have a
complete linear graph for their main branch HEAD [see attachment]
Regards
Naba.
Re: [REQUEST] Squash merge please
Posted by Owen Nichols <on...@pivotal.io>.
Once a PR is reviewed and merged, the remainder of its lifecycle could include a revert, a cherry-pick to another branch, or just browsing the git history.
In general it’s most convenient for all of the above cases if 1 JIRA == 1 commit on develop.
As a set-it-and-forget-it default, Squash and Merge takes care of this for you. However, there are two other options in GitHub, and I think what most people really dislike is the “Create a merge commit” option. If you have carefully prepared your PR in a way that "Rebase and Merge” makes sense, I don’t necessarily see a problem with that. Just keep in mind the cherry-pick case — if your “fix” commit depends on your carefully-separated “refactor” commit, maybe squash is just better so the whole fix can be cherry-picked as a single unit in the future.
If the commits are relatively independent, maybe delivering as multiple PRs would better express that. If the problem is that our PR process is too “heavy”, and you’re trying to deliver multiple commits via one PR vehicle just to cut down on overhead, perhaps this merits further community discussion. Is getting reviewers the biggest difficulty, or waiting for PR checks to pass, or is it just too much busywork creating a JIRA, etc, for each change?
> On Dec 16, 2019, at 9:47 AM, Kirk Lund <kl...@apache.org> wrote:
>
> Whenever I submit a PR with multiple commits that I intend to rebase to
> develop, I always try to ensure that each commit stands alone as is
> (compiles and passes tests). Separating file renames and refactoring from
> behavior changes into different commits seems very valuable to me, and I've
> had trouble getting people to review PRs without this separation (but it
> could be squashed as it's merged to develop).
>
> It sounds to me like the real problem is (a) some PRs have multiple commits
> that don't compile or don't pass tests, and (b) some PRs that should be
> merged with squash are not (by accident most likely).
>
> I can submit multiple PRs instead of one PR with multiple commits. So I'll
> change my response to -0 if that helps prevent commits to develop that
> don't compile or pass tests. Without preventing rebase or merge commits
> from github, I'm not sure how we can really enforce this or prevent (b)
> above.
>
> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <am...@pivotal.io>
> wrote:
>
>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>
>> Make the change easy (warning: this may be hard), then make the easy
>>> change."
>>
>> -Kent Beck
>>
>> Following Kent Beck's advise might reasonably split into two commits. One
>> refactor commit and a separate commit that introduces the actual change.
>> They should be individually revertible and might be easier understood if
>> split out. I vividly remember a change on our code base where someone did a
>> huge amount of refactoring that resulted than in one parameter changing in
>> order to get the desired functionality change. If that was in one commit,
>> it would be hard to see the actual change. If split out, it's beautiful and
>> crystal clear.
>>
>> I am unsure how that would be reflected in terms of JIRA ticket references.
>> Usually we assume that if there is a commit with the ticket number, the
>> issue is resolved. Maybe the key here is to create a separate refactoring
>> ticket.
>>
>> Would that allow us to have our cake and eat it too?
>>
>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>
>>> It is to help with bisect operations when things start failing ... helps
>> us
>>> it revert and build faster.
>>> also with cherry picking features / fixes to previous versions .
>>> And keeping the git history clean with no unnecessary “merge commits”.
>>>
>>> Regards
>>> Naba
>>>
>>>
>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
>>>
>>>> -1 I really like to sometimes have more than 1 commit in a PR and keep
>>> them
>>>> separate when they merge to develop
>>>>
>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>>>
>>>>> Hi Geode Committers,
>>>>>
>>>>> A kind request for using squash commit instead of using merge.
>>>>> This will really help us in our bisect operations when a
>>>>> regression/flakiness in the product is introduced. We can automate
>> and
>>> go
>>>>> through fewer commits faster, avoiding commits like "spotless fix"
>> and
>>>>> "re-trigger precheck-in" or other minor commits in the merged branch.
>>>>>
>>>>> Also, please use the commit format : (helps us to know who worked on
>>> it,
>>>>> what is the history)
>>>>>
>>>>>
>>>>>
>>>>> * GEODE-xxxx: <brief intro >
>>>>> * explanation line 1 * explanation
>> line
>>> 2*
>>>>>
>>>>> This is not a rule or anything, but a request to help out your fellow
>>>>> committers in quickly detecting a problem.
>>>>>
>>>>> For inspiration, we can look into Apache Kafka / Spark where they
>> have
>>> a
>>>>> complete linear graph for their main branch HEAD [see attachment]
>>>>>
>>>>> Regards
>>>>> Naba.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Jacob Barrett <jb...@pivotal.io>.
If the appropriate or necessary process is a merge then this proposal prevents that. I am not interested in any hard restrictions like this. You proposal in response to dan is not palatable by disabling merges via github but allowing it manually.
> On Dec 19, 2019, at 4:54 PM, Owen Nichols <on...@pivotal.io> wrote:
>
> This proposal in no way prevents you from getting work done. Squash is always enabled and always the most acceptable way to bring changes to develop.
>
> Please start a separate thread if you would like to revisit the community decision to require passing PR checks.
>
>> On Dec 19, 2019, at 4:49 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>>
>> I’m in agreement with Dan. Changes to the infrastructure to flat out prevent things that should be self policing is annoying. This PR review lock we have had already cost us valuable time waiting for PR pipelines to pass that have no relevance to the commit, like CI work: I’d hat to see yet another process enforced that Kees us from getting work done when necessary.
>>
>> -Jake
>>
>>
>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>>>
>>> -1 to (1) and (2).
>>>
>>> I think merge commits are appropriate in certain circumstances, so I don't
>>> think we should make a blanket restriction. In fact I think our release
>>> process involves some merges.
>>>
>>> I think setting standards on what is reasonable to be an individual commit
>>> will do a lot more to clean up our history than blocking merges. We'd
>>> rather not see commits like "Spotless Apply" in the history, but if
>>> reasonably separate and well written commits come in as part of a merge, I
>>> think that's fine.
>>>
>>> -Dan
>>>
>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io> wrote:
>>>>
>>>> +1
>>>>
>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io> wrote:
>>>>>
>>>>> I’d like to advance this topic from an informal request/discussion to a
>>>>> discussion of a concrete proposal.
>>>>>
>>>>> To recap, it sounds like there is general agreement that commit history
>>>> on
>>>>> develop should be linear (no merge commits), and that the biggest
>>>> obstacle
>>>>> to this is that the PR merge button in GitHub creates a merge commit by
>>>>> default.
>>>>>
>>>>> I propose the following changes:
>>>>> 1) Change GitHub settings to remove the ability to create a merge commit.
>>>>> This will make Squash & Merge the default.
>>>>>
>>>>> 2) Change GitHub settings to require linear history on develop. This
>>>>> prevents merge commits via command-line (not recommended, but wiki still
>>>>> has instructions for merging PRs this way).
>>>>>
>>>>> 3) Update the PR template to change the text "Is your initial
>>>> contribution
>>>>> a single, squashed commit” to “Is your initial contribution squashed for
>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
>>>>> ‘fix’ commit)"
>>>>>
>>>>> For clarity, I am proposing no-change in the following areas:
>>>>> i) Leave Rebase & Merge as an option for PRs that have been structured to
>>>>> benefit from it (this can make it easier in a bisect to see whether the
>>>>> refactoring or the “fix” broke something).
>>>>> ii) Leave existing wording in the wiki as-is [stating that squashing is
>>>>> preferred].
>>>>>
>>>>>
>>>>> Please comment via this email thread.
>>>>> -Owen
>>>>>
>>>>>
>>>>>
>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>>>>
>>>>>> I think it's already resolved Udo ;)
>>>>>>
>>>>>> Here's the problem, if I fixup a dunit test by removing all uses of
>>>>> "this."
>>>>>> and I rename the dunit test, then git doesn't remember that the file
>>>> is a
>>>>>> rename -- it forever afterwards interprets it as a new file that I
>>>>> created
>>>>>> if I touch more than 50% of the lines (which "this." can easily do). If
>>>>> we
>>>>>> squash two commits: the rename and the cleanup of that dunit test --
>>>> then
>>>>>> we effectively lose the history of that file and it shows that I
>>>> created
>>>>> a
>>>>>> new file.
>>>>>>
>>>>>> Also for the record, I've been working on Geode since the beginning
>>>> and I
>>>>>> was never made aware of this change in our process. I never voted on
>>>> it.
>>>>>> I'm not a big fan of changing various details in our process every
>>>> single
>>>>>> week. It's very easy to miss these discussions unless someone points it
>>>>> out
>>>>>> to me.
>>>>>>
>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <uk...@pivotal.io>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm not sure what this discussion is about... WE, as a community, have
>>>>>>> agreed in common practices, in two place no less...
>>>>>>>
>>>>>>> 1) Quoting our PR template
>>>>>>>
>>>>>>>
>>>>>>> For all changes:
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> Is there a JIRA ticket associated with this PR? Is it referenced in
>>>>>>> the commit message?
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> Has your PR been rebased against the latest commit within the
>>>> target
>>>>>>> branch (typically|develop|)?
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> Have you written or updated unit tests to verify your changes?
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> If adding new dependencies to the code, are these dependencies
>>>>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>>
>>>>>>> On our PR template we call out that the initial PR commit should be
>>>>>>> squashed.
>>>>>>>
>>>>>>> 2)
>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>
>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>>
>>>>>>>
>>>>>>> @Kirk, if each of your commits "stands alone", I commend you on the
>>>>>>> diligence, but in reality, they should either then be stand alone PR's
>>>>>>> or just extra work created for yourself.
>>>>>>>
>>>>>>> If we want to change the way we have agreed upon we
>>>> submit/commit/merge
>>>>>>> changes back into develop... Then this is another discussion thread,
>>>>>>> until then, I think we should all remind ourselves on our agreed
>>>>>>> contributions code of conduct.
>>>>>>>
>>>>>>> --Udo
>>>>>>>
>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>> Kirk, I believe that creating a Pull Request with multiple commits is
>>>>> ok.
>>>>>>>> It's just in the end that when it's being pushed to develop branch,
>>>> it
>>>>>>>> needs to be squash merged. I believe that is what you have mentioned
>>>> in
>>>>>>> the
>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>> If you can see in the first screenshot comparison that I had attached
>>>>> in
>>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>>
>>>>>>>> Thank you for your feedback.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Naba
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
>>>>>>>>
>>>>>>>>> Whenever I submit a PR with multiple commits that I intend to rebase
>>>>> to
>>>>>>>>> develop, I always try to ensure that each commit stands alone as is
>>>>>>>>> (compiles and passes tests). Separating file renames and refactoring
>>>>>>> from
>>>>>>>>> behavior changes into different commits seems very valuable to me,
>>>> and
>>>>>>> I've
>>>>>>>>> had trouble getting people to review PRs without this separation
>>>> (but
>>>>> it
>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>
>>>>>>>>> It sounds to me like the real problem is (a) some PRs have multiple
>>>>>>> commits
>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that should
>>>>> be
>>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>>
>>>>>>>>> I can submit multiple PRs instead of one PR with multiple commits.
>>>> So
>>>>>>> I'll
>>>>>>>>> change my response to -0 if that helps prevent commits to develop
>>>> that
>>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
>>>>> commits
>>>>>>>>> from github, I'm not sure how we can really enforce this or prevent
>>>>> (b)
>>>>>>>>> above.
>>>>>>>>>
>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>> amurmann@pivotal.io>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>>>>>>>>>
>>>>>>>>>> Make the change easy (warning: this may be hard), then make the
>>>> easy
>>>>>>>>>>> change."
>>>>>>>>>> -Kent Beck
>>>>>>>>>>
>>>>>>>>>> Following Kent Beck's advise might reasonably split into two
>>>> commits.
>>>>>>> One
>>>>>>>>>> refactor commit and a separate commit that introduces the actual
>>>>>>> change.
>>>>>>>>>> They should be individually revertible and might be easier
>>>> understood
>>>>>>> if
>>>>>>>>>> split out. I vividly remember a change on our code base where
>>>> someone
>>>>>>>>> did a
>>>>>>>>>> huge amount of refactoring that resulted than in one parameter
>>>>> changing
>>>>>>>>> in
>>>>>>>>>> order to get the desired functionality change. If that was in one
>>>>>>> commit,
>>>>>>>>>> it would be hard to see the actual change. If split out, it's
>>>>> beautiful
>>>>>>>>> and
>>>>>>>>>> crystal clear.
>>>>>>>>>>
>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
>>>>>>>>> references.
>>>>>>>>>> Usually we assume that if there is a commit with the ticket number,
>>>>> the
>>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>>>>> refactoring
>>>>>>>>>> ticket.
>>>>>>>>>>
>>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> It is to help with bisect operations when things start failing ...
>>>>>>>>> helps
>>>>>>>>>> us
>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>> also with cherry picking features / fixes to previous versions .
>>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
>>>>> commits”.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Naba
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
>>>>>>>>> keep
>>>>>>>>>>> them
>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>
>>>>>>>>>>>>> A kind request for using squash commit instead of using merge.
>>>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>>>> regression/flakiness in the product is introduced. We can
>>>> automate
>>>>>>>>>> and
>>>>>>>>>>> go
>>>>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless
>>>> fix"
>>>>>>>>>> and
>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>>>>>>>>> branch.
>>>>>>>>>>>>> Also, please use the commit format : (helps us to know who
>>>> worked
>>>>>>>>> on
>>>>>>>>>>> it,
>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>> * explanation line 1 *
>>>> explanation
>>>>>>>>>> line
>>>>>>>>>>> 2*
>>>>>>>>>>>>> This is not a rule or anything, but a request to help out your
>>>>>>>>> fellow
>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
>>>> they
>>>>>>>>>> have
>>>>>>>>>>> a
>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>>>> attachment]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Jinmei Liao <ji...@pivotal.io>.
Yes, I got freaked out somehow this morning by thinking I had accidentally
clicked the wrong button to include all the individual commits in my PR to
the develop branch, (luckily it's just a wrong view). I would think disable
that button would be a good idea.
On Thu, Dec 19, 2019 at 5:04 PM Nabarun Nag <nn...@pivotal.io> wrote:
> Hi all,
>
> This is not a blanket restriction.
> My suggestion, like last time, lets try it out and this time we don't even
> need Apache Infra to step in. Feels like it has been requested in multiple
> INFRA JIRAs by so many Apache projects to enable only the squash merge
> button and disable the others, that this setting has been moved to a simple
> entry in .asf.yml file in root git repository
>
> Again this is a setting only for the develop branch. And can be reversed
> with a simple commit.
>
> I agree too much policing is a bad thing, but I want to look at it as a
> safeguard. I have spoken to multiple developers who have mentioned they
> clicked the wrong button in a hurry or the page refreshed and the commit
> got merged in a wrong way.
>
> Regards
> Naba
>
> Reference :
>
> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories
> Merge buttons
>
> Projects can enable/disable the "merge PR" button in the GitHub UI and
> configure which actions should be allowed by adding the following
> configuration (or derivatives thereof):
> github:
> enabled_merge_buttons:
> # enable squash button:
> squash: true
> # enable merge button:
> merge: true
> # disable rebase button:
> rebase: false
>
>
> On Thu, Dec 19, 2019 at 4:54 PM Owen Nichols <on...@pivotal.io> wrote:
>
> > This proposal in no way prevents you from getting work done. Squash is
> > always enabled and always the most acceptable way to bring changes to
> > develop.
> >
> > Please start a separate thread if you would like to revisit the community
> > decision to require passing PR checks.
> >
> > > On Dec 19, 2019, at 4:49 PM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> > >
> > > I’m in agreement with Dan. Changes to the infrastructure to flat out
> > prevent things that should be self policing is annoying. This PR review
> > lock we have had already cost us valuable time waiting for PR pipelines
> to
> > pass that have no relevance to the commit, like CI work: I’d hat to see
> yet
> > another process enforced that Kees us from getting work done when
> necessary.
> > >
> > > -Jake
> > >
> > >
> > >> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
> > >>
> > >> -1 to (1) and (2).
> > >>
> > >> I think merge commits are appropriate in certain circumstances, so I
> > don't
> > >> think we should make a blanket restriction. In fact I think our
> release
> > >> process involves some merges.
> > >>
> > >> I think setting standards on what is reasonable to be an individual
> > commit
> > >> will do a lot more to clean up our history than blocking merges. We'd
> > >> rather not see commits like "Spotless Apply" in the history, but if
> > >> reasonably separate and well written commits come in as part of a
> > merge, I
> > >> think that's fine.
> > >>
> > >> -Dan
> > >>
> > >>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io>
> wrote:
> > >>>
> > >>> +1
> > >>>
> > >>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io>
> > wrote:
> > >>>>
> > >>>> I’d like to advance this topic from an informal request/discussion
> to
> > a
> > >>>> discussion of a concrete proposal.
> > >>>>
> > >>>> To recap, it sounds like there is general agreement that commit
> > history
> > >>> on
> > >>>> develop should be linear (no merge commits), and that the biggest
> > >>> obstacle
> > >>>> to this is that the PR merge button in GitHub creates a merge commit
> > by
> > >>>> default.
> > >>>>
> > >>>> I propose the following changes:
> > >>>> 1) Change GitHub settings to remove the ability to create a merge
> > commit.
> > >>>> This will make Squash & Merge the default.
> > >>>>
> > >>>> 2) Change GitHub settings to require linear history on develop.
> This
> > >>>> prevents merge commits via command-line (not recommended, but wiki
> > still
> > >>>> has instructions for merging PRs this way).
> > >>>>
> > >>>> 3) Update the PR template to change the text "Is your initial
> > >>> contribution
> > >>>> a single, squashed commit” to “Is your initial contribution squashed
> > for
> > >>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> plus a
> > >>>> ‘fix’ commit)"
> > >>>>
> > >>>> For clarity, I am proposing no-change in the following areas:
> > >>>> i) Leave Rebase & Merge as an option for PRs that have been
> > structured to
> > >>>> benefit from it (this can make it easier in a bisect to see whether
> > the
> > >>>> refactoring or the “fix” broke something).
> > >>>> ii) Leave existing wording in the wiki as-is [stating that squashing
> > is
> > >>>> preferred].
> > >>>>
> > >>>>
> > >>>> Please comment via this email thread.
> > >>>> -Owen
> > >>>>
> > >>>>
> > >>>>
> > >>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
> > >>>>>
> > >>>>> I think it's already resolved Udo ;)
> > >>>>>
> > >>>>> Here's the problem, if I fixup a dunit test by removing all uses of
> > >>>> "this."
> > >>>>> and I rename the dunit test, then git doesn't remember that the
> file
> > >>> is a
> > >>>>> rename -- it forever afterwards interprets it as a new file that I
> > >>>> created
> > >>>>> if I touch more than 50% of the lines (which "this." can easily
> do).
> > If
> > >>>> we
> > >>>>> squash two commits: the rename and the cleanup of that dunit test
> --
> > >>> then
> > >>>>> we effectively lose the history of that file and it shows that I
> > >>> created
> > >>>> a
> > >>>>> new file.
> > >>>>>
> > >>>>> Also for the record, I've been working on Geode since the beginning
> > >>> and I
> > >>>>> was never made aware of this change in our process. I never voted
> on
> > >>> it.
> > >>>>> I'm not a big fan of changing various details in our process every
> > >>> single
> > >>>>> week. It's very easy to miss these discussions unless someone
> points
> > it
> > >>>> out
> > >>>>> to me.
> > >>>>>
> > >>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > ukohlmeyer@pivotal.io>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> I'm not sure what this discussion is about... WE, as a community,
> > have
> > >>>>>> agreed in common practices, in two place no less...
> > >>>>>>
> > >>>>>> 1) Quoting our PR template
> > >>>>>>
> > >>>>>>
> > >>>>>> For all changes:
> > >>>>>>
> > >>>>>> *
> > >>>>>>
> > >>>>>> Is there a JIRA ticket associated with this PR? Is it referenced
> in
> > >>>>>> the commit message?
> > >>>>>>
> > >>>>>> *
> > >>>>>>
> > >>>>>> Has your PR been rebased against the latest commit within the
> > >>> target
> > >>>>>> branch (typically|develop|)?
> > >>>>>>
> > >>>>>> *
> > >>>>>>
> > >>>>>> ***Is your initial contribution a single, squashed commit?*
> > >>>>>>
> > >>>>>> *
> > >>>>>>
> > >>>>>> Does|gradlew build|run cleanly?
> > >>>>>>
> > >>>>>> *
> > >>>>>>
> > >>>>>> Have you written or updated unit tests to verify your changes?
> > >>>>>>
> > >>>>>> *
> > >>>>>>
> > >>>>>> If adding new dependencies to the code, are these dependencies
> > >>>>>> licensed in a way that is compatible for inclusion underASF 2.0
> > >>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> > >>>>>>
> > >>>>>> On our PR template we call out that the initial PR commit should
> be
> > >>>>>> squashed.
> > >>>>>>
> > >>>>>> 2)
> > >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>>>> <
> > https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>>
> > >>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> > >>>>>>
> > >>>>>>
> > >>>>>> @Kirk, if each of your commits "stands alone", I commend you on
> the
> > >>>>>> diligence, but in reality, they should either then be stand alone
> > PR's
> > >>>>>> or just extra work created for yourself.
> > >>>>>>
> > >>>>>> If we want to change the way we have agreed upon we
> > >>> submit/commit/merge
> > >>>>>> changes back into develop... Then this is another discussion
> thread,
> > >>>>>> until then, I think we should all remind ourselves on our agreed
> > >>>>>> contributions code of conduct.
> > >>>>>>
> > >>>>>> --Udo
> > >>>>>>
> > >>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > >>>>>>> Kirk, I believe that creating a Pull Request with multiple
> commits
> > is
> > >>>> ok.
> > >>>>>>> It's just in the end that when it's being pushed to develop
> branch,
> > >>> it
> > >>>>>>> needs to be squash merged. I believe that is what you have
> > mentioned
> > >>> in
> > >>>>>> the
> > >>>>>>> first paragraph, and I am more than happy with that.
> > >>>>>>> If you can see in the first screenshot comparison that I had
> > attached
> > >>>> in
> > >>>>>>> the first email in this thread is what I want to avoid.
> > >>>>>>>
> > >>>>>>> Thank you for your feedback.
> > >>>>>>>
> > >>>>>>> Regards
> > >>>>>>> Naba
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org>
> > wrote:
> > >>>>>>>
> > >>>>>>>> Whenever I submit a PR with multiple commits that I intend to
> > rebase
> > >>>> to
> > >>>>>>>> develop, I always try to ensure that each commit stands alone as
> > is
> > >>>>>>>> (compiles and passes tests). Separating file renames and
> > refactoring
> > >>>>>> from
> > >>>>>>>> behavior changes into different commits seems very valuable to
> me,
> > >>> and
> > >>>>>> I've
> > >>>>>>>> had trouble getting people to review PRs without this separation
> > >>> (but
> > >>>> it
> > >>>>>>>> could be squashed as it's merged to develop).
> > >>>>>>>>
> > >>>>>>>> It sounds to me like the real problem is (a) some PRs have
> > multiple
> > >>>>>> commits
> > >>>>>>>> that don't compile or don't pass tests, and (b) some PRs that
> > should
> > >>>> be
> > >>>>>>>> merged with squash are not (by accident most likely).
> > >>>>>>>>
> > >>>>>>>> I can submit multiple PRs instead of one PR with multiple
> commits.
> > >>> So
> > >>>>>> I'll
> > >>>>>>>> change my response to -0 if that helps prevent commits to
> develop
> > >>> that
> > >>>>>>>> don't compile or pass tests. Without preventing rebase or merge
> > >>>> commits
> > >>>>>>>> from github, I'm not sure how we can really enforce this or
> > prevent
> > >>>> (b)
> > >>>>>>>> above.
> > >>>>>>>>
> > >>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > >>>> amurmann@pivotal.io>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at
> odds.
> > >>>>>>>>>
> > >>>>>>>>> Make the change easy (warning: this may be hard), then make the
> > >>> easy
> > >>>>>>>>>> change."
> > >>>>>>>>> -Kent Beck
> > >>>>>>>>>
> > >>>>>>>>> Following Kent Beck's advise might reasonably split into two
> > >>> commits.
> > >>>>>> One
> > >>>>>>>>> refactor commit and a separate commit that introduces the
> actual
> > >>>>>> change.
> > >>>>>>>>> They should be individually revertible and might be easier
> > >>> understood
> > >>>>>> if
> > >>>>>>>>> split out. I vividly remember a change on our code base where
> > >>> someone
> > >>>>>>>> did a
> > >>>>>>>>> huge amount of refactoring that resulted than in one parameter
> > >>>> changing
> > >>>>>>>> in
> > >>>>>>>>> order to get the desired functionality change. If that was in
> one
> > >>>>>> commit,
> > >>>>>>>>> it would be hard to see the actual change. If split out, it's
> > >>>> beautiful
> > >>>>>>>> and
> > >>>>>>>>> crystal clear.
> > >>>>>>>>>
> > >>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
> > >>>>>>>> references.
> > >>>>>>>>> Usually we assume that if there is a commit with the ticket
> > number,
> > >>>> the
> > >>>>>>>>> issue is resolved. Maybe the key here is to create a separate
> > >>>>>> refactoring
> > >>>>>>>>> ticket.
> > >>>>>>>>>
> > >>>>>>>>> Would that allow us to have our cake and eat it too?
> > >>>>>>>>>
> > >>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
> > >>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> It is to help with bisect operations when things start failing
> > ...
> > >>>>>>>> helps
> > >>>>>>>>> us
> > >>>>>>>>>> it revert and build faster.
> > >>>>>>>>>> also with cherry picking features / fixes to previous
> versions .
> > >>>>>>>>>> And keeping the git history clean with no unnecessary “merge
> > >>>> commits”.
> > >>>>>>>>>>
> > >>>>>>>>>> Regards
> > >>>>>>>>>> Naba
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
> > >>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR
> > and
> > >>>>>>>> keep
> > >>>>>>>>>> them
> > >>>>>>>>>>> separate when they merge to develop
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nnag@pivotal.io
> >
> > >>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Hi Geode Committers,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> A kind request for using squash commit instead of using
> merge.
> > >>>>>>>>>>>> This will really help us in our bisect operations when a
> > >>>>>>>>>>>> regression/flakiness in the product is introduced. We can
> > >>> automate
> > >>>>>>>>> and
> > >>>>>>>>>> go
> > >>>>>>>>>>>> through fewer commits faster, avoiding commits like
> "spotless
> > >>> fix"
> > >>>>>>>>> and
> > >>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the
> merged
> > >>>>>>>> branch.
> > >>>>>>>>>>>> Also, please use the commit format : (helps us to know who
> > >>> worked
> > >>>>>>>> on
> > >>>>>>>>>> it,
> > >>>>>>>>>>>> what is the history)
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> > >>>>>>>>>>>> * explanation line 1 *
> > >>> explanation
> > >>>>>>>>> line
> > >>>>>>>>>> 2*
> > >>>>>>>>>>>> This is not a rule or anything, but a request to help out
> your
> > >>>>>>>> fellow
> > >>>>>>>>>>>> committers in quickly detecting a problem.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
> > >>> they
> > >>>>>>>>> have
> > >>>>>>>>>> a
> > >>>>>>>>>>>> complete linear graph for their main branch HEAD [see
> > >>> attachment]
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Regards
> > >>>>>>>>>>>> Naba.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>>
> >
> >
>
--
Cheers
Jinmei
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Nabarun Nag <nn...@pivotal.io>.
Hi all,
This is not a blanket restriction.
My suggestion, like last time, lets try it out and this time we don't even
need Apache Infra to step in. Feels like it has been requested in multiple
INFRA JIRAs by so many Apache projects to enable only the squash merge
button and disable the others, that this setting has been moved to a simple
entry in .asf.yml file in root git repository
Again this is a setting only for the develop branch. And can be reversed
with a simple commit.
I agree too much policing is a bad thing, but I want to look at it as a
safeguard. I have spoken to multiple developers who have mentioned they
clicked the wrong button in a hurry or the page refreshed and the commit
got merged in a wrong way.
Regards
Naba
Reference :
https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories
Merge buttons
Projects can enable/disable the "merge PR" button in the GitHub UI and
configure which actions should be allowed by adding the following
configuration (or derivatives thereof):
github:
enabled_merge_buttons:
# enable squash button:
squash: true
# enable merge button:
merge: true
# disable rebase button:
rebase: false
On Thu, Dec 19, 2019 at 4:54 PM Owen Nichols <on...@pivotal.io> wrote:
> This proposal in no way prevents you from getting work done. Squash is
> always enabled and always the most acceptable way to bring changes to
> develop.
>
> Please start a separate thread if you would like to revisit the community
> decision to require passing PR checks.
>
> > On Dec 19, 2019, at 4:49 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > I’m in agreement with Dan. Changes to the infrastructure to flat out
> prevent things that should be self policing is annoying. This PR review
> lock we have had already cost us valuable time waiting for PR pipelines to
> pass that have no relevance to the commit, like CI work: I’d hat to see yet
> another process enforced that Kees us from getting work done when necessary.
> >
> > -Jake
> >
> >
> >> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
> >>
> >> -1 to (1) and (2).
> >>
> >> I think merge commits are appropriate in certain circumstances, so I
> don't
> >> think we should make a blanket restriction. In fact I think our release
> >> process involves some merges.
> >>
> >> I think setting standards on what is reasonable to be an individual
> commit
> >> will do a lot more to clean up our history than blocking merges. We'd
> >> rather not see commits like "Spotless Apply" in the history, but if
> >> reasonably separate and well written commits come in as part of a
> merge, I
> >> think that's fine.
> >>
> >> -Dan
> >>
> >>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io> wrote:
> >>>
> >>> +1
> >>>
> >>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io>
> wrote:
> >>>>
> >>>> I’d like to advance this topic from an informal request/discussion to
> a
> >>>> discussion of a concrete proposal.
> >>>>
> >>>> To recap, it sounds like there is general agreement that commit
> history
> >>> on
> >>>> develop should be linear (no merge commits), and that the biggest
> >>> obstacle
> >>>> to this is that the PR merge button in GitHub creates a merge commit
> by
> >>>> default.
> >>>>
> >>>> I propose the following changes:
> >>>> 1) Change GitHub settings to remove the ability to create a merge
> commit.
> >>>> This will make Squash & Merge the default.
> >>>>
> >>>> 2) Change GitHub settings to require linear history on develop. This
> >>>> prevents merge commits via command-line (not recommended, but wiki
> still
> >>>> has instructions for merging PRs this way).
> >>>>
> >>>> 3) Update the PR template to change the text "Is your initial
> >>> contribution
> >>>> a single, squashed commit” to “Is your initial contribution squashed
> for
> >>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
> >>>> ‘fix’ commit)"
> >>>>
> >>>> For clarity, I am proposing no-change in the following areas:
> >>>> i) Leave Rebase & Merge as an option for PRs that have been
> structured to
> >>>> benefit from it (this can make it easier in a bisect to see whether
> the
> >>>> refactoring or the “fix” broke something).
> >>>> ii) Leave existing wording in the wiki as-is [stating that squashing
> is
> >>>> preferred].
> >>>>
> >>>>
> >>>> Please comment via this email thread.
> >>>> -Owen
> >>>>
> >>>>
> >>>>
> >>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
> >>>>>
> >>>>> I think it's already resolved Udo ;)
> >>>>>
> >>>>> Here's the problem, if I fixup a dunit test by removing all uses of
> >>>> "this."
> >>>>> and I rename the dunit test, then git doesn't remember that the file
> >>> is a
> >>>>> rename -- it forever afterwards interprets it as a new file that I
> >>>> created
> >>>>> if I touch more than 50% of the lines (which "this." can easily do).
> If
> >>>> we
> >>>>> squash two commits: the rename and the cleanup of that dunit test --
> >>> then
> >>>>> we effectively lose the history of that file and it shows that I
> >>> created
> >>>> a
> >>>>> new file.
> >>>>>
> >>>>> Also for the record, I've been working on Geode since the beginning
> >>> and I
> >>>>> was never made aware of this change in our process. I never voted on
> >>> it.
> >>>>> I'm not a big fan of changing various details in our process every
> >>> single
> >>>>> week. It's very easy to miss these discussions unless someone points
> it
> >>>> out
> >>>>> to me.
> >>>>>
> >>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> ukohlmeyer@pivotal.io>
> >>>>> wrote:
> >>>>>
> >>>>>> I'm not sure what this discussion is about... WE, as a community,
> have
> >>>>>> agreed in common practices, in two place no less...
> >>>>>>
> >>>>>> 1) Quoting our PR template
> >>>>>>
> >>>>>>
> >>>>>> For all changes:
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>> Is there a JIRA ticket associated with this PR? Is it referenced in
> >>>>>> the commit message?
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>> Has your PR been rebased against the latest commit within the
> >>> target
> >>>>>> branch (typically|develop|)?
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>> ***Is your initial contribution a single, squashed commit?*
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>> Does|gradlew build|run cleanly?
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>> Have you written or updated unit tests to verify your changes?
> >>>>>>
> >>>>>> *
> >>>>>>
> >>>>>> If adding new dependencies to the code, are these dependencies
> >>>>>> licensed in a way that is compatible for inclusion underASF 2.0
> >>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> >>>>>>
> >>>>>> On our PR template we call out that the initial PR commit should be
> >>>>>> squashed.
> >>>>>>
> >>>>>> 2)
> >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>> <
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>
> >>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> >>>>>>
> >>>>>>
> >>>>>> @Kirk, if each of your commits "stands alone", I commend you on the
> >>>>>> diligence, but in reality, they should either then be stand alone
> PR's
> >>>>>> or just extra work created for yourself.
> >>>>>>
> >>>>>> If we want to change the way we have agreed upon we
> >>> submit/commit/merge
> >>>>>> changes back into develop... Then this is another discussion thread,
> >>>>>> until then, I think we should all remind ourselves on our agreed
> >>>>>> contributions code of conduct.
> >>>>>>
> >>>>>> --Udo
> >>>>>>
> >>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >>>>>>> Kirk, I believe that creating a Pull Request with multiple commits
> is
> >>>> ok.
> >>>>>>> It's just in the end that when it's being pushed to develop branch,
> >>> it
> >>>>>>> needs to be squash merged. I believe that is what you have
> mentioned
> >>> in
> >>>>>> the
> >>>>>>> first paragraph, and I am more than happy with that.
> >>>>>>> If you can see in the first screenshot comparison that I had
> attached
> >>>> in
> >>>>>>> the first email in this thread is what I want to avoid.
> >>>>>>>
> >>>>>>> Thank you for your feedback.
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> Naba
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org>
> wrote:
> >>>>>>>
> >>>>>>>> Whenever I submit a PR with multiple commits that I intend to
> rebase
> >>>> to
> >>>>>>>> develop, I always try to ensure that each commit stands alone as
> is
> >>>>>>>> (compiles and passes tests). Separating file renames and
> refactoring
> >>>>>> from
> >>>>>>>> behavior changes into different commits seems very valuable to me,
> >>> and
> >>>>>> I've
> >>>>>>>> had trouble getting people to review PRs without this separation
> >>> (but
> >>>> it
> >>>>>>>> could be squashed as it's merged to develop).
> >>>>>>>>
> >>>>>>>> It sounds to me like the real problem is (a) some PRs have
> multiple
> >>>>>> commits
> >>>>>>>> that don't compile or don't pass tests, and (b) some PRs that
> should
> >>>> be
> >>>>>>>> merged with squash are not (by accident most likely).
> >>>>>>>>
> >>>>>>>> I can submit multiple PRs instead of one PR with multiple commits.
> >>> So
> >>>>>> I'll
> >>>>>>>> change my response to -0 if that helps prevent commits to develop
> >>> that
> >>>>>>>> don't compile or pass tests. Without preventing rebase or merge
> >>>> commits
> >>>>>>>> from github, I'm not sure how we can really enforce this or
> prevent
> >>>> (b)
> >>>>>>>> above.
> >>>>>>>>
> >>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >>>> amurmann@pivotal.io>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
> >>>>>>>>>
> >>>>>>>>> Make the change easy (warning: this may be hard), then make the
> >>> easy
> >>>>>>>>>> change."
> >>>>>>>>> -Kent Beck
> >>>>>>>>>
> >>>>>>>>> Following Kent Beck's advise might reasonably split into two
> >>> commits.
> >>>>>> One
> >>>>>>>>> refactor commit and a separate commit that introduces the actual
> >>>>>> change.
> >>>>>>>>> They should be individually revertible and might be easier
> >>> understood
> >>>>>> if
> >>>>>>>>> split out. I vividly remember a change on our code base where
> >>> someone
> >>>>>>>> did a
> >>>>>>>>> huge amount of refactoring that resulted than in one parameter
> >>>> changing
> >>>>>>>> in
> >>>>>>>>> order to get the desired functionality change. If that was in one
> >>>>>> commit,
> >>>>>>>>> it would be hard to see the actual change. If split out, it's
> >>>> beautiful
> >>>>>>>> and
> >>>>>>>>> crystal clear.
> >>>>>>>>>
> >>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
> >>>>>>>> references.
> >>>>>>>>> Usually we assume that if there is a commit with the ticket
> number,
> >>>> the
> >>>>>>>>> issue is resolved. Maybe the key here is to create a separate
> >>>>>> refactoring
> >>>>>>>>> ticket.
> >>>>>>>>>
> >>>>>>>>> Would that allow us to have our cake and eat it too?
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
> >>> wrote:
> >>>>>>>>>
> >>>>>>>>>> It is to help with bisect operations when things start failing
> ...
> >>>>>>>> helps
> >>>>>>>>> us
> >>>>>>>>>> it revert and build faster.
> >>>>>>>>>> also with cherry picking features / fixes to previous versions .
> >>>>>>>>>> And keeping the git history clean with no unnecessary “merge
> >>>> commits”.
> >>>>>>>>>>
> >>>>>>>>>> Regards
> >>>>>>>>>> Naba
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
> >>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR
> and
> >>>>>>>> keep
> >>>>>>>>>> them
> >>>>>>>>>>> separate when they merge to develop
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
> >>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Geode Committers,
> >>>>>>>>>>>>
> >>>>>>>>>>>> A kind request for using squash commit instead of using merge.
> >>>>>>>>>>>> This will really help us in our bisect operations when a
> >>>>>>>>>>>> regression/flakiness in the product is introduced. We can
> >>> automate
> >>>>>>>>> and
> >>>>>>>>>> go
> >>>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless
> >>> fix"
> >>>>>>>>> and
> >>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
> >>>>>>>> branch.
> >>>>>>>>>>>> Also, please use the commit format : (helps us to know who
> >>> worked
> >>>>>>>> on
> >>>>>>>>>> it,
> >>>>>>>>>>>> what is the history)
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> >>>>>>>>>>>> * explanation line 1 *
> >>> explanation
> >>>>>>>>> line
> >>>>>>>>>> 2*
> >>>>>>>>>>>> This is not a rule or anything, but a request to help out your
> >>>>>>>> fellow
> >>>>>>>>>>>> committers in quickly detecting a problem.
> >>>>>>>>>>>>
> >>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
> >>> they
> >>>>>>>>> have
> >>>>>>>>>> a
> >>>>>>>>>>>> complete linear graph for their main branch HEAD [see
> >>> attachment]
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regards
> >>>>>>>>>>>> Naba.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
This proposal in no way prevents you from getting work done. Squash is always enabled and always the most acceptable way to bring changes to develop.
Please start a separate thread if you would like to revisit the community decision to require passing PR checks.
> On Dec 19, 2019, at 4:49 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> I’m in agreement with Dan. Changes to the infrastructure to flat out prevent things that should be self policing is annoying. This PR review lock we have had already cost us valuable time waiting for PR pipelines to pass that have no relevance to the commit, like CI work: I’d hat to see yet another process enforced that Kees us from getting work done when necessary.
>
> -Jake
>
>
>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>>
>> -1 to (1) and (2).
>>
>> I think merge commits are appropriate in certain circumstances, so I don't
>> think we should make a blanket restriction. In fact I think our release
>> process involves some merges.
>>
>> I think setting standards on what is reasonable to be an individual commit
>> will do a lot more to clean up our history than blocking merges. We'd
>> rather not see commits like "Spotless Apply" in the history, but if
>> reasonably separate and well written commits come in as part of a merge, I
>> think that's fine.
>>
>> -Dan
>>
>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io> wrote:
>>>
>>> +1
>>>
>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io> wrote:
>>>>
>>>> I’d like to advance this topic from an informal request/discussion to a
>>>> discussion of a concrete proposal.
>>>>
>>>> To recap, it sounds like there is general agreement that commit history
>>> on
>>>> develop should be linear (no merge commits), and that the biggest
>>> obstacle
>>>> to this is that the PR merge button in GitHub creates a merge commit by
>>>> default.
>>>>
>>>> I propose the following changes:
>>>> 1) Change GitHub settings to remove the ability to create a merge commit.
>>>> This will make Squash & Merge the default.
>>>>
>>>> 2) Change GitHub settings to require linear history on develop. This
>>>> prevents merge commits via command-line (not recommended, but wiki still
>>>> has instructions for merging PRs this way).
>>>>
>>>> 3) Update the PR template to change the text "Is your initial
>>> contribution
>>>> a single, squashed commit” to “Is your initial contribution squashed for
>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
>>>> ‘fix’ commit)"
>>>>
>>>> For clarity, I am proposing no-change in the following areas:
>>>> i) Leave Rebase & Merge as an option for PRs that have been structured to
>>>> benefit from it (this can make it easier in a bisect to see whether the
>>>> refactoring or the “fix” broke something).
>>>> ii) Leave existing wording in the wiki as-is [stating that squashing is
>>>> preferred].
>>>>
>>>>
>>>> Please comment via this email thread.
>>>> -Owen
>>>>
>>>>
>>>>
>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>>>
>>>>> I think it's already resolved Udo ;)
>>>>>
>>>>> Here's the problem, if I fixup a dunit test by removing all uses of
>>>> "this."
>>>>> and I rename the dunit test, then git doesn't remember that the file
>>> is a
>>>>> rename -- it forever afterwards interprets it as a new file that I
>>>> created
>>>>> if I touch more than 50% of the lines (which "this." can easily do). If
>>>> we
>>>>> squash two commits: the rename and the cleanup of that dunit test --
>>> then
>>>>> we effectively lose the history of that file and it shows that I
>>> created
>>>> a
>>>>> new file.
>>>>>
>>>>> Also for the record, I've been working on Geode since the beginning
>>> and I
>>>>> was never made aware of this change in our process. I never voted on
>>> it.
>>>>> I'm not a big fan of changing various details in our process every
>>> single
>>>>> week. It's very easy to miss these discussions unless someone points it
>>>> out
>>>>> to me.
>>>>>
>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <uk...@pivotal.io>
>>>>> wrote:
>>>>>
>>>>>> I'm not sure what this discussion is about... WE, as a community, have
>>>>>> agreed in common practices, in two place no less...
>>>>>>
>>>>>> 1) Quoting our PR template
>>>>>>
>>>>>>
>>>>>> For all changes:
>>>>>>
>>>>>> *
>>>>>>
>>>>>> Is there a JIRA ticket associated with this PR? Is it referenced in
>>>>>> the commit message?
>>>>>>
>>>>>> *
>>>>>>
>>>>>> Has your PR been rebased against the latest commit within the
>>> target
>>>>>> branch (typically|develop|)?
>>>>>>
>>>>>> *
>>>>>>
>>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>>
>>>>>> *
>>>>>>
>>>>>> Does|gradlew build|run cleanly?
>>>>>>
>>>>>> *
>>>>>>
>>>>>> Have you written or updated unit tests to verify your changes?
>>>>>>
>>>>>> *
>>>>>>
>>>>>> If adding new dependencies to the code, are these dependencies
>>>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>
>>>>>> On our PR template we call out that the initial PR commit should be
>>>>>> squashed.
>>>>>>
>>>>>> 2)
>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>
>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>
>>>>>>
>>>>>> @Kirk, if each of your commits "stands alone", I commend you on the
>>>>>> diligence, but in reality, they should either then be stand alone PR's
>>>>>> or just extra work created for yourself.
>>>>>>
>>>>>> If we want to change the way we have agreed upon we
>>> submit/commit/merge
>>>>>> changes back into develop... Then this is another discussion thread,
>>>>>> until then, I think we should all remind ourselves on our agreed
>>>>>> contributions code of conduct.
>>>>>>
>>>>>> --Udo
>>>>>>
>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>> Kirk, I believe that creating a Pull Request with multiple commits is
>>>> ok.
>>>>>>> It's just in the end that when it's being pushed to develop branch,
>>> it
>>>>>>> needs to be squash merged. I believe that is what you have mentioned
>>> in
>>>>>> the
>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>> If you can see in the first screenshot comparison that I had attached
>>>> in
>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>
>>>>>>> Thank you for your feedback.
>>>>>>>
>>>>>>> Regards
>>>>>>> Naba
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
>>>>>>>
>>>>>>>> Whenever I submit a PR with multiple commits that I intend to rebase
>>>> to
>>>>>>>> develop, I always try to ensure that each commit stands alone as is
>>>>>>>> (compiles and passes tests). Separating file renames and refactoring
>>>>>> from
>>>>>>>> behavior changes into different commits seems very valuable to me,
>>> and
>>>>>> I've
>>>>>>>> had trouble getting people to review PRs without this separation
>>> (but
>>>> it
>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>
>>>>>>>> It sounds to me like the real problem is (a) some PRs have multiple
>>>>>> commits
>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that should
>>>> be
>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>
>>>>>>>> I can submit multiple PRs instead of one PR with multiple commits.
>>> So
>>>>>> I'll
>>>>>>>> change my response to -0 if that helps prevent commits to develop
>>> that
>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
>>>> commits
>>>>>>>> from github, I'm not sure how we can really enforce this or prevent
>>>> (b)
>>>>>>>> above.
>>>>>>>>
>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>> amurmann@pivotal.io>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>>>>>>>>
>>>>>>>>> Make the change easy (warning: this may be hard), then make the
>>> easy
>>>>>>>>>> change."
>>>>>>>>> -Kent Beck
>>>>>>>>>
>>>>>>>>> Following Kent Beck's advise might reasonably split into two
>>> commits.
>>>>>> One
>>>>>>>>> refactor commit and a separate commit that introduces the actual
>>>>>> change.
>>>>>>>>> They should be individually revertible and might be easier
>>> understood
>>>>>> if
>>>>>>>>> split out. I vividly remember a change on our code base where
>>> someone
>>>>>>>> did a
>>>>>>>>> huge amount of refactoring that resulted than in one parameter
>>>> changing
>>>>>>>> in
>>>>>>>>> order to get the desired functionality change. If that was in one
>>>>>> commit,
>>>>>>>>> it would be hard to see the actual change. If split out, it's
>>>> beautiful
>>>>>>>> and
>>>>>>>>> crystal clear.
>>>>>>>>>
>>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
>>>>>>>> references.
>>>>>>>>> Usually we assume that if there is a commit with the ticket number,
>>>> the
>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>>>> refactoring
>>>>>>>>> ticket.
>>>>>>>>>
>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>
>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
>>> wrote:
>>>>>>>>>
>>>>>>>>>> It is to help with bisect operations when things start failing ...
>>>>>>>> helps
>>>>>>>>> us
>>>>>>>>>> it revert and build faster.
>>>>>>>>>> also with cherry picking features / fixes to previous versions .
>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
>>>> commits”.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Naba
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
>>>>>>>> keep
>>>>>>>>>> them
>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>
>>>>>>>>>>>> A kind request for using squash commit instead of using merge.
>>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>>> regression/flakiness in the product is introduced. We can
>>> automate
>>>>>>>>> and
>>>>>>>>>> go
>>>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless
>>> fix"
>>>>>>>>> and
>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>>>>>>>> branch.
>>>>>>>>>>>> Also, please use the commit format : (helps us to know who
>>> worked
>>>>>>>> on
>>>>>>>>>> it,
>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>> * explanation line 1 *
>>> explanation
>>>>>>>>> line
>>>>>>>>>> 2*
>>>>>>>>>>>> This is not a rule or anything, but a request to help out your
>>>>>>>> fellow
>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>
>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
>>> they
>>>>>>>>> have
>>>>>>>>>> a
>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>>> attachment]
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Naba.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
Bruce, you’re right, there doesn’t seem to be consensus, and a PR was
premature. I was reminded this week that voting is a “last resort”, not the
way to build consensus. I have withdrawn the PR.
On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <eb...@pivotal.io>
wrote:
> I'm a proponent of using squash-and-merge, and once a person has chosen
> this option once it comes up by default afterwards...
>
> Owen, I don't think you have consensus to put forth this PR, there are -1s
> above... (early voting)
>
> maybe we'll be better off socializing the norm of squash-and-merge and
> gaining a natural consensus that way...
>
> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <on...@pivotal.io> wrote:
>
> > The proposed action manifests as a commit to the Geode git repository, so
> > a PR is an acceptable vehicle for voting in this case.
> >
> > > On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <bs...@pivotal.io>
> > wrote:
> > >
> > > I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread
> > and a request to "vote" using a PR. This all seems out of order to me.
> > Our votes are supposed to be on the email list, aren't they? and I
> haven't
> > seen a VOTE request.
> > >
> > > On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > >> +1
> > >>
> > >> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io>
> > wrote:
> > >>
> > >>> Based on the feedback so far, I will amend the proposal to drop item
> > 2).
> > >>> Therefore, the current ability to create merge commits using
> > command-line
> > >>> git will remain available.
> > >>>
> > >>> The proposal as amended is now:
> > >>>> Change GitHub settings to make "Squash and merge" the default
> > >>>> (by removing “Create a merge commit” option).
> > >>>>
> > >>>> Update the PR template to change the text "Is your initial
> > contribution
> > >>>> a single, squashed commit” to “Is your initial contribution squashed
> > for
> > >>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> plus a
> > >>>> ‘fix’ commit)"
> > >>>
> > >>> As Naba suggested, we can try it, and if we don’t like it, it’s
> simple
> > to
> > >>> revert.
> > >>>
> > >>> I’ve create a PR for the proposed change here:
> > >>> https://github.com/apache/geode/pull/4513
> > >>>
> > >>> Please use the PR to vote for against this proposal. It will not be
> > >>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that time)
> > >>>
> > >>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
> > >>>>
> > >>>> +1
> > >>>>
> > >>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io>
> > wrote:
> > >>>>
> > >>>>> Hi Bruce, this proposal will not waste a single second of your
> > time. It
> > >>>>> just prevents people from accidentally pressing a button that we
> have
> > >>>>> already agreed should never be pressed, but because we never
> > configured
> > >>> our
> > >>>>> GitHub to match our stated policy, is currently the default.
> > >>>>>
> > >>>>> However, it will save a lot of time and frustration for anyone
> > needing
> > >>> to
> > >>>>> bisect failures, revert, or cherry-pick changes, which has merit
> > even if
> > >>>>> you personally never do any of those three things.
> > >>>>>
> > >>>>> Please start a separate thread if you would like to revisit the
> > >>> community
> > >>>>> decision to require passing PR checks.
> > >>>>>
> > >>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > bschuchardt@pivotal.io>
> > >>>>> wrote:
> > >>>>>> I agree with Jake. I would go further by saying that I see very
> > little
> > >>>>> merit in this proposal. I think we're getting more and more
> > >>> bureaucratic
> > >>>>> in our process and that it stifles productivity. I was recently
> > forced
> > >>> to
> > >>>>> spend three days fixing tests in which I had changed an import
> > statement
> > >>>>> before they would pass stress testing. I'm glad the tests now pass
> > >>>>> reliably but I was very frustrated by the process.
> > >>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > >>>>>>> I’m in agreement with Dan. Changes to the infrastructure to flat
> > out
> > >>>>> prevent things that should be self policing is annoying. This PR
> > review
> > >>>>> lock we have had already cost us valuable time waiting for PR
> > pipelines
> > >>> to
> > >>>>> pass that have no relevance to the commit, like CI work: I’d hat to
> > see
> > >>> yet
> > >>>>> another process enforced that Kees us from getting work done when
> > >>> necessary.
> > >>>>>>> -Jake
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io>
> wrote:
> > >>>>>>>>
> > >>>>>>>> -1 to (1) and (2).
> > >>>>>>>>
> > >>>>>>>> I think merge commits are appropriate in certain circumstances,
> > so I
> > >>>>> don't
> > >>>>>>>> think we should make a blanket restriction. In fact I think our
> > >>> release
> > >>>>>>>> process involves some merges.
> > >>>>>>>>
> > >>>>>>>> I think setting standards on what is reasonable to be an
> > individual
> > >>>>> commit
> > >>>>>>>> will do a lot more to clean up our history than blocking merges.
> > We'd
> > >>>>>>>> rather not see commits like "Spotless Apply" in the history, but
> > if
> > >>>>>>>> reasonably separate and well written commits come in as part of
> a
> > >>>>> merge, I
> > >>>>>>>> think that's fine.
> > >>>>>>>>
> > >>>>>>>> -Dan
> > >>>>>>>>
> > >>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <jiliao@pivotal.io
> >
> > >>>>> wrote:
> > >>>>>>>>> +1
> > >>>>>>>>>
> > >>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> onichols@pivotal.io
> > >
> > >>>>> wrote:
> > >>>>>>>>>> I’d like to advance this topic from an informal
> > request/discussion
> > >>>>> to a
> > >>>>>>>>>> discussion of a concrete proposal.
> > >>>>>>>>>>
> > >>>>>>>>>> To recap, it sounds like there is general agreement that
> commit
> > >>>>> history
> > >>>>>>>>> on
> > >>>>>>>>>> develop should be linear (no merge commits), and that the
> > biggest
> > >>>>>>>>> obstacle
> > >>>>>>>>>> to this is that the PR merge button in GitHub creates a merge
> > >>> commit
> > >>>>> by
> > >>>>>>>>>> default.
> > >>>>>>>>>>
> > >>>>>>>>>> I propose the following changes:
> > >>>>>>>>>> 1) Change GitHub settings to remove the ability to create a
> > merge
> > >>>>> commit.
> > >>>>>>>>>> This will make Squash & Merge the default.
> > >>>>>>>>>>
> > >>>>>>>>>> 2) Change GitHub settings to require linear history on
> develop.
> > >>> This
> > >>>>>>>>>> prevents merge commits via command-line (not recommended, but
> > wiki
> > >>>>> still
> > >>>>>>>>>> has instructions for merging PRs this way).
> > >>>>>>>>>>
> > >>>>>>>>>> 3) Update the PR template to change the text "Is your initial
> > >>>>>>>>> contribution
> > >>>>>>>>>> a single, squashed commit” to “Is your initial contribution
> > >>> squashed
> > >>>>> for
> > >>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> commit
> > >>> plus
> > >>>>> a
> > >>>>>>>>>> ‘fix’ commit)"
> > >>>>>>>>>>
> > >>>>>>>>>> For clarity, I am proposing no-change in the following areas:
> > >>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
> > >>>>> structured to
> > >>>>>>>>>> benefit from it (this can make it easier in a bisect to see
> > whether
> > >>>>> the
> > >>>>>>>>>> refactoring or the “fix” broke something).
> > >>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
> > >>> squashing
> > >>>>> is
> > >>>>>>>>>> preferred].
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Please comment via this email thread.
> > >>>>>>>>>> -Owen
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org>
> > wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> I think it's already resolved Udo ;)
> > >>>>>>>>>>>
> > >>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all
> > uses
> > >>> of
> > >>>>>>>>>> "this."
> > >>>>>>>>>>> and I rename the dunit test, then git doesn't remember that
> the
> > >>> file
> > >>>>>>>>> is a
> > >>>>>>>>>>> rename -- it forever afterwards interprets it as a new file
> > that I
> > >>>>>>>>>> created
> > >>>>>>>>>>> if I touch more than 50% of the lines (which "this." can
> easily
> > >>>>> do). If
> > >>>>>>>>>> we
> > >>>>>>>>>>> squash two commits: the rename and the cleanup of that dunit
> > test
> > >>> --
> > >>>>>>>>> then
> > >>>>>>>>>>> we effectively lose the history of that file and it shows
> that
> > I
> > >>>>>>>>> created
> > >>>>>>>>>> a
> > >>>>>>>>>>> new file.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Also for the record, I've been working on Geode since the
> > >>> beginning
> > >>>>>>>>> and I
> > >>>>>>>>>>> was never made aware of this change in our process. I never
> > voted
> > >>> on
> > >>>>>>>>> it.
> > >>>>>>>>>>> I'm not a big fan of changing various details in our process
> > every
> > >>>>>>>>> single
> > >>>>>>>>>>> week. It's very easy to miss these discussions unless someone
> > >>>>> points it
> > >>>>>>>>>> out
> > >>>>>>>>>>> to me.
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > >>>>> ukohlmeyer@pivotal.io>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
> > community,
> > >>>>> have
> > >>>>>>>>>>>> agreed in common practices, in two place no less...
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 1) Quoting our PR template
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> For all changes:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> > referenced
> > >>>>> in
> > >>>>>>>>>>>> the commit message?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Has your PR been rebased against the latest commit within
> the
> > >>>>>>>>> target
> > >>>>>>>>>>>> branch (typically|develop|)?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> ***Is your initial contribution a single, squashed commit?*
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Does|gradlew build|run cleanly?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Have you written or updated unit tests to verify your
> > changes?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> If adding new dependencies to the code, are these
> > dependencies
> > >>>>>>>>>>>> licensed in a way that is compatible for inclusion underASF
> > 2.0
> > >>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On our PR template we call out that the initial PR commit
> > should
> > >>> be
> > >>>>>>>>>>>> squashed.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 2)
> > >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>>>>>>>>>> <
> > >>>>>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend you
> > on
> > >>> the
> > >>>>>>>>>>>> diligence, but in reality, they should either then be stand
> > alone
> > >>>>> PR's
> > >>>>>>>>>>>> or just extra work created for yourself.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> If we want to change the way we have agreed upon we
> > >>>>>>>>> submit/commit/merge
> > >>>>>>>>>>>> changes back into develop... Then this is another discussion
> > >>>>> thread,
> > >>>>>>>>>>>> until then, I think we should all remind ourselves on our
> > agreed
> > >>>>>>>>>>>> contributions code of conduct.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --Udo
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > >>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with multiple
> > >>>>> commits is
> > >>>>>>>>>> ok.
> > >>>>>>>>>>>>> It's just in the end that when it's being pushed to develop
> > >>>>> branch,
> > >>>>>>>>> it
> > >>>>>>>>>>>>> needs to be squash merged. I believe that is what you have
> > >>>>> mentioned
> > >>>>>>>>> in
> > >>>>>>>>>>>> the
> > >>>>>>>>>>>>> first paragraph, and I am more than happy with that.
> > >>>>>>>>>>>>> If you can see in the first screenshot comparison that I
> had
> > >>>>> attached
> > >>>>>>>>>> in
> > >>>>>>>>>>>>> the first email in this thread is what I want to avoid.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thank you for your feedback.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>> Naba
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> klund@apache.org>
> > >>>>> wrote:
> > >>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I intend
> > to
> > >>>>> rebase
> > >>>>>>>>>> to
> > >>>>>>>>>>>>>> develop, I always try to ensure that each commit stands
> > alone
> > >>> as
> > >>>>> is
> > >>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
> > >>>>> refactoring
> > >>>>>>>>>>>> from
> > >>>>>>>>>>>>>> behavior changes into different commits seems very
> valuable
> > to
> > >>>>> me,
> > >>>>>>>>> and
> > >>>>>>>>>>>> I've
> > >>>>>>>>>>>>>> had trouble getting people to review PRs without this
> > >>> separation
> > >>>>>>>>> (but
> > >>>>>>>>>> it
> > >>>>>>>>>>>>>> could be squashed as it's merged to develop).
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs have
> > >>>>> multiple
> > >>>>>>>>>>>> commits
> > >>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs
> > that
> > >>>>> should
> > >>>>>>>>>> be
> > >>>>>>>>>>>>>> merged with squash are not (by accident most likely).
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with multiple
> > >>>>> commits.
> > >>>>>>>>> So
> > >>>>>>>>>>>> I'll
> > >>>>>>>>>>>>>> change my response to -0 if that helps prevent commits to
> > >>> develop
> > >>>>>>>>> that
> > >>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase or
> > merge
> > >>>>>>>>>> commits
> > >>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this
> or
> > >>>>> prevent
> > >>>>>>>>>> (b)
> > >>>>>>>>>>>>>> above.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > >>>>>>>>>> amurmann@pivotal.io>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily
> at
> > >>>>> odds.
> > >>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then
> make
> > >>> the
> > >>>>>>>>> easy
> > >>>>>>>>>>>>>>>> change."
> > >>>>>>>>>>>>>>> -Kent Beck
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split into
> > two
> > >>>>>>>>> commits.
> > >>>>>>>>>>>> One
> > >>>>>>>>>>>>>>> refactor commit and a separate commit that introduces the
> > >>> actual
> > >>>>>>>>>>>> change.
> > >>>>>>>>>>>>>>> They should be individually revertible and might be
> easier
> > >>>>>>>>> understood
> > >>>>>>>>>>>> if
> > >>>>>>>>>>>>>>> split out. I vividly remember a change on our code base
> > where
> > >>>>>>>>> someone
> > >>>>>>>>>>>>>> did a
> > >>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one
> > parameter
> > >>>>>>>>>> changing
> > >>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>> order to get the desired functionality change. If that
> was
> > in
> > >>>>> one
> > >>>>>>>>>>>> commit,
> > >>>>>>>>>>>>>>> it would be hard to see the actual change. If split out,
> > it's
> > >>>>>>>>>> beautiful
> > >>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>> crystal clear.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA
> > >>> ticket
> > >>>>>>>>>>>>>> references.
> > >>>>>>>>>>>>>>> Usually we assume that if there is a commit with the
> ticket
> > >>>>> number,
> > >>>>>>>>>> the
> > >>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a
> > separate
> > >>>>>>>>>>>> refactoring
> > >>>>>>>>>>>>>>> ticket.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> > nnag@pivotal.io>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>> It is to help with bisect operations when things start
> > >>> failing
> > >>>>> ...
> > >>>>>>>>>>>>>> helps
> > >>>>>>>>>>>>>>> us
> > >>>>>>>>>>>>>>>> it revert and build faster.
> > >>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
> > >>> versions
> > >>>>> .
> > >>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary
> > “merge
> > >>>>>>>>>> commits”.
> > >>>>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>>> Naba
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> > klund@apache.org>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit
> in
> > a
> > >>> PR
> > >>>>> and
> > >>>>>>>>>>>>>> keep
> > >>>>>>>>>>>>>>>> them
> > >>>>>>>>>>>>>>>>> separate when they merge to develop
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> > >>> nnag@pivotal.io>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>> Hi Geode Committers,
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of
> using
> > >>>>> merge.
> > >>>>>>>>>>>>>>>>>> This will really help us in our bisect operations
> when a
> > >>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced. We
> > can
> > >>>>>>>>> automate
> > >>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>> go
> > >>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
> > >>> "spotless
> > >>>>>>>>> fix"
> > >>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the
> > >>> merged
> > >>>>>>>>>>>>>> branch.
> > >>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to know
> > who
> > >>>>>>>>> worked
> > >>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>> it,
> > >>>>>>>>>>>>>>>>>> what is the history)
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> > >>>>>>>>>>>>>>>>>> * explanation line 1 *
> > >>>>>>>>> explanation
> > >>>>>>>>>>>>>>> line
> > >>>>>>>>>>>>>>>> 2*
> > >>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to help
> > out
> > >>>>> your
> > >>>>>>>>>>>>>> fellow
> > >>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark
> > >>> where
> > >>>>>>>>> they
> > >>>>>>>>>>>>>>> have
> > >>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
> > >>>>>>>>> attachment]
> > >>>>>>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>>>>> Naba.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>> --
> > >>>> Ju@N
> > >>>
> >
> >
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Blake Bender <bb...@pivotal.io>.
This was the part I was referring to, from the existing PR template:
> Update the PR template to change the text "Is your initial contribution
> a single, squashed commit” to “Is your initial contribution squashed for
> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
> ‘fix’ commit)"
Either of these, while I guess not strictly required(?), is a change from
what SOP has been for native client. We rebase onto the current develop
when submitting a PR, but don't pre-squash commits in any meaningful way,
because it's unnecessary.
The rest is fine - changing the default option to Squash & Merge is the
right thing to do IMO.
Thanks,
Blake
On Fri, Dec 20, 2019 at 12:00 PM Nabarun Nag <nn...@pivotal.io> wrote:
> Just to reiterate. Nothing changes in the workflow of a developer. It's
> just in the end, when all the reviews are done and all the tests are
> passing, then the button to click in the Github web UI is "Squash and
> Merge". That's all.
>
> Regards
> Naba
>
>
>
> On Fri, Dec 20, 2019 at 11:55 AM Blake Bender <bb...@pivotal.io> wrote:
>
> > Very well, then, I'll abide by the group consensus but am on the record
> as:
> > * strongly opposed to multi-commit PRs, because I believe it clutters
> > history, and
> > * also not a big fan of forcing devs to rebase and squash prior to
> > submitting a PR. IMO this is busy work, and *may* in some small minority
> > of cases hide information that would be useful to reviewers.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
> wrote:
> >
> > > Whether we are talking about the geode/ repository or the geode-native/
> > > repository we are all one GEODE community.
> > >
> > > The idea of a native client team may matter in some contexts but in
> this
> > > space we are all GEODE contributors.
> > >
> > > Adopting a common approach across our repos will make it easier for new
> > > contributors to engage, learn our norms, and join our efforts.
> > >
> > > $0.02,
> > > Anthony
> > >
> > >
> > > > On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
> wrote:
> > > >
> > > > Is this a policy the native client team must abide by, as well? It
> > > varies
> > > > slightly with what we've been doing, and all other things being
> equal I
> > > see
> > > > no reason for us to change that. If I am to have any measure of
> > control
> > > > over the nc repository, I will definitely enforce a 1:1
> correspondence
> > > > between commits to develop and JIRA tickets. IMO, if your
> refactoring
> > > in a
> > > > PR is sufficiently large or complex that it's difficult to tease it
> out
> > > > from the bug you're fixing or feature you're implementing, it merits
> > its
> > > > own JIRA ticket and a separate PR. If your "actual" fix then becomes
> > > > dependent on the refactored code, that's a price I'm willing to pay
> to
> > > keep
> > > > history clean.
> > > >
> > > > On the other hand, I see no real value in squashing to a single
> commit
> > > > prior to submitting a PR, since your view of the changes on GitHub is
> > > > essentially the same either way. We haven't enforced this on the nc
> > > repo,
> > > > and I'd prefer to keep it that way.
> > > >
> > > > Thanks,
> > > >
> > > > Blake
> > > >
> > > >
> > > > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
> > wrote:
> > > >
> > > >> Merge commit is the new contributor's default setting. When we are
> > > merging
> > > >> new contributor's PR, since we are so used to THINKING
> > > "squash-and-merge"
> > > >> is the default, we forgot to check what the button really says when
> we
> > > are
> > > >> merging other people's PR.
> > > >>
> > > >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > > eburghardt@pivotal.io>
> > > >> wrote:
> > > >>
> > > >>> I'm a proponent of using squash-and-merge, and once a person has
> > chosen
> > > >>> this option once it comes up by default afterwards...
> > > >>>
> > > >>> Owen, I don't think you have consensus to put forth this PR, there
> > are
> > > >> -1s
> > > >>> above... (early voting)
> > > >>>
> > > >>> maybe we'll be better off socializing the norm of squash-and-merge
> > and
> > > >>> gaining a natural consensus that way...
> > > >>>
> > > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <onichols@pivotal.io
> >
> > > >> wrote:
> > > >>>
> > > >>>> The proposed action manifests as a commit to the Geode git
> > repository,
> > > >> so
> > > >>>> a PR is an acceptable vehicle for voting in this case.
> > > >>>>
> > > >>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > > >> bschuchardt@pivotal.io>
> > > >>>> wrote:
> > > >>>>>
> > > >>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> > > >> thread
> > > >>>> and a request to "vote" using a PR. This all seems out of order
> to
> > > me.
> > > >>>> Our votes are supposed to be on the email list, aren't they? and I
> > > >>> haven't
> > > >>>> seen a VOTE request.
> > > >>>>>
> > > >>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > > >>>>>> +1
> > > >>>>>>
> > > >>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
> onichols@pivotal.io
> > >
> > > >>>> wrote:
> > > >>>>>>
> > > >>>>>>> Based on the feedback so far, I will amend the proposal to drop
> > > >> item
> > > >>>> 2).
> > > >>>>>>> Therefore, the current ability to create merge commits using
> > > >>>> command-line
> > > >>>>>>> git will remain available.
> > > >>>>>>>
> > > >>>>>>> The proposal as amended is now:
> > > >>>>>>>> Change GitHub settings to make "Squash and merge" the default
> > > >>>>>>>> (by removing “Create a merge commit” option).
> > > >>>>>>>>
> > > >>>>>>>> Update the PR template to change the text "Is your initial
> > > >>>> contribution
> > > >>>>>>>> a single, squashed commit” to “Is your initial contribution
> > > >> squashed
> > > >>>> for
> > > >>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> commit
> > > >>> plus a
> > > >>>>>>>> ‘fix’ commit)"
> > > >>>>>>>
> > > >>>>>>> As Naba suggested, we can try it, and if we don’t like it, it’s
> > > >>> simple
> > > >>>> to
> > > >>>>>>> revert.
> > > >>>>>>>
> > > >>>>>>> I’ve create a PR for the proposed change here:
> > > >>>>>>> https://github.com/apache/geode/pull/4513
> > > >>>>>>>
> > > >>>>>>> Please use the PR to vote for against this proposal. It will
> not
> > > >> be
> > > >>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
> > > >> time)
> > > >>>>>>>
> > > >>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
> wrote:
> > > >>>>>>>>
> > > >>>>>>>> +1
> > > >>>>>>>>
> > > >>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
> onichols@pivotal.io>
> > > >>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Hi Bruce, this proposal will not waste a single second of
> your
> > > >>>> time. It
> > > >>>>>>>>> just prevents people from accidentally pressing a button that
> > we
> > > >>> have
> > > >>>>>>>>> already agreed should never be pressed, but because we never
> > > >>>> configured
> > > >>>>>>> our
> > > >>>>>>>>> GitHub to match our stated policy, is currently the default.
> > > >>>>>>>>>
> > > >>>>>>>>> However, it will save a lot of time and frustration for
> anyone
> > > >>>> needing
> > > >>>>>>> to
> > > >>>>>>>>> bisect failures, revert, or cherry-pick changes, which has
> > merit
> > > >>>> even if
> > > >>>>>>>>> you personally never do any of those three things.
> > > >>>>>>>>>
> > > >>>>>>>>> Please start a separate thread if you would like to revisit
> the
> > > >>>>>>> community
> > > >>>>>>>>> decision to require passing PR checks.
> > > >>>>>>>>>
> > > >>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > > >>>> bschuchardt@pivotal.io>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>> I agree with Jake. I would go further by saying that I see
> > very
> > > >>>> little
> > > >>>>>>>>> merit in this proposal. I think we're getting more and more
> > > >>>>>>> bureaucratic
> > > >>>>>>>>> in our process and that it stifles productivity. I was
> > recently
> > > >>>> forced
> > > >>>>>>> to
> > > >>>>>>>>> spend three days fixing tests in which I had changed an
> import
> > > >>>> statement
> > > >>>>>>>>> before they would pass stress testing. I'm glad the tests
> now
> > > >> pass
> > > >>>>>>>>> reliably but I was very frustrated by the process.
> > > >>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > > >>>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to
> > > >> flat
> > > >>>> out
> > > >>>>>>>>> prevent things that should be self policing is annoying. This
> > PR
> > > >>>> review
> > > >>>>>>>>> lock we have had already cost us valuable time waiting for PR
> > > >>>> pipelines
> > > >>>>>>> to
> > > >>>>>>>>> pass that have no relevance to the commit, like CI work: I’d
> > hat
> > > >> to
> > > >>>> see
> > > >>>>>>> yet
> > > >>>>>>>>> another process enforced that Kees us from getting work done
> > when
> > > >>>>>>> necessary.
> > > >>>>>>>>>>> -Jake
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <dsmith@pivotal.io
> >
> > > >>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> -1 to (1) and (2).
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I think merge commits are appropriate in certain
> > > >> circumstances,
> > > >>>> so I
> > > >>>>>>>>> don't
> > > >>>>>>>>>>>> think we should make a blanket restriction. In fact I
> think
> > > >> our
> > > >>>>>>> release
> > > >>>>>>>>>>>> process involves some merges.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I think setting standards on what is reasonable to be an
> > > >>>> individual
> > > >>>>>>>>> commit
> > > >>>>>>>>>>>> will do a lot more to clean up our history than blocking
> > > >> merges.
> > > >>>> We'd
> > > >>>>>>>>>>>> rather not see commits like "Spotless Apply" in the
> history,
> > > >> but
> > > >>>> if
> > > >>>>>>>>>>>> reasonably separate and well written commits come in as
> part
> > > >> of
> > > >>> a
> > > >>>>>>>>> merge, I
> > > >>>>>>>>>>>> think that's fine.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> -Dan
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> > > >> jiliao@pivotal.io
> > > >>>>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>> +1
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> > > >>> onichols@pivotal.io
> > > >>>>>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>>> I’d like to advance this topic from an informal
> > > >>>> request/discussion
> > > >>>>>>>>> to a
> > > >>>>>>>>>>>>>> discussion of a concrete proposal.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> To recap, it sounds like there is general agreement that
> > > >>> commit
> > > >>>>>>>>> history
> > > >>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>> develop should be linear (no merge commits), and that
> the
> > > >>>> biggest
> > > >>>>>>>>>>>>> obstacle
> > > >>>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a
> > > >> merge
> > > >>>>>>> commit
> > > >>>>>>>>> by
> > > >>>>>>>>>>>>>> default.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I propose the following changes:
> > > >>>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to
> create
> > a
> > > >>>> merge
> > > >>>>>>>>> commit.
> > > >>>>>>>>>>>>>> This will make Squash & Merge the default.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 2) Change GitHub settings to require linear history on
> > > >>> develop.
> > > >>>>>>> This
> > > >>>>>>>>>>>>>> prevents merge commits via command-line (not
> recommended,
> > > >> but
> > > >>>> wiki
> > > >>>>>>>>> still
> > > >>>>>>>>>>>>>> has instructions for merging PRs this way).
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 3) Update the PR template to change the text "Is your
> > > >> initial
> > > >>>>>>>>>>>>> contribution
> > > >>>>>>>>>>>>>> a single, squashed commit” to “Is your initial
> > contribution
> > > >>>>>>> squashed
> > > >>>>>>>>> for
> > > >>>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> > > >>> commit
> > > >>>>>>> plus
> > > >>>>>>>>> a
> > > >>>>>>>>>>>>>> ‘fix’ commit)"
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> For clarity, I am proposing no-change in the following
> > > >> areas:
> > > >>>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have
> > been
> > > >>>>>>>>> structured to
> > > >>>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to
> > see
> > > >>>> whether
> > > >>>>>>>>> the
> > > >>>>>>>>>>>>>> refactoring or the “fix” broke something).
> > > >>>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating
> that
> > > >>>>>>> squashing
> > > >>>>>>>>> is
> > > >>>>>>>>>>>>>> preferred].
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Please comment via this email thread.
> > > >>>>>>>>>>>>>> -Owen
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> > klund@apache.org>
> > > >>>> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> I think it's already resolved Udo ;)
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing
> > all
> > > >>>> uses
> > > >>>>>>> of
> > > >>>>>>>>>>>>>> "this."
> > > >>>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember
> > that
> > > >>> the
> > > >>>>>>> file
> > > >>>>>>>>>>>>> is a
> > > >>>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new
> > file
> > > >>>> that I
> > > >>>>>>>>>>>>>> created
> > > >>>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this."
> can
> > > >>> easily
> > > >>>>>>>>> do). If
> > > >>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that
> > > >> dunit
> > > >>>> test
> > > >>>>>>> --
> > > >>>>>>>>>>>>> then
> > > >>>>>>>>>>>>>>> we effectively lose the history of that file and it
> shows
> > > >>> that
> > > >>>> I
> > > >>>>>>>>>>>>> created
> > > >>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>> new file.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Also for the record, I've been working on Geode since
> the
> > > >>>>>>> beginning
> > > >>>>>>>>>>>>> and I
> > > >>>>>>>>>>>>>>> was never made aware of this change in our process. I
> > never
> > > >>>> voted
> > > >>>>>>> on
> > > >>>>>>>>>>>>> it.
> > > >>>>>>>>>>>>>>> I'm not a big fan of changing various details in our
> > > >> process
> > > >>>> every
> > > >>>>>>>>>>>>> single
> > > >>>>>>>>>>>>>>> week. It's very easy to miss these discussions unless
> > > >> someone
> > > >>>>>>>>> points it
> > > >>>>>>>>>>>>>> out
> > > >>>>>>>>>>>>>>> to me.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > > >>>>>>>>> ukohlmeyer@pivotal.io>
> > > >>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
> > > >>>> community,
> > > >>>>>>>>> have
> > > >>>>>>>>>>>>>>>> agreed in common practices, in two place no less...
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 1) Quoting our PR template
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> For all changes:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> > > >>>> referenced
> > > >>>>>>>>> in
> > > >>>>>>>>>>>>>>>> the commit message?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Has your PR been rebased against the latest commit
> > within
> > > >>> the
> > > >>>>>>>>>>>>> target
> > > >>>>>>>>>>>>>>>> branch (typically|develop|)?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed
> > > >> commit?*
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
> > > >>>> changes?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> If adding new dependencies to the code, are these
> > > >>>> dependencies
> > > >>>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion
> > > >> underASF
> > > >>>> 2.0
> > > >>>>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a
> >?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On our PR template we call out that the initial PR
> > commit
> > > >>>> should
> > > >>>>>>> be
> > > >>>>>>>>>>>>>>>> squashed.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 2)
> > > >>>>>>>
> > > >>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > >>>>>>>>>>>>>>>> <
> > > >>>>>>>>>
> > > >>>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > >>>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point
> > #3.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I
> commend
> > > >> you
> > > >>>> on
> > > >>>>>>> the
> > > >>>>>>>>>>>>>>>> diligence, but in reality, they should either then be
> > > >> stand
> > > >>>> alone
> > > >>>>>>>>> PR's
> > > >>>>>>>>>>>>>>>> or just extra work created for yourself.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
> > > >>>>>>>>>>>>> submit/commit/merge
> > > >>>>>>>>>>>>>>>> changes back into develop... Then this is another
> > > >> discussion
> > > >>>>>>>>> thread,
> > > >>>>>>>>>>>>>>>> until then, I think we should all remind ourselves on
> > our
> > > >>>> agreed
> > > >>>>>>>>>>>>>>>> contributions code of conduct.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> --Udo
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > > >>>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
> > > >> multiple
> > > >>>>>>>>> commits is
> > > >>>>>>>>>>>>>> ok.
> > > >>>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to
> > > >> develop
> > > >>>>>>>>> branch,
> > > >>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you
> > > >> have
> > > >>>>>>>>> mentioned
> > > >>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
> > > >>>>>>>>>>>>>>>>> If you can see in the first screenshot comparison
> that
> > I
> > > >>> had
> > > >>>>>>>>> attached
> > > >>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>> the first email in this thread is what I want to
> avoid.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Thank you for your feedback.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Regards
> > > >>>>>>>>>>>>>>>>> Naba
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> > > >>> klund@apache.org>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
> > > >> intend
> > > >>>> to
> > > >>>>>>>>> rebase
> > > >>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit
> > stands
> > > >>>> alone
> > > >>>>>>> as
> > > >>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames
> > and
> > > >>>>>>>>> refactoring
> > > >>>>>>>>>>>>>>>> from
> > > >>>>>>>>>>>>>>>>>> behavior changes into different commits seems very
> > > >>> valuable
> > > >>>> to
> > > >>>>>>>>> me,
> > > >>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>> I've
> > > >>>>>>>>>>>>>>>>>> had trouble getting people to review PRs without
> this
> > > >>>>>>> separation
> > > >>>>>>>>>>>>> (but
> > > >>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some
> PRs
> > > >> have
> > > >>>>>>>>> multiple
> > > >>>>>>>>>>>>>>>> commits
> > > >>>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some
> > PRs
> > > >>>> that
> > > >>>>>>>>> should
> > > >>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>> merged with squash are not (by accident most
> likely).
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
> > > >> multiple
> > > >>>>>>>>> commits.
> > > >>>>>>>>>>>>> So
> > > >>>>>>>>>>>>>>>> I'll
> > > >>>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent
> commits
> > > >> to
> > > >>>>>>> develop
> > > >>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing
> rebase
> > > >> or
> > > >>>> merge
> > > >>>>>>>>>>>>>> commits
> > > >>>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce
> > this
> > > >>> or
> > > >>>>>>>>> prevent
> > > >>>>>>>>>>>>>> (b)
> > > >>>>>>>>>>>>>>>>>> above.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > > >>>>>>>>>>>>>> amurmann@pivotal.io>
> > > >>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
> > > >> necessarily
> > > >>> at
> > > >>>>>>>>> odds.
> > > >>>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard),
> > then
> > > >>> make
> > > >>>>>>> the
> > > >>>>>>>>>>>>> easy
> > > >>>>>>>>>>>>>>>>>>>> change."
> > > >>>>>>>>>>>>>>>>>>> -Kent Beck
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split
> > > >> into
> > > >>>> two
> > > >>>>>>>>>>>>> commits.
> > > >>>>>>>>>>>>>>>> One
> > > >>>>>>>>>>>>>>>>>>> refactor commit and a separate commit that
> introduces
> > > >> the
> > > >>>>>>> actual
> > > >>>>>>>>>>>>>>>> change.
> > > >>>>>>>>>>>>>>>>>>> They should be individually revertible and might be
> > > >>> easier
> > > >>>>>>>>>>>>> understood
> > > >>>>>>>>>>>>>>>> if
> > > >>>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code
> > base
> > > >>>> where
> > > >>>>>>>>>>>>> someone
> > > >>>>>>>>>>>>>>>>>> did a
> > > >>>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in
> one
> > > >>>> parameter
> > > >>>>>>>>>>>>>> changing
> > > >>>>>>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>>>> order to get the desired functionality change. If
> > that
> > > >>> was
> > > >>>> in
> > > >>>>>>>>> one
> > > >>>>>>>>>>>>>>>> commit,
> > > >>>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split
> > > >> out,
> > > >>>> it's
> > > >>>>>>>>>>>>>> beautiful
> > > >>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>> crystal clear.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of
> > > >> JIRA
> > > >>>>>>> ticket
> > > >>>>>>>>>>>>>>>>>> references.
> > > >>>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with
> the
> > > >>> ticket
> > > >>>>>>>>> number,
> > > >>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create
> a
> > > >>>> separate
> > > >>>>>>>>>>>>>>>> refactoring
> > > >>>>>>>>>>>>>>>>>>> ticket.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it
> too?
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> > > >>>> nnag@pivotal.io>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things
> > start
> > > >>>>>>> failing
> > > >>>>>>>>> ...
> > > >>>>>>>>>>>>>>>>>> helps
> > > >>>>>>>>>>>>>>>>>>> us
> > > >>>>>>>>>>>>>>>>>>>> it revert and build faster.
> > > >>>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to
> > previous
> > > >>>>>>> versions
> > > >>>>>>>>> .
> > > >>>>>>>>>>>>>>>>>>>> And keeping the git history clean with no
> > unnecessary
> > > >>>> “merge
> > > >>>>>>>>>>>>>> commits”.
> > > >>>>>>>>>>>>>>>>>>>> Regards
> > > >>>>>>>>>>>>>>>>>>>> Naba
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> > > >>>> klund@apache.org>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1
> > commit
> > > >>> in
> > > >>>> a
> > > >>>>>>> PR
> > > >>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>> keep
> > > >>>>>>>>>>>>>>>>>>>> them
> > > >>>>>>>>>>>>>>>>>>>>> separate when they merge to develop
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> > > >>>>>>> nnag@pivotal.io>
> > > >>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead
> of
> > > >>> using
> > > >>>>>>>>> merge.
> > > >>>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect
> operations
> > > >>> when a
> > > >>>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is
> introduced.
> > > >> We
> > > >>>> can
> > > >>>>>>>>>>>>> automate
> > > >>>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>> go
> > > >>>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits
> > like
> > > >>>>>>> "spotless
> > > >>>>>>>>>>>>> fix"
> > > >>>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits
> in
> > > >> the
> > > >>>>>>> merged
> > > >>>>>>>>>>>>>>>>>> branch.
> > > >>>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us
> to
> > > >> know
> > > >>>> who
> > > >>>>>>>>>>>>> worked
> > > >>>>>>>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>>>>>>>> it,
> > > >>>>>>>>>>>>>>>>>>>>>> what is the history)
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> > > >>>>>>>>>>>>>>>>>>>>>> * explanation line 1
> > > >> *
> > > >>>>>>>>>>>>> explanation
> > > >>>>>>>>>>>>>>>>>>> line
> > > >>>>>>>>>>>>>>>>>>>> 2*
> > > >>>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to
> > > >> help
> > > >>>> out
> > > >>>>>>>>> your
> > > >>>>>>>>>>>>>>>>>> fellow
> > > >>>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka /
> > > >> Spark
> > > >>>>>>> where
> > > >>>>>>>>>>>>> they
> > > >>>>>>>>>>>>>>>>>>> have
> > > >>>>>>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD
> > > >> [see
> > > >>>>>>>>>>>>> attachment]
> > > >>>>>>>>>>>>>>>>>>>>>> Regards
> > > >>>>>>>>>>>>>>>>>>>>>> Naba.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>> Ju@N
> > > >>>>>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Cheers
> > > >>
> > > >> Jinmei
> > > >>
> > >
> > >
> >
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Nabarun Nag <nn...@pivotal.io>.
Just to reiterate. Nothing changes in the workflow of a developer. It's
just in the end, when all the reviews are done and all the tests are
passing, then the button to click in the Github web UI is "Squash and
Merge". That's all.
Regards
Naba
On Fri, Dec 20, 2019 at 11:55 AM Blake Bender <bb...@pivotal.io> wrote:
> Very well, then, I'll abide by the group consensus but am on the record as:
> * strongly opposed to multi-commit PRs, because I believe it clutters
> history, and
> * also not a big fan of forcing devs to rebase and squash prior to
> submitting a PR. IMO this is busy work, and *may* in some small minority
> of cases hide information that would be useful to reviewers.
>
> Thanks,
>
> Blake
>
>
> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io> wrote:
>
> > Whether we are talking about the geode/ repository or the geode-native/
> > repository we are all one GEODE community.
> >
> > The idea of a native client team may matter in some contexts but in this
> > space we are all GEODE contributors.
> >
> > Adopting a common approach across our repos will make it easier for new
> > contributors to engage, learn our norms, and join our efforts.
> >
> > $0.02,
> > Anthony
> >
> >
> > > On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io> wrote:
> > >
> > > Is this a policy the native client team must abide by, as well? It
> > varies
> > > slightly with what we've been doing, and all other things being equal I
> > see
> > > no reason for us to change that. If I am to have any measure of
> control
> > > over the nc repository, I will definitely enforce a 1:1 correspondence
> > > between commits to develop and JIRA tickets. IMO, if your refactoring
> > in a
> > > PR is sufficiently large or complex that it's difficult to tease it out
> > > from the bug you're fixing or feature you're implementing, it merits
> its
> > > own JIRA ticket and a separate PR. If your "actual" fix then becomes
> > > dependent on the refactored code, that's a price I'm willing to pay to
> > keep
> > > history clean.
> > >
> > > On the other hand, I see no real value in squashing to a single commit
> > > prior to submitting a PR, since your view of the changes on GitHub is
> > > essentially the same either way. We haven't enforced this on the nc
> > repo,
> > > and I'd prefer to keep it that way.
> > >
> > > Thanks,
> > >
> > > Blake
> > >
> > >
> > > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
> wrote:
> > >
> > >> Merge commit is the new contributor's default setting. When we are
> > merging
> > >> new contributor's PR, since we are so used to THINKING
> > "squash-and-merge"
> > >> is the default, we forgot to check what the button really says when we
> > are
> > >> merging other people's PR.
> > >>
> > >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > eburghardt@pivotal.io>
> > >> wrote:
> > >>
> > >>> I'm a proponent of using squash-and-merge, and once a person has
> chosen
> > >>> this option once it comes up by default afterwards...
> > >>>
> > >>> Owen, I don't think you have consensus to put forth this PR, there
> are
> > >> -1s
> > >>> above... (early voting)
> > >>>
> > >>> maybe we'll be better off socializing the norm of squash-and-merge
> and
> > >>> gaining a natural consensus that way...
> > >>>
> > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <on...@pivotal.io>
> > >> wrote:
> > >>>
> > >>>> The proposed action manifests as a commit to the Geode git
> repository,
> > >> so
> > >>>> a PR is an acceptable vehicle for voting in this case.
> > >>>>
> > >>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > >> bschuchardt@pivotal.io>
> > >>>> wrote:
> > >>>>>
> > >>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> > >> thread
> > >>>> and a request to "vote" using a PR. This all seems out of order to
> > me.
> > >>>> Our votes are supposed to be on the email list, aren't they? and I
> > >>> haven't
> > >>>> seen a VOTE request.
> > >>>>>
> > >>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > >>>>>> +1
> > >>>>>>
> > >>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <onichols@pivotal.io
> >
> > >>>> wrote:
> > >>>>>>
> > >>>>>>> Based on the feedback so far, I will amend the proposal to drop
> > >> item
> > >>>> 2).
> > >>>>>>> Therefore, the current ability to create merge commits using
> > >>>> command-line
> > >>>>>>> git will remain available.
> > >>>>>>>
> > >>>>>>> The proposal as amended is now:
> > >>>>>>>> Change GitHub settings to make "Squash and merge" the default
> > >>>>>>>> (by removing “Create a merge commit” option).
> > >>>>>>>>
> > >>>>>>>> Update the PR template to change the text "Is your initial
> > >>>> contribution
> > >>>>>>>> a single, squashed commit” to “Is your initial contribution
> > >> squashed
> > >>>> for
> > >>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> > >>> plus a
> > >>>>>>>> ‘fix’ commit)"
> > >>>>>>>
> > >>>>>>> As Naba suggested, we can try it, and if we don’t like it, it’s
> > >>> simple
> > >>>> to
> > >>>>>>> revert.
> > >>>>>>>
> > >>>>>>> I’ve create a PR for the proposed change here:
> > >>>>>>> https://github.com/apache/geode/pull/4513
> > >>>>>>>
> > >>>>>>> Please use the PR to vote for against this proposal. It will not
> > >> be
> > >>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
> > >> time)
> > >>>>>>>
> > >>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
> > >>>>>>>>
> > >>>>>>>> +1
> > >>>>>>>>
> > >>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io>
> > >>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Hi Bruce, this proposal will not waste a single second of your
> > >>>> time. It
> > >>>>>>>>> just prevents people from accidentally pressing a button that
> we
> > >>> have
> > >>>>>>>>> already agreed should never be pressed, but because we never
> > >>>> configured
> > >>>>>>> our
> > >>>>>>>>> GitHub to match our stated policy, is currently the default.
> > >>>>>>>>>
> > >>>>>>>>> However, it will save a lot of time and frustration for anyone
> > >>>> needing
> > >>>>>>> to
> > >>>>>>>>> bisect failures, revert, or cherry-pick changes, which has
> merit
> > >>>> even if
> > >>>>>>>>> you personally never do any of those three things.
> > >>>>>>>>>
> > >>>>>>>>> Please start a separate thread if you would like to revisit the
> > >>>>>>> community
> > >>>>>>>>> decision to require passing PR checks.
> > >>>>>>>>>
> > >>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > >>>> bschuchardt@pivotal.io>
> > >>>>>>>>> wrote:
> > >>>>>>>>>> I agree with Jake. I would go further by saying that I see
> very
> > >>>> little
> > >>>>>>>>> merit in this proposal. I think we're getting more and more
> > >>>>>>> bureaucratic
> > >>>>>>>>> in our process and that it stifles productivity. I was
> recently
> > >>>> forced
> > >>>>>>> to
> > >>>>>>>>> spend three days fixing tests in which I had changed an import
> > >>>> statement
> > >>>>>>>>> before they would pass stress testing. I'm glad the tests now
> > >> pass
> > >>>>>>>>> reliably but I was very frustrated by the process.
> > >>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > >>>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to
> > >> flat
> > >>>> out
> > >>>>>>>>> prevent things that should be self policing is annoying. This
> PR
> > >>>> review
> > >>>>>>>>> lock we have had already cost us valuable time waiting for PR
> > >>>> pipelines
> > >>>>>>> to
> > >>>>>>>>> pass that have no relevance to the commit, like CI work: I’d
> hat
> > >> to
> > >>>> see
> > >>>>>>> yet
> > >>>>>>>>> another process enforced that Kees us from getting work done
> when
> > >>>>>>> necessary.
> > >>>>>>>>>>> -Jake
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io>
> > >>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> -1 to (1) and (2).
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I think merge commits are appropriate in certain
> > >> circumstances,
> > >>>> so I
> > >>>>>>>>> don't
> > >>>>>>>>>>>> think we should make a blanket restriction. In fact I think
> > >> our
> > >>>>>>> release
> > >>>>>>>>>>>> process involves some merges.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I think setting standards on what is reasonable to be an
> > >>>> individual
> > >>>>>>>>> commit
> > >>>>>>>>>>>> will do a lot more to clean up our history than blocking
> > >> merges.
> > >>>> We'd
> > >>>>>>>>>>>> rather not see commits like "Spotless Apply" in the history,
> > >> but
> > >>>> if
> > >>>>>>>>>>>> reasonably separate and well written commits come in as part
> > >> of
> > >>> a
> > >>>>>>>>> merge, I
> > >>>>>>>>>>>> think that's fine.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> -Dan
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> > >> jiliao@pivotal.io
> > >>>>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>> +1
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> > >>> onichols@pivotal.io
> > >>>>>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>>> I’d like to advance this topic from an informal
> > >>>> request/discussion
> > >>>>>>>>> to a
> > >>>>>>>>>>>>>> discussion of a concrete proposal.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> To recap, it sounds like there is general agreement that
> > >>> commit
> > >>>>>>>>> history
> > >>>>>>>>>>>>> on
> > >>>>>>>>>>>>>> develop should be linear (no merge commits), and that the
> > >>>> biggest
> > >>>>>>>>>>>>> obstacle
> > >>>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a
> > >> merge
> > >>>>>>> commit
> > >>>>>>>>> by
> > >>>>>>>>>>>>>> default.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I propose the following changes:
> > >>>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to create
> a
> > >>>> merge
> > >>>>>>>>> commit.
> > >>>>>>>>>>>>>> This will make Squash & Merge the default.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 2) Change GitHub settings to require linear history on
> > >>> develop.
> > >>>>>>> This
> > >>>>>>>>>>>>>> prevents merge commits via command-line (not recommended,
> > >> but
> > >>>> wiki
> > >>>>>>>>> still
> > >>>>>>>>>>>>>> has instructions for merging PRs this way).
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 3) Update the PR template to change the text "Is your
> > >> initial
> > >>>>>>>>>>>>> contribution
> > >>>>>>>>>>>>>> a single, squashed commit” to “Is your initial
> contribution
> > >>>>>>> squashed
> > >>>>>>>>> for
> > >>>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> > >>> commit
> > >>>>>>> plus
> > >>>>>>>>> a
> > >>>>>>>>>>>>>> ‘fix’ commit)"
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> For clarity, I am proposing no-change in the following
> > >> areas:
> > >>>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have
> been
> > >>>>>>>>> structured to
> > >>>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to
> see
> > >>>> whether
> > >>>>>>>>> the
> > >>>>>>>>>>>>>> refactoring or the “fix” broke something).
> > >>>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
> > >>>>>>> squashing
> > >>>>>>>>> is
> > >>>>>>>>>>>>>> preferred].
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Please comment via this email thread.
> > >>>>>>>>>>>>>> -Owen
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> klund@apache.org>
> > >>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I think it's already resolved Udo ;)
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing
> all
> > >>>> uses
> > >>>>>>> of
> > >>>>>>>>>>>>>> "this."
> > >>>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember
> that
> > >>> the
> > >>>>>>> file
> > >>>>>>>>>>>>> is a
> > >>>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new
> file
> > >>>> that I
> > >>>>>>>>>>>>>> created
> > >>>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this." can
> > >>> easily
> > >>>>>>>>> do). If
> > >>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that
> > >> dunit
> > >>>> test
> > >>>>>>> --
> > >>>>>>>>>>>>> then
> > >>>>>>>>>>>>>>> we effectively lose the history of that file and it shows
> > >>> that
> > >>>> I
> > >>>>>>>>>>>>> created
> > >>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>> new file.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Also for the record, I've been working on Geode since the
> > >>>>>>> beginning
> > >>>>>>>>>>>>> and I
> > >>>>>>>>>>>>>>> was never made aware of this change in our process. I
> never
> > >>>> voted
> > >>>>>>> on
> > >>>>>>>>>>>>> it.
> > >>>>>>>>>>>>>>> I'm not a big fan of changing various details in our
> > >> process
> > >>>> every
> > >>>>>>>>>>>>> single
> > >>>>>>>>>>>>>>> week. It's very easy to miss these discussions unless
> > >> someone
> > >>>>>>>>> points it
> > >>>>>>>>>>>>>> out
> > >>>>>>>>>>>>>>> to me.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > >>>>>>>>> ukohlmeyer@pivotal.io>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
> > >>>> community,
> > >>>>>>>>> have
> > >>>>>>>>>>>>>>>> agreed in common practices, in two place no less...
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 1) Quoting our PR template
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> For all changes:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> > >>>> referenced
> > >>>>>>>>> in
> > >>>>>>>>>>>>>>>> the commit message?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Has your PR been rebased against the latest commit
> within
> > >>> the
> > >>>>>>>>>>>>> target
> > >>>>>>>>>>>>>>>> branch (typically|develop|)?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed
> > >> commit?*
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
> > >>>> changes?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> If adding new dependencies to the code, are these
> > >>>> dependencies
> > >>>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion
> > >> underASF
> > >>>> 2.0
> > >>>>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On our PR template we call out that the initial PR
> commit
> > >>>> should
> > >>>>>>> be
> > >>>>>>>>>>>>>>>> squashed.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 2)
> > >>>>>>>
> > >> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>>>>>>>>>>>>>> <
> > >>>>>>>>>
> > >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point
> #3.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend
> > >> you
> > >>>> on
> > >>>>>>> the
> > >>>>>>>>>>>>>>>> diligence, but in reality, they should either then be
> > >> stand
> > >>>> alone
> > >>>>>>>>> PR's
> > >>>>>>>>>>>>>>>> or just extra work created for yourself.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
> > >>>>>>>>>>>>> submit/commit/merge
> > >>>>>>>>>>>>>>>> changes back into develop... Then this is another
> > >> discussion
> > >>>>>>>>> thread,
> > >>>>>>>>>>>>>>>> until then, I think we should all remind ourselves on
> our
> > >>>> agreed
> > >>>>>>>>>>>>>>>> contributions code of conduct.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> --Udo
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > >>>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
> > >> multiple
> > >>>>>>>>> commits is
> > >>>>>>>>>>>>>> ok.
> > >>>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to
> > >> develop
> > >>>>>>>>> branch,
> > >>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you
> > >> have
> > >>>>>>>>> mentioned
> > >>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
> > >>>>>>>>>>>>>>>>> If you can see in the first screenshot comparison that
> I
> > >>> had
> > >>>>>>>>> attached
> > >>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>> the first email in this thread is what I want to avoid.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Thank you for your feedback.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>>>> Naba
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> > >>> klund@apache.org>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
> > >> intend
> > >>>> to
> > >>>>>>>>> rebase
> > >>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit
> stands
> > >>>> alone
> > >>>>>>> as
> > >>>>>>>>> is
> > >>>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames
> and
> > >>>>>>>>> refactoring
> > >>>>>>>>>>>>>>>> from
> > >>>>>>>>>>>>>>>>>> behavior changes into different commits seems very
> > >>> valuable
> > >>>> to
> > >>>>>>>>> me,
> > >>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>> I've
> > >>>>>>>>>>>>>>>>>> had trouble getting people to review PRs without this
> > >>>>>>> separation
> > >>>>>>>>>>>>> (but
> > >>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs
> > >> have
> > >>>>>>>>> multiple
> > >>>>>>>>>>>>>>>> commits
> > >>>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some
> PRs
> > >>>> that
> > >>>>>>>>> should
> > >>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>> merged with squash are not (by accident most likely).
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
> > >> multiple
> > >>>>>>>>> commits.
> > >>>>>>>>>>>>> So
> > >>>>>>>>>>>>>>>> I'll
> > >>>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent commits
> > >> to
> > >>>>>>> develop
> > >>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase
> > >> or
> > >>>> merge
> > >>>>>>>>>>>>>> commits
> > >>>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce
> this
> > >>> or
> > >>>>>>>>> prevent
> > >>>>>>>>>>>>>> (b)
> > >>>>>>>>>>>>>>>>>> above.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > >>>>>>>>>>>>>> amurmann@pivotal.io>
> > >>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
> > >> necessarily
> > >>> at
> > >>>>>>>>> odds.
> > >>>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard),
> then
> > >>> make
> > >>>>>>> the
> > >>>>>>>>>>>>> easy
> > >>>>>>>>>>>>>>>>>>>> change."
> > >>>>>>>>>>>>>>>>>>> -Kent Beck
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split
> > >> into
> > >>>> two
> > >>>>>>>>>>>>> commits.
> > >>>>>>>>>>>>>>>> One
> > >>>>>>>>>>>>>>>>>>> refactor commit and a separate commit that introduces
> > >> the
> > >>>>>>> actual
> > >>>>>>>>>>>>>>>> change.
> > >>>>>>>>>>>>>>>>>>> They should be individually revertible and might be
> > >>> easier
> > >>>>>>>>>>>>> understood
> > >>>>>>>>>>>>>>>> if
> > >>>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code
> base
> > >>>> where
> > >>>>>>>>>>>>> someone
> > >>>>>>>>>>>>>>>>>> did a
> > >>>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one
> > >>>> parameter
> > >>>>>>>>>>>>>> changing
> > >>>>>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>>> order to get the desired functionality change. If
> that
> > >>> was
> > >>>> in
> > >>>>>>>>> one
> > >>>>>>>>>>>>>>>> commit,
> > >>>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split
> > >> out,
> > >>>> it's
> > >>>>>>>>>>>>>> beautiful
> > >>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>> crystal clear.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of
> > >> JIRA
> > >>>>>>> ticket
> > >>>>>>>>>>>>>>>>>> references.
> > >>>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with the
> > >>> ticket
> > >>>>>>>>> number,
> > >>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a
> > >>>> separate
> > >>>>>>>>>>>>>>>> refactoring
> > >>>>>>>>>>>>>>>>>>> ticket.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> > >>>> nnag@pivotal.io>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things
> start
> > >>>>>>> failing
> > >>>>>>>>> ...
> > >>>>>>>>>>>>>>>>>> helps
> > >>>>>>>>>>>>>>>>>>> us
> > >>>>>>>>>>>>>>>>>>>> it revert and build faster.
> > >>>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to
> previous
> > >>>>>>> versions
> > >>>>>>>>> .
> > >>>>>>>>>>>>>>>>>>>> And keeping the git history clean with no
> unnecessary
> > >>>> “merge
> > >>>>>>>>>>>>>> commits”.
> > >>>>>>>>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>>>>>>> Naba
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> > >>>> klund@apache.org>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1
> commit
> > >>> in
> > >>>> a
> > >>>>>>> PR
> > >>>>>>>>> and
> > >>>>>>>>>>>>>>>>>> keep
> > >>>>>>>>>>>>>>>>>>>> them
> > >>>>>>>>>>>>>>>>>>>>> separate when they merge to develop
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> > >>>>>>> nnag@pivotal.io>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of
> > >>> using
> > >>>>>>>>> merge.
> > >>>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect operations
> > >>> when a
> > >>>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced.
> > >> We
> > >>>> can
> > >>>>>>>>>>>>> automate
> > >>>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>> go
> > >>>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits
> like
> > >>>>>>> "spotless
> > >>>>>>>>>>>>> fix"
> > >>>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in
> > >> the
> > >>>>>>> merged
> > >>>>>>>>>>>>>>>>>> branch.
> > >>>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to
> > >> know
> > >>>> who
> > >>>>>>>>>>>>> worked
> > >>>>>>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>>>>>> it,
> > >>>>>>>>>>>>>>>>>>>>>> what is the history)
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> > >>>>>>>>>>>>>>>>>>>>>> * explanation line 1
> > >> *
> > >>>>>>>>>>>>> explanation
> > >>>>>>>>>>>>>>>>>>> line
> > >>>>>>>>>>>>>>>>>>>> 2*
> > >>>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to
> > >> help
> > >>>> out
> > >>>>>>>>> your
> > >>>>>>>>>>>>>>>>>> fellow
> > >>>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka /
> > >> Spark
> > >>>>>>> where
> > >>>>>>>>>>>>> they
> > >>>>>>>>>>>>>>>>>>> have
> > >>>>>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD
> > >> [see
> > >>>>>>>>>>>>> attachment]
> > >>>>>>>>>>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>>>>>>>>> Naba.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>> Ju@N
> > >>>>>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Cheers
> > >>
> > >> Jinmei
> > >>
> >
> >
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
We are not trying to force devs to squash prior to committing a PR. There was old language in the PR template that stated this, which we are relaxing to emphasize submitting your PR in a way that is most amenable to review. The geode-native repo does not appear to have a .github/PULL_REQUEST_TEMPLATE.md <https://github.com/apache/geode/pull/4513#diff-195a635ad245ded9076330e31134bd80>, but you may wish to consider adopting Geode’s and/or proposing changes that could be applied to both repos.
Squash and merge remains the most common and most acceptable way to merge PRs, but the Geode community felt strongly that some developers might have a good reason to group multiple commits in one PR. It’s entirely possible each commit could have it’s own JIRA, preserving your 1:1 expectation after rebase&merge to develop. The geode-native repo does not appear to have a .a <https://github.com/apache/geode/pull/4513#diff-195a635ad245ded9076330e31134bd80>sf.yaml, but you may wish to consider adopting the one currently proposed for Geode and/or proposing changes that could be applied to both repos.
> On Dec 20, 2019, at 11:54 AM, Blake Bender <bb...@pivotal.io> wrote:
>
> Very well, then, I'll abide by the group consensus but am on the record as:
> * strongly opposed to multi-commit PRs, because I believe it clutters
> history, and
> * also not a big fan of forcing devs to rebase and squash prior to
> submitting a PR. IMO this is busy work, and *may* in some small minority
> of cases hide information that would be useful to reviewers.
>
> Thanks,
>
> Blake
>
>
> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io> wrote:
>
>> Whether we are talking about the geode/ repository or the geode-native/
>> repository we are all one GEODE community.
>>
>> The idea of a native client team may matter in some contexts but in this
>> space we are all GEODE contributors.
>>
>> Adopting a common approach across our repos will make it easier for new
>> contributors to engage, learn our norms, and join our efforts.
>>
>> $0.02,
>> Anthony
>>
>>
>>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io> wrote:
>>>
>>> Is this a policy the native client team must abide by, as well? It
>> varies
>>> slightly with what we've been doing, and all other things being equal I
>> see
>>> no reason for us to change that. If I am to have any measure of control
>>> over the nc repository, I will definitely enforce a 1:1 correspondence
>>> between commits to develop and JIRA tickets. IMO, if your refactoring
>> in a
>>> PR is sufficiently large or complex that it's difficult to tease it out
>>> from the bug you're fixing or feature you're implementing, it merits its
>>> own JIRA ticket and a separate PR. If your "actual" fix then becomes
>>> dependent on the refactored code, that's a price I'm willing to pay to
>> keep
>>> history clean.
>>>
>>> On the other hand, I see no real value in squashing to a single commit
>>> prior to submitting a PR, since your view of the changes on GitHub is
>>> essentially the same either way. We haven't enforced this on the nc
>> repo,
>>> and I'd prefer to keep it that way.
>>>
>>> Thanks,
>>>
>>> Blake
>>>
>>>
>>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io> wrote:
>>>
>>>> Merge commit is the new contributor's default setting. When we are
>> merging
>>>> new contributor's PR, since we are so used to THINKING
>> "squash-and-merge"
>>>> is the default, we forgot to check what the button really says when we
>> are
>>>> merging other people's PR.
>>>>
>>>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
>> eburghardt@pivotal.io>
>>>> wrote:
>>>>
>>>>> I'm a proponent of using squash-and-merge, and once a person has chosen
>>>>> this option once it comes up by default afterwards...
>>>>>
>>>>> Owen, I don't think you have consensus to put forth this PR, there are
>>>> -1s
>>>>> above... (early voting)
>>>>>
>>>>> maybe we'll be better off socializing the norm of squash-and-merge and
>>>>> gaining a natural consensus that way...
>>>>>
>>>>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <on...@pivotal.io>
>>>> wrote:
>>>>>
>>>>>> The proposed action manifests as a commit to the Geode git repository,
>>>> so
>>>>>> a PR is an acceptable vehicle for voting in this case.
>>>>>>
>>>>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
>>>> bschuchardt@pivotal.io>
>>>>>> wrote:
>>>>>>>
>>>>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
>>>> thread
>>>>>> and a request to "vote" using a PR. This all seems out of order to
>> me.
>>>>>> Our votes are supposed to be on the email list, aren't they? and I
>>>>> haven't
>>>>>> seen a VOTE request.
>>>>>>>
>>>>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
>>>>>>>> +1
>>>>>>>>
>>>>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Based on the feedback so far, I will amend the proposal to drop
>>>> item
>>>>>> 2).
>>>>>>>>> Therefore, the current ability to create merge commits using
>>>>>> command-line
>>>>>>>>> git will remain available.
>>>>>>>>>
>>>>>>>>> The proposal as amended is now:
>>>>>>>>>> Change GitHub settings to make "Squash and merge" the default
>>>>>>>>>> (by removing “Create a merge commit” option).
>>>>>>>>>>
>>>>>>>>>> Update the PR template to change the text "Is your initial
>>>>>> contribution
>>>>>>>>>> a single, squashed commit” to “Is your initial contribution
>>>> squashed
>>>>>> for
>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
>>>>> plus a
>>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>
>>>>>>>>> As Naba suggested, we can try it, and if we don’t like it, it’s
>>>>> simple
>>>>>> to
>>>>>>>>> revert.
>>>>>>>>>
>>>>>>>>> I’ve create a PR for the proposed change here:
>>>>>>>>> https://github.com/apache/geode/pull/4513
>>>>>>>>>
>>>>>>>>> Please use the PR to vote for against this proposal. It will not
>>>> be
>>>>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
>>>> time)
>>>>>>>>>
>>>>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Bruce, this proposal will not waste a single second of your
>>>>>> time. It
>>>>>>>>>>> just prevents people from accidentally pressing a button that we
>>>>> have
>>>>>>>>>>> already agreed should never be pressed, but because we never
>>>>>> configured
>>>>>>>>> our
>>>>>>>>>>> GitHub to match our stated policy, is currently the default.
>>>>>>>>>>>
>>>>>>>>>>> However, it will save a lot of time and frustration for anyone
>>>>>> needing
>>>>>>>>> to
>>>>>>>>>>> bisect failures, revert, or cherry-pick changes, which has merit
>>>>>> even if
>>>>>>>>>>> you personally never do any of those three things.
>>>>>>>>>>>
>>>>>>>>>>> Please start a separate thread if you would like to revisit the
>>>>>>>>> community
>>>>>>>>>>> decision to require passing PR checks.
>>>>>>>>>>>
>>>>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
>>>>>> bschuchardt@pivotal.io>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> I agree with Jake. I would go further by saying that I see very
>>>>>> little
>>>>>>>>>>> merit in this proposal. I think we're getting more and more
>>>>>>>>> bureaucratic
>>>>>>>>>>> in our process and that it stifles productivity. I was recently
>>>>>> forced
>>>>>>>>> to
>>>>>>>>>>> spend three days fixing tests in which I had changed an import
>>>>>> statement
>>>>>>>>>>> before they would pass stress testing. I'm glad the tests now
>>>> pass
>>>>>>>>>>> reliably but I was very frustrated by the process.
>>>>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>>>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to
>>>> flat
>>>>>> out
>>>>>>>>>>> prevent things that should be self policing is annoying. This PR
>>>>>> review
>>>>>>>>>>> lock we have had already cost us valuable time waiting for PR
>>>>>> pipelines
>>>>>>>>> to
>>>>>>>>>>> pass that have no relevance to the commit, like CI work: I’d hat
>>>> to
>>>>>> see
>>>>>>>>> yet
>>>>>>>>>>> another process enforced that Kees us from getting work done when
>>>>>>>>> necessary.
>>>>>>>>>>>>> -Jake
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io>
>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -1 to (1) and (2).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think merge commits are appropriate in certain
>>>> circumstances,
>>>>>> so I
>>>>>>>>>>> don't
>>>>>>>>>>>>>> think we should make a blanket restriction. In fact I think
>>>> our
>>>>>>>>> release
>>>>>>>>>>>>>> process involves some merges.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think setting standards on what is reasonable to be an
>>>>>> individual
>>>>>>>>>>> commit
>>>>>>>>>>>>>> will do a lot more to clean up our history than blocking
>>>> merges.
>>>>>> We'd
>>>>>>>>>>>>>> rather not see commits like "Spotless Apply" in the history,
>>>> but
>>>>>> if
>>>>>>>>>>>>>> reasonably separate and well written commits come in as part
>>>> of
>>>>> a
>>>>>>>>>>> merge, I
>>>>>>>>>>>>>> think that's fine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Dan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
>>>> jiliao@pivotal.io
>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
>>>>> onichols@pivotal.io
>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> I’d like to advance this topic from an informal
>>>>>> request/discussion
>>>>>>>>>>> to a
>>>>>>>>>>>>>>>> discussion of a concrete proposal.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To recap, it sounds like there is general agreement that
>>>>> commit
>>>>>>>>>>> history
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> develop should be linear (no merge commits), and that the
>>>>>> biggest
>>>>>>>>>>>>>>> obstacle
>>>>>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a
>>>> merge
>>>>>>>>> commit
>>>>>>>>>>> by
>>>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I propose the following changes:
>>>>>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to create a
>>>>>> merge
>>>>>>>>>>> commit.
>>>>>>>>>>>>>>>> This will make Squash & Merge the default.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2) Change GitHub settings to require linear history on
>>>>> develop.
>>>>>>>>> This
>>>>>>>>>>>>>>>> prevents merge commits via command-line (not recommended,
>>>> but
>>>>>> wiki
>>>>>>>>>>> still
>>>>>>>>>>>>>>>> has instructions for merging PRs this way).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3) Update the PR template to change the text "Is your
>>>> initial
>>>>>>>>>>>>>>> contribution
>>>>>>>>>>>>>>>> a single, squashed commit” to “Is your initial contribution
>>>>>>>>> squashed
>>>>>>>>>>> for
>>>>>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
>>>>> commit
>>>>>>>>> plus
>>>>>>>>>>> a
>>>>>>>>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For clarity, I am proposing no-change in the following
>>>> areas:
>>>>>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
>>>>>>>>>>> structured to
>>>>>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to see
>>>>>> whether
>>>>>>>>>>> the
>>>>>>>>>>>>>>>> refactoring or the “fix” broke something).
>>>>>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
>>>>>>>>> squashing
>>>>>>>>>>> is
>>>>>>>>>>>>>>>> preferred].
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please comment via this email thread.
>>>>>>>>>>>>>>>> -Owen
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org>
>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think it's already resolved Udo ;)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all
>>>>>> uses
>>>>>>>>> of
>>>>>>>>>>>>>>>> "this."
>>>>>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember that
>>>>> the
>>>>>>>>> file
>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new file
>>>>>> that I
>>>>>>>>>>>>>>>> created
>>>>>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this." can
>>>>> easily
>>>>>>>>>>> do). If
>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that
>>>> dunit
>>>>>> test
>>>>>>>>> --
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>> we effectively lose the history of that file and it shows
>>>>> that
>>>>>> I
>>>>>>>>>>>>>>> created
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> new file.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Also for the record, I've been working on Geode since the
>>>>>>>>> beginning
>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>>>> was never made aware of this change in our process. I never
>>>>>> voted
>>>>>>>>> on
>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>> I'm not a big fan of changing various details in our
>>>> process
>>>>>> every
>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>>>> week. It's very easy to miss these discussions unless
>>>> someone
>>>>>>>>>>> points it
>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>>> to me.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>>>>>>>>>>> ukohlmeyer@pivotal.io>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
>>>>>> community,
>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> agreed in common practices, in two place no less...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1) Quoting our PR template
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For all changes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
>>>>>> referenced
>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> the commit message?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Has your PR been rebased against the latest commit within
>>>>> the
>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>> branch (typically|develop|)?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed
>>>> commit?*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
>>>>>> changes?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If adding new dependencies to the code, are these
>>>>>> dependencies
>>>>>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion
>>>> underASF
>>>>>> 2.0
>>>>>>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On our PR template we call out that the initial PR commit
>>>>>> should
>>>>>>>>> be
>>>>>>>>>>>>>>>>>> squashed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2)
>>>>>>>>>
>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>
>>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend
>>>> you
>>>>>> on
>>>>>>>>> the
>>>>>>>>>>>>>>>>>> diligence, but in reality, they should either then be
>>>> stand
>>>>>> alone
>>>>>>>>>>> PR's
>>>>>>>>>>>>>>>>>> or just extra work created for yourself.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
>>>>>>>>>>>>>>> submit/commit/merge
>>>>>>>>>>>>>>>>>> changes back into develop... Then this is another
>>>> discussion
>>>>>>>>>>> thread,
>>>>>>>>>>>>>>>>>> until then, I think we should all remind ourselves on our
>>>>>> agreed
>>>>>>>>>>>>>>>>>> contributions code of conduct.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --Udo
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
>>>> multiple
>>>>>>>>>>> commits is
>>>>>>>>>>>>>>>> ok.
>>>>>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to
>>>> develop
>>>>>>>>>>> branch,
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you
>>>> have
>>>>>>>>>>> mentioned
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>>>>>>>>>>>>> If you can see in the first screenshot comparison that I
>>>>> had
>>>>>>>>>>> attached
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thank you for your feedback.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
>>>>> klund@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
>>>> intend
>>>>>> to
>>>>>>>>>>> rebase
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit stands
>>>>>> alone
>>>>>>>>> as
>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
>>>>>>>>>>> refactoring
>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>> behavior changes into different commits seems very
>>>>> valuable
>>>>>> to
>>>>>>>>>>> me,
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>> had trouble getting people to review PRs without this
>>>>>>>>> separation
>>>>>>>>>>>>>>> (but
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs
>>>> have
>>>>>>>>>>> multiple
>>>>>>>>>>>>>>>>>> commits
>>>>>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs
>>>>>> that
>>>>>>>>>>> should
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
>>>> multiple
>>>>>>>>>>> commits.
>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent commits
>>>> to
>>>>>>>>> develop
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase
>>>> or
>>>>>> merge
>>>>>>>>>>>>>>>> commits
>>>>>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this
>>>>> or
>>>>>>>>>>> prevent
>>>>>>>>>>>>>>>> (b)
>>>>>>>>>>>>>>>>>>>> above.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>>>>>>>>>>>>> amurmann@pivotal.io>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
>>>> necessarily
>>>>> at
>>>>>>>>>>> odds.
>>>>>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then
>>>>> make
>>>>>>>>> the
>>>>>>>>>>>>>>> easy
>>>>>>>>>>>>>>>>>>>>>> change."
>>>>>>>>>>>>>>>>>>>>> -Kent Beck
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split
>>>> into
>>>>>> two
>>>>>>>>>>>>>>> commits.
>>>>>>>>>>>>>>>>>> One
>>>>>>>>>>>>>>>>>>>>> refactor commit and a separate commit that introduces
>>>> the
>>>>>>>>> actual
>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>> They should be individually revertible and might be
>>>>> easier
>>>>>>>>>>>>>>> understood
>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code base
>>>>>> where
>>>>>>>>>>>>>>> someone
>>>>>>>>>>>>>>>>>>>> did a
>>>>>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one
>>>>>> parameter
>>>>>>>>>>>>>>>> changing
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> order to get the desired functionality change. If that
>>>>> was
>>>>>> in
>>>>>>>>>>> one
>>>>>>>>>>>>>>>>>> commit,
>>>>>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split
>>>> out,
>>>>>> it's
>>>>>>>>>>>>>>>> beautiful
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> crystal clear.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of
>>>> JIRA
>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>>> references.
>>>>>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with the
>>>>> ticket
>>>>>>>>>>> number,
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a
>>>>>> separate
>>>>>>>>>>>>>>>>>> refactoring
>>>>>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
>>>>>> nnag@pivotal.io>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things start
>>>>>>>>> failing
>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>> helps
>>>>>>>>>>>>>>>>>>>>> us
>>>>>>>>>>>>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
>>>>>>>>> versions
>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary
>>>>>> “merge
>>>>>>>>>>>>>>>> commits”.
>>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
>>>>>> klund@apache.org>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit
>>>>> in
>>>>>> a
>>>>>>>>> PR
>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> keep
>>>>>>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>>>>>>>>> nnag@pivotal.io>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of
>>>>> using
>>>>>>>>>>> merge.
>>>>>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect operations
>>>>> when a
>>>>>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced.
>>>> We
>>>>>> can
>>>>>>>>>>>>>>> automate
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
>>>>>>>>> "spotless
>>>>>>>>>>>>>>> fix"
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in
>>>> the
>>>>>>>>> merged
>>>>>>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to
>>>> know
>>>>>> who
>>>>>>>>>>>>>>> worked
>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>> it,
>>>>>>>>>>>>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>>>>>>>>>>>>> * explanation line 1
>>>> *
>>>>>>>>>>>>>>> explanation
>>>>>>>>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>>>>>>>>> 2*
>>>>>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to
>>>> help
>>>>>> out
>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>>> fellow
>>>>>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka /
>>>> Spark
>>>>>>>>> where
>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD
>>>> [see
>>>>>>>>>>>>>>> attachment]
>>>>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>> Ju@N
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers
>>>>
>>>> Jinmei
>>>>
>>
>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Blake Bender <bb...@pivotal.io>.
Very well, then, I'll abide by the group consensus but am on the record as:
* strongly opposed to multi-commit PRs, because I believe it clutters
history, and
* also not a big fan of forcing devs to rebase and squash prior to
submitting a PR. IMO this is busy work, and *may* in some small minority
of cases hide information that would be useful to reviewers.
Thanks,
Blake
On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io> wrote:
> Whether we are talking about the geode/ repository or the geode-native/
> repository we are all one GEODE community.
>
> The idea of a native client team may matter in some contexts but in this
> space we are all GEODE contributors.
>
> Adopting a common approach across our repos will make it easier for new
> contributors to engage, learn our norms, and join our efforts.
>
> $0.02,
> Anthony
>
>
> > On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io> wrote:
> >
> > Is this a policy the native client team must abide by, as well? It
> varies
> > slightly with what we've been doing, and all other things being equal I
> see
> > no reason for us to change that. If I am to have any measure of control
> > over the nc repository, I will definitely enforce a 1:1 correspondence
> > between commits to develop and JIRA tickets. IMO, if your refactoring
> in a
> > PR is sufficiently large or complex that it's difficult to tease it out
> > from the bug you're fixing or feature you're implementing, it merits its
> > own JIRA ticket and a separate PR. If your "actual" fix then becomes
> > dependent on the refactored code, that's a price I'm willing to pay to
> keep
> > history clean.
> >
> > On the other hand, I see no real value in squashing to a single commit
> > prior to submitting a PR, since your view of the changes on GitHub is
> > essentially the same either way. We haven't enforced this on the nc
> repo,
> > and I'd prefer to keep it that way.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io> wrote:
> >
> >> Merge commit is the new contributor's default setting. When we are
> merging
> >> new contributor's PR, since we are so used to THINKING
> "squash-and-merge"
> >> is the default, we forgot to check what the button really says when we
> are
> >> merging other people's PR.
> >>
> >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> eburghardt@pivotal.io>
> >> wrote:
> >>
> >>> I'm a proponent of using squash-and-merge, and once a person has chosen
> >>> this option once it comes up by default afterwards...
> >>>
> >>> Owen, I don't think you have consensus to put forth this PR, there are
> >> -1s
> >>> above... (early voting)
> >>>
> >>> maybe we'll be better off socializing the norm of squash-and-merge and
> >>> gaining a natural consensus that way...
> >>>
> >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <on...@pivotal.io>
> >> wrote:
> >>>
> >>>> The proposed action manifests as a commit to the Geode git repository,
> >> so
> >>>> a PR is an acceptable vehicle for voting in this case.
> >>>>
> >>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> >> bschuchardt@pivotal.io>
> >>>> wrote:
> >>>>>
> >>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> >> thread
> >>>> and a request to "vote" using a PR. This all seems out of order to
> me.
> >>>> Our votes are supposed to be on the email list, aren't they? and I
> >>> haven't
> >>>> seen a VOTE request.
> >>>>>
> >>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> >>>>>> +1
> >>>>>>
> >>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io>
> >>>> wrote:
> >>>>>>
> >>>>>>> Based on the feedback so far, I will amend the proposal to drop
> >> item
> >>>> 2).
> >>>>>>> Therefore, the current ability to create merge commits using
> >>>> command-line
> >>>>>>> git will remain available.
> >>>>>>>
> >>>>>>> The proposal as amended is now:
> >>>>>>>> Change GitHub settings to make "Squash and merge" the default
> >>>>>>>> (by removing “Create a merge commit” option).
> >>>>>>>>
> >>>>>>>> Update the PR template to change the text "Is your initial
> >>>> contribution
> >>>>>>>> a single, squashed commit” to “Is your initial contribution
> >> squashed
> >>>> for
> >>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> >>> plus a
> >>>>>>>> ‘fix’ commit)"
> >>>>>>>
> >>>>>>> As Naba suggested, we can try it, and if we don’t like it, it’s
> >>> simple
> >>>> to
> >>>>>>> revert.
> >>>>>>>
> >>>>>>> I’ve create a PR for the proposed change here:
> >>>>>>> https://github.com/apache/geode/pull/4513
> >>>>>>>
> >>>>>>> Please use the PR to vote for against this proposal. It will not
> >> be
> >>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
> >> time)
> >>>>>>>
> >>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> +1
> >>>>>>>>
> >>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io>
> >>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Bruce, this proposal will not waste a single second of your
> >>>> time. It
> >>>>>>>>> just prevents people from accidentally pressing a button that we
> >>> have
> >>>>>>>>> already agreed should never be pressed, but because we never
> >>>> configured
> >>>>>>> our
> >>>>>>>>> GitHub to match our stated policy, is currently the default.
> >>>>>>>>>
> >>>>>>>>> However, it will save a lot of time and frustration for anyone
> >>>> needing
> >>>>>>> to
> >>>>>>>>> bisect failures, revert, or cherry-pick changes, which has merit
> >>>> even if
> >>>>>>>>> you personally never do any of those three things.
> >>>>>>>>>
> >>>>>>>>> Please start a separate thread if you would like to revisit the
> >>>>>>> community
> >>>>>>>>> decision to require passing PR checks.
> >>>>>>>>>
> >>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> >>>> bschuchardt@pivotal.io>
> >>>>>>>>> wrote:
> >>>>>>>>>> I agree with Jake. I would go further by saying that I see very
> >>>> little
> >>>>>>>>> merit in this proposal. I think we're getting more and more
> >>>>>>> bureaucratic
> >>>>>>>>> in our process and that it stifles productivity. I was recently
> >>>> forced
> >>>>>>> to
> >>>>>>>>> spend three days fixing tests in which I had changed an import
> >>>> statement
> >>>>>>>>> before they would pass stress testing. I'm glad the tests now
> >> pass
> >>>>>>>>> reliably but I was very frustrated by the process.
> >>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> >>>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to
> >> flat
> >>>> out
> >>>>>>>>> prevent things that should be self policing is annoying. This PR
> >>>> review
> >>>>>>>>> lock we have had already cost us valuable time waiting for PR
> >>>> pipelines
> >>>>>>> to
> >>>>>>>>> pass that have no relevance to the commit, like CI work: I’d hat
> >> to
> >>>> see
> >>>>>>> yet
> >>>>>>>>> another process enforced that Kees us from getting work done when
> >>>>>>> necessary.
> >>>>>>>>>>> -Jake
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io>
> >>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> -1 to (1) and (2).
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think merge commits are appropriate in certain
> >> circumstances,
> >>>> so I
> >>>>>>>>> don't
> >>>>>>>>>>>> think we should make a blanket restriction. In fact I think
> >> our
> >>>>>>> release
> >>>>>>>>>>>> process involves some merges.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think setting standards on what is reasonable to be an
> >>>> individual
> >>>>>>>>> commit
> >>>>>>>>>>>> will do a lot more to clean up our history than blocking
> >> merges.
> >>>> We'd
> >>>>>>>>>>>> rather not see commits like "Spotless Apply" in the history,
> >> but
> >>>> if
> >>>>>>>>>>>> reasonably separate and well written commits come in as part
> >> of
> >>> a
> >>>>>>>>> merge, I
> >>>>>>>>>>>> think that's fine.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -Dan
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> >> jiliao@pivotal.io
> >>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>> +1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> >>> onichols@pivotal.io
> >>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>> I’d like to advance this topic from an informal
> >>>> request/discussion
> >>>>>>>>> to a
> >>>>>>>>>>>>>> discussion of a concrete proposal.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> To recap, it sounds like there is general agreement that
> >>> commit
> >>>>>>>>> history
> >>>>>>>>>>>>> on
> >>>>>>>>>>>>>> develop should be linear (no merge commits), and that the
> >>>> biggest
> >>>>>>>>>>>>> obstacle
> >>>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a
> >> merge
> >>>>>>> commit
> >>>>>>>>> by
> >>>>>>>>>>>>>> default.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I propose the following changes:
> >>>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to create a
> >>>> merge
> >>>>>>>>> commit.
> >>>>>>>>>>>>>> This will make Squash & Merge the default.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2) Change GitHub settings to require linear history on
> >>> develop.
> >>>>>>> This
> >>>>>>>>>>>>>> prevents merge commits via command-line (not recommended,
> >> but
> >>>> wiki
> >>>>>>>>> still
> >>>>>>>>>>>>>> has instructions for merging PRs this way).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 3) Update the PR template to change the text "Is your
> >> initial
> >>>>>>>>>>>>> contribution
> >>>>>>>>>>>>>> a single, squashed commit” to “Is your initial contribution
> >>>>>>> squashed
> >>>>>>>>> for
> >>>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> >>> commit
> >>>>>>> plus
> >>>>>>>>> a
> >>>>>>>>>>>>>> ‘fix’ commit)"
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> For clarity, I am proposing no-change in the following
> >> areas:
> >>>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
> >>>>>>>>> structured to
> >>>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to see
> >>>> whether
> >>>>>>>>> the
> >>>>>>>>>>>>>> refactoring or the “fix” broke something).
> >>>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
> >>>>>>> squashing
> >>>>>>>>> is
> >>>>>>>>>>>>>> preferred].
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please comment via this email thread.
> >>>>>>>>>>>>>> -Owen
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org>
> >>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think it's already resolved Udo ;)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all
> >>>> uses
> >>>>>>> of
> >>>>>>>>>>>>>> "this."
> >>>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember that
> >>> the
> >>>>>>> file
> >>>>>>>>>>>>> is a
> >>>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new file
> >>>> that I
> >>>>>>>>>>>>>> created
> >>>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this." can
> >>> easily
> >>>>>>>>> do). If
> >>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that
> >> dunit
> >>>> test
> >>>>>>> --
> >>>>>>>>>>>>> then
> >>>>>>>>>>>>>>> we effectively lose the history of that file and it shows
> >>> that
> >>>> I
> >>>>>>>>>>>>> created
> >>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>> new file.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Also for the record, I've been working on Geode since the
> >>>>>>> beginning
> >>>>>>>>>>>>> and I
> >>>>>>>>>>>>>>> was never made aware of this change in our process. I never
> >>>> voted
> >>>>>>> on
> >>>>>>>>>>>>> it.
> >>>>>>>>>>>>>>> I'm not a big fan of changing various details in our
> >> process
> >>>> every
> >>>>>>>>>>>>> single
> >>>>>>>>>>>>>>> week. It's very easy to miss these discussions unless
> >> someone
> >>>>>>>>> points it
> >>>>>>>>>>>>>> out
> >>>>>>>>>>>>>>> to me.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> >>>>>>>>> ukohlmeyer@pivotal.io>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
> >>>> community,
> >>>>>>>>> have
> >>>>>>>>>>>>>>>> agreed in common practices, in two place no less...
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1) Quoting our PR template
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> For all changes:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> >>>> referenced
> >>>>>>>>> in
> >>>>>>>>>>>>>>>> the commit message?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Has your PR been rebased against the latest commit within
> >>> the
> >>>>>>>>>>>>> target
> >>>>>>>>>>>>>>>> branch (typically|develop|)?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed
> >> commit?*
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
> >>>> changes?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If adding new dependencies to the code, are these
> >>>> dependencies
> >>>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion
> >> underASF
> >>>> 2.0
> >>>>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On our PR template we call out that the initial PR commit
> >>>> should
> >>>>>>> be
> >>>>>>>>>>>>>>>> squashed.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2)
> >>>>>>>
> >> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>>>>>>>>> <
> >>>>>>>>>
> >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend
> >> you
> >>>> on
> >>>>>>> the
> >>>>>>>>>>>>>>>> diligence, but in reality, they should either then be
> >> stand
> >>>> alone
> >>>>>>>>> PR's
> >>>>>>>>>>>>>>>> or just extra work created for yourself.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
> >>>>>>>>>>>>> submit/commit/merge
> >>>>>>>>>>>>>>>> changes back into develop... Then this is another
> >> discussion
> >>>>>>>>> thread,
> >>>>>>>>>>>>>>>> until then, I think we should all remind ourselves on our
> >>>> agreed
> >>>>>>>>>>>>>>>> contributions code of conduct.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --Udo
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >>>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
> >> multiple
> >>>>>>>>> commits is
> >>>>>>>>>>>>>> ok.
> >>>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to
> >> develop
> >>>>>>>>> branch,
> >>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you
> >> have
> >>>>>>>>> mentioned
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
> >>>>>>>>>>>>>>>>> If you can see in the first screenshot comparison that I
> >>> had
> >>>>>>>>> attached
> >>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>> the first email in this thread is what I want to avoid.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thank you for your feedback.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>> Naba
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> >>> klund@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
> >> intend
> >>>> to
> >>>>>>>>> rebase
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit stands
> >>>> alone
> >>>>>>> as
> >>>>>>>>> is
> >>>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
> >>>>>>>>> refactoring
> >>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>>> behavior changes into different commits seems very
> >>> valuable
> >>>> to
> >>>>>>>>> me,
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> I've
> >>>>>>>>>>>>>>>>>> had trouble getting people to review PRs without this
> >>>>>>> separation
> >>>>>>>>>>>>> (but
> >>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs
> >> have
> >>>>>>>>> multiple
> >>>>>>>>>>>>>>>> commits
> >>>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs
> >>>> that
> >>>>>>>>> should
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>> merged with squash are not (by accident most likely).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
> >> multiple
> >>>>>>>>> commits.
> >>>>>>>>>>>>> So
> >>>>>>>>>>>>>>>> I'll
> >>>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent commits
> >> to
> >>>>>>> develop
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase
> >> or
> >>>> merge
> >>>>>>>>>>>>>> commits
> >>>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this
> >>> or
> >>>>>>>>> prevent
> >>>>>>>>>>>>>> (b)
> >>>>>>>>>>>>>>>>>> above.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >>>>>>>>>>>>>> amurmann@pivotal.io>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
> >> necessarily
> >>> at
> >>>>>>>>> odds.
> >>>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then
> >>> make
> >>>>>>> the
> >>>>>>>>>>>>> easy
> >>>>>>>>>>>>>>>>>>>> change."
> >>>>>>>>>>>>>>>>>>> -Kent Beck
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split
> >> into
> >>>> two
> >>>>>>>>>>>>> commits.
> >>>>>>>>>>>>>>>> One
> >>>>>>>>>>>>>>>>>>> refactor commit and a separate commit that introduces
> >> the
> >>>>>>> actual
> >>>>>>>>>>>>>>>> change.
> >>>>>>>>>>>>>>>>>>> They should be individually revertible and might be
> >>> easier
> >>>>>>>>>>>>> understood
> >>>>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code base
> >>>> where
> >>>>>>>>>>>>> someone
> >>>>>>>>>>>>>>>>>> did a
> >>>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one
> >>>> parameter
> >>>>>>>>>>>>>> changing
> >>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>> order to get the desired functionality change. If that
> >>> was
> >>>> in
> >>>>>>>>> one
> >>>>>>>>>>>>>>>> commit,
> >>>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split
> >> out,
> >>>> it's
> >>>>>>>>>>>>>> beautiful
> >>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> crystal clear.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of
> >> JIRA
> >>>>>>> ticket
> >>>>>>>>>>>>>>>>>> references.
> >>>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with the
> >>> ticket
> >>>>>>>>> number,
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a
> >>>> separate
> >>>>>>>>>>>>>>>> refactoring
> >>>>>>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> >>>> nnag@pivotal.io>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things start
> >>>>>>> failing
> >>>>>>>>> ...
> >>>>>>>>>>>>>>>>>> helps
> >>>>>>>>>>>>>>>>>>> us
> >>>>>>>>>>>>>>>>>>>> it revert and build faster.
> >>>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
> >>>>>>> versions
> >>>>>>>>> .
> >>>>>>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary
> >>>> “merge
> >>>>>>>>>>>>>> commits”.
> >>>>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>>>> Naba
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> >>>> klund@apache.org>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit
> >>> in
> >>>> a
> >>>>>>> PR
> >>>>>>>>> and
> >>>>>>>>>>>>>>>>>> keep
> >>>>>>>>>>>>>>>>>>>> them
> >>>>>>>>>>>>>>>>>>>>> separate when they merge to develop
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> >>>>>>> nnag@pivotal.io>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of
> >>> using
> >>>>>>>>> merge.
> >>>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect operations
> >>> when a
> >>>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced.
> >> We
> >>>> can
> >>>>>>>>>>>>> automate
> >>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> go
> >>>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
> >>>>>>> "spotless
> >>>>>>>>>>>>> fix"
> >>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in
> >> the
> >>>>>>> merged
> >>>>>>>>>>>>>>>>>> branch.
> >>>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to
> >> know
> >>>> who
> >>>>>>>>>>>>> worked
> >>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>> it,
> >>>>>>>>>>>>>>>>>>>>>> what is the history)
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> >>>>>>>>>>>>>>>>>>>>>> * explanation line 1
> >> *
> >>>>>>>>>>>>> explanation
> >>>>>>>>>>>>>>>>>>> line
> >>>>>>>>>>>>>>>>>>>> 2*
> >>>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to
> >> help
> >>>> out
> >>>>>>>>> your
> >>>>>>>>>>>>>>>>>> fellow
> >>>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka /
> >> Spark
> >>>>>>> where
> >>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD
> >> [see
> >>>>>>>>>>>>> attachment]
> >>>>>>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>>>>>> Naba.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>> Ju@N
> >>>>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Jacob Barrett <jb...@pivotal.io>.
-1 on removing rebase option. I use it frequently to void squashing properly independent commits, like a cleanup or refactor and then a fix commit.
-Jake
> On Dec 31, 2019, at 3:10 PM, Owen Nichols <on...@pivotal.io> wrote:
>
> To recap, this proposal is now revised to remove 2 of the 3 merge options
> from GitHub, leaving only Squash and Merge. PR #4513
> <https://github.com/apache/geode/pull/4513> serves as an exhibit of what is
> proposed (it is not to be merged unless discussion leads to consensus and a
> successful vote). Please use the dev list (not the PR) for all discussion
> (and voting, if we get that far).
>
> Squash and merge is already used almost exclusively by the Geode community,
> with any exceptions tending to be accidental more often than intentional.
> However, some have raised the concern that implementing this restriction
> could result in harm or wasted time. Can someone give an example of a such
> a scenario?
>
> It seems there is a divide here between junior and senior community
> members. Newer committers appreciate additional guardrails to protect them
> from accidentally doing the wrong thing, while those with more experience
> want to be able to work unencumbered by restrictions of any kind.
>
> Our welcome email to new committers states “We like to work on trust rather
> than unnecessary constraints...Being a committer enables you to more easily
> make changes without needing to go through the patch submission process”.
> I can see this as an argument against this proposal (perhaps even an
> argument against any form of branch protection).
>
> In the scheme of things, this proposal makes very little difference. There
> are still other ways to get non-compiling commits onto develop (e.g.
> waiting a long time between running PR checks and merging to develop).
> What’s more important is working well together as a community. So, perhaps
> what’s best for the community is to encourage working on trust rather than
> unnecessary constraints.
>
> -Owen
>
> On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org> wrote:
>
> I'm happy to file multiple PRs when I need to merge multiple commits to
> develop.
>
> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <mh...@pivotal.io> wrote:
>
> This change to disable all but squash-merge would be really easy to
> revert. How about we try it for a while and see? If people decide it is
> really limiting them, we can change it back. Let’s do it for 1 month and
> see how it goes. Does that sound reasonable?
>
> Thanks,
> Mark
>
> On Dec 30, 2019, at 5:25 PM, Owen Nichols <on...@pivotal.io> wrote:
>
> Given that we adopted <
>
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
>>
> and still wish to continue <
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
>>
> having branch protection rules to ensure every commit landing in develop
> has passed the required PR checks, it seems like that decision alone
> mandates that we disable all merge mechanisms other than squash-and-merge.
>
>
> Allowing merge commits or rebase merges bypasses branch protection for
>
> all commits other than the final one in the merge or rebase set. Given
> that we decided <
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
>>
> that bypassing PR checks should never be allowed, keeping this loophole
> open seems untenable.
>
>
> This is not just hypothetical — this loophole is causing real problems.
>
> We now have commits on develop that don’t compile. For example:
>
> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> ./gradlew devBuild
> ...spotlessJava FAILED
> We implemented branch protections to make this impossible, right?
>
> We can very easily close this loophole by disabling all but the
>
> Squash&Merge button for PRs. This will not make more work for any
> developer. If you want to get multiple commits onto develop, simply submit
> each as a separate PR — that is the only way to assure that required PR
> checks have passed for each.
>
>
> On the other hand, if we as a Geode community feel strongly that
>
> bypassing branch protection via merge commits and rebase commits is
> important to allow, why not also allow arbitrary overrides (or get rid of
> branch protection entirely)?
>
>
> -Owen
>
> On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io> wrote:
>
> Just FWIW, the situation described of having multiple commits in a
>
> single
>
> PR with separate associated JIRA tickets is still kind of problematic.
>
> It
>
> could well be the case that the commits are interdependent, thus when
> bisecting etc it's still not possible to revert the fix for a single
> bug/feature/whatever atomically. It's all good, though, I'm satisfied
>
> no
>
> one's forcing me to adopt practice I'm opposed to. Apologies for
>
> getting
>
> my feathers a little ruffled, or if I ruffled anyone else's in return.
>
> Thanks,
>
> Blake
>
>
> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Dan,
>
> When we do squash merge all the commit messages are preserved and also
>
> the
>
> co-authored tag works when we do squash merge.
> So the authorship and history are preserved.
>
> In my own personal experience and reverts and pinpointing regression
> failures are tough when the commits are spread out. Also, reverts are
> easier when it is just one commit while we are bisecting failures.
>
>
> Regards
> Naba
>
> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io> wrote:
>
> I'll change to -0.
>
> I think merge commits are a nice way to record history in some cases,
>
> and
>
> can also be a way to avoid messy conflicts that come with rebase.
>
> Merge
>
> commits also preserve authorship of commits (compared to
>
> squash-merge),
>
> which I think is valuable as an open source community that is trying
>
> to
>
> keep track of outside contributions.
>
> That said, if the rest of y'all feel it will help to disable the
>
> button,
>
> I
>
> won't stand in the way.
>
> -Dan
>
> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
>
> wrote:
>
>
> Whether we are talking about the geode/ repository or the
>
> geode-native/
>
> repository we are all one GEODE community.
>
> The idea of a native client team may matter in some contexts but in
>
> this
>
> space we are all GEODE contributors.
>
> Adopting a common approach across our repos will make it easier for
>
> new
>
> contributors to engage, learn our norms, and join our efforts.
>
> $0.02,
> Anthony
>
>
> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
>
> wrote:
>
>
> Is this a policy the native client team must abide by, as well? It
>
> varies
>
> slightly with what we've been doing, and all other things being
>
> equal I
>
> see
>
> no reason for us to change that. If I am to have any measure of
>
> control
>
> over the nc repository, I will definitely enforce a 1:1
>
> correspondence
>
> between commits to develop and JIRA tickets. IMO, if your
>
> refactoring
>
> in a
>
> PR is sufficiently large or complex that it's difficult to tease it
>
> out
>
> from the bug you're fixing or feature you're implementing, it merits
>
> its
>
> own JIRA ticket and a separate PR. If your "actual" fix then
>
> becomes
>
> dependent on the refactored code, that's a price I'm willing to pay
>
> to
>
> keep
>
> history clean.
>
> On the other hand, I see no real value in squashing to a single
>
> commit
>
> prior to submitting a PR, since your view of the changes on GitHub
>
> is
>
> essentially the same either way. We haven't enforced this on the nc
>
> repo,
>
> and I'd prefer to keep it that way.
>
> Thanks,
>
> Blake
>
>
> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
>
> wrote:
>
>
> Merge commit is the new contributor's default setting. When we are
>
> merging
>
> new contributor's PR, since we are so used to THINKING
>
> "squash-and-merge"
>
> is the default, we forgot to check what the button really says when
>
> we
>
> are
>
> merging other people's PR.
>
> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
>
> eburghardt@pivotal.io>
>
> wrote:
>
> I'm a proponent of using squash-and-merge, and once a person has
>
> chosen
>
> this option once it comes up by default afterwards...
>
> Owen, I don't think you have consensus to put forth this PR,
>
> there
>
> are
>
> -1s
>
> above... (early voting)
>
> maybe we'll be better off socializing the norm of squash-and-merge
>
> and
>
> gaining a natural consensus that way...
>
> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
>
> onichols@pivotal.io
>
>
> wrote:
>
>
> The proposed action manifests as a commit to the Geode git
>
> repository,
>
> so
>
> a PR is an acceptable vehicle for voting in this case.
>
> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
>
> bschuchardt@pivotal.io>
>
> wrote:
>
>
> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
>
> thread
>
> and a request to "vote" using a PR. This all seems out of order
>
> to
>
> me.
>
> Our votes are supposed to be on the email list, aren't they? and
>
> I
>
> haven't
>
> seen a VOTE request.
>
>
> On 12/20/19 9:33 AM, Nabarun Nag wrote:
>
> +1
>
> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
>
> onichols@pivotal.io
>
>
> wrote:
>
>
> Based on the feedback so far, I will amend the proposal to
>
> drop
>
> item
>
> 2).
>
> Therefore, the current ability to create merge commits using
>
> command-line
>
> git will remain available.
>
> The proposal as amended is now:
>
> Change GitHub settings to make "Squash and merge" the default
> (by removing “Create a merge commit” option).
>
> Update the PR template to change the text "Is your initial
>
> contribution
>
> a single, squashed commit” to “Is your initial contribution
>
> squashed
>
> for
>
> ease of review (e.g. a single commit, or a ‘refactoring’
>
> commit
>
> plus a
>
> ‘fix’ commit)"
>
>
> As Naba suggested, we can try it, and if we don’t like it,
>
> it’s
>
> simple
>
> to
>
> revert.
>
> I’ve create a PR for the proposed change here:
> https://github.com/apache/geode/pull/4513
>
> Please use the PR to vote for against this proposal. It will
>
> not
>
> be
>
> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
>
> that
>
> time)
>
>
> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
>
> wrote:
>
>
> +1
>
> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
>
> onichols@pivotal.io>
>
> wrote:
>
>
> Hi Bruce, this proposal will not waste a single second of
>
> your
>
> time. It
>
> just prevents people from accidentally pressing a button
>
> that
>
> we
>
> have
>
> already agreed should never be pressed, but because we never
>
> configured
>
> our
>
> GitHub to match our stated policy, is currently the default.
>
> However, it will save a lot of time and frustration for
>
> anyone
>
> needing
>
> to
>
> bisect failures, revert, or cherry-pick changes, which has
>
> merit
>
> even if
>
> you personally never do any of those three things.
>
> Please start a separate thread if you would like to revisit
>
> the
>
> community
>
> decision to require passing PR checks.
>
> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
>
> bschuchardt@pivotal.io>
>
> wrote:
>
> I agree with Jake. I would go further by saying that I see
>
> very
>
> little
>
> merit in this proposal. I think we're getting more and more
>
> bureaucratic
>
> in our process and that it stifles productivity. I was
>
> recently
>
> forced
>
> to
>
> spend three days fixing tests in which I had changed an
>
> import
>
> statement
>
> before they would pass stress testing. I'm glad the tests
>
> now
>
> pass
>
> reliably but I was very frustrated by the process.
>
> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>
> I’m in agreement with Dan. Changes to the infrastructure
>
> to
>
> flat
>
> out
>
> prevent things that should be self policing is annoying.
>
> This
>
> PR
>
> review
>
> lock we have had already cost us valuable time waiting for
>
> PR
>
> pipelines
>
> to
>
> pass that have no relevance to the commit, like CI work: I’d
>
> hat
>
> to
>
> see
>
> yet
>
> another process enforced that Kees us from getting work done
>
> when
>
> necessary.
>
> -Jake
>
>
> On Dec 19, 2019, at 4:43 PM, Dan Smith <
>
> dsmith@pivotal.io
>
>
> wrote:
>
>
> -1 to (1) and (2).
>
> I think merge commits are appropriate in certain
>
> circumstances,
>
> so I
>
> don't
>
> think we should make a blanket restriction. In fact I
>
> think
>
> our
>
> release
>
> process involves some merges.
>
> I think setting standards on what is reasonable to be an
>
> individual
>
> commit
>
> will do a lot more to clean up our history than blocking
>
> merges.
>
> We'd
>
> rather not see commits like "Spotless Apply" in the
>
> history,
>
> but
>
> if
>
> reasonably separate and well written commits come in as
>
> part
>
> of
>
> a
>
> merge, I
>
> think that's fine.
>
> -Dan
>
> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
>
> jiliao@pivotal.io
>
>
> wrote:
>
> +1
>
> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
>
> onichols@pivotal.io
>
>
> wrote:
>
> I’d like to advance this topic from an informal
>
> request/discussion
>
> to a
>
> discussion of a concrete proposal.
>
> To recap, it sounds like there is general agreement
>
> that
>
> commit
>
> history
>
> on
>
> develop should be linear (no merge commits), and that
>
> the
>
> biggest
>
> obstacle
>
> to this is that the PR merge button in GitHub creates a
>
> merge
>
> commit
>
> by
>
> default.
>
> I propose the following changes:
> 1) Change GitHub settings to remove the ability to
>
> create
>
> a
>
> merge
>
> commit.
>
> This will make Squash & Merge the default.
>
> 2) Change GitHub settings to require linear history on
>
> develop.
>
> This
>
> prevents merge commits via command-line (not
>
> recommended,
>
> but
>
> wiki
>
> still
>
> has instructions for merging PRs this way).
>
> 3) Update the PR template to change the text "Is your
>
> initial
>
> contribution
>
> a single, squashed commit” to “Is your initial
>
> contribution
>
> squashed
>
> for
>
> ease of review (e.g. a single commit, or a
>
> ‘refactoring’
>
> commit
>
> plus
>
> a
>
> ‘fix’ commit)"
>
> For clarity, I am proposing no-change in the following
>
> areas:
>
> i) Leave Rebase & Merge as an option for PRs that have
>
> been
>
> structured to
>
> benefit from it (this can make it easier in a bisect to
>
> see
>
> whether
>
> the
>
> refactoring or the “fix” broke something).
> ii) Leave existing wording in the wiki as-is [stating
>
> that
>
> squashing
>
> is
>
> preferred].
>
>
> Please comment via this email thread.
> -Owen
>
>
>
> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
>
> klund@apache.org>
>
> wrote:
>
>
> I think it's already resolved Udo ;)
>
> Here's the problem, if I fixup a dunit test by
>
> removing
>
> all
>
> uses
>
> of
>
> "this."
>
> and I rename the dunit test, then git doesn't remember
>
> that
>
> the
>
> file
>
> is a
>
> rename -- it forever afterwards interprets it as a new
>
> file
>
> that I
>
> created
>
> if I touch more than 50% of the lines (which "this."
>
> can
>
> easily
>
> do). If
>
> we
>
> squash two commits: the rename and the cleanup of that
>
> dunit
>
> test
>
> --
>
> then
>
> we effectively lose the history of that file and it
>
> shows
>
> that
>
> I
>
> created
>
> a
>
> new file.
>
> Also for the record, I've been working on Geode since
>
> the
>
> beginning
>
> and I
>
> was never made aware of this change in our process. I
>
> never
>
> voted
>
> on
>
> it.
>
> I'm not a big fan of changing various details in our
>
> process
>
> every
>
> single
>
> week. It's very easy to miss these discussions unless
>
> someone
>
> points it
>
> out
>
> to me.
>
> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>
> ukohlmeyer@pivotal.io>
>
> wrote:
>
> I'm not sure what this discussion is about... WE, as
>
> a
>
> community,
>
> have
>
> agreed in common practices, in two place no less...
>
> 1) Quoting our PR template
>
>
> For all changes:
>
> *
>
> Is there a JIRA ticket associated with this PR? Is it
>
> referenced
>
> in
>
> the commit message?
>
> *
>
> Has your PR been rebased against the latest commit
>
> within
>
> the
>
> target
>
> branch (typically|develop|)?
>
> *
>
> ***Is your initial contribution a single, squashed
>
> commit?*
>
>
> *
>
> Does|gradlew build|run cleanly?
>
> *
>
> Have you written or updated unit tests to verify your
>
> changes?
>
>
> *
>
> If adding new dependencies to the code, are these
>
> dependencies
>
> licensed in a way that is compatible for inclusion
>
> underASF
>
> 2.0
>
> <
>
> http://www.apache.org/legal/resolved.html#category-a
>
> ?
>
>
> On our PR template we call out that the initial PR
>
> commit
>
> should
>
> be
>
> squashed.
>
> 2)
>
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>
> <
>
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>
> -- See "Accepting a PR Using the Command Line" -
>
> Point
>
> #3.
>
>
>
> @Kirk, if each of your commits "stands alone", I
>
> commend
>
> you
>
> on
>
> the
>
> diligence, but in reality, they should either then be
>
> stand
>
> alone
>
> PR's
>
> or just extra work created for yourself.
>
> If we want to change the way we have agreed upon we
>
> submit/commit/merge
>
> changes back into develop... Then this is another
>
> discussion
>
> thread,
>
> until then, I think we should all remind ourselves on
>
> our
>
> agreed
>
> contributions code of conduct.
>
> --Udo
>
> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>
> Kirk, I believe that creating a Pull Request with
>
> multiple
>
> commits is
>
> ok.
>
> It's just in the end that when it's being pushed to
>
> develop
>
> branch,
>
> it
>
> needs to be squash merged. I believe that is what
>
> you
>
> have
>
> mentioned
>
> in
>
> the
>
> first paragraph, and I am more than happy with that.
> If you can see in the first screenshot comparison
>
> that
>
> I
>
> had
>
> attached
>
> in
>
> the first email in this thread is what I want to
>
> avoid.
>
>
> Thank you for your feedback.
>
> Regards
> Naba
>
>
> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
>
> klund@apache.org>
>
> wrote:
>
> Whenever I submit a PR with multiple commits that I
>
> intend
>
> to
>
> rebase
>
> to
>
> develop, I always try to ensure that each commit
>
> stands
>
> alone
>
> as
>
> is
>
> (compiles and passes tests). Separating file
>
> renames
>
> and
>
> refactoring
>
> from
>
> behavior changes into different commits seems very
>
> valuable
>
> to
>
> me,
>
> and
>
> I've
>
> had trouble getting people to review PRs without
>
> this
>
> separation
>
> (but
>
> it
>
> could be squashed as it's merged to develop).
>
> It sounds to me like the real problem is (a) some
>
> PRs
>
> have
>
> multiple
>
> commits
>
> that don't compile or don't pass tests, and (b)
>
> some
>
> PRs
>
> that
>
> should
>
> be
>
> merged with squash are not (by accident most
>
> likely).
>
>
> I can submit multiple PRs instead of one PR with
>
> multiple
>
> commits.
>
> So
>
> I'll
>
> change my response to -0 if that helps prevent
>
> commits
>
> to
>
> develop
>
> that
>
> don't compile or pass tests. Without preventing
>
> rebase
>
> or
>
> merge
>
> commits
>
> from github, I'm not sure how we can really enforce
>
> this
>
> or
>
> prevent
>
> (b)
>
> above.
>
> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>
> amurmann@pivotal.io>
>
> wrote:
>
> I wonder if Kirk's and Naba's statements are
>
> necessarily
>
> at
>
> odds.
>
> Make the change easy (warning: this may be hard),
>
> then
>
> make
>
> the
>
> easy
>
> change."
>
> -Kent Beck
>
> Following Kent Beck's advise might reasonably
>
> split
>
> into
>
> two
>
> commits.
>
> One
>
> refactor commit and a separate commit that
>
> introduces
>
> the
>
> actual
>
> change.
>
> They should be individually revertible and might
>
> be
>
> easier
>
> understood
>
> if
>
> split out. I vividly remember a change on our code
>
> base
>
> where
>
> someone
>
> did a
>
> huge amount of refactoring that resulted than in
>
> one
>
> parameter
>
> changing
>
> in
>
> order to get the desired functionality change. If
>
> that
>
> was
>
> in
>
> one
>
> commit,
>
> it would be hard to see the actual change. If
>
> split
>
> out,
>
> it's
>
> beautiful
>
> and
>
> crystal clear.
>
> I am unsure how that would be reflected in terms
>
> of
>
> JIRA
>
> ticket
>
> references.
>
> Usually we assume that if there is a commit with
>
> the
>
> ticket
>
> number,
>
> the
>
> issue is resolved. Maybe the key here is to create
>
> a
>
> separate
>
> refactoring
>
> ticket.
>
> Would that allow us to have our cake and eat it
>
> too?
>
>
> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
>
> nnag@pivotal.io>
>
> wrote:
>
> It is to help with bisect operations when things
>
> start
>
> failing
>
> ...
>
> helps
>
> us
>
> it revert and build faster.
> also with cherry picking features / fixes to
>
> previous
>
> versions
>
> .
>
> And keeping the git history clean with no
>
> unnecessary
>
> “merge
>
> commits”.
>
> Regards
> Naba
>
>
> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
>
> klund@apache.org>
>
> wrote:
>
> -1 I really like to sometimes have more than 1
>
> commit
>
> in
>
> a
>
> PR
>
> and
>
> keep
>
> them
>
> separate when they merge to develop
>
> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>
> nnag@pivotal.io>
>
> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead
>
> of
>
> using
>
> merge.
>
> This will really help us in our bisect
>
> operations
>
> when a
>
> regression/flakiness in the product is
>
> introduced.
>
> We
>
> can
>
> automate
>
> and
>
> go
>
> through fewer commits faster, avoiding commits
>
> like
>
> "spotless
>
> fix"
>
> and
>
> "re-trigger precheck-in" or other minor commits
>
> in
>
> the
>
> merged
>
> branch.
>
> Also, please use the commit format : (helps us
>
> to
>
> know
>
> who
>
> worked
>
> on
>
> it,
>
> what is the history)
>
>
>
> * GEODE-xxxx: <brief intro >
> * explanation line 1
>
> *
>
> explanation
>
> line
>
> 2*
>
> This is not a rule or anything, but a request
>
> to
>
> help
>
> out
>
> your
>
> fellow
>
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka
>
> /
>
> Spark
>
> where
>
> they
>
> have
>
> a
>
> complete linear graph for their main branch
>
> HEAD
>
> [see
>
> attachment]
>
> Regards
> Naba.
>
>
>
> --
>
> Ju@N
>
>
>
>
>
>
>
> --
> Cheers
>
> Jinmei
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by "Ju@N" <ju...@gmail.com>.
I'm also using Blake's approach when dealing with refactoring + code
changes, it's clear and it never caused me any troubles so far.
+1 to to require linear commit history on develop.
Cheers.
On Thu, Jan 2, 2020 at 6:03 PM Mark Hanson <mh...@pivotal.io> wrote:
> This is the approach I am using as well Blake.
>
> Thanks,
> Mark
>
> > On Jan 2, 2020, at 7:16 AM, Blake Bender <bb...@pivotal.io> wrote:
> >
> > That's not how I approach this sort of a change, and to my mind it feels
> > sort of like that approach is asking for trouble. When I have a refactor
> > plus a code change, I do the refactor on a branch, submit the PR, then
> > branch off of *that* branch to do the feature work. This forces an
> > ordering of the changes, but alleviates most/all of the conflicts. When
> > the refactor PR is accepted, I rebase the feature work off of the new
> > develop branch, and submit the second PR, usually without encountering
> any
> > issues.
> >
> >
> >
> > On Wed, Jan 1, 2020 at 9:57 AM Aaron Lindsey <aa...@apache.org>
> > wrote:
> >
> >>>
> >>> Is it not the case currently? If I am working on a feature modifying
> >> class
> >>> X and another developer makes some refactoring changes on class X and
> >>> pushes it to develop, won't I have to resolve the merge commits anyway.
> >>
> >>
> >> Yes, you will always have to deal with resolving conflicts with other
> >> people's changes. The scenario I was describing was me having to resolve
> >> conflicts between my own 2 changes that modify the same files. If I
> make a
> >> refactor commit and a fix commit as two separate PRs that are each
> based on
> >> develop (i.e. they are independent PRs), after I merge the first one to
> >> develop the second one will have merge conflicts. The simplest way to
> avoid
> >> this is to put the commits in the same PR and use rebase-and-merge.
> >>
> >>
> >>
> >> On Tue, Dec 31, 2019 at 10:46 PM Owen Nichols <on...@pivotal.io>
> wrote:
> >>
> >>> It sounds like there is value in being able to deliver un-squashed PRs,
> >> and
> >>> we believe the richer commit message history outweighs any potential
> >>> inconvenience to bisect operations (as Aaron pointed out, finer-grained
> >>> commits should generally be to the benefit of bisect operations).
> >>>
> >>> We will leave all 3 merge options enabled in GitHub.
> >>>
> >>> On Tue, Dec 31, 2019 at 7:27 PM Dan Smith <ds...@pivotal.io> wrote:
> >>>
> >>>> I also tend to do the same workflow Aaron described - make a
> >> refactoring
> >>>> change to support a feature followed by the actual change I want to
> >> make.
> >>>> It makes the history a lot clearer because refactoring tends to touch
> a
> >>> lot
> >>>> of files, so it's nice to have those changes clearly marked as a
> >>>> refactoring that should not change behavior.
> >>>>
> >>>> It's possible to do this as to separate PRs, but that drags out the
> >>> process
> >>>> because you have to get the first in merged before you create the
> >> second.
> >>>> That encourages bunching changes in a single squashed commit, which
> >> makes
> >>>> git blame less useful.
> >>>>
> >>>>
> >>>> -Dan
> >>>>
> >>>> On Tue, Dec 31, 2019, 6:36 PM Nabarun Nag <nn...@apache.org> wrote:
> >>>>
> >>>>> Aaron ,
> >>>>>
> >>>>> Is it not the case currently? If I am working on a feature modifying
> >>>> class
> >>>>> X and another developer makes some refactoring changes on class X and
> >>>>> pushes it to develop, won't I have to resolve the merge commits
> >> anyway.
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>> Naba
> >>>>>
> >>>>>
> >>>>> On Tue, Dec 31, 2019 at 6:01 PM Aaron Lindsey <
> >> aaronlindsey@apache.org
> >>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Suppose I’m refactoring the same classes I’m touching for the
> >>> feature.
> >>>> I
> >>>>>> do the refactoring on one branch and submit a PR for that. Then I
> >>>>> implement
> >>>>>> the feature on another branch which is based on develop and does
> >> not
> >>>> have
> >>>>>> the refactoring changes since those are not merged yet. I’ll have
> >> to
> >>>>>> resolve conflicts on the second PR that I merge.
> >>>>>>
> >>>>>> Having interdependent PRs where one PR branch is based on another
> >> PR
> >>>>>> branch is not something I’ve tried. That requires more overhead in
> >>>> having
> >>>>>> to create more PRs and branches. And if you have N interdependent
> >>> PRs,
> >>>>> you
> >>>>>> have to do N-1 merges each time a PR is merged to develop (to
> >> update
> >>>> the
> >>>>>> other branches). It could be done, but is it worth the hassle?
> >>>>>>
> >>>>>> One more point about rebase-and-merge is that it seems like this
> >>> would
> >>>>>> make bisecting a failure easier since there would be smaller
> >> commits.
> >>>>>>
> >>>>>> Aaron
> >>>>>>
> >>>>>>> On Dec 31, 2019, at 5:41 PM, Owen Nichols <on...@pivotal.io>
> >>>> wrote:
> >>>>>>>
> >>>>>>> Can you elaborate on why you would have to deal with conflicts if
> >>> the
> >>>>>>> refactoring work was kept as a separate PR from the fix?
> >>>>>>>
> >>>>>>> As with many git workflows, there’s an easy way and a hard way to
> >>>>> manage
> >>>>>>> interdependent PRs (tl;dr only merge, never rebase!). I wonder if
> >>>> this
> >>>>>>> points out an opportunity for a “tips and tricks” page on the
> >> Geode
> >>>>> wiki.
> >>>>>>>
> >>>>>>> On Tue, Dec 31, 2019 at 5:22 PM Aaron Lindsey <
> >>>> aaronlindsey@apache.org
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> -0.9
> >>>>>>>>
> >>>>>>>> I’m not in favor of the revised proposal that disallows
> >>>>>> rebase-and-merge.
> >>>>>>>> Say I am working on a PR and I have a refactor commit and
> >> another
> >>>>> commit
> >>>>>>>> which implements a new feature. I don’t want those commits to
> >> get
> >>>>>> squashed
> >>>>>>>> because that makes it hard to understand the diff. However, if I
> >>>> make
> >>>>>> those
> >>>>>>>> commits as two separate PRs then I am going to have to deal with
> >>>>>> conflicts.
> >>>>>>>>
> >>>>>>>> I’m not sure when we made it a rule that every commit in develop
> >>> had
> >>>>> to
> >>>>>>>> compile and pass tests. I know we implemented a rule that all
> >> PRs
> >>>> had
> >>>>> to
> >>>>>>>> pass certain checks, but I never thought that rule implied all
> >>>> commits
> >>>>>> had
> >>>>>>>> to pass those checks.
> >>>>>>>>
> >>>>>>>> In general I just don’t see the problem with rebase-and-merge
> >> and
> >>>> this
> >>>>>>>> feels like an unnecessary restriction, but I will go with it if
> >>>> that’s
> >>>>>> what
> >>>>>>>> everyone wants to do.
> >>>>>>>>
> >>>>>>>> Aaron
> >>>>>>>>
> >>>>>>>>> On Dec 31, 2019, at 3:09 PM, Owen Nichols <onichols@pivotal.io
> >>>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> To recap, this proposal is now revised to remove 2 of the 3
> >> merge
> >>>>>> options
> >>>>>>>>> from GitHub, leaving only Squash and Merge. PR #4513
> >>>>>>>>> <https://github.com/apache/geode/pull/4513> serves as an
> >> exhibit
> >>>> of
> >>>>>>>> what is
> >>>>>>>>> proposed (it is not to be merged unless discussion leads to
> >>>> consensus
> >>>>>>>> and a
> >>>>>>>>> successful vote). Please use the dev list (not the PR) for all
> >>>>>>>> discussion
> >>>>>>>>> (and voting, if we get that far).
> >>>>>>>>>
> >>>>>>>>> Squash and merge is already used almost exclusively by the
> >> Geode
> >>>>>>>> community,
> >>>>>>>>> with any exceptions tending to be accidental more often than
> >>>>>> intentional.
> >>>>>>>>> However, some have raised the concern that implementing this
> >>>>>> restriction
> >>>>>>>>> could result in harm or wasted time. Can someone give an
> >> example
> >>>> of
> >>>>> a
> >>>>>>>> such
> >>>>>>>>> a scenario?
> >>>>>>>>>
> >>>>>>>>> It seems there is a divide here between junior and senior
> >>> community
> >>>>>>>>> members. Newer committers appreciate additional guardrails to
> >>>>> protect
> >>>>>>>> them
> >>>>>>>>> from accidentally doing the wrong thing, while those with more
> >>>>>> experience
> >>>>>>>>> want to be able to work unencumbered by restrictions of any
> >> kind.
> >>>>>>>>>
> >>>>>>>>> Our welcome email to new committers states “We like to work on
> >>>> trust
> >>>>>>>> rather
> >>>>>>>>> than unnecessary constraints...Being a committer enables you to
> >>>> more
> >>>>>>>> easily
> >>>>>>>>> make changes without needing to go through the patch submission
> >>>>>> process”.
> >>>>>>>>> I can see this as an argument against this proposal (perhaps
> >> even
> >>>> an
> >>>>>>>>> argument against any form of branch protection).
> >>>>>>>>>
> >>>>>>>>> In the scheme of things, this proposal makes very little
> >>>> difference.
> >>>>>>>> There
> >>>>>>>>> are still other ways to get non-compiling commits onto develop
> >>>> (e.g.
> >>>>>>>>> waiting a long time between running PR checks and merging to
> >>>>> develop).
> >>>>>>>>> What’s more important is working well together as a community.
> >>> So,
> >>>>>>>> perhaps
> >>>>>>>>> what’s best for the community is to encourage working on trust
> >>>> rather
> >>>>>>>> than
> >>>>>>>>> unnecessary constraints.
> >>>>>>>>>
> >>>>>>>>> -Owen
> >>>>>>>>>
> >>>>>>>>> On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org>
> >>> wrote:
> >>>>>>>>>
> >>>>>>>>> I'm happy to file multiple PRs when I need to merge multiple
> >>>> commits
> >>>>> to
> >>>>>>>>> develop.
> >>>>>>>>>
> >>>>>>>>> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <
> >> mhanson@pivotal.io>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> This change to disable all but squash-merge would be really
> >> easy
> >>> to
> >>>>>>>>> revert. How about we try it for a while and see? If people
> >> decide
> >>>> it
> >>>>> is
> >>>>>>>>> really limiting them, we can change it back. Let’s do it for 1
> >>>> month
> >>>>>> and
> >>>>>>>>> see how it goes. Does that sound reasonable?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Mark
> >>>>>>>>>
> >>>>>>>>> On Dec 30, 2019, at 5:25 PM, Owen Nichols <onichols@pivotal.io
> >>>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Given that we adopted <
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
> >>>>>>>>>>
> >>>>>>>>> and still wish to continue <
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
> >>>>>>>>>>
> >>>>>>>>> having branch protection rules to ensure every commit landing
> >> in
> >>>>>> develop
> >>>>>>>>> has passed the required PR checks, it seems like that decision
> >>>> alone
> >>>>>>>>> mandates that we disable all merge mechanisms other than
> >>>>>>>> squash-and-merge.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Allowing merge commits or rebase merges bypasses branch
> >>> protection
> >>>>> for
> >>>>>>>>>
> >>>>>>>>> all commits other than the final one in the merge or rebase
> >> set.
> >>>>> Given
> >>>>>>>>> that we decided <
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
> >>>>>>>>>>
> >>>>>>>>> that bypassing PR checks should never be allowed, keeping this
> >>>>> loophole
> >>>>>>>>> open seems untenable.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> This is not just hypothetical — this loophole is causing real
> >>>>> problems.
> >>>>>>>>>
> >>>>>>>>> We now have commits on develop that don’t compile. For
> >> example:
> >>>>>>>>>
> >>>>>>>>> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> >>>>>>>>> ./gradlew devBuild
> >>>>>>>>> ...spotlessJava FAILED
> >>>>>>>>> We implemented branch protections to make this impossible,
> >> right?
> >>>>>>>>>
> >>>>>>>>> We can very easily close this loophole by disabling all but the
> >>>>>>>>>
> >>>>>>>>> Squash&Merge button for PRs. This will not make more work for
> >>> any
> >>>>>>>>> developer. If you want to get multiple commits onto develop,
> >>>> simply
> >>>>>>>> submit
> >>>>>>>>> each as a separate PR — that is the only way to assure that
> >>>> required
> >>>>> PR
> >>>>>>>>> checks have passed for each.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On the other hand, if we as a Geode community feel strongly
> >> that
> >>>>>>>>>
> >>>>>>>>> bypassing branch protection via merge commits and rebase
> >> commits
> >>> is
> >>>>>>>>> important to allow, why not also allow arbitrary overrides (or
> >>> get
> >>>>> rid
> >>>>>> of
> >>>>>>>>> branch protection entirely)?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -Owen
> >>>>>>>>>
> >>>>>>>>> On Dec 20, 2019, at 12:31 PM, Blake Bender <bbender@pivotal.io
> >>>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Just FWIW, the situation described of having multiple commits
> >> in
> >>> a
> >>>>>>>>>
> >>>>>>>>> single
> >>>>>>>>>
> >>>>>>>>> PR with separate associated JIRA tickets is still kind of
> >>>>> problematic.
> >>>>>>>>>
> >>>>>>>>> It
> >>>>>>>>>
> >>>>>>>>> could well be the case that the commits are interdependent,
> >> thus
> >>>> when
> >>>>>>>>> bisecting etc it's still not possible to revert the fix for a
> >>>> single
> >>>>>>>>> bug/feature/whatever atomically. It's all good, though, I'm
> >>>>> satisfied
> >>>>>>>>>
> >>>>>>>>> no
> >>>>>>>>>
> >>>>>>>>> one's forcing me to adopt practice I'm opposed to. Apologies
> >> for
> >>>>>>>>>
> >>>>>>>>> getting
> >>>>>>>>>
> >>>>>>>>> my feathers a little ruffled, or if I ruffled anyone else's in
> >>>>> return.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Blake
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Hi Dan,
> >>>>>>>>>
> >>>>>>>>> When we do squash merge all the commit messages are preserved
> >> and
> >>>>> also
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> co-authored tag works when we do squash merge.
> >>>>>>>>> So the authorship and history are preserved.
> >>>>>>>>>
> >>>>>>>>> In my own personal experience and reverts and pinpointing
> >>>> regression
> >>>>>>>>> failures are tough when the commits are spread out. Also,
> >> reverts
> >>>> are
> >>>>>>>>> easier when it is just one commit while we are bisecting
> >>> failures.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Regards
> >>>>>>>>> Naba
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> I'll change to -0.
> >>>>>>>>>
> >>>>>>>>> I think merge commits are a nice way to record history in some
> >>>> cases,
> >>>>>>>>>
> >>>>>>>>> and
> >>>>>>>>>
> >>>>>>>>> can also be a way to avoid messy conflicts that come with
> >> rebase.
> >>>>>>>>>
> >>>>>>>>> Merge
> >>>>>>>>>
> >>>>>>>>> commits also preserve authorship of commits (compared to
> >>>>>>>>>
> >>>>>>>>> squash-merge),
> >>>>>>>>>
> >>>>>>>>> which I think is valuable as an open source community that is
> >>>> trying
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> keep track of outside contributions.
> >>>>>>>>>
> >>>>>>>>> That said, if the rest of y'all feel it will help to disable
> >> the
> >>>>>>>>>
> >>>>>>>>> button,
> >>>>>>>>>
> >>>>>>>>> I
> >>>>>>>>>
> >>>>>>>>> won't stand in the way.
> >>>>>>>>>
> >>>>>>>>> -Dan
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <
> >>> abaker@pivotal.io>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Whether we are talking about the geode/ repository or the
> >>>>>>>>>
> >>>>>>>>> geode-native/
> >>>>>>>>>
> >>>>>>>>> repository we are all one GEODE community.
> >>>>>>>>>
> >>>>>>>>> The idea of a native client team may matter in some contexts
> >> but
> >>> in
> >>>>>>>>>
> >>>>>>>>> this
> >>>>>>>>>
> >>>>>>>>> space we are all GEODE contributors.
> >>>>>>>>>
> >>>>>>>>> Adopting a common approach across our repos will make it easier
> >>> for
> >>>>>>>>>
> >>>>>>>>> new
> >>>>>>>>>
> >>>>>>>>> contributors to engage, learn our norms, and join our efforts.
> >>>>>>>>>
> >>>>>>>>> $0.02,
> >>>>>>>>> Anthony
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bbender@pivotal.io
> >>>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Is this a policy the native client team must abide by, as well?
> >>> It
> >>>>>>>>>
> >>>>>>>>> varies
> >>>>>>>>>
> >>>>>>>>> slightly with what we've been doing, and all other things being
> >>>>>>>>>
> >>>>>>>>> equal I
> >>>>>>>>>
> >>>>>>>>> see
> >>>>>>>>>
> >>>>>>>>> no reason for us to change that. If I am to have any measure
> >> of
> >>>>>>>>>
> >>>>>>>>> control
> >>>>>>>>>
> >>>>>>>>> over the nc repository, I will definitely enforce a 1:1
> >>>>>>>>>
> >>>>>>>>> correspondence
> >>>>>>>>>
> >>>>>>>>> between commits to develop and JIRA tickets. IMO, if your
> >>>>>>>>>
> >>>>>>>>> refactoring
> >>>>>>>>>
> >>>>>>>>> in a
> >>>>>>>>>
> >>>>>>>>> PR is sufficiently large or complex that it's difficult to
> >> tease
> >>> it
> >>>>>>>>>
> >>>>>>>>> out
> >>>>>>>>>
> >>>>>>>>> from the bug you're fixing or feature you're implementing, it
> >>>> merits
> >>>>>>>>>
> >>>>>>>>> its
> >>>>>>>>>
> >>>>>>>>> own JIRA ticket and a separate PR. If your "actual" fix then
> >>>>>>>>>
> >>>>>>>>> becomes
> >>>>>>>>>
> >>>>>>>>> dependent on the refactored code, that's a price I'm willing to
> >>> pay
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> keep
> >>>>>>>>>
> >>>>>>>>> history clean.
> >>>>>>>>>
> >>>>>>>>> On the other hand, I see no real value in squashing to a single
> >>>>>>>>>
> >>>>>>>>> commit
> >>>>>>>>>
> >>>>>>>>> prior to submitting a PR, since your view of the changes on
> >>> GitHub
> >>>>>>>>>
> >>>>>>>>> is
> >>>>>>>>>
> >>>>>>>>> essentially the same either way. We haven't enforced this on
> >> the
> >>>> nc
> >>>>>>>>>
> >>>>>>>>> repo,
> >>>>>>>>>
> >>>>>>>>> and I'd prefer to keep it that way.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Blake
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <
> >> jiliao@pivotal.io>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Merge commit is the new contributor's default setting. When we
> >>> are
> >>>>>>>>>
> >>>>>>>>> merging
> >>>>>>>>>
> >>>>>>>>> new contributor's PR, since we are so used to THINKING
> >>>>>>>>>
> >>>>>>>>> "squash-and-merge"
> >>>>>>>>>
> >>>>>>>>> is the default, we forgot to check what the button really says
> >>> when
> >>>>>>>>>
> >>>>>>>>> we
> >>>>>>>>>
> >>>>>>>>> are
> >>>>>>>>>
> >>>>>>>>> merging other people's PR.
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> >>>>>>>>>
> >>>>>>>>> eburghardt@pivotal.io>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> I'm a proponent of using squash-and-merge, and once a person
> >> has
> >>>>>>>>>
> >>>>>>>>> chosen
> >>>>>>>>>
> >>>>>>>>> this option once it comes up by default afterwards...
> >>>>>>>>>
> >>>>>>>>> Owen, I don't think you have consensus to put forth this PR,
> >>>>>>>>>
> >>>>>>>>> there
> >>>>>>>>>
> >>>>>>>>> are
> >>>>>>>>>
> >>>>>>>>> -1s
> >>>>>>>>>
> >>>>>>>>> above... (early voting)
> >>>>>>>>>
> >>>>>>>>> maybe we'll be better off socializing the norm of
> >>> squash-and-merge
> >>>>>>>>>
> >>>>>>>>> and
> >>>>>>>>>
> >>>>>>>>> gaining a natural consensus that way...
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
> >>>>>>>>>
> >>>>>>>>> onichols@pivotal.io
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The proposed action manifests as a commit to the Geode git
> >>>>>>>>>
> >>>>>>>>> repository,
> >>>>>>>>>
> >>>>>>>>> so
> >>>>>>>>>
> >>>>>>>>> a PR is an acceptable vehicle for voting in this case.
> >>>>>>>>>
> >>>>>>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> >>>>>>>>>
> >>>>>>>>> bschuchardt@pivotal.io>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I see a lot of plus-ones and a "voting deadline" on this
> >> DISCUSS
> >>>>>>>>>
> >>>>>>>>> thread
> >>>>>>>>>
> >>>>>>>>> and a request to "vote" using a PR. This all seems out of
> >> order
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> me.
> >>>>>>>>>
> >>>>>>>>> Our votes are supposed to be on the email list, aren't they?
> >> and
> >>>>>>>>>
> >>>>>>>>> I
> >>>>>>>>>
> >>>>>>>>> haven't
> >>>>>>>>>
> >>>>>>>>> seen a VOTE request.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> >>>>>>>>>
> >>>>>>>>> +1
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
> >>>>>>>>>
> >>>>>>>>> onichols@pivotal.io
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Based on the feedback so far, I will amend the proposal to
> >>>>>>>>>
> >>>>>>>>> drop
> >>>>>>>>>
> >>>>>>>>> item
> >>>>>>>>>
> >>>>>>>>> 2).
> >>>>>>>>>
> >>>>>>>>> Therefore, the current ability to create merge commits using
> >>>>>>>>>
> >>>>>>>>> command-line
> >>>>>>>>>
> >>>>>>>>> git will remain available.
> >>>>>>>>>
> >>>>>>>>> The proposal as amended is now:
> >>>>>>>>>
> >>>>>>>>> Change GitHub settings to make "Squash and merge" the default
> >>>>>>>>> (by removing “Create a merge commit” option).
> >>>>>>>>>
> >>>>>>>>> Update the PR template to change the text "Is your initial
> >>>>>>>>>
> >>>>>>>>> contribution
> >>>>>>>>>
> >>>>>>>>> a single, squashed commit” to “Is your initial contribution
> >>>>>>>>>
> >>>>>>>>> squashed
> >>>>>>>>>
> >>>>>>>>> for
> >>>>>>>>>
> >>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> >>>>>>>>>
> >>>>>>>>> commit
> >>>>>>>>>
> >>>>>>>>> plus a
> >>>>>>>>>
> >>>>>>>>> ‘fix’ commit)"
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> As Naba suggested, we can try it, and if we don’t like it,
> >>>>>>>>>
> >>>>>>>>> it’s
> >>>>>>>>>
> >>>>>>>>> simple
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> revert.
> >>>>>>>>>
> >>>>>>>>> I’ve create a PR for the proposed change here:
> >>>>>>>>> https://github.com/apache/geode/pull/4513
> >>>>>>>>>
> >>>>>>>>> Please use the PR to vote for against this proposal. It will
> >>>>>>>>>
> >>>>>>>>> not
> >>>>>>>>>
> >>>>>>>>> be
> >>>>>>>>>
> >>>>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
> >>>>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>> time)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> +1
> >>>>>>>>>
> >>>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
> >>>>>>>>>
> >>>>>>>>> onichols@pivotal.io>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Hi Bruce, this proposal will not waste a single second of
> >>>>>>>>>
> >>>>>>>>> your
> >>>>>>>>>
> >>>>>>>>> time. It
> >>>>>>>>>
> >>>>>>>>> just prevents people from accidentally pressing a button
> >>>>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>> we
> >>>>>>>>>
> >>>>>>>>> have
> >>>>>>>>>
> >>>>>>>>> already agreed should never be pressed, but because we never
> >>>>>>>>>
> >>>>>>>>> configured
> >>>>>>>>>
> >>>>>>>>> our
> >>>>>>>>>
> >>>>>>>>> GitHub to match our stated policy, is currently the default.
> >>>>>>>>>
> >>>>>>>>> However, it will save a lot of time and frustration for
> >>>>>>>>>
> >>>>>>>>> anyone
> >>>>>>>>>
> >>>>>>>>> needing
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> bisect failures, revert, or cherry-pick changes, which has
> >>>>>>>>>
> >>>>>>>>> merit
> >>>>>>>>>
> >>>>>>>>> even if
> >>>>>>>>>
> >>>>>>>>> you personally never do any of those three things.
> >>>>>>>>>
> >>>>>>>>> Please start a separate thread if you would like to revisit
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> community
> >>>>>>>>>
> >>>>>>>>> decision to require passing PR checks.
> >>>>>>>>>
> >>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> >>>>>>>>>
> >>>>>>>>> bschuchardt@pivotal.io>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> I agree with Jake. I would go further by saying that I see
> >>>>>>>>>
> >>>>>>>>> very
> >>>>>>>>>
> >>>>>>>>> little
> >>>>>>>>>
> >>>>>>>>> merit in this proposal. I think we're getting more and more
> >>>>>>>>>
> >>>>>>>>> bureaucratic
> >>>>>>>>>
> >>>>>>>>> in our process and that it stifles productivity. I was
> >>>>>>>>>
> >>>>>>>>> recently
> >>>>>>>>>
> >>>>>>>>> forced
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> spend three days fixing tests in which I had changed an
> >>>>>>>>>
> >>>>>>>>> import
> >>>>>>>>>
> >>>>>>>>> statement
> >>>>>>>>>
> >>>>>>>>> before they would pass stress testing. I'm glad the tests
> >>>>>>>>>
> >>>>>>>>> now
> >>>>>>>>>
> >>>>>>>>> pass
> >>>>>>>>>
> >>>>>>>>> reliably but I was very frustrated by the process.
> >>>>>>>>>
> >>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> >>>>>>>>>
> >>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> flat
> >>>>>>>>>
> >>>>>>>>> out
> >>>>>>>>>
> >>>>>>>>> prevent things that should be self policing is annoying.
> >>>>>>>>>
> >>>>>>>>> This
> >>>>>>>>>
> >>>>>>>>> PR
> >>>>>>>>>
> >>>>>>>>> review
> >>>>>>>>>
> >>>>>>>>> lock we have had already cost us valuable time waiting for
> >>>>>>>>>
> >>>>>>>>> PR
> >>>>>>>>>
> >>>>>>>>> pipelines
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> pass that have no relevance to the commit, like CI work: I’d
> >>>>>>>>>
> >>>>>>>>> hat
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> see
> >>>>>>>>>
> >>>>>>>>> yet
> >>>>>>>>>
> >>>>>>>>> another process enforced that Kees us from getting work done
> >>>>>>>>>
> >>>>>>>>> when
> >>>>>>>>>
> >>>>>>>>> necessary.
> >>>>>>>>>
> >>>>>>>>> -Jake
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <
> >>>>>>>>>
> >>>>>>>>> dsmith@pivotal.io
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -1 to (1) and (2).
> >>>>>>>>>
> >>>>>>>>> I think merge commits are appropriate in certain
> >>>>>>>>>
> >>>>>>>>> circumstances,
> >>>>>>>>>
> >>>>>>>>> so I
> >>>>>>>>>
> >>>>>>>>> don't
> >>>>>>>>>
> >>>>>>>>> think we should make a blanket restriction. In fact I
> >>>>>>>>>
> >>>>>>>>> think
> >>>>>>>>>
> >>>>>>>>> our
> >>>>>>>>>
> >>>>>>>>> release
> >>>>>>>>>
> >>>>>>>>> process involves some merges.
> >>>>>>>>>
> >>>>>>>>> I think setting standards on what is reasonable to be an
> >>>>>>>>>
> >>>>>>>>> individual
> >>>>>>>>>
> >>>>>>>>> commit
> >>>>>>>>>
> >>>>>>>>> will do a lot more to clean up our history than blocking
> >>>>>>>>>
> >>>>>>>>> merges.
> >>>>>>>>>
> >>>>>>>>> We'd
> >>>>>>>>>
> >>>>>>>>> rather not see commits like "Spotless Apply" in the
> >>>>>>>>>
> >>>>>>>>> history,
> >>>>>>>>>
> >>>>>>>>> but
> >>>>>>>>>
> >>>>>>>>> if
> >>>>>>>>>
> >>>>>>>>> reasonably separate and well written commits come in as
> >>>>>>>>>
> >>>>>>>>> part
> >>>>>>>>>
> >>>>>>>>> of
> >>>>>>>>>
> >>>>>>>>> a
> >>>>>>>>>
> >>>>>>>>> merge, I
> >>>>>>>>>
> >>>>>>>>> think that's fine.
> >>>>>>>>>
> >>>>>>>>> -Dan
> >>>>>>>>>
> >>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> >>>>>>>>>
> >>>>>>>>> jiliao@pivotal.io
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> +1
> >>>>>>>>>
> >>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> >>>>>>>>>
> >>>>>>>>> onichols@pivotal.io
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> I’d like to advance this topic from an informal
> >>>>>>>>>
> >>>>>>>>> request/discussion
> >>>>>>>>>
> >>>>>>>>> to a
> >>>>>>>>>
> >>>>>>>>> discussion of a concrete proposal.
> >>>>>>>>>
> >>>>>>>>> To recap, it sounds like there is general agreement
> >>>>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>> commit
> >>>>>>>>>
> >>>>>>>>> history
> >>>>>>>>>
> >>>>>>>>> on
> >>>>>>>>>
> >>>>>>>>> develop should be linear (no merge commits), and that
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> biggest
> >>>>>>>>>
> >>>>>>>>> obstacle
> >>>>>>>>>
> >>>>>>>>> to this is that the PR merge button in GitHub creates a
> >>>>>>>>>
> >>>>>>>>> merge
> >>>>>>>>>
> >>>>>>>>> commit
> >>>>>>>>>
> >>>>>>>>> by
> >>>>>>>>>
> >>>>>>>>> default.
> >>>>>>>>>
> >>>>>>>>> I propose the following changes:
> >>>>>>>>> 1) Change GitHub settings to remove the ability to
> >>>>>>>>>
> >>>>>>>>> create
> >>>>>>>>>
> >>>>>>>>> a
> >>>>>>>>>
> >>>>>>>>> merge
> >>>>>>>>>
> >>>>>>>>> commit.
> >>>>>>>>>
> >>>>>>>>> This will make Squash & Merge the default.
> >>>>>>>>>
> >>>>>>>>> 2) Change GitHub settings to require linear history on
> >>>>>>>>>
> >>>>>>>>> develop.
> >>>>>>>>>
> >>>>>>>>> This
> >>>>>>>>>
> >>>>>>>>> prevents merge commits via command-line (not
> >>>>>>>>>
> >>>>>>>>> recommended,
> >>>>>>>>>
> >>>>>>>>> but
> >>>>>>>>>
> >>>>>>>>> wiki
> >>>>>>>>>
> >>>>>>>>> still
> >>>>>>>>>
> >>>>>>>>> has instructions for merging PRs this way).
> >>>>>>>>>
> >>>>>>>>> 3) Update the PR template to change the text "Is your
> >>>>>>>>>
> >>>>>>>>> initial
> >>>>>>>>>
> >>>>>>>>> contribution
> >>>>>>>>>
> >>>>>>>>> a single, squashed commit” to “Is your initial
> >>>>>>>>>
> >>>>>>>>> contribution
> >>>>>>>>>
> >>>>>>>>> squashed
> >>>>>>>>>
> >>>>>>>>> for
> >>>>>>>>>
> >>>>>>>>> ease of review (e.g. a single commit, or a
> >>>>>>>>>
> >>>>>>>>> ‘refactoring’
> >>>>>>>>>
> >>>>>>>>> commit
> >>>>>>>>>
> >>>>>>>>> plus
> >>>>>>>>>
> >>>>>>>>> a
> >>>>>>>>>
> >>>>>>>>> ‘fix’ commit)"
> >>>>>>>>>
> >>>>>>>>> For clarity, I am proposing no-change in the following
> >>>>>>>>>
> >>>>>>>>> areas:
> >>>>>>>>>
> >>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have
> >>>>>>>>>
> >>>>>>>>> been
> >>>>>>>>>
> >>>>>>>>> structured to
> >>>>>>>>>
> >>>>>>>>> benefit from it (this can make it easier in a bisect to
> >>>>>>>>>
> >>>>>>>>> see
> >>>>>>>>>
> >>>>>>>>> whether
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> refactoring or the “fix” broke something).
> >>>>>>>>> ii) Leave existing wording in the wiki as-is [stating
> >>>>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>> squashing
> >>>>>>>>>
> >>>>>>>>> is
> >>>>>>>>>
> >>>>>>>>> preferred].
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Please comment via this email thread.
> >>>>>>>>> -Owen
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> >>>>>>>>>
> >>>>>>>>> klund@apache.org>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I think it's already resolved Udo ;)
> >>>>>>>>>
> >>>>>>>>> Here's the problem, if I fixup a dunit test by
> >>>>>>>>>
> >>>>>>>>> removing
> >>>>>>>>>
> >>>>>>>>> all
> >>>>>>>>>
> >>>>>>>>> uses
> >>>>>>>>>
> >>>>>>>>> of
> >>>>>>>>>
> >>>>>>>>> "this."
> >>>>>>>>>
> >>>>>>>>> and I rename the dunit test, then git doesn't remember
> >>>>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> file
> >>>>>>>>>
> >>>>>>>>> is a
> >>>>>>>>>
> >>>>>>>>> rename -- it forever afterwards interprets it as a new
> >>>>>>>>>
> >>>>>>>>> file
> >>>>>>>>>
> >>>>>>>>> that I
> >>>>>>>>>
> >>>>>>>>> created
> >>>>>>>>>
> >>>>>>>>> if I touch more than 50% of the lines (which "this."
> >>>>>>>>>
> >>>>>>>>> can
> >>>>>>>>>
> >>>>>>>>> easily
> >>>>>>>>>
> >>>>>>>>> do). If
> >>>>>>>>>
> >>>>>>>>> we
> >>>>>>>>>
> >>>>>>>>> squash two commits: the rename and the cleanup of that
> >>>>>>>>>
> >>>>>>>>> dunit
> >>>>>>>>>
> >>>>>>>>> test
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>> then
> >>>>>>>>>
> >>>>>>>>> we effectively lose the history of that file and it
> >>>>>>>>>
> >>>>>>>>> shows
> >>>>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>> I
> >>>>>>>>>
> >>>>>>>>> created
> >>>>>>>>>
> >>>>>>>>> a
> >>>>>>>>>
> >>>>>>>>> new file.
> >>>>>>>>>
> >>>>>>>>> Also for the record, I've been working on Geode since
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> beginning
> >>>>>>>>>
> >>>>>>>>> and I
> >>>>>>>>>
> >>>>>>>>> was never made aware of this change in our process. I
> >>>>>>>>>
> >>>>>>>>> never
> >>>>>>>>>
> >>>>>>>>> voted
> >>>>>>>>>
> >>>>>>>>> on
> >>>>>>>>>
> >>>>>>>>> it.
> >>>>>>>>>
> >>>>>>>>> I'm not a big fan of changing various details in our
> >>>>>>>>>
> >>>>>>>>> process
> >>>>>>>>>
> >>>>>>>>> every
> >>>>>>>>>
> >>>>>>>>> single
> >>>>>>>>>
> >>>>>>>>> week. It's very easy to miss these discussions unless
> >>>>>>>>>
> >>>>>>>>> someone
> >>>>>>>>>
> >>>>>>>>> points it
> >>>>>>>>>
> >>>>>>>>> out
> >>>>>>>>>
> >>>>>>>>> to me.
> >>>>>>>>>
> >>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> >>>>>>>>>
> >>>>>>>>> ukohlmeyer@pivotal.io>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> I'm not sure what this discussion is about... WE, as
> >>>>>>>>>
> >>>>>>>>> a
> >>>>>>>>>
> >>>>>>>>> community,
> >>>>>>>>>
> >>>>>>>>> have
> >>>>>>>>>
> >>>>>>>>> agreed in common practices, in two place no less...
> >>>>>>>>>
> >>>>>>>>> 1) Quoting our PR template
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> For all changes:
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> >>>>>>>>>
> >>>>>>>>> referenced
> >>>>>>>>>
> >>>>>>>>> in
> >>>>>>>>>
> >>>>>>>>> the commit message?
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> Has your PR been rebased against the latest commit
> >>>>>>>>>
> >>>>>>>>> within
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> target
> >>>>>>>>>
> >>>>>>>>> branch (typically|develop|)?
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> ***Is your initial contribution a single, squashed
> >>>>>>>>>
> >>>>>>>>> commit?*
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> Does|gradlew build|run cleanly?
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> Have you written or updated unit tests to verify your
> >>>>>>>>>
> >>>>>>>>> changes?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> If adding new dependencies to the code, are these
> >>>>>>>>>
> >>>>>>>>> dependencies
> >>>>>>>>>
> >>>>>>>>> licensed in a way that is compatible for inclusion
> >>>>>>>>>
> >>>>>>>>> underASF
> >>>>>>>>>
> >>>>>>>>> 2.0
> >>>>>>>>>
> >>>>>>>>> <
> >>>>>>>>>
> >>>>>>>>> http://www.apache.org/legal/resolved.html#category-a
> >>>>>>>>>
> >>>>>>>>> ?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On our PR template we call out that the initial PR
> >>>>>>>>>
> >>>>>>>>> commit
> >>>>>>>>>
> >>>>>>>>> should
> >>>>>>>>>
> >>>>>>>>> be
> >>>>>>>>>
> >>>>>>>>> squashed.
> >>>>>>>>>
> >>>>>>>>> 2)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>>
> >>>>>>>>> <
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>>
> >>>>>>>>> -- See "Accepting a PR Using the Command Line" -
> >>>>>>>>>
> >>>>>>>>> Point
> >>>>>>>>>
> >>>>>>>>> #3.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> @Kirk, if each of your commits "stands alone", I
> >>>>>>>>>
> >>>>>>>>> commend
> >>>>>>>>>
> >>>>>>>>> you
> >>>>>>>>>
> >>>>>>>>> on
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> diligence, but in reality, they should either then be
> >>>>>>>>>
> >>>>>>>>> stand
> >>>>>>>>>
> >>>>>>>>> alone
> >>>>>>>>>
> >>>>>>>>> PR's
> >>>>>>>>>
> >>>>>>>>> or just extra work created for yourself.
> >>>>>>>>>
> >>>>>>>>> If we want to change the way we have agreed upon we
> >>>>>>>>>
> >>>>>>>>> submit/commit/merge
> >>>>>>>>>
> >>>>>>>>> changes back into develop... Then this is another
> >>>>>>>>>
> >>>>>>>>> discussion
> >>>>>>>>>
> >>>>>>>>> thread,
> >>>>>>>>>
> >>>>>>>>> until then, I think we should all remind ourselves on
> >>>>>>>>>
> >>>>>>>>> our
> >>>>>>>>>
> >>>>>>>>> agreed
> >>>>>>>>>
> >>>>>>>>> contributions code of conduct.
> >>>>>>>>>
> >>>>>>>>> --Udo
> >>>>>>>>>
> >>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >>>>>>>>>
> >>>>>>>>> Kirk, I believe that creating a Pull Request with
> >>>>>>>>>
> >>>>>>>>> multiple
> >>>>>>>>>
> >>>>>>>>> commits is
> >>>>>>>>>
> >>>>>>>>> ok.
> >>>>>>>>>
> >>>>>>>>> It's just in the end that when it's being pushed to
> >>>>>>>>>
> >>>>>>>>> develop
> >>>>>>>>>
> >>>>>>>>> branch,
> >>>>>>>>>
> >>>>>>>>> it
> >>>>>>>>>
> >>>>>>>>> needs to be squash merged. I believe that is what
> >>>>>>>>>
> >>>>>>>>> you
> >>>>>>>>>
> >>>>>>>>> have
> >>>>>>>>>
> >>>>>>>>> mentioned
> >>>>>>>>>
> >>>>>>>>> in
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> first paragraph, and I am more than happy with that.
> >>>>>>>>> If you can see in the first screenshot comparison
> >>>>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>> I
> >>>>>>>>>
> >>>>>>>>> had
> >>>>>>>>>
> >>>>>>>>> attached
> >>>>>>>>>
> >>>>>>>>> in
> >>>>>>>>>
> >>>>>>>>> the first email in this thread is what I want to
> >>>>>>>>>
> >>>>>>>>> avoid.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thank you for your feedback.
> >>>>>>>>>
> >>>>>>>>> Regards
> >>>>>>>>> Naba
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> >>>>>>>>>
> >>>>>>>>> klund@apache.org>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Whenever I submit a PR with multiple commits that I
> >>>>>>>>>
> >>>>>>>>> intend
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> rebase
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> develop, I always try to ensure that each commit
> >>>>>>>>>
> >>>>>>>>> stands
> >>>>>>>>>
> >>>>>>>>> alone
> >>>>>>>>>
> >>>>>>>>> as
> >>>>>>>>>
> >>>>>>>>> is
> >>>>>>>>>
> >>>>>>>>> (compiles and passes tests). Separating file
> >>>>>>>>>
> >>>>>>>>> renames
> >>>>>>>>>
> >>>>>>>>> and
> >>>>>>>>>
> >>>>>>>>> refactoring
> >>>>>>>>>
> >>>>>>>>> from
> >>>>>>>>>
> >>>>>>>>> behavior changes into different commits seems very
> >>>>>>>>>
> >>>>>>>>> valuable
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> me,
> >>>>>>>>>
> >>>>>>>>> and
> >>>>>>>>>
> >>>>>>>>> I've
> >>>>>>>>>
> >>>>>>>>> had trouble getting people to review PRs without
> >>>>>>>>>
> >>>>>>>>> this
> >>>>>>>>>
> >>>>>>>>> separation
> >>>>>>>>>
> >>>>>>>>> (but
> >>>>>>>>>
> >>>>>>>>> it
> >>>>>>>>>
> >>>>>>>>> could be squashed as it's merged to develop).
> >>>>>>>>>
> >>>>>>>>> It sounds to me like the real problem is (a) some
> >>>>>>>>>
> >>>>>>>>> PRs
> >>>>>>>>>
> >>>>>>>>> have
> >>>>>>>>>
> >>>>>>>>> multiple
> >>>>>>>>>
> >>>>>>>>> commits
> >>>>>>>>>
> >>>>>>>>> that don't compile or don't pass tests, and (b)
> >>>>>>>>>
> >>>>>>>>> some
> >>>>>>>>>
> >>>>>>>>> PRs
> >>>>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>> should
> >>>>>>>>>
> >>>>>>>>> be
> >>>>>>>>>
> >>>>>>>>> merged with squash are not (by accident most
> >>>>>>>>>
> >>>>>>>>> likely).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I can submit multiple PRs instead of one PR with
> >>>>>>>>>
> >>>>>>>>> multiple
> >>>>>>>>>
> >>>>>>>>> commits.
> >>>>>>>>>
> >>>>>>>>> So
> >>>>>>>>>
> >>>>>>>>> I'll
> >>>>>>>>>
> >>>>>>>>> change my response to -0 if that helps prevent
> >>>>>>>>>
> >>>>>>>>> commits
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> develop
> >>>>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>> don't compile or pass tests. Without preventing
> >>>>>>>>>
> >>>>>>>>> rebase
> >>>>>>>>>
> >>>>>>>>> or
> >>>>>>>>>
> >>>>>>>>> merge
> >>>>>>>>>
> >>>>>>>>> commits
> >>>>>>>>>
> >>>>>>>>> from github, I'm not sure how we can really enforce
> >>>>>>>>>
> >>>>>>>>> this
> >>>>>>>>>
> >>>>>>>>> or
> >>>>>>>>>
> >>>>>>>>> prevent
> >>>>>>>>>
> >>>>>>>>> (b)
> >>>>>>>>>
> >>>>>>>>> above.
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >>>>>>>>>
> >>>>>>>>> amurmann@pivotal.io>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> I wonder if Kirk's and Naba's statements are
> >>>>>>>>>
> >>>>>>>>> necessarily
> >>>>>>>>>
> >>>>>>>>> at
> >>>>>>>>>
> >>>>>>>>> odds.
> >>>>>>>>>
> >>>>>>>>> Make the change easy (warning: this may be hard),
> >>>>>>>>>
> >>>>>>>>> then
> >>>>>>>>>
> >>>>>>>>> make
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> easy
> >>>>>>>>>
> >>>>>>>>> change."
> >>>>>>>>>
> >>>>>>>>> -Kent Beck
> >>>>>>>>>
> >>>>>>>>> Following Kent Beck's advise might reasonably
> >>>>>>>>>
> >>>>>>>>> split
> >>>>>>>>>
> >>>>>>>>> into
> >>>>>>>>>
> >>>>>>>>> two
> >>>>>>>>>
> >>>>>>>>> commits.
> >>>>>>>>>
> >>>>>>>>> One
> >>>>>>>>>
> >>>>>>>>> refactor commit and a separate commit that
> >>>>>>>>>
> >>>>>>>>> introduces
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> actual
> >>>>>>>>>
> >>>>>>>>> change.
> >>>>>>>>>
> >>>>>>>>> They should be individually revertible and might
> >>>>>>>>>
> >>>>>>>>> be
> >>>>>>>>>
> >>>>>>>>> easier
> >>>>>>>>>
> >>>>>>>>> understood
> >>>>>>>>>
> >>>>>>>>> if
> >>>>>>>>>
> >>>>>>>>> split out. I vividly remember a change on our code
> >>>>>>>>>
> >>>>>>>>> base
> >>>>>>>>>
> >>>>>>>>> where
> >>>>>>>>>
> >>>>>>>>> someone
> >>>>>>>>>
> >>>>>>>>> did a
> >>>>>>>>>
> >>>>>>>>> huge amount of refactoring that resulted than in
> >>>>>>>>>
> >>>>>>>>> one
> >>>>>>>>>
> >>>>>>>>> parameter
> >>>>>>>>>
> >>>>>>>>> changing
> >>>>>>>>>
> >>>>>>>>> in
> >>>>>>>>>
> >>>>>>>>> order to get the desired functionality change. If
> >>>>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>> was
> >>>>>>>>>
> >>>>>>>>> in
> >>>>>>>>>
> >>>>>>>>> one
> >>>>>>>>>
> >>>>>>>>> commit,
> >>>>>>>>>
> >>>>>>>>> it would be hard to see the actual change. If
> >>>>>>>>>
> >>>>>>>>> split
> >>>>>>>>>
> >>>>>>>>> out,
> >>>>>>>>>
> >>>>>>>>> it's
> >>>>>>>>>
> >>>>>>>>> beautiful
> >>>>>>>>>
> >>>>>>>>> and
> >>>>>>>>>
> >>>>>>>>> crystal clear.
> >>>>>>>>>
> >>>>>>>>> I am unsure how that would be reflected in terms
> >>>>>>>>>
> >>>>>>>>> of
> >>>>>>>>>
> >>>>>>>>> JIRA
> >>>>>>>>>
> >>>>>>>>> ticket
> >>>>>>>>>
> >>>>>>>>> references.
> >>>>>>>>>
> >>>>>>>>> Usually we assume that if there is a commit with
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> ticket
> >>>>>>>>>
> >>>>>>>>> number,
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> issue is resolved. Maybe the key here is to create
> >>>>>>>>>
> >>>>>>>>> a
> >>>>>>>>>
> >>>>>>>>> separate
> >>>>>>>>>
> >>>>>>>>> refactoring
> >>>>>>>>>
> >>>>>>>>> ticket.
> >>>>>>>>>
> >>>>>>>>> Would that allow us to have our cake and eat it
> >>>>>>>>>
> >>>>>>>>> too?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> >>>>>>>>>
> >>>>>>>>> nnag@pivotal.io>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> It is to help with bisect operations when things
> >>>>>>>>>
> >>>>>>>>> start
> >>>>>>>>>
> >>>>>>>>> failing
> >>>>>>>>>
> >>>>>>>>> ...
> >>>>>>>>>
> >>>>>>>>> helps
> >>>>>>>>>
> >>>>>>>>> us
> >>>>>>>>>
> >>>>>>>>> it revert and build faster.
> >>>>>>>>> also with cherry picking features / fixes to
> >>>>>>>>>
> >>>>>>>>> previous
> >>>>>>>>>
> >>>>>>>>> versions
> >>>>>>>>>
> >>>>>>>>> .
> >>>>>>>>>
> >>>>>>>>> And keeping the git history clean with no
> >>>>>>>>>
> >>>>>>>>> unnecessary
> >>>>>>>>>
> >>>>>>>>> “merge
> >>>>>>>>>
> >>>>>>>>> commits”.
> >>>>>>>>>
> >>>>>>>>> Regards
> >>>>>>>>> Naba
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> >>>>>>>>>
> >>>>>>>>> klund@apache.org>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> -1 I really like to sometimes have more than 1
> >>>>>>>>>
> >>>>>>>>> commit
> >>>>>>>>>
> >>>>>>>>> in
> >>>>>>>>>
> >>>>>>>>> a
> >>>>>>>>>
> >>>>>>>>> PR
> >>>>>>>>>
> >>>>>>>>> and
> >>>>>>>>>
> >>>>>>>>> keep
> >>>>>>>>>
> >>>>>>>>> them
> >>>>>>>>>
> >>>>>>>>> separate when they merge to develop
> >>>>>>>>>
> >>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> >>>>>>>>>
> >>>>>>>>> nnag@pivotal.io>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Hi Geode Committers,
> >>>>>>>>>
> >>>>>>>>> A kind request for using squash commit instead
> >>>>>>>>>
> >>>>>>>>> of
> >>>>>>>>>
> >>>>>>>>> using
> >>>>>>>>>
> >>>>>>>>> merge.
> >>>>>>>>>
> >>>>>>>>> This will really help us in our bisect
> >>>>>>>>>
> >>>>>>>>> operations
> >>>>>>>>>
> >>>>>>>>> when a
> >>>>>>>>>
> >>>>>>>>> regression/flakiness in the product is
> >>>>>>>>>
> >>>>>>>>> introduced.
> >>>>>>>>>
> >>>>>>>>> We
> >>>>>>>>>
> >>>>>>>>> can
> >>>>>>>>>
> >>>>>>>>> automate
> >>>>>>>>>
> >>>>>>>>> and
> >>>>>>>>>
> >>>>>>>>> go
> >>>>>>>>>
> >>>>>>>>> through fewer commits faster, avoiding commits
> >>>>>>>>>
> >>>>>>>>> like
> >>>>>>>>>
> >>>>>>>>> "spotless
> >>>>>>>>>
> >>>>>>>>> fix"
> >>>>>>>>>
> >>>>>>>>> and
> >>>>>>>>>
> >>>>>>>>> "re-trigger precheck-in" or other minor commits
> >>>>>>>>>
> >>>>>>>>> in
> >>>>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>> merged
> >>>>>>>>>
> >>>>>>>>> branch.
> >>>>>>>>>
> >>>>>>>>> Also, please use the commit format : (helps us
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> know
> >>>>>>>>>
> >>>>>>>>> who
> >>>>>>>>>
> >>>>>>>>> worked
> >>>>>>>>>
> >>>>>>>>> on
> >>>>>>>>>
> >>>>>>>>> it,
> >>>>>>>>>
> >>>>>>>>> what is the history)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> * GEODE-xxxx: <brief intro >
> >>>>>>>>> * explanation line 1
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> explanation
> >>>>>>>>>
> >>>>>>>>> line
> >>>>>>>>>
> >>>>>>>>> 2*
> >>>>>>>>>
> >>>>>>>>> This is not a rule or anything, but a request
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>>
> >>>>>>>>> help
> >>>>>>>>>
> >>>>>>>>> out
> >>>>>>>>>
> >>>>>>>>> your
> >>>>>>>>>
> >>>>>>>>> fellow
> >>>>>>>>>
> >>>>>>>>> committers in quickly detecting a problem.
> >>>>>>>>>
> >>>>>>>>> For inspiration, we can look into Apache Kafka
> >>>>>>>>>
> >>>>>>>>> /
> >>>>>>>>>
> >>>>>>>>> Spark
> >>>>>>>>>
> >>>>>>>>> where
> >>>>>>>>>
> >>>>>>>>> they
> >>>>>>>>>
> >>>>>>>>> have
> >>>>>>>>>
> >>>>>>>>> a
> >>>>>>>>>
> >>>>>>>>> complete linear graph for their main branch
> >>>>>>>>>
> >>>>>>>>> HEAD
> >>>>>>>>>
> >>>>>>>>> [see
> >>>>>>>>>
> >>>>>>>>> attachment]
> >>>>>>>>>
> >>>>>>>>> Regards
> >>>>>>>>> Naba.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>> Ju@N
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Cheers
> >>>>>>>>>
> >>>>>>>>> Jinmei
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
--
Ju@N
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Mark Hanson <mh...@pivotal.io>.
This is the approach I am using as well Blake.
Thanks,
Mark
> On Jan 2, 2020, at 7:16 AM, Blake Bender <bb...@pivotal.io> wrote:
>
> That's not how I approach this sort of a change, and to my mind it feels
> sort of like that approach is asking for trouble. When I have a refactor
> plus a code change, I do the refactor on a branch, submit the PR, then
> branch off of *that* branch to do the feature work. This forces an
> ordering of the changes, but alleviates most/all of the conflicts. When
> the refactor PR is accepted, I rebase the feature work off of the new
> develop branch, and submit the second PR, usually without encountering any
> issues.
>
>
>
> On Wed, Jan 1, 2020 at 9:57 AM Aaron Lindsey <aa...@apache.org>
> wrote:
>
>>>
>>> Is it not the case currently? If I am working on a feature modifying
>> class
>>> X and another developer makes some refactoring changes on class X and
>>> pushes it to develop, won't I have to resolve the merge commits anyway.
>>
>>
>> Yes, you will always have to deal with resolving conflicts with other
>> people's changes. The scenario I was describing was me having to resolve
>> conflicts between my own 2 changes that modify the same files. If I make a
>> refactor commit and a fix commit as two separate PRs that are each based on
>> develop (i.e. they are independent PRs), after I merge the first one to
>> develop the second one will have merge conflicts. The simplest way to avoid
>> this is to put the commits in the same PR and use rebase-and-merge.
>>
>>
>>
>> On Tue, Dec 31, 2019 at 10:46 PM Owen Nichols <on...@pivotal.io> wrote:
>>
>>> It sounds like there is value in being able to deliver un-squashed PRs,
>> and
>>> we believe the richer commit message history outweighs any potential
>>> inconvenience to bisect operations (as Aaron pointed out, finer-grained
>>> commits should generally be to the benefit of bisect operations).
>>>
>>> We will leave all 3 merge options enabled in GitHub.
>>>
>>> On Tue, Dec 31, 2019 at 7:27 PM Dan Smith <ds...@pivotal.io> wrote:
>>>
>>>> I also tend to do the same workflow Aaron described - make a
>> refactoring
>>>> change to support a feature followed by the actual change I want to
>> make.
>>>> It makes the history a lot clearer because refactoring tends to touch a
>>> lot
>>>> of files, so it's nice to have those changes clearly marked as a
>>>> refactoring that should not change behavior.
>>>>
>>>> It's possible to do this as to separate PRs, but that drags out the
>>> process
>>>> because you have to get the first in merged before you create the
>> second.
>>>> That encourages bunching changes in a single squashed commit, which
>> makes
>>>> git blame less useful.
>>>>
>>>>
>>>> -Dan
>>>>
>>>> On Tue, Dec 31, 2019, 6:36 PM Nabarun Nag <nn...@apache.org> wrote:
>>>>
>>>>> Aaron ,
>>>>>
>>>>> Is it not the case currently? If I am working on a feature modifying
>>>> class
>>>>> X and another developer makes some refactoring changes on class X and
>>>>> pushes it to develop, won't I have to resolve the merge commits
>> anyway.
>>>>>
>>>>>
>>>>> Regards
>>>>> Naba
>>>>>
>>>>>
>>>>> On Tue, Dec 31, 2019 at 6:01 PM Aaron Lindsey <
>> aaronlindsey@apache.org
>>>>
>>>>> wrote:
>>>>>
>>>>>> Suppose I’m refactoring the same classes I’m touching for the
>>> feature.
>>>> I
>>>>>> do the refactoring on one branch and submit a PR for that. Then I
>>>>> implement
>>>>>> the feature on another branch which is based on develop and does
>> not
>>>> have
>>>>>> the refactoring changes since those are not merged yet. I’ll have
>> to
>>>>>> resolve conflicts on the second PR that I merge.
>>>>>>
>>>>>> Having interdependent PRs where one PR branch is based on another
>> PR
>>>>>> branch is not something I’ve tried. That requires more overhead in
>>>> having
>>>>>> to create more PRs and branches. And if you have N interdependent
>>> PRs,
>>>>> you
>>>>>> have to do N-1 merges each time a PR is merged to develop (to
>> update
>>>> the
>>>>>> other branches). It could be done, but is it worth the hassle?
>>>>>>
>>>>>> One more point about rebase-and-merge is that it seems like this
>>> would
>>>>>> make bisecting a failure easier since there would be smaller
>> commits.
>>>>>>
>>>>>> Aaron
>>>>>>
>>>>>>> On Dec 31, 2019, at 5:41 PM, Owen Nichols <on...@pivotal.io>
>>>> wrote:
>>>>>>>
>>>>>>> Can you elaborate on why you would have to deal with conflicts if
>>> the
>>>>>>> refactoring work was kept as a separate PR from the fix?
>>>>>>>
>>>>>>> As with many git workflows, there’s an easy way and a hard way to
>>>>> manage
>>>>>>> interdependent PRs (tl;dr only merge, never rebase!). I wonder if
>>>> this
>>>>>>> points out an opportunity for a “tips and tricks” page on the
>> Geode
>>>>> wiki.
>>>>>>>
>>>>>>> On Tue, Dec 31, 2019 at 5:22 PM Aaron Lindsey <
>>>> aaronlindsey@apache.org
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> -0.9
>>>>>>>>
>>>>>>>> I’m not in favor of the revised proposal that disallows
>>>>>> rebase-and-merge.
>>>>>>>> Say I am working on a PR and I have a refactor commit and
>> another
>>>>> commit
>>>>>>>> which implements a new feature. I don’t want those commits to
>> get
>>>>>> squashed
>>>>>>>> because that makes it hard to understand the diff. However, if I
>>>> make
>>>>>> those
>>>>>>>> commits as two separate PRs then I am going to have to deal with
>>>>>> conflicts.
>>>>>>>>
>>>>>>>> I’m not sure when we made it a rule that every commit in develop
>>> had
>>>>> to
>>>>>>>> compile and pass tests. I know we implemented a rule that all
>> PRs
>>>> had
>>>>> to
>>>>>>>> pass certain checks, but I never thought that rule implied all
>>>> commits
>>>>>> had
>>>>>>>> to pass those checks.
>>>>>>>>
>>>>>>>> In general I just don’t see the problem with rebase-and-merge
>> and
>>>> this
>>>>>>>> feels like an unnecessary restriction, but I will go with it if
>>>> that’s
>>>>>> what
>>>>>>>> everyone wants to do.
>>>>>>>>
>>>>>>>> Aaron
>>>>>>>>
>>>>>>>>> On Dec 31, 2019, at 3:09 PM, Owen Nichols <onichols@pivotal.io
>>>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> To recap, this proposal is now revised to remove 2 of the 3
>> merge
>>>>>> options
>>>>>>>>> from GitHub, leaving only Squash and Merge. PR #4513
>>>>>>>>> <https://github.com/apache/geode/pull/4513> serves as an
>> exhibit
>>>> of
>>>>>>>> what is
>>>>>>>>> proposed (it is not to be merged unless discussion leads to
>>>> consensus
>>>>>>>> and a
>>>>>>>>> successful vote). Please use the dev list (not the PR) for all
>>>>>>>> discussion
>>>>>>>>> (and voting, if we get that far).
>>>>>>>>>
>>>>>>>>> Squash and merge is already used almost exclusively by the
>> Geode
>>>>>>>> community,
>>>>>>>>> with any exceptions tending to be accidental more often than
>>>>>> intentional.
>>>>>>>>> However, some have raised the concern that implementing this
>>>>>> restriction
>>>>>>>>> could result in harm or wasted time. Can someone give an
>> example
>>>> of
>>>>> a
>>>>>>>> such
>>>>>>>>> a scenario?
>>>>>>>>>
>>>>>>>>> It seems there is a divide here between junior and senior
>>> community
>>>>>>>>> members. Newer committers appreciate additional guardrails to
>>>>> protect
>>>>>>>> them
>>>>>>>>> from accidentally doing the wrong thing, while those with more
>>>>>> experience
>>>>>>>>> want to be able to work unencumbered by restrictions of any
>> kind.
>>>>>>>>>
>>>>>>>>> Our welcome email to new committers states “We like to work on
>>>> trust
>>>>>>>> rather
>>>>>>>>> than unnecessary constraints...Being a committer enables you to
>>>> more
>>>>>>>> easily
>>>>>>>>> make changes without needing to go through the patch submission
>>>>>> process”.
>>>>>>>>> I can see this as an argument against this proposal (perhaps
>> even
>>>> an
>>>>>>>>> argument against any form of branch protection).
>>>>>>>>>
>>>>>>>>> In the scheme of things, this proposal makes very little
>>>> difference.
>>>>>>>> There
>>>>>>>>> are still other ways to get non-compiling commits onto develop
>>>> (e.g.
>>>>>>>>> waiting a long time between running PR checks and merging to
>>>>> develop).
>>>>>>>>> What’s more important is working well together as a community.
>>> So,
>>>>>>>> perhaps
>>>>>>>>> what’s best for the community is to encourage working on trust
>>>> rather
>>>>>>>> than
>>>>>>>>> unnecessary constraints.
>>>>>>>>>
>>>>>>>>> -Owen
>>>>>>>>>
>>>>>>>>> On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org>
>>> wrote:
>>>>>>>>>
>>>>>>>>> I'm happy to file multiple PRs when I need to merge multiple
>>>> commits
>>>>> to
>>>>>>>>> develop.
>>>>>>>>>
>>>>>>>>> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <
>> mhanson@pivotal.io>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> This change to disable all but squash-merge would be really
>> easy
>>> to
>>>>>>>>> revert. How about we try it for a while and see? If people
>> decide
>>>> it
>>>>> is
>>>>>>>>> really limiting them, we can change it back. Let’s do it for 1
>>>> month
>>>>>> and
>>>>>>>>> see how it goes. Does that sound reasonable?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Mark
>>>>>>>>>
>>>>>>>>> On Dec 30, 2019, at 5:25 PM, Owen Nichols <onichols@pivotal.io
>>>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Given that we adopted <
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
>>>>>>>>>>
>>>>>>>>> and still wish to continue <
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
>>>>>>>>>>
>>>>>>>>> having branch protection rules to ensure every commit landing
>> in
>>>>>> develop
>>>>>>>>> has passed the required PR checks, it seems like that decision
>>>> alone
>>>>>>>>> mandates that we disable all merge mechanisms other than
>>>>>>>> squash-and-merge.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Allowing merge commits or rebase merges bypasses branch
>>> protection
>>>>> for
>>>>>>>>>
>>>>>>>>> all commits other than the final one in the merge or rebase
>> set.
>>>>> Given
>>>>>>>>> that we decided <
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
>>>>>>>>>>
>>>>>>>>> that bypassing PR checks should never be allowed, keeping this
>>>>> loophole
>>>>>>>>> open seems untenable.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is not just hypothetical — this loophole is causing real
>>>>> problems.
>>>>>>>>>
>>>>>>>>> We now have commits on develop that don’t compile. For
>> example:
>>>>>>>>>
>>>>>>>>> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
>>>>>>>>> ./gradlew devBuild
>>>>>>>>> ...spotlessJava FAILED
>>>>>>>>> We implemented branch protections to make this impossible,
>> right?
>>>>>>>>>
>>>>>>>>> We can very easily close this loophole by disabling all but the
>>>>>>>>>
>>>>>>>>> Squash&Merge button for PRs. This will not make more work for
>>> any
>>>>>>>>> developer. If you want to get multiple commits onto develop,
>>>> simply
>>>>>>>> submit
>>>>>>>>> each as a separate PR — that is the only way to assure that
>>>> required
>>>>> PR
>>>>>>>>> checks have passed for each.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On the other hand, if we as a Geode community feel strongly
>> that
>>>>>>>>>
>>>>>>>>> bypassing branch protection via merge commits and rebase
>> commits
>>> is
>>>>>>>>> important to allow, why not also allow arbitrary overrides (or
>>> get
>>>>> rid
>>>>>> of
>>>>>>>>> branch protection entirely)?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Owen
>>>>>>>>>
>>>>>>>>> On Dec 20, 2019, at 12:31 PM, Blake Bender <bbender@pivotal.io
>>>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Just FWIW, the situation described of having multiple commits
>> in
>>> a
>>>>>>>>>
>>>>>>>>> single
>>>>>>>>>
>>>>>>>>> PR with separate associated JIRA tickets is still kind of
>>>>> problematic.
>>>>>>>>>
>>>>>>>>> It
>>>>>>>>>
>>>>>>>>> could well be the case that the commits are interdependent,
>> thus
>>>> when
>>>>>>>>> bisecting etc it's still not possible to revert the fix for a
>>>> single
>>>>>>>>> bug/feature/whatever atomically. It's all good, though, I'm
>>>>> satisfied
>>>>>>>>>
>>>>>>>>> no
>>>>>>>>>
>>>>>>>>> one's forcing me to adopt practice I'm opposed to. Apologies
>> for
>>>>>>>>>
>>>>>>>>> getting
>>>>>>>>>
>>>>>>>>> my feathers a little ruffled, or if I ruffled anyone else's in
>>>>> return.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Blake
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Dan,
>>>>>>>>>
>>>>>>>>> When we do squash merge all the commit messages are preserved
>> and
>>>>> also
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> co-authored tag works when we do squash merge.
>>>>>>>>> So the authorship and history are preserved.
>>>>>>>>>
>>>>>>>>> In my own personal experience and reverts and pinpointing
>>>> regression
>>>>>>>>> failures are tough when the commits are spread out. Also,
>> reverts
>>>> are
>>>>>>>>> easier when it is just one commit while we are bisecting
>>> failures.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Naba
>>>>>>>>>
>>>>>>>>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I'll change to -0.
>>>>>>>>>
>>>>>>>>> I think merge commits are a nice way to record history in some
>>>> cases,
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> can also be a way to avoid messy conflicts that come with
>> rebase.
>>>>>>>>>
>>>>>>>>> Merge
>>>>>>>>>
>>>>>>>>> commits also preserve authorship of commits (compared to
>>>>>>>>>
>>>>>>>>> squash-merge),
>>>>>>>>>
>>>>>>>>> which I think is valuable as an open source community that is
>>>> trying
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> keep track of outside contributions.
>>>>>>>>>
>>>>>>>>> That said, if the rest of y'all feel it will help to disable
>> the
>>>>>>>>>
>>>>>>>>> button,
>>>>>>>>>
>>>>>>>>> I
>>>>>>>>>
>>>>>>>>> won't stand in the way.
>>>>>>>>>
>>>>>>>>> -Dan
>>>>>>>>>
>>>>>>>>> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <
>>> abaker@pivotal.io>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Whether we are talking about the geode/ repository or the
>>>>>>>>>
>>>>>>>>> geode-native/
>>>>>>>>>
>>>>>>>>> repository we are all one GEODE community.
>>>>>>>>>
>>>>>>>>> The idea of a native client team may matter in some contexts
>> but
>>> in
>>>>>>>>>
>>>>>>>>> this
>>>>>>>>>
>>>>>>>>> space we are all GEODE contributors.
>>>>>>>>>
>>>>>>>>> Adopting a common approach across our repos will make it easier
>>> for
>>>>>>>>>
>>>>>>>>> new
>>>>>>>>>
>>>>>>>>> contributors to engage, learn our norms, and join our efforts.
>>>>>>>>>
>>>>>>>>> $0.02,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bbender@pivotal.io
>>>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is this a policy the native client team must abide by, as well?
>>> It
>>>>>>>>>
>>>>>>>>> varies
>>>>>>>>>
>>>>>>>>> slightly with what we've been doing, and all other things being
>>>>>>>>>
>>>>>>>>> equal I
>>>>>>>>>
>>>>>>>>> see
>>>>>>>>>
>>>>>>>>> no reason for us to change that. If I am to have any measure
>> of
>>>>>>>>>
>>>>>>>>> control
>>>>>>>>>
>>>>>>>>> over the nc repository, I will definitely enforce a 1:1
>>>>>>>>>
>>>>>>>>> correspondence
>>>>>>>>>
>>>>>>>>> between commits to develop and JIRA tickets. IMO, if your
>>>>>>>>>
>>>>>>>>> refactoring
>>>>>>>>>
>>>>>>>>> in a
>>>>>>>>>
>>>>>>>>> PR is sufficiently large or complex that it's difficult to
>> tease
>>> it
>>>>>>>>>
>>>>>>>>> out
>>>>>>>>>
>>>>>>>>> from the bug you're fixing or feature you're implementing, it
>>>> merits
>>>>>>>>>
>>>>>>>>> its
>>>>>>>>>
>>>>>>>>> own JIRA ticket and a separate PR. If your "actual" fix then
>>>>>>>>>
>>>>>>>>> becomes
>>>>>>>>>
>>>>>>>>> dependent on the refactored code, that's a price I'm willing to
>>> pay
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> keep
>>>>>>>>>
>>>>>>>>> history clean.
>>>>>>>>>
>>>>>>>>> On the other hand, I see no real value in squashing to a single
>>>>>>>>>
>>>>>>>>> commit
>>>>>>>>>
>>>>>>>>> prior to submitting a PR, since your view of the changes on
>>> GitHub
>>>>>>>>>
>>>>>>>>> is
>>>>>>>>>
>>>>>>>>> essentially the same either way. We haven't enforced this on
>> the
>>>> nc
>>>>>>>>>
>>>>>>>>> repo,
>>>>>>>>>
>>>>>>>>> and I'd prefer to keep it that way.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Blake
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <
>> jiliao@pivotal.io>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Merge commit is the new contributor's default setting. When we
>>> are
>>>>>>>>>
>>>>>>>>> merging
>>>>>>>>>
>>>>>>>>> new contributor's PR, since we are so used to THINKING
>>>>>>>>>
>>>>>>>>> "squash-and-merge"
>>>>>>>>>
>>>>>>>>> is the default, we forgot to check what the button really says
>>> when
>>>>>>>>>
>>>>>>>>> we
>>>>>>>>>
>>>>>>>>> are
>>>>>>>>>
>>>>>>>>> merging other people's PR.
>>>>>>>>>
>>>>>>>>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
>>>>>>>>>
>>>>>>>>> eburghardt@pivotal.io>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I'm a proponent of using squash-and-merge, and once a person
>> has
>>>>>>>>>
>>>>>>>>> chosen
>>>>>>>>>
>>>>>>>>> this option once it comes up by default afterwards...
>>>>>>>>>
>>>>>>>>> Owen, I don't think you have consensus to put forth this PR,
>>>>>>>>>
>>>>>>>>> there
>>>>>>>>>
>>>>>>>>> are
>>>>>>>>>
>>>>>>>>> -1s
>>>>>>>>>
>>>>>>>>> above... (early voting)
>>>>>>>>>
>>>>>>>>> maybe we'll be better off socializing the norm of
>>> squash-and-merge
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> gaining a natural consensus that way...
>>>>>>>>>
>>>>>>>>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
>>>>>>>>>
>>>>>>>>> onichols@pivotal.io
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The proposed action manifests as a commit to the Geode git
>>>>>>>>>
>>>>>>>>> repository,
>>>>>>>>>
>>>>>>>>> so
>>>>>>>>>
>>>>>>>>> a PR is an acceptable vehicle for voting in this case.
>>>>>>>>>
>>>>>>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
>>>>>>>>>
>>>>>>>>> bschuchardt@pivotal.io>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I see a lot of plus-ones and a "voting deadline" on this
>> DISCUSS
>>>>>>>>>
>>>>>>>>> thread
>>>>>>>>>
>>>>>>>>> and a request to "vote" using a PR. This all seems out of
>> order
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> me.
>>>>>>>>>
>>>>>>>>> Our votes are supposed to be on the email list, aren't they?
>> and
>>>>>>>>>
>>>>>>>>> I
>>>>>>>>>
>>>>>>>>> haven't
>>>>>>>>>
>>>>>>>>> seen a VOTE request.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
>>>>>>>>>
>>>>>>>>> onichols@pivotal.io
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Based on the feedback so far, I will amend the proposal to
>>>>>>>>>
>>>>>>>>> drop
>>>>>>>>>
>>>>>>>>> item
>>>>>>>>>
>>>>>>>>> 2).
>>>>>>>>>
>>>>>>>>> Therefore, the current ability to create merge commits using
>>>>>>>>>
>>>>>>>>> command-line
>>>>>>>>>
>>>>>>>>> git will remain available.
>>>>>>>>>
>>>>>>>>> The proposal as amended is now:
>>>>>>>>>
>>>>>>>>> Change GitHub settings to make "Squash and merge" the default
>>>>>>>>> (by removing “Create a merge commit” option).
>>>>>>>>>
>>>>>>>>> Update the PR template to change the text "Is your initial
>>>>>>>>>
>>>>>>>>> contribution
>>>>>>>>>
>>>>>>>>> a single, squashed commit” to “Is your initial contribution
>>>>>>>>>
>>>>>>>>> squashed
>>>>>>>>>
>>>>>>>>> for
>>>>>>>>>
>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
>>>>>>>>>
>>>>>>>>> commit
>>>>>>>>>
>>>>>>>>> plus a
>>>>>>>>>
>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As Naba suggested, we can try it, and if we don’t like it,
>>>>>>>>>
>>>>>>>>> it’s
>>>>>>>>>
>>>>>>>>> simple
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> revert.
>>>>>>>>>
>>>>>>>>> I’ve create a PR for the proposed change here:
>>>>>>>>> https://github.com/apache/geode/pull/4513
>>>>>>>>>
>>>>>>>>> Please use the PR to vote for against this proposal. It will
>>>>>>>>>
>>>>>>>>> not
>>>>>>>>>
>>>>>>>>> be
>>>>>>>>>
>>>>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>> time)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
>>>>>>>>>
>>>>>>>>> onichols@pivotal.io>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Bruce, this proposal will not waste a single second of
>>>>>>>>>
>>>>>>>>> your
>>>>>>>>>
>>>>>>>>> time. It
>>>>>>>>>
>>>>>>>>> just prevents people from accidentally pressing a button
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>> we
>>>>>>>>>
>>>>>>>>> have
>>>>>>>>>
>>>>>>>>> already agreed should never be pressed, but because we never
>>>>>>>>>
>>>>>>>>> configured
>>>>>>>>>
>>>>>>>>> our
>>>>>>>>>
>>>>>>>>> GitHub to match our stated policy, is currently the default.
>>>>>>>>>
>>>>>>>>> However, it will save a lot of time and frustration for
>>>>>>>>>
>>>>>>>>> anyone
>>>>>>>>>
>>>>>>>>> needing
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> bisect failures, revert, or cherry-pick changes, which has
>>>>>>>>>
>>>>>>>>> merit
>>>>>>>>>
>>>>>>>>> even if
>>>>>>>>>
>>>>>>>>> you personally never do any of those three things.
>>>>>>>>>
>>>>>>>>> Please start a separate thread if you would like to revisit
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> community
>>>>>>>>>
>>>>>>>>> decision to require passing PR checks.
>>>>>>>>>
>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
>>>>>>>>>
>>>>>>>>> bschuchardt@pivotal.io>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I agree with Jake. I would go further by saying that I see
>>>>>>>>>
>>>>>>>>> very
>>>>>>>>>
>>>>>>>>> little
>>>>>>>>>
>>>>>>>>> merit in this proposal. I think we're getting more and more
>>>>>>>>>
>>>>>>>>> bureaucratic
>>>>>>>>>
>>>>>>>>> in our process and that it stifles productivity. I was
>>>>>>>>>
>>>>>>>>> recently
>>>>>>>>>
>>>>>>>>> forced
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> spend three days fixing tests in which I had changed an
>>>>>>>>>
>>>>>>>>> import
>>>>>>>>>
>>>>>>>>> statement
>>>>>>>>>
>>>>>>>>> before they would pass stress testing. I'm glad the tests
>>>>>>>>>
>>>>>>>>> now
>>>>>>>>>
>>>>>>>>> pass
>>>>>>>>>
>>>>>>>>> reliably but I was very frustrated by the process.
>>>>>>>>>
>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>>>>>>>
>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> flat
>>>>>>>>>
>>>>>>>>> out
>>>>>>>>>
>>>>>>>>> prevent things that should be self policing is annoying.
>>>>>>>>>
>>>>>>>>> This
>>>>>>>>>
>>>>>>>>> PR
>>>>>>>>>
>>>>>>>>> review
>>>>>>>>>
>>>>>>>>> lock we have had already cost us valuable time waiting for
>>>>>>>>>
>>>>>>>>> PR
>>>>>>>>>
>>>>>>>>> pipelines
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> pass that have no relevance to the commit, like CI work: I’d
>>>>>>>>>
>>>>>>>>> hat
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> see
>>>>>>>>>
>>>>>>>>> yet
>>>>>>>>>
>>>>>>>>> another process enforced that Kees us from getting work done
>>>>>>>>>
>>>>>>>>> when
>>>>>>>>>
>>>>>>>>> necessary.
>>>>>>>>>
>>>>>>>>> -Jake
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <
>>>>>>>>>
>>>>>>>>> dsmith@pivotal.io
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -1 to (1) and (2).
>>>>>>>>>
>>>>>>>>> I think merge commits are appropriate in certain
>>>>>>>>>
>>>>>>>>> circumstances,
>>>>>>>>>
>>>>>>>>> so I
>>>>>>>>>
>>>>>>>>> don't
>>>>>>>>>
>>>>>>>>> think we should make a blanket restriction. In fact I
>>>>>>>>>
>>>>>>>>> think
>>>>>>>>>
>>>>>>>>> our
>>>>>>>>>
>>>>>>>>> release
>>>>>>>>>
>>>>>>>>> process involves some merges.
>>>>>>>>>
>>>>>>>>> I think setting standards on what is reasonable to be an
>>>>>>>>>
>>>>>>>>> individual
>>>>>>>>>
>>>>>>>>> commit
>>>>>>>>>
>>>>>>>>> will do a lot more to clean up our history than blocking
>>>>>>>>>
>>>>>>>>> merges.
>>>>>>>>>
>>>>>>>>> We'd
>>>>>>>>>
>>>>>>>>> rather not see commits like "Spotless Apply" in the
>>>>>>>>>
>>>>>>>>> history,
>>>>>>>>>
>>>>>>>>> but
>>>>>>>>>
>>>>>>>>> if
>>>>>>>>>
>>>>>>>>> reasonably separate and well written commits come in as
>>>>>>>>>
>>>>>>>>> part
>>>>>>>>>
>>>>>>>>> of
>>>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>> merge, I
>>>>>>>>>
>>>>>>>>> think that's fine.
>>>>>>>>>
>>>>>>>>> -Dan
>>>>>>>>>
>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
>>>>>>>>>
>>>>>>>>> jiliao@pivotal.io
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
>>>>>>>>>
>>>>>>>>> onichols@pivotal.io
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I’d like to advance this topic from an informal
>>>>>>>>>
>>>>>>>>> request/discussion
>>>>>>>>>
>>>>>>>>> to a
>>>>>>>>>
>>>>>>>>> discussion of a concrete proposal.
>>>>>>>>>
>>>>>>>>> To recap, it sounds like there is general agreement
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>> commit
>>>>>>>>>
>>>>>>>>> history
>>>>>>>>>
>>>>>>>>> on
>>>>>>>>>
>>>>>>>>> develop should be linear (no merge commits), and that
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> biggest
>>>>>>>>>
>>>>>>>>> obstacle
>>>>>>>>>
>>>>>>>>> to this is that the PR merge button in GitHub creates a
>>>>>>>>>
>>>>>>>>> merge
>>>>>>>>>
>>>>>>>>> commit
>>>>>>>>>
>>>>>>>>> by
>>>>>>>>>
>>>>>>>>> default.
>>>>>>>>>
>>>>>>>>> I propose the following changes:
>>>>>>>>> 1) Change GitHub settings to remove the ability to
>>>>>>>>>
>>>>>>>>> create
>>>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>> merge
>>>>>>>>>
>>>>>>>>> commit.
>>>>>>>>>
>>>>>>>>> This will make Squash & Merge the default.
>>>>>>>>>
>>>>>>>>> 2) Change GitHub settings to require linear history on
>>>>>>>>>
>>>>>>>>> develop.
>>>>>>>>>
>>>>>>>>> This
>>>>>>>>>
>>>>>>>>> prevents merge commits via command-line (not
>>>>>>>>>
>>>>>>>>> recommended,
>>>>>>>>>
>>>>>>>>> but
>>>>>>>>>
>>>>>>>>> wiki
>>>>>>>>>
>>>>>>>>> still
>>>>>>>>>
>>>>>>>>> has instructions for merging PRs this way).
>>>>>>>>>
>>>>>>>>> 3) Update the PR template to change the text "Is your
>>>>>>>>>
>>>>>>>>> initial
>>>>>>>>>
>>>>>>>>> contribution
>>>>>>>>>
>>>>>>>>> a single, squashed commit” to “Is your initial
>>>>>>>>>
>>>>>>>>> contribution
>>>>>>>>>
>>>>>>>>> squashed
>>>>>>>>>
>>>>>>>>> for
>>>>>>>>>
>>>>>>>>> ease of review (e.g. a single commit, or a
>>>>>>>>>
>>>>>>>>> ‘refactoring’
>>>>>>>>>
>>>>>>>>> commit
>>>>>>>>>
>>>>>>>>> plus
>>>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>
>>>>>>>>> For clarity, I am proposing no-change in the following
>>>>>>>>>
>>>>>>>>> areas:
>>>>>>>>>
>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have
>>>>>>>>>
>>>>>>>>> been
>>>>>>>>>
>>>>>>>>> structured to
>>>>>>>>>
>>>>>>>>> benefit from it (this can make it easier in a bisect to
>>>>>>>>>
>>>>>>>>> see
>>>>>>>>>
>>>>>>>>> whether
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> refactoring or the “fix” broke something).
>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>> squashing
>>>>>>>>>
>>>>>>>>> is
>>>>>>>>>
>>>>>>>>> preferred].
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please comment via this email thread.
>>>>>>>>> -Owen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
>>>>>>>>>
>>>>>>>>> klund@apache.org>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think it's already resolved Udo ;)
>>>>>>>>>
>>>>>>>>> Here's the problem, if I fixup a dunit test by
>>>>>>>>>
>>>>>>>>> removing
>>>>>>>>>
>>>>>>>>> all
>>>>>>>>>
>>>>>>>>> uses
>>>>>>>>>
>>>>>>>>> of
>>>>>>>>>
>>>>>>>>> "this."
>>>>>>>>>
>>>>>>>>> and I rename the dunit test, then git doesn't remember
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> file
>>>>>>>>>
>>>>>>>>> is a
>>>>>>>>>
>>>>>>>>> rename -- it forever afterwards interprets it as a new
>>>>>>>>>
>>>>>>>>> file
>>>>>>>>>
>>>>>>>>> that I
>>>>>>>>>
>>>>>>>>> created
>>>>>>>>>
>>>>>>>>> if I touch more than 50% of the lines (which "this."
>>>>>>>>>
>>>>>>>>> can
>>>>>>>>>
>>>>>>>>> easily
>>>>>>>>>
>>>>>>>>> do). If
>>>>>>>>>
>>>>>>>>> we
>>>>>>>>>
>>>>>>>>> squash two commits: the rename and the cleanup of that
>>>>>>>>>
>>>>>>>>> dunit
>>>>>>>>>
>>>>>>>>> test
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> then
>>>>>>>>>
>>>>>>>>> we effectively lose the history of that file and it
>>>>>>>>>
>>>>>>>>> shows
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>> I
>>>>>>>>>
>>>>>>>>> created
>>>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>> new file.
>>>>>>>>>
>>>>>>>>> Also for the record, I've been working on Geode since
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> beginning
>>>>>>>>>
>>>>>>>>> and I
>>>>>>>>>
>>>>>>>>> was never made aware of this change in our process. I
>>>>>>>>>
>>>>>>>>> never
>>>>>>>>>
>>>>>>>>> voted
>>>>>>>>>
>>>>>>>>> on
>>>>>>>>>
>>>>>>>>> it.
>>>>>>>>>
>>>>>>>>> I'm not a big fan of changing various details in our
>>>>>>>>>
>>>>>>>>> process
>>>>>>>>>
>>>>>>>>> every
>>>>>>>>>
>>>>>>>>> single
>>>>>>>>>
>>>>>>>>> week. It's very easy to miss these discussions unless
>>>>>>>>>
>>>>>>>>> someone
>>>>>>>>>
>>>>>>>>> points it
>>>>>>>>>
>>>>>>>>> out
>>>>>>>>>
>>>>>>>>> to me.
>>>>>>>>>
>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>>>>>>>>>
>>>>>>>>> ukohlmeyer@pivotal.io>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I'm not sure what this discussion is about... WE, as
>>>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>> community,
>>>>>>>>>
>>>>>>>>> have
>>>>>>>>>
>>>>>>>>> agreed in common practices, in two place no less...
>>>>>>>>>
>>>>>>>>> 1) Quoting our PR template
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For all changes:
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
>>>>>>>>>
>>>>>>>>> referenced
>>>>>>>>>
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>> the commit message?
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Has your PR been rebased against the latest commit
>>>>>>>>>
>>>>>>>>> within
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> target
>>>>>>>>>
>>>>>>>>> branch (typically|develop|)?
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> ***Is your initial contribution a single, squashed
>>>>>>>>>
>>>>>>>>> commit?*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Have you written or updated unit tests to verify your
>>>>>>>>>
>>>>>>>>> changes?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> If adding new dependencies to the code, are these
>>>>>>>>>
>>>>>>>>> dependencies
>>>>>>>>>
>>>>>>>>> licensed in a way that is compatible for inclusion
>>>>>>>>>
>>>>>>>>> underASF
>>>>>>>>>
>>>>>>>>> 2.0
>>>>>>>>>
>>>>>>>>> <
>>>>>>>>>
>>>>>>>>> http://www.apache.org/legal/resolved.html#category-a
>>>>>>>>>
>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On our PR template we call out that the initial PR
>>>>>>>>>
>>>>>>>>> commit
>>>>>>>>>
>>>>>>>>> should
>>>>>>>>>
>>>>>>>>> be
>>>>>>>>>
>>>>>>>>> squashed.
>>>>>>>>>
>>>>>>>>> 2)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>
>>>>>>>>> <
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>
>>>>>>>>> -- See "Accepting a PR Using the Command Line" -
>>>>>>>>>
>>>>>>>>> Point
>>>>>>>>>
>>>>>>>>> #3.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @Kirk, if each of your commits "stands alone", I
>>>>>>>>>
>>>>>>>>> commend
>>>>>>>>>
>>>>>>>>> you
>>>>>>>>>
>>>>>>>>> on
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> diligence, but in reality, they should either then be
>>>>>>>>>
>>>>>>>>> stand
>>>>>>>>>
>>>>>>>>> alone
>>>>>>>>>
>>>>>>>>> PR's
>>>>>>>>>
>>>>>>>>> or just extra work created for yourself.
>>>>>>>>>
>>>>>>>>> If we want to change the way we have agreed upon we
>>>>>>>>>
>>>>>>>>> submit/commit/merge
>>>>>>>>>
>>>>>>>>> changes back into develop... Then this is another
>>>>>>>>>
>>>>>>>>> discussion
>>>>>>>>>
>>>>>>>>> thread,
>>>>>>>>>
>>>>>>>>> until then, I think we should all remind ourselves on
>>>>>>>>>
>>>>>>>>> our
>>>>>>>>>
>>>>>>>>> agreed
>>>>>>>>>
>>>>>>>>> contributions code of conduct.
>>>>>>>>>
>>>>>>>>> --Udo
>>>>>>>>>
>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>>>
>>>>>>>>> Kirk, I believe that creating a Pull Request with
>>>>>>>>>
>>>>>>>>> multiple
>>>>>>>>>
>>>>>>>>> commits is
>>>>>>>>>
>>>>>>>>> ok.
>>>>>>>>>
>>>>>>>>> It's just in the end that when it's being pushed to
>>>>>>>>>
>>>>>>>>> develop
>>>>>>>>>
>>>>>>>>> branch,
>>>>>>>>>
>>>>>>>>> it
>>>>>>>>>
>>>>>>>>> needs to be squash merged. I believe that is what
>>>>>>>>>
>>>>>>>>> you
>>>>>>>>>
>>>>>>>>> have
>>>>>>>>>
>>>>>>>>> mentioned
>>>>>>>>>
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>>> If you can see in the first screenshot comparison
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>> I
>>>>>>>>>
>>>>>>>>> had
>>>>>>>>>
>>>>>>>>> attached
>>>>>>>>>
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>> the first email in this thread is what I want to
>>>>>>>>>
>>>>>>>>> avoid.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thank you for your feedback.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Naba
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
>>>>>>>>>
>>>>>>>>> klund@apache.org>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Whenever I submit a PR with multiple commits that I
>>>>>>>>>
>>>>>>>>> intend
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> rebase
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> develop, I always try to ensure that each commit
>>>>>>>>>
>>>>>>>>> stands
>>>>>>>>>
>>>>>>>>> alone
>>>>>>>>>
>>>>>>>>> as
>>>>>>>>>
>>>>>>>>> is
>>>>>>>>>
>>>>>>>>> (compiles and passes tests). Separating file
>>>>>>>>>
>>>>>>>>> renames
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> refactoring
>>>>>>>>>
>>>>>>>>> from
>>>>>>>>>
>>>>>>>>> behavior changes into different commits seems very
>>>>>>>>>
>>>>>>>>> valuable
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> me,
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> I've
>>>>>>>>>
>>>>>>>>> had trouble getting people to review PRs without
>>>>>>>>>
>>>>>>>>> this
>>>>>>>>>
>>>>>>>>> separation
>>>>>>>>>
>>>>>>>>> (but
>>>>>>>>>
>>>>>>>>> it
>>>>>>>>>
>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>
>>>>>>>>> It sounds to me like the real problem is (a) some
>>>>>>>>>
>>>>>>>>> PRs
>>>>>>>>>
>>>>>>>>> have
>>>>>>>>>
>>>>>>>>> multiple
>>>>>>>>>
>>>>>>>>> commits
>>>>>>>>>
>>>>>>>>> that don't compile or don't pass tests, and (b)
>>>>>>>>>
>>>>>>>>> some
>>>>>>>>>
>>>>>>>>> PRs
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>> should
>>>>>>>>>
>>>>>>>>> be
>>>>>>>>>
>>>>>>>>> merged with squash are not (by accident most
>>>>>>>>>
>>>>>>>>> likely).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I can submit multiple PRs instead of one PR with
>>>>>>>>>
>>>>>>>>> multiple
>>>>>>>>>
>>>>>>>>> commits.
>>>>>>>>>
>>>>>>>>> So
>>>>>>>>>
>>>>>>>>> I'll
>>>>>>>>>
>>>>>>>>> change my response to -0 if that helps prevent
>>>>>>>>>
>>>>>>>>> commits
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> develop
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>> don't compile or pass tests. Without preventing
>>>>>>>>>
>>>>>>>>> rebase
>>>>>>>>>
>>>>>>>>> or
>>>>>>>>>
>>>>>>>>> merge
>>>>>>>>>
>>>>>>>>> commits
>>>>>>>>>
>>>>>>>>> from github, I'm not sure how we can really enforce
>>>>>>>>>
>>>>>>>>> this
>>>>>>>>>
>>>>>>>>> or
>>>>>>>>>
>>>>>>>>> prevent
>>>>>>>>>
>>>>>>>>> (b)
>>>>>>>>>
>>>>>>>>> above.
>>>>>>>>>
>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>>>>>>
>>>>>>>>> amurmann@pivotal.io>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I wonder if Kirk's and Naba's statements are
>>>>>>>>>
>>>>>>>>> necessarily
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>>
>>>>>>>>> odds.
>>>>>>>>>
>>>>>>>>> Make the change easy (warning: this may be hard),
>>>>>>>>>
>>>>>>>>> then
>>>>>>>>>
>>>>>>>>> make
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> easy
>>>>>>>>>
>>>>>>>>> change."
>>>>>>>>>
>>>>>>>>> -Kent Beck
>>>>>>>>>
>>>>>>>>> Following Kent Beck's advise might reasonably
>>>>>>>>>
>>>>>>>>> split
>>>>>>>>>
>>>>>>>>> into
>>>>>>>>>
>>>>>>>>> two
>>>>>>>>>
>>>>>>>>> commits.
>>>>>>>>>
>>>>>>>>> One
>>>>>>>>>
>>>>>>>>> refactor commit and a separate commit that
>>>>>>>>>
>>>>>>>>> introduces
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> actual
>>>>>>>>>
>>>>>>>>> change.
>>>>>>>>>
>>>>>>>>> They should be individually revertible and might
>>>>>>>>>
>>>>>>>>> be
>>>>>>>>>
>>>>>>>>> easier
>>>>>>>>>
>>>>>>>>> understood
>>>>>>>>>
>>>>>>>>> if
>>>>>>>>>
>>>>>>>>> split out. I vividly remember a change on our code
>>>>>>>>>
>>>>>>>>> base
>>>>>>>>>
>>>>>>>>> where
>>>>>>>>>
>>>>>>>>> someone
>>>>>>>>>
>>>>>>>>> did a
>>>>>>>>>
>>>>>>>>> huge amount of refactoring that resulted than in
>>>>>>>>>
>>>>>>>>> one
>>>>>>>>>
>>>>>>>>> parameter
>>>>>>>>>
>>>>>>>>> changing
>>>>>>>>>
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>> order to get the desired functionality change. If
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>> was
>>>>>>>>>
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>> one
>>>>>>>>>
>>>>>>>>> commit,
>>>>>>>>>
>>>>>>>>> it would be hard to see the actual change. If
>>>>>>>>>
>>>>>>>>> split
>>>>>>>>>
>>>>>>>>> out,
>>>>>>>>>
>>>>>>>>> it's
>>>>>>>>>
>>>>>>>>> beautiful
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> crystal clear.
>>>>>>>>>
>>>>>>>>> I am unsure how that would be reflected in terms
>>>>>>>>>
>>>>>>>>> of
>>>>>>>>>
>>>>>>>>> JIRA
>>>>>>>>>
>>>>>>>>> ticket
>>>>>>>>>
>>>>>>>>> references.
>>>>>>>>>
>>>>>>>>> Usually we assume that if there is a commit with
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> ticket
>>>>>>>>>
>>>>>>>>> number,
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> issue is resolved. Maybe the key here is to create
>>>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>> separate
>>>>>>>>>
>>>>>>>>> refactoring
>>>>>>>>>
>>>>>>>>> ticket.
>>>>>>>>>
>>>>>>>>> Would that allow us to have our cake and eat it
>>>>>>>>>
>>>>>>>>> too?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
>>>>>>>>>
>>>>>>>>> nnag@pivotal.io>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> It is to help with bisect operations when things
>>>>>>>>>
>>>>>>>>> start
>>>>>>>>>
>>>>>>>>> failing
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> helps
>>>>>>>>>
>>>>>>>>> us
>>>>>>>>>
>>>>>>>>> it revert and build faster.
>>>>>>>>> also with cherry picking features / fixes to
>>>>>>>>>
>>>>>>>>> previous
>>>>>>>>>
>>>>>>>>> versions
>>>>>>>>>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> And keeping the git history clean with no
>>>>>>>>>
>>>>>>>>> unnecessary
>>>>>>>>>
>>>>>>>>> “merge
>>>>>>>>>
>>>>>>>>> commits”.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Naba
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
>>>>>>>>>
>>>>>>>>> klund@apache.org>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> -1 I really like to sometimes have more than 1
>>>>>>>>>
>>>>>>>>> commit
>>>>>>>>>
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>> PR
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> keep
>>>>>>>>>
>>>>>>>>> them
>>>>>>>>>
>>>>>>>>> separate when they merge to develop
>>>>>>>>>
>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>>>>>>>>>
>>>>>>>>> nnag@pivotal.io>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Geode Committers,
>>>>>>>>>
>>>>>>>>> A kind request for using squash commit instead
>>>>>>>>>
>>>>>>>>> of
>>>>>>>>>
>>>>>>>>> using
>>>>>>>>>
>>>>>>>>> merge.
>>>>>>>>>
>>>>>>>>> This will really help us in our bisect
>>>>>>>>>
>>>>>>>>> operations
>>>>>>>>>
>>>>>>>>> when a
>>>>>>>>>
>>>>>>>>> regression/flakiness in the product is
>>>>>>>>>
>>>>>>>>> introduced.
>>>>>>>>>
>>>>>>>>> We
>>>>>>>>>
>>>>>>>>> can
>>>>>>>>>
>>>>>>>>> automate
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> go
>>>>>>>>>
>>>>>>>>> through fewer commits faster, avoiding commits
>>>>>>>>>
>>>>>>>>> like
>>>>>>>>>
>>>>>>>>> "spotless
>>>>>>>>>
>>>>>>>>> fix"
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> "re-trigger precheck-in" or other minor commits
>>>>>>>>>
>>>>>>>>> in
>>>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> merged
>>>>>>>>>
>>>>>>>>> branch.
>>>>>>>>>
>>>>>>>>> Also, please use the commit format : (helps us
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> know
>>>>>>>>>
>>>>>>>>> who
>>>>>>>>>
>>>>>>>>> worked
>>>>>>>>>
>>>>>>>>> on
>>>>>>>>>
>>>>>>>>> it,
>>>>>>>>>
>>>>>>>>> what is the history)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>> * explanation line 1
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> explanation
>>>>>>>>>
>>>>>>>>> line
>>>>>>>>>
>>>>>>>>> 2*
>>>>>>>>>
>>>>>>>>> This is not a rule or anything, but a request
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>> help
>>>>>>>>>
>>>>>>>>> out
>>>>>>>>>
>>>>>>>>> your
>>>>>>>>>
>>>>>>>>> fellow
>>>>>>>>>
>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>
>>>>>>>>> For inspiration, we can look into Apache Kafka
>>>>>>>>>
>>>>>>>>> /
>>>>>>>>>
>>>>>>>>> Spark
>>>>>>>>>
>>>>>>>>> where
>>>>>>>>>
>>>>>>>>> they
>>>>>>>>>
>>>>>>>>> have
>>>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>> complete linear graph for their main branch
>>>>>>>>>
>>>>>>>>> HEAD
>>>>>>>>>
>>>>>>>>> [see
>>>>>>>>>
>>>>>>>>> attachment]
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Naba.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Ju@N
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Cheers
>>>>>>>>>
>>>>>>>>> Jinmei
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Blake Bender <bb...@pivotal.io>.
That's not how I approach this sort of a change, and to my mind it feels
sort of like that approach is asking for trouble. When I have a refactor
plus a code change, I do the refactor on a branch, submit the PR, then
branch off of *that* branch to do the feature work. This forces an
ordering of the changes, but alleviates most/all of the conflicts. When
the refactor PR is accepted, I rebase the feature work off of the new
develop branch, and submit the second PR, usually without encountering any
issues.
On Wed, Jan 1, 2020 at 9:57 AM Aaron Lindsey <aa...@apache.org>
wrote:
> >
> > Is it not the case currently? If I am working on a feature modifying
> class
> > X and another developer makes some refactoring changes on class X and
> > pushes it to develop, won't I have to resolve the merge commits anyway.
>
>
> Yes, you will always have to deal with resolving conflicts with other
> people's changes. The scenario I was describing was me having to resolve
> conflicts between my own 2 changes that modify the same files. If I make a
> refactor commit and a fix commit as two separate PRs that are each based on
> develop (i.e. they are independent PRs), after I merge the first one to
> develop the second one will have merge conflicts. The simplest way to avoid
> this is to put the commits in the same PR and use rebase-and-merge.
>
>
>
> On Tue, Dec 31, 2019 at 10:46 PM Owen Nichols <on...@pivotal.io> wrote:
>
> > It sounds like there is value in being able to deliver un-squashed PRs,
> and
> > we believe the richer commit message history outweighs any potential
> > inconvenience to bisect operations (as Aaron pointed out, finer-grained
> > commits should generally be to the benefit of bisect operations).
> >
> > We will leave all 3 merge options enabled in GitHub.
> >
> > On Tue, Dec 31, 2019 at 7:27 PM Dan Smith <ds...@pivotal.io> wrote:
> >
> > > I also tend to do the same workflow Aaron described - make a
> refactoring
> > > change to support a feature followed by the actual change I want to
> make.
> > > It makes the history a lot clearer because refactoring tends to touch a
> > lot
> > > of files, so it's nice to have those changes clearly marked as a
> > > refactoring that should not change behavior.
> > >
> > > It's possible to do this as to separate PRs, but that drags out the
> > process
> > > because you have to get the first in merged before you create the
> second.
> > > That encourages bunching changes in a single squashed commit, which
> makes
> > > git blame less useful.
> > >
> > >
> > > -Dan
> > >
> > > On Tue, Dec 31, 2019, 6:36 PM Nabarun Nag <nn...@apache.org> wrote:
> > >
> > > > Aaron ,
> > > >
> > > > Is it not the case currently? If I am working on a feature modifying
> > > class
> > > > X and another developer makes some refactoring changes on class X and
> > > > pushes it to develop, won't I have to resolve the merge commits
> anyway.
> > > >
> > > >
> > > > Regards
> > > > Naba
> > > >
> > > >
> > > > On Tue, Dec 31, 2019 at 6:01 PM Aaron Lindsey <
> aaronlindsey@apache.org
> > >
> > > > wrote:
> > > >
> > > > > Suppose I’m refactoring the same classes I’m touching for the
> > feature.
> > > I
> > > > > do the refactoring on one branch and submit a PR for that. Then I
> > > > implement
> > > > > the feature on another branch which is based on develop and does
> not
> > > have
> > > > > the refactoring changes since those are not merged yet. I’ll have
> to
> > > > > resolve conflicts on the second PR that I merge.
> > > > >
> > > > > Having interdependent PRs where one PR branch is based on another
> PR
> > > > > branch is not something I’ve tried. That requires more overhead in
> > > having
> > > > > to create more PRs and branches. And if you have N interdependent
> > PRs,
> > > > you
> > > > > have to do N-1 merges each time a PR is merged to develop (to
> update
> > > the
> > > > > other branches). It could be done, but is it worth the hassle?
> > > > >
> > > > > One more point about rebase-and-merge is that it seems like this
> > would
> > > > > make bisecting a failure easier since there would be smaller
> commits.
> > > > >
> > > > > Aaron
> > > > >
> > > > > > On Dec 31, 2019, at 5:41 PM, Owen Nichols <on...@pivotal.io>
> > > wrote:
> > > > > >
> > > > > > Can you elaborate on why you would have to deal with conflicts if
> > the
> > > > > > refactoring work was kept as a separate PR from the fix?
> > > > > >
> > > > > > As with many git workflows, there’s an easy way and a hard way to
> > > > manage
> > > > > > interdependent PRs (tl;dr only merge, never rebase!). I wonder if
> > > this
> > > > > > points out an opportunity for a “tips and tricks” page on the
> Geode
> > > > wiki.
> > > > > >
> > > > > > On Tue, Dec 31, 2019 at 5:22 PM Aaron Lindsey <
> > > aaronlindsey@apache.org
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> -0.9
> > > > > >>
> > > > > >> I’m not in favor of the revised proposal that disallows
> > > > > rebase-and-merge.
> > > > > >> Say I am working on a PR and I have a refactor commit and
> another
> > > > commit
> > > > > >> which implements a new feature. I don’t want those commits to
> get
> > > > > squashed
> > > > > >> because that makes it hard to understand the diff. However, if I
> > > make
> > > > > those
> > > > > >> commits as two separate PRs then I am going to have to deal with
> > > > > conflicts.
> > > > > >>
> > > > > >> I’m not sure when we made it a rule that every commit in develop
> > had
> > > > to
> > > > > >> compile and pass tests. I know we implemented a rule that all
> PRs
> > > had
> > > > to
> > > > > >> pass certain checks, but I never thought that rule implied all
> > > commits
> > > > > had
> > > > > >> to pass those checks.
> > > > > >>
> > > > > >> In general I just don’t see the problem with rebase-and-merge
> and
> > > this
> > > > > >> feels like an unnecessary restriction, but I will go with it if
> > > that’s
> > > > > what
> > > > > >> everyone wants to do.
> > > > > >>
> > > > > >> Aaron
> > > > > >>
> > > > > >>> On Dec 31, 2019, at 3:09 PM, Owen Nichols <onichols@pivotal.io
> >
> > > > wrote:
> > > > > >>>
> > > > > >>> To recap, this proposal is now revised to remove 2 of the 3
> merge
> > > > > options
> > > > > >>> from GitHub, leaving only Squash and Merge. PR #4513
> > > > > >>> <https://github.com/apache/geode/pull/4513> serves as an
> exhibit
> > > of
> > > > > >> what is
> > > > > >>> proposed (it is not to be merged unless discussion leads to
> > > consensus
> > > > > >> and a
> > > > > >>> successful vote). Please use the dev list (not the PR) for all
> > > > > >> discussion
> > > > > >>> (and voting, if we get that far).
> > > > > >>>
> > > > > >>> Squash and merge is already used almost exclusively by the
> Geode
> > > > > >> community,
> > > > > >>> with any exceptions tending to be accidental more often than
> > > > > intentional.
> > > > > >>> However, some have raised the concern that implementing this
> > > > > restriction
> > > > > >>> could result in harm or wasted time. Can someone give an
> example
> > > of
> > > > a
> > > > > >> such
> > > > > >>> a scenario?
> > > > > >>>
> > > > > >>> It seems there is a divide here between junior and senior
> > community
> > > > > >>> members. Newer committers appreciate additional guardrails to
> > > > protect
> > > > > >> them
> > > > > >>> from accidentally doing the wrong thing, while those with more
> > > > > experience
> > > > > >>> want to be able to work unencumbered by restrictions of any
> kind.
> > > > > >>>
> > > > > >>> Our welcome email to new committers states “We like to work on
> > > trust
> > > > > >> rather
> > > > > >>> than unnecessary constraints...Being a committer enables you to
> > > more
> > > > > >> easily
> > > > > >>> make changes without needing to go through the patch submission
> > > > > process”.
> > > > > >>> I can see this as an argument against this proposal (perhaps
> even
> > > an
> > > > > >>> argument against any form of branch protection).
> > > > > >>>
> > > > > >>> In the scheme of things, this proposal makes very little
> > > difference.
> > > > > >> There
> > > > > >>> are still other ways to get non-compiling commits onto develop
> > > (e.g.
> > > > > >>> waiting a long time between running PR checks and merging to
> > > > develop).
> > > > > >>> What’s more important is working well together as a community.
> > So,
> > > > > >> perhaps
> > > > > >>> what’s best for the community is to encourage working on trust
> > > rather
> > > > > >> than
> > > > > >>> unnecessary constraints.
> > > > > >>>
> > > > > >>> -Owen
> > > > > >>>
> > > > > >>> On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org>
> > wrote:
> > > > > >>>
> > > > > >>> I'm happy to file multiple PRs when I need to merge multiple
> > > commits
> > > > to
> > > > > >>> develop.
> > > > > >>>
> > > > > >>> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <
> mhanson@pivotal.io>
> > > > > wrote:
> > > > > >>>
> > > > > >>> This change to disable all but squash-merge would be really
> easy
> > to
> > > > > >>> revert. How about we try it for a while and see? If people
> decide
> > > it
> > > > is
> > > > > >>> really limiting them, we can change it back. Let’s do it for 1
> > > month
> > > > > and
> > > > > >>> see how it goes. Does that sound reasonable?
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>> Mark
> > > > > >>>
> > > > > >>> On Dec 30, 2019, at 5:25 PM, Owen Nichols <onichols@pivotal.io
> >
> > > > wrote:
> > > > > >>>
> > > > > >>> Given that we adopted <
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
> > > > > >>>>
> > > > > >>> and still wish to continue <
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
> > > > > >>>>
> > > > > >>> having branch protection rules to ensure every commit landing
> in
> > > > > develop
> > > > > >>> has passed the required PR checks, it seems like that decision
> > > alone
> > > > > >>> mandates that we disable all merge mechanisms other than
> > > > > >> squash-and-merge.
> > > > > >>>
> > > > > >>>
> > > > > >>> Allowing merge commits or rebase merges bypasses branch
> > protection
> > > > for
> > > > > >>>
> > > > > >>> all commits other than the final one in the merge or rebase
> set.
> > > > Given
> > > > > >>> that we decided <
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
> > > > > >>>>
> > > > > >>> that bypassing PR checks should never be allowed, keeping this
> > > > loophole
> > > > > >>> open seems untenable.
> > > > > >>>
> > > > > >>>
> > > > > >>> This is not just hypothetical — this loophole is causing real
> > > > problems.
> > > > > >>>
> > > > > >>> We now have commits on develop that don’t compile. For
> example:
> > > > > >>>
> > > > > >>> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> > > > > >>> ./gradlew devBuild
> > > > > >>> ...spotlessJava FAILED
> > > > > >>> We implemented branch protections to make this impossible,
> right?
> > > > > >>>
> > > > > >>> We can very easily close this loophole by disabling all but the
> > > > > >>>
> > > > > >>> Squash&Merge button for PRs. This will not make more work for
> > any
> > > > > >>> developer. If you want to get multiple commits onto develop,
> > > simply
> > > > > >> submit
> > > > > >>> each as a separate PR — that is the only way to assure that
> > > required
> > > > PR
> > > > > >>> checks have passed for each.
> > > > > >>>
> > > > > >>>
> > > > > >>> On the other hand, if we as a Geode community feel strongly
> that
> > > > > >>>
> > > > > >>> bypassing branch protection via merge commits and rebase
> commits
> > is
> > > > > >>> important to allow, why not also allow arbitrary overrides (or
> > get
> > > > rid
> > > > > of
> > > > > >>> branch protection entirely)?
> > > > > >>>
> > > > > >>>
> > > > > >>> -Owen
> > > > > >>>
> > > > > >>> On Dec 20, 2019, at 12:31 PM, Blake Bender <bbender@pivotal.io
> >
> > > > wrote:
> > > > > >>>
> > > > > >>> Just FWIW, the situation described of having multiple commits
> in
> > a
> > > > > >>>
> > > > > >>> single
> > > > > >>>
> > > > > >>> PR with separate associated JIRA tickets is still kind of
> > > > problematic.
> > > > > >>>
> > > > > >>> It
> > > > > >>>
> > > > > >>> could well be the case that the commits are interdependent,
> thus
> > > when
> > > > > >>> bisecting etc it's still not possible to revert the fix for a
> > > single
> > > > > >>> bug/feature/whatever atomically. It's all good, though, I'm
> > > > satisfied
> > > > > >>>
> > > > > >>> no
> > > > > >>>
> > > > > >>> one's forcing me to adopt practice I'm opposed to. Apologies
> for
> > > > > >>>
> > > > > >>> getting
> > > > > >>>
> > > > > >>> my feathers a little ruffled, or if I ruffled anyone else's in
> > > > return.
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>>
> > > > > >>> Blake
> > > > > >>>
> > > > > >>>
> > > > > >>> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io>
> > > > wrote:
> > > > > >>>
> > > > > >>> Hi Dan,
> > > > > >>>
> > > > > >>> When we do squash merge all the commit messages are preserved
> and
> > > > also
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> co-authored tag works when we do squash merge.
> > > > > >>> So the authorship and history are preserved.
> > > > > >>>
> > > > > >>> In my own personal experience and reverts and pinpointing
> > > regression
> > > > > >>> failures are tough when the commits are spread out. Also,
> reverts
> > > are
> > > > > >>> easier when it is just one commit while we are bisecting
> > failures.
> > > > > >>>
> > > > > >>>
> > > > > >>> Regards
> > > > > >>> Naba
> > > > > >>>
> > > > > >>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io>
> > > > wrote:
> > > > > >>>
> > > > > >>> I'll change to -0.
> > > > > >>>
> > > > > >>> I think merge commits are a nice way to record history in some
> > > cases,
> > > > > >>>
> > > > > >>> and
> > > > > >>>
> > > > > >>> can also be a way to avoid messy conflicts that come with
> rebase.
> > > > > >>>
> > > > > >>> Merge
> > > > > >>>
> > > > > >>> commits also preserve authorship of commits (compared to
> > > > > >>>
> > > > > >>> squash-merge),
> > > > > >>>
> > > > > >>> which I think is valuable as an open source community that is
> > > trying
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> keep track of outside contributions.
> > > > > >>>
> > > > > >>> That said, if the rest of y'all feel it will help to disable
> the
> > > > > >>>
> > > > > >>> button,
> > > > > >>>
> > > > > >>> I
> > > > > >>>
> > > > > >>> won't stand in the way.
> > > > > >>>
> > > > > >>> -Dan
> > > > > >>>
> > > > > >>> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <
> > abaker@pivotal.io>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> Whether we are talking about the geode/ repository or the
> > > > > >>>
> > > > > >>> geode-native/
> > > > > >>>
> > > > > >>> repository we are all one GEODE community.
> > > > > >>>
> > > > > >>> The idea of a native client team may matter in some contexts
> but
> > in
> > > > > >>>
> > > > > >>> this
> > > > > >>>
> > > > > >>> space we are all GEODE contributors.
> > > > > >>>
> > > > > >>> Adopting a common approach across our repos will make it easier
> > for
> > > > > >>>
> > > > > >>> new
> > > > > >>>
> > > > > >>> contributors to engage, learn our norms, and join our efforts.
> > > > > >>>
> > > > > >>> $0.02,
> > > > > >>> Anthony
> > > > > >>>
> > > > > >>>
> > > > > >>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bbender@pivotal.io
> >
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> Is this a policy the native client team must abide by, as well?
> > It
> > > > > >>>
> > > > > >>> varies
> > > > > >>>
> > > > > >>> slightly with what we've been doing, and all other things being
> > > > > >>>
> > > > > >>> equal I
> > > > > >>>
> > > > > >>> see
> > > > > >>>
> > > > > >>> no reason for us to change that. If I am to have any measure
> of
> > > > > >>>
> > > > > >>> control
> > > > > >>>
> > > > > >>> over the nc repository, I will definitely enforce a 1:1
> > > > > >>>
> > > > > >>> correspondence
> > > > > >>>
> > > > > >>> between commits to develop and JIRA tickets. IMO, if your
> > > > > >>>
> > > > > >>> refactoring
> > > > > >>>
> > > > > >>> in a
> > > > > >>>
> > > > > >>> PR is sufficiently large or complex that it's difficult to
> tease
> > it
> > > > > >>>
> > > > > >>> out
> > > > > >>>
> > > > > >>> from the bug you're fixing or feature you're implementing, it
> > > merits
> > > > > >>>
> > > > > >>> its
> > > > > >>>
> > > > > >>> own JIRA ticket and a separate PR. If your "actual" fix then
> > > > > >>>
> > > > > >>> becomes
> > > > > >>>
> > > > > >>> dependent on the refactored code, that's a price I'm willing to
> > pay
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> keep
> > > > > >>>
> > > > > >>> history clean.
> > > > > >>>
> > > > > >>> On the other hand, I see no real value in squashing to a single
> > > > > >>>
> > > > > >>> commit
> > > > > >>>
> > > > > >>> prior to submitting a PR, since your view of the changes on
> > GitHub
> > > > > >>>
> > > > > >>> is
> > > > > >>>
> > > > > >>> essentially the same either way. We haven't enforced this on
> the
> > > nc
> > > > > >>>
> > > > > >>> repo,
> > > > > >>>
> > > > > >>> and I'd prefer to keep it that way.
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>>
> > > > > >>> Blake
> > > > > >>>
> > > > > >>>
> > > > > >>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <
> jiliao@pivotal.io>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> Merge commit is the new contributor's default setting. When we
> > are
> > > > > >>>
> > > > > >>> merging
> > > > > >>>
> > > > > >>> new contributor's PR, since we are so used to THINKING
> > > > > >>>
> > > > > >>> "squash-and-merge"
> > > > > >>>
> > > > > >>> is the default, we forgot to check what the button really says
> > when
> > > > > >>>
> > > > > >>> we
> > > > > >>>
> > > > > >>> are
> > > > > >>>
> > > > > >>> merging other people's PR.
> > > > > >>>
> > > > > >>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > > > > >>>
> > > > > >>> eburghardt@pivotal.io>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> I'm a proponent of using squash-and-merge, and once a person
> has
> > > > > >>>
> > > > > >>> chosen
> > > > > >>>
> > > > > >>> this option once it comes up by default afterwards...
> > > > > >>>
> > > > > >>> Owen, I don't think you have consensus to put forth this PR,
> > > > > >>>
> > > > > >>> there
> > > > > >>>
> > > > > >>> are
> > > > > >>>
> > > > > >>> -1s
> > > > > >>>
> > > > > >>> above... (early voting)
> > > > > >>>
> > > > > >>> maybe we'll be better off socializing the norm of
> > squash-and-merge
> > > > > >>>
> > > > > >>> and
> > > > > >>>
> > > > > >>> gaining a natural consensus that way...
> > > > > >>>
> > > > > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
> > > > > >>>
> > > > > >>> onichols@pivotal.io
> > > > > >>>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> The proposed action manifests as a commit to the Geode git
> > > > > >>>
> > > > > >>> repository,
> > > > > >>>
> > > > > >>> so
> > > > > >>>
> > > > > >>> a PR is an acceptable vehicle for voting in this case.
> > > > > >>>
> > > > > >>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > > > > >>>
> > > > > >>> bschuchardt@pivotal.io>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> I see a lot of plus-ones and a "voting deadline" on this
> DISCUSS
> > > > > >>>
> > > > > >>> thread
> > > > > >>>
> > > > > >>> and a request to "vote" using a PR. This all seems out of
> order
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> me.
> > > > > >>>
> > > > > >>> Our votes are supposed to be on the email list, aren't they?
> and
> > > > > >>>
> > > > > >>> I
> > > > > >>>
> > > > > >>> haven't
> > > > > >>>
> > > > > >>> seen a VOTE request.
> > > > > >>>
> > > > > >>>
> > > > > >>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > > > > >>>
> > > > > >>> +1
> > > > > >>>
> > > > > >>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
> > > > > >>>
> > > > > >>> onichols@pivotal.io
> > > > > >>>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> Based on the feedback so far, I will amend the proposal to
> > > > > >>>
> > > > > >>> drop
> > > > > >>>
> > > > > >>> item
> > > > > >>>
> > > > > >>> 2).
> > > > > >>>
> > > > > >>> Therefore, the current ability to create merge commits using
> > > > > >>>
> > > > > >>> command-line
> > > > > >>>
> > > > > >>> git will remain available.
> > > > > >>>
> > > > > >>> The proposal as amended is now:
> > > > > >>>
> > > > > >>> Change GitHub settings to make "Squash and merge" the default
> > > > > >>> (by removing “Create a merge commit” option).
> > > > > >>>
> > > > > >>> Update the PR template to change the text "Is your initial
> > > > > >>>
> > > > > >>> contribution
> > > > > >>>
> > > > > >>> a single, squashed commit” to “Is your initial contribution
> > > > > >>>
> > > > > >>> squashed
> > > > > >>>
> > > > > >>> for
> > > > > >>>
> > > > > >>> ease of review (e.g. a single commit, or a ‘refactoring’
> > > > > >>>
> > > > > >>> commit
> > > > > >>>
> > > > > >>> plus a
> > > > > >>>
> > > > > >>> ‘fix’ commit)"
> > > > > >>>
> > > > > >>>
> > > > > >>> As Naba suggested, we can try it, and if we don’t like it,
> > > > > >>>
> > > > > >>> it’s
> > > > > >>>
> > > > > >>> simple
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> revert.
> > > > > >>>
> > > > > >>> I’ve create a PR for the proposed change here:
> > > > > >>> https://github.com/apache/geode/pull/4513
> > > > > >>>
> > > > > >>> Please use the PR to vote for against this proposal. It will
> > > > > >>>
> > > > > >>> not
> > > > > >>>
> > > > > >>> be
> > > > > >>>
> > > > > >>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
> > > > > >>>
> > > > > >>> that
> > > > > >>>
> > > > > >>> time)
> > > > > >>>
> > > > > >>>
> > > > > >>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> +1
> > > > > >>>
> > > > > >>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
> > > > > >>>
> > > > > >>> onichols@pivotal.io>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> Hi Bruce, this proposal will not waste a single second of
> > > > > >>>
> > > > > >>> your
> > > > > >>>
> > > > > >>> time. It
> > > > > >>>
> > > > > >>> just prevents people from accidentally pressing a button
> > > > > >>>
> > > > > >>> that
> > > > > >>>
> > > > > >>> we
> > > > > >>>
> > > > > >>> have
> > > > > >>>
> > > > > >>> already agreed should never be pressed, but because we never
> > > > > >>>
> > > > > >>> configured
> > > > > >>>
> > > > > >>> our
> > > > > >>>
> > > > > >>> GitHub to match our stated policy, is currently the default.
> > > > > >>>
> > > > > >>> However, it will save a lot of time and frustration for
> > > > > >>>
> > > > > >>> anyone
> > > > > >>>
> > > > > >>> needing
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> bisect failures, revert, or cherry-pick changes, which has
> > > > > >>>
> > > > > >>> merit
> > > > > >>>
> > > > > >>> even if
> > > > > >>>
> > > > > >>> you personally never do any of those three things.
> > > > > >>>
> > > > > >>> Please start a separate thread if you would like to revisit
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> community
> > > > > >>>
> > > > > >>> decision to require passing PR checks.
> > > > > >>>
> > > > > >>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > > > > >>>
> > > > > >>> bschuchardt@pivotal.io>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> I agree with Jake. I would go further by saying that I see
> > > > > >>>
> > > > > >>> very
> > > > > >>>
> > > > > >>> little
> > > > > >>>
> > > > > >>> merit in this proposal. I think we're getting more and more
> > > > > >>>
> > > > > >>> bureaucratic
> > > > > >>>
> > > > > >>> in our process and that it stifles productivity. I was
> > > > > >>>
> > > > > >>> recently
> > > > > >>>
> > > > > >>> forced
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> spend three days fixing tests in which I had changed an
> > > > > >>>
> > > > > >>> import
> > > > > >>>
> > > > > >>> statement
> > > > > >>>
> > > > > >>> before they would pass stress testing. I'm glad the tests
> > > > > >>>
> > > > > >>> now
> > > > > >>>
> > > > > >>> pass
> > > > > >>>
> > > > > >>> reliably but I was very frustrated by the process.
> > > > > >>>
> > > > > >>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > > > > >>>
> > > > > >>> I’m in agreement with Dan. Changes to the infrastructure
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> flat
> > > > > >>>
> > > > > >>> out
> > > > > >>>
> > > > > >>> prevent things that should be self policing is annoying.
> > > > > >>>
> > > > > >>> This
> > > > > >>>
> > > > > >>> PR
> > > > > >>>
> > > > > >>> review
> > > > > >>>
> > > > > >>> lock we have had already cost us valuable time waiting for
> > > > > >>>
> > > > > >>> PR
> > > > > >>>
> > > > > >>> pipelines
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> pass that have no relevance to the commit, like CI work: I’d
> > > > > >>>
> > > > > >>> hat
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> see
> > > > > >>>
> > > > > >>> yet
> > > > > >>>
> > > > > >>> another process enforced that Kees us from getting work done
> > > > > >>>
> > > > > >>> when
> > > > > >>>
> > > > > >>> necessary.
> > > > > >>>
> > > > > >>> -Jake
> > > > > >>>
> > > > > >>>
> > > > > >>> On Dec 19, 2019, at 4:43 PM, Dan Smith <
> > > > > >>>
> > > > > >>> dsmith@pivotal.io
> > > > > >>>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> -1 to (1) and (2).
> > > > > >>>
> > > > > >>> I think merge commits are appropriate in certain
> > > > > >>>
> > > > > >>> circumstances,
> > > > > >>>
> > > > > >>> so I
> > > > > >>>
> > > > > >>> don't
> > > > > >>>
> > > > > >>> think we should make a blanket restriction. In fact I
> > > > > >>>
> > > > > >>> think
> > > > > >>>
> > > > > >>> our
> > > > > >>>
> > > > > >>> release
> > > > > >>>
> > > > > >>> process involves some merges.
> > > > > >>>
> > > > > >>> I think setting standards on what is reasonable to be an
> > > > > >>>
> > > > > >>> individual
> > > > > >>>
> > > > > >>> commit
> > > > > >>>
> > > > > >>> will do a lot more to clean up our history than blocking
> > > > > >>>
> > > > > >>> merges.
> > > > > >>>
> > > > > >>> We'd
> > > > > >>>
> > > > > >>> rather not see commits like "Spotless Apply" in the
> > > > > >>>
> > > > > >>> history,
> > > > > >>>
> > > > > >>> but
> > > > > >>>
> > > > > >>> if
> > > > > >>>
> > > > > >>> reasonably separate and well written commits come in as
> > > > > >>>
> > > > > >>> part
> > > > > >>>
> > > > > >>> of
> > > > > >>>
> > > > > >>> a
> > > > > >>>
> > > > > >>> merge, I
> > > > > >>>
> > > > > >>> think that's fine.
> > > > > >>>
> > > > > >>> -Dan
> > > > > >>>
> > > > > >>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> > > > > >>>
> > > > > >>> jiliao@pivotal.io
> > > > > >>>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> +1
> > > > > >>>
> > > > > >>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> > > > > >>>
> > > > > >>> onichols@pivotal.io
> > > > > >>>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> I’d like to advance this topic from an informal
> > > > > >>>
> > > > > >>> request/discussion
> > > > > >>>
> > > > > >>> to a
> > > > > >>>
> > > > > >>> discussion of a concrete proposal.
> > > > > >>>
> > > > > >>> To recap, it sounds like there is general agreement
> > > > > >>>
> > > > > >>> that
> > > > > >>>
> > > > > >>> commit
> > > > > >>>
> > > > > >>> history
> > > > > >>>
> > > > > >>> on
> > > > > >>>
> > > > > >>> develop should be linear (no merge commits), and that
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> biggest
> > > > > >>>
> > > > > >>> obstacle
> > > > > >>>
> > > > > >>> to this is that the PR merge button in GitHub creates a
> > > > > >>>
> > > > > >>> merge
> > > > > >>>
> > > > > >>> commit
> > > > > >>>
> > > > > >>> by
> > > > > >>>
> > > > > >>> default.
> > > > > >>>
> > > > > >>> I propose the following changes:
> > > > > >>> 1) Change GitHub settings to remove the ability to
> > > > > >>>
> > > > > >>> create
> > > > > >>>
> > > > > >>> a
> > > > > >>>
> > > > > >>> merge
> > > > > >>>
> > > > > >>> commit.
> > > > > >>>
> > > > > >>> This will make Squash & Merge the default.
> > > > > >>>
> > > > > >>> 2) Change GitHub settings to require linear history on
> > > > > >>>
> > > > > >>> develop.
> > > > > >>>
> > > > > >>> This
> > > > > >>>
> > > > > >>> prevents merge commits via command-line (not
> > > > > >>>
> > > > > >>> recommended,
> > > > > >>>
> > > > > >>> but
> > > > > >>>
> > > > > >>> wiki
> > > > > >>>
> > > > > >>> still
> > > > > >>>
> > > > > >>> has instructions for merging PRs this way).
> > > > > >>>
> > > > > >>> 3) Update the PR template to change the text "Is your
> > > > > >>>
> > > > > >>> initial
> > > > > >>>
> > > > > >>> contribution
> > > > > >>>
> > > > > >>> a single, squashed commit” to “Is your initial
> > > > > >>>
> > > > > >>> contribution
> > > > > >>>
> > > > > >>> squashed
> > > > > >>>
> > > > > >>> for
> > > > > >>>
> > > > > >>> ease of review (e.g. a single commit, or a
> > > > > >>>
> > > > > >>> ‘refactoring’
> > > > > >>>
> > > > > >>> commit
> > > > > >>>
> > > > > >>> plus
> > > > > >>>
> > > > > >>> a
> > > > > >>>
> > > > > >>> ‘fix’ commit)"
> > > > > >>>
> > > > > >>> For clarity, I am proposing no-change in the following
> > > > > >>>
> > > > > >>> areas:
> > > > > >>>
> > > > > >>> i) Leave Rebase & Merge as an option for PRs that have
> > > > > >>>
> > > > > >>> been
> > > > > >>>
> > > > > >>> structured to
> > > > > >>>
> > > > > >>> benefit from it (this can make it easier in a bisect to
> > > > > >>>
> > > > > >>> see
> > > > > >>>
> > > > > >>> whether
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> refactoring or the “fix” broke something).
> > > > > >>> ii) Leave existing wording in the wiki as-is [stating
> > > > > >>>
> > > > > >>> that
> > > > > >>>
> > > > > >>> squashing
> > > > > >>>
> > > > > >>> is
> > > > > >>>
> > > > > >>> preferred].
> > > > > >>>
> > > > > >>>
> > > > > >>> Please comment via this email thread.
> > > > > >>> -Owen
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> > > > > >>>
> > > > > >>> klund@apache.org>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> I think it's already resolved Udo ;)
> > > > > >>>
> > > > > >>> Here's the problem, if I fixup a dunit test by
> > > > > >>>
> > > > > >>> removing
> > > > > >>>
> > > > > >>> all
> > > > > >>>
> > > > > >>> uses
> > > > > >>>
> > > > > >>> of
> > > > > >>>
> > > > > >>> "this."
> > > > > >>>
> > > > > >>> and I rename the dunit test, then git doesn't remember
> > > > > >>>
> > > > > >>> that
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> file
> > > > > >>>
> > > > > >>> is a
> > > > > >>>
> > > > > >>> rename -- it forever afterwards interprets it as a new
> > > > > >>>
> > > > > >>> file
> > > > > >>>
> > > > > >>> that I
> > > > > >>>
> > > > > >>> created
> > > > > >>>
> > > > > >>> if I touch more than 50% of the lines (which "this."
> > > > > >>>
> > > > > >>> can
> > > > > >>>
> > > > > >>> easily
> > > > > >>>
> > > > > >>> do). If
> > > > > >>>
> > > > > >>> we
> > > > > >>>
> > > > > >>> squash two commits: the rename and the cleanup of that
> > > > > >>>
> > > > > >>> dunit
> > > > > >>>
> > > > > >>> test
> > > > > >>>
> > > > > >>> --
> > > > > >>>
> > > > > >>> then
> > > > > >>>
> > > > > >>> we effectively lose the history of that file and it
> > > > > >>>
> > > > > >>> shows
> > > > > >>>
> > > > > >>> that
> > > > > >>>
> > > > > >>> I
> > > > > >>>
> > > > > >>> created
> > > > > >>>
> > > > > >>> a
> > > > > >>>
> > > > > >>> new file.
> > > > > >>>
> > > > > >>> Also for the record, I've been working on Geode since
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> beginning
> > > > > >>>
> > > > > >>> and I
> > > > > >>>
> > > > > >>> was never made aware of this change in our process. I
> > > > > >>>
> > > > > >>> never
> > > > > >>>
> > > > > >>> voted
> > > > > >>>
> > > > > >>> on
> > > > > >>>
> > > > > >>> it.
> > > > > >>>
> > > > > >>> I'm not a big fan of changing various details in our
> > > > > >>>
> > > > > >>> process
> > > > > >>>
> > > > > >>> every
> > > > > >>>
> > > > > >>> single
> > > > > >>>
> > > > > >>> week. It's very easy to miss these discussions unless
> > > > > >>>
> > > > > >>> someone
> > > > > >>>
> > > > > >>> points it
> > > > > >>>
> > > > > >>> out
> > > > > >>>
> > > > > >>> to me.
> > > > > >>>
> > > > > >>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > > > > >>>
> > > > > >>> ukohlmeyer@pivotal.io>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> I'm not sure what this discussion is about... WE, as
> > > > > >>>
> > > > > >>> a
> > > > > >>>
> > > > > >>> community,
> > > > > >>>
> > > > > >>> have
> > > > > >>>
> > > > > >>> agreed in common practices, in two place no less...
> > > > > >>>
> > > > > >>> 1) Quoting our PR template
> > > > > >>>
> > > > > >>>
> > > > > >>> For all changes:
> > > > > >>>
> > > > > >>> *
> > > > > >>>
> > > > > >>> Is there a JIRA ticket associated with this PR? Is it
> > > > > >>>
> > > > > >>> referenced
> > > > > >>>
> > > > > >>> in
> > > > > >>>
> > > > > >>> the commit message?
> > > > > >>>
> > > > > >>> *
> > > > > >>>
> > > > > >>> Has your PR been rebased against the latest commit
> > > > > >>>
> > > > > >>> within
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> target
> > > > > >>>
> > > > > >>> branch (typically|develop|)?
> > > > > >>>
> > > > > >>> *
> > > > > >>>
> > > > > >>> ***Is your initial contribution a single, squashed
> > > > > >>>
> > > > > >>> commit?*
> > > > > >>>
> > > > > >>>
> > > > > >>> *
> > > > > >>>
> > > > > >>> Does|gradlew build|run cleanly?
> > > > > >>>
> > > > > >>> *
> > > > > >>>
> > > > > >>> Have you written or updated unit tests to verify your
> > > > > >>>
> > > > > >>> changes?
> > > > > >>>
> > > > > >>>
> > > > > >>> *
> > > > > >>>
> > > > > >>> If adding new dependencies to the code, are these
> > > > > >>>
> > > > > >>> dependencies
> > > > > >>>
> > > > > >>> licensed in a way that is compatible for inclusion
> > > > > >>>
> > > > > >>> underASF
> > > > > >>>
> > > > > >>> 2.0
> > > > > >>>
> > > > > >>> <
> > > > > >>>
> > > > > >>> http://www.apache.org/legal/resolved.html#category-a
> > > > > >>>
> > > > > >>> ?
> > > > > >>>
> > > > > >>>
> > > > > >>> On our PR template we call out that the initial PR
> > > > > >>>
> > > > > >>> commit
> > > > > >>>
> > > > > >>> should
> > > > > >>>
> > > > > >>> be
> > > > > >>>
> > > > > >>> squashed.
> > > > > >>>
> > > > > >>> 2)
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > > > >>>
> > > > > >>> <
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > > > >>>
> > > > > >>> -- See "Accepting a PR Using the Command Line" -
> > > > > >>>
> > > > > >>> Point
> > > > > >>>
> > > > > >>> #3.
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> @Kirk, if each of your commits "stands alone", I
> > > > > >>>
> > > > > >>> commend
> > > > > >>>
> > > > > >>> you
> > > > > >>>
> > > > > >>> on
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> diligence, but in reality, they should either then be
> > > > > >>>
> > > > > >>> stand
> > > > > >>>
> > > > > >>> alone
> > > > > >>>
> > > > > >>> PR's
> > > > > >>>
> > > > > >>> or just extra work created for yourself.
> > > > > >>>
> > > > > >>> If we want to change the way we have agreed upon we
> > > > > >>>
> > > > > >>> submit/commit/merge
> > > > > >>>
> > > > > >>> changes back into develop... Then this is another
> > > > > >>>
> > > > > >>> discussion
> > > > > >>>
> > > > > >>> thread,
> > > > > >>>
> > > > > >>> until then, I think we should all remind ourselves on
> > > > > >>>
> > > > > >>> our
> > > > > >>>
> > > > > >>> agreed
> > > > > >>>
> > > > > >>> contributions code of conduct.
> > > > > >>>
> > > > > >>> --Udo
> > > > > >>>
> > > > > >>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > > > > >>>
> > > > > >>> Kirk, I believe that creating a Pull Request with
> > > > > >>>
> > > > > >>> multiple
> > > > > >>>
> > > > > >>> commits is
> > > > > >>>
> > > > > >>> ok.
> > > > > >>>
> > > > > >>> It's just in the end that when it's being pushed to
> > > > > >>>
> > > > > >>> develop
> > > > > >>>
> > > > > >>> branch,
> > > > > >>>
> > > > > >>> it
> > > > > >>>
> > > > > >>> needs to be squash merged. I believe that is what
> > > > > >>>
> > > > > >>> you
> > > > > >>>
> > > > > >>> have
> > > > > >>>
> > > > > >>> mentioned
> > > > > >>>
> > > > > >>> in
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> first paragraph, and I am more than happy with that.
> > > > > >>> If you can see in the first screenshot comparison
> > > > > >>>
> > > > > >>> that
> > > > > >>>
> > > > > >>> I
> > > > > >>>
> > > > > >>> had
> > > > > >>>
> > > > > >>> attached
> > > > > >>>
> > > > > >>> in
> > > > > >>>
> > > > > >>> the first email in this thread is what I want to
> > > > > >>>
> > > > > >>> avoid.
> > > > > >>>
> > > > > >>>
> > > > > >>> Thank you for your feedback.
> > > > > >>>
> > > > > >>> Regards
> > > > > >>> Naba
> > > > > >>>
> > > > > >>>
> > > > > >>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> > > > > >>>
> > > > > >>> klund@apache.org>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> Whenever I submit a PR with multiple commits that I
> > > > > >>>
> > > > > >>> intend
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> rebase
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> develop, I always try to ensure that each commit
> > > > > >>>
> > > > > >>> stands
> > > > > >>>
> > > > > >>> alone
> > > > > >>>
> > > > > >>> as
> > > > > >>>
> > > > > >>> is
> > > > > >>>
> > > > > >>> (compiles and passes tests). Separating file
> > > > > >>>
> > > > > >>> renames
> > > > > >>>
> > > > > >>> and
> > > > > >>>
> > > > > >>> refactoring
> > > > > >>>
> > > > > >>> from
> > > > > >>>
> > > > > >>> behavior changes into different commits seems very
> > > > > >>>
> > > > > >>> valuable
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> me,
> > > > > >>>
> > > > > >>> and
> > > > > >>>
> > > > > >>> I've
> > > > > >>>
> > > > > >>> had trouble getting people to review PRs without
> > > > > >>>
> > > > > >>> this
> > > > > >>>
> > > > > >>> separation
> > > > > >>>
> > > > > >>> (but
> > > > > >>>
> > > > > >>> it
> > > > > >>>
> > > > > >>> could be squashed as it's merged to develop).
> > > > > >>>
> > > > > >>> It sounds to me like the real problem is (a) some
> > > > > >>>
> > > > > >>> PRs
> > > > > >>>
> > > > > >>> have
> > > > > >>>
> > > > > >>> multiple
> > > > > >>>
> > > > > >>> commits
> > > > > >>>
> > > > > >>> that don't compile or don't pass tests, and (b)
> > > > > >>>
> > > > > >>> some
> > > > > >>>
> > > > > >>> PRs
> > > > > >>>
> > > > > >>> that
> > > > > >>>
> > > > > >>> should
> > > > > >>>
> > > > > >>> be
> > > > > >>>
> > > > > >>> merged with squash are not (by accident most
> > > > > >>>
> > > > > >>> likely).
> > > > > >>>
> > > > > >>>
> > > > > >>> I can submit multiple PRs instead of one PR with
> > > > > >>>
> > > > > >>> multiple
> > > > > >>>
> > > > > >>> commits.
> > > > > >>>
> > > > > >>> So
> > > > > >>>
> > > > > >>> I'll
> > > > > >>>
> > > > > >>> change my response to -0 if that helps prevent
> > > > > >>>
> > > > > >>> commits
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> develop
> > > > > >>>
> > > > > >>> that
> > > > > >>>
> > > > > >>> don't compile or pass tests. Without preventing
> > > > > >>>
> > > > > >>> rebase
> > > > > >>>
> > > > > >>> or
> > > > > >>>
> > > > > >>> merge
> > > > > >>>
> > > > > >>> commits
> > > > > >>>
> > > > > >>> from github, I'm not sure how we can really enforce
> > > > > >>>
> > > > > >>> this
> > > > > >>>
> > > > > >>> or
> > > > > >>>
> > > > > >>> prevent
> > > > > >>>
> > > > > >>> (b)
> > > > > >>>
> > > > > >>> above.
> > > > > >>>
> > > > > >>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > > > > >>>
> > > > > >>> amurmann@pivotal.io>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> I wonder if Kirk's and Naba's statements are
> > > > > >>>
> > > > > >>> necessarily
> > > > > >>>
> > > > > >>> at
> > > > > >>>
> > > > > >>> odds.
> > > > > >>>
> > > > > >>> Make the change easy (warning: this may be hard),
> > > > > >>>
> > > > > >>> then
> > > > > >>>
> > > > > >>> make
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> easy
> > > > > >>>
> > > > > >>> change."
> > > > > >>>
> > > > > >>> -Kent Beck
> > > > > >>>
> > > > > >>> Following Kent Beck's advise might reasonably
> > > > > >>>
> > > > > >>> split
> > > > > >>>
> > > > > >>> into
> > > > > >>>
> > > > > >>> two
> > > > > >>>
> > > > > >>> commits.
> > > > > >>>
> > > > > >>> One
> > > > > >>>
> > > > > >>> refactor commit and a separate commit that
> > > > > >>>
> > > > > >>> introduces
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> actual
> > > > > >>>
> > > > > >>> change.
> > > > > >>>
> > > > > >>> They should be individually revertible and might
> > > > > >>>
> > > > > >>> be
> > > > > >>>
> > > > > >>> easier
> > > > > >>>
> > > > > >>> understood
> > > > > >>>
> > > > > >>> if
> > > > > >>>
> > > > > >>> split out. I vividly remember a change on our code
> > > > > >>>
> > > > > >>> base
> > > > > >>>
> > > > > >>> where
> > > > > >>>
> > > > > >>> someone
> > > > > >>>
> > > > > >>> did a
> > > > > >>>
> > > > > >>> huge amount of refactoring that resulted than in
> > > > > >>>
> > > > > >>> one
> > > > > >>>
> > > > > >>> parameter
> > > > > >>>
> > > > > >>> changing
> > > > > >>>
> > > > > >>> in
> > > > > >>>
> > > > > >>> order to get the desired functionality change. If
> > > > > >>>
> > > > > >>> that
> > > > > >>>
> > > > > >>> was
> > > > > >>>
> > > > > >>> in
> > > > > >>>
> > > > > >>> one
> > > > > >>>
> > > > > >>> commit,
> > > > > >>>
> > > > > >>> it would be hard to see the actual change. If
> > > > > >>>
> > > > > >>> split
> > > > > >>>
> > > > > >>> out,
> > > > > >>>
> > > > > >>> it's
> > > > > >>>
> > > > > >>> beautiful
> > > > > >>>
> > > > > >>> and
> > > > > >>>
> > > > > >>> crystal clear.
> > > > > >>>
> > > > > >>> I am unsure how that would be reflected in terms
> > > > > >>>
> > > > > >>> of
> > > > > >>>
> > > > > >>> JIRA
> > > > > >>>
> > > > > >>> ticket
> > > > > >>>
> > > > > >>> references.
> > > > > >>>
> > > > > >>> Usually we assume that if there is a commit with
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> ticket
> > > > > >>>
> > > > > >>> number,
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> issue is resolved. Maybe the key here is to create
> > > > > >>>
> > > > > >>> a
> > > > > >>>
> > > > > >>> separate
> > > > > >>>
> > > > > >>> refactoring
> > > > > >>>
> > > > > >>> ticket.
> > > > > >>>
> > > > > >>> Would that allow us to have our cake and eat it
> > > > > >>>
> > > > > >>> too?
> > > > > >>>
> > > > > >>>
> > > > > >>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> > > > > >>>
> > > > > >>> nnag@pivotal.io>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> It is to help with bisect operations when things
> > > > > >>>
> > > > > >>> start
> > > > > >>>
> > > > > >>> failing
> > > > > >>>
> > > > > >>> ...
> > > > > >>>
> > > > > >>> helps
> > > > > >>>
> > > > > >>> us
> > > > > >>>
> > > > > >>> it revert and build faster.
> > > > > >>> also with cherry picking features / fixes to
> > > > > >>>
> > > > > >>> previous
> > > > > >>>
> > > > > >>> versions
> > > > > >>>
> > > > > >>> .
> > > > > >>>
> > > > > >>> And keeping the git history clean with no
> > > > > >>>
> > > > > >>> unnecessary
> > > > > >>>
> > > > > >>> “merge
> > > > > >>>
> > > > > >>> commits”.
> > > > > >>>
> > > > > >>> Regards
> > > > > >>> Naba
> > > > > >>>
> > > > > >>>
> > > > > >>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> > > > > >>>
> > > > > >>> klund@apache.org>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> -1 I really like to sometimes have more than 1
> > > > > >>>
> > > > > >>> commit
> > > > > >>>
> > > > > >>> in
> > > > > >>>
> > > > > >>> a
> > > > > >>>
> > > > > >>> PR
> > > > > >>>
> > > > > >>> and
> > > > > >>>
> > > > > >>> keep
> > > > > >>>
> > > > > >>> them
> > > > > >>>
> > > > > >>> separate when they merge to develop
> > > > > >>>
> > > > > >>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> > > > > >>>
> > > > > >>> nnag@pivotal.io>
> > > > > >>>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> Hi Geode Committers,
> > > > > >>>
> > > > > >>> A kind request for using squash commit instead
> > > > > >>>
> > > > > >>> of
> > > > > >>>
> > > > > >>> using
> > > > > >>>
> > > > > >>> merge.
> > > > > >>>
> > > > > >>> This will really help us in our bisect
> > > > > >>>
> > > > > >>> operations
> > > > > >>>
> > > > > >>> when a
> > > > > >>>
> > > > > >>> regression/flakiness in the product is
> > > > > >>>
> > > > > >>> introduced.
> > > > > >>>
> > > > > >>> We
> > > > > >>>
> > > > > >>> can
> > > > > >>>
> > > > > >>> automate
> > > > > >>>
> > > > > >>> and
> > > > > >>>
> > > > > >>> go
> > > > > >>>
> > > > > >>> through fewer commits faster, avoiding commits
> > > > > >>>
> > > > > >>> like
> > > > > >>>
> > > > > >>> "spotless
> > > > > >>>
> > > > > >>> fix"
> > > > > >>>
> > > > > >>> and
> > > > > >>>
> > > > > >>> "re-trigger precheck-in" or other minor commits
> > > > > >>>
> > > > > >>> in
> > > > > >>>
> > > > > >>> the
> > > > > >>>
> > > > > >>> merged
> > > > > >>>
> > > > > >>> branch.
> > > > > >>>
> > > > > >>> Also, please use the commit format : (helps us
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> know
> > > > > >>>
> > > > > >>> who
> > > > > >>>
> > > > > >>> worked
> > > > > >>>
> > > > > >>> on
> > > > > >>>
> > > > > >>> it,
> > > > > >>>
> > > > > >>> what is the history)
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> * GEODE-xxxx: <brief intro >
> > > > > >>> * explanation line 1
> > > > > >>>
> > > > > >>> *
> > > > > >>>
> > > > > >>> explanation
> > > > > >>>
> > > > > >>> line
> > > > > >>>
> > > > > >>> 2*
> > > > > >>>
> > > > > >>> This is not a rule or anything, but a request
> > > > > >>>
> > > > > >>> to
> > > > > >>>
> > > > > >>> help
> > > > > >>>
> > > > > >>> out
> > > > > >>>
> > > > > >>> your
> > > > > >>>
> > > > > >>> fellow
> > > > > >>>
> > > > > >>> committers in quickly detecting a problem.
> > > > > >>>
> > > > > >>> For inspiration, we can look into Apache Kafka
> > > > > >>>
> > > > > >>> /
> > > > > >>>
> > > > > >>> Spark
> > > > > >>>
> > > > > >>> where
> > > > > >>>
> > > > > >>> they
> > > > > >>>
> > > > > >>> have
> > > > > >>>
> > > > > >>> a
> > > > > >>>
> > > > > >>> complete linear graph for their main branch
> > > > > >>>
> > > > > >>> HEAD
> > > > > >>>
> > > > > >>> [see
> > > > > >>>
> > > > > >>> attachment]
> > > > > >>>
> > > > > >>> Regards
> > > > > >>> Naba.
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> --
> > > > > >>>
> > > > > >>> Ju@N
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> --
> > > > > >>> Cheers
> > > > > >>>
> > > > > >>> Jinmei
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Aaron Lindsey <aa...@apache.org>.
>
> Is it not the case currently? If I am working on a feature modifying class
> X and another developer makes some refactoring changes on class X and
> pushes it to develop, won't I have to resolve the merge commits anyway.
Yes, you will always have to deal with resolving conflicts with other
people's changes. The scenario I was describing was me having to resolve
conflicts between my own 2 changes that modify the same files. If I make a
refactor commit and a fix commit as two separate PRs that are each based on
develop (i.e. they are independent PRs), after I merge the first one to
develop the second one will have merge conflicts. The simplest way to avoid
this is to put the commits in the same PR and use rebase-and-merge.
On Tue, Dec 31, 2019 at 10:46 PM Owen Nichols <on...@pivotal.io> wrote:
> It sounds like there is value in being able to deliver un-squashed PRs, and
> we believe the richer commit message history outweighs any potential
> inconvenience to bisect operations (as Aaron pointed out, finer-grained
> commits should generally be to the benefit of bisect operations).
>
> We will leave all 3 merge options enabled in GitHub.
>
> On Tue, Dec 31, 2019 at 7:27 PM Dan Smith <ds...@pivotal.io> wrote:
>
> > I also tend to do the same workflow Aaron described - make a refactoring
> > change to support a feature followed by the actual change I want to make.
> > It makes the history a lot clearer because refactoring tends to touch a
> lot
> > of files, so it's nice to have those changes clearly marked as a
> > refactoring that should not change behavior.
> >
> > It's possible to do this as to separate PRs, but that drags out the
> process
> > because you have to get the first in merged before you create the second.
> > That encourages bunching changes in a single squashed commit, which makes
> > git blame less useful.
> >
> >
> > -Dan
> >
> > On Tue, Dec 31, 2019, 6:36 PM Nabarun Nag <nn...@apache.org> wrote:
> >
> > > Aaron ,
> > >
> > > Is it not the case currently? If I am working on a feature modifying
> > class
> > > X and another developer makes some refactoring changes on class X and
> > > pushes it to develop, won't I have to resolve the merge commits anyway.
> > >
> > >
> > > Regards
> > > Naba
> > >
> > >
> > > On Tue, Dec 31, 2019 at 6:01 PM Aaron Lindsey <aaronlindsey@apache.org
> >
> > > wrote:
> > >
> > > > Suppose I’m refactoring the same classes I’m touching for the
> feature.
> > I
> > > > do the refactoring on one branch and submit a PR for that. Then I
> > > implement
> > > > the feature on another branch which is based on develop and does not
> > have
> > > > the refactoring changes since those are not merged yet. I’ll have to
> > > > resolve conflicts on the second PR that I merge.
> > > >
> > > > Having interdependent PRs where one PR branch is based on another PR
> > > > branch is not something I’ve tried. That requires more overhead in
> > having
> > > > to create more PRs and branches. And if you have N interdependent
> PRs,
> > > you
> > > > have to do N-1 merges each time a PR is merged to develop (to update
> > the
> > > > other branches). It could be done, but is it worth the hassle?
> > > >
> > > > One more point about rebase-and-merge is that it seems like this
> would
> > > > make bisecting a failure easier since there would be smaller commits.
> > > >
> > > > Aaron
> > > >
> > > > > On Dec 31, 2019, at 5:41 PM, Owen Nichols <on...@pivotal.io>
> > wrote:
> > > > >
> > > > > Can you elaborate on why you would have to deal with conflicts if
> the
> > > > > refactoring work was kept as a separate PR from the fix?
> > > > >
> > > > > As with many git workflows, there’s an easy way and a hard way to
> > > manage
> > > > > interdependent PRs (tl;dr only merge, never rebase!). I wonder if
> > this
> > > > > points out an opportunity for a “tips and tricks” page on the Geode
> > > wiki.
> > > > >
> > > > > On Tue, Dec 31, 2019 at 5:22 PM Aaron Lindsey <
> > aaronlindsey@apache.org
> > > >
> > > > > wrote:
> > > > >
> > > > >> -0.9
> > > > >>
> > > > >> I’m not in favor of the revised proposal that disallows
> > > > rebase-and-merge.
> > > > >> Say I am working on a PR and I have a refactor commit and another
> > > commit
> > > > >> which implements a new feature. I don’t want those commits to get
> > > > squashed
> > > > >> because that makes it hard to understand the diff. However, if I
> > make
> > > > those
> > > > >> commits as two separate PRs then I am going to have to deal with
> > > > conflicts.
> > > > >>
> > > > >> I’m not sure when we made it a rule that every commit in develop
> had
> > > to
> > > > >> compile and pass tests. I know we implemented a rule that all PRs
> > had
> > > to
> > > > >> pass certain checks, but I never thought that rule implied all
> > commits
> > > > had
> > > > >> to pass those checks.
> > > > >>
> > > > >> In general I just don’t see the problem with rebase-and-merge and
> > this
> > > > >> feels like an unnecessary restriction, but I will go with it if
> > that’s
> > > > what
> > > > >> everyone wants to do.
> > > > >>
> > > > >> Aaron
> > > > >>
> > > > >>> On Dec 31, 2019, at 3:09 PM, Owen Nichols <on...@pivotal.io>
> > > wrote:
> > > > >>>
> > > > >>> To recap, this proposal is now revised to remove 2 of the 3 merge
> > > > options
> > > > >>> from GitHub, leaving only Squash and Merge. PR #4513
> > > > >>> <https://github.com/apache/geode/pull/4513> serves as an exhibit
> > of
> > > > >> what is
> > > > >>> proposed (it is not to be merged unless discussion leads to
> > consensus
> > > > >> and a
> > > > >>> successful vote). Please use the dev list (not the PR) for all
> > > > >> discussion
> > > > >>> (and voting, if we get that far).
> > > > >>>
> > > > >>> Squash and merge is already used almost exclusively by the Geode
> > > > >> community,
> > > > >>> with any exceptions tending to be accidental more often than
> > > > intentional.
> > > > >>> However, some have raised the concern that implementing this
> > > > restriction
> > > > >>> could result in harm or wasted time. Can someone give an example
> > of
> > > a
> > > > >> such
> > > > >>> a scenario?
> > > > >>>
> > > > >>> It seems there is a divide here between junior and senior
> community
> > > > >>> members. Newer committers appreciate additional guardrails to
> > > protect
> > > > >> them
> > > > >>> from accidentally doing the wrong thing, while those with more
> > > > experience
> > > > >>> want to be able to work unencumbered by restrictions of any kind.
> > > > >>>
> > > > >>> Our welcome email to new committers states “We like to work on
> > trust
> > > > >> rather
> > > > >>> than unnecessary constraints...Being a committer enables you to
> > more
> > > > >> easily
> > > > >>> make changes without needing to go through the patch submission
> > > > process”.
> > > > >>> I can see this as an argument against this proposal (perhaps even
> > an
> > > > >>> argument against any form of branch protection).
> > > > >>>
> > > > >>> In the scheme of things, this proposal makes very little
> > difference.
> > > > >> There
> > > > >>> are still other ways to get non-compiling commits onto develop
> > (e.g.
> > > > >>> waiting a long time between running PR checks and merging to
> > > develop).
> > > > >>> What’s more important is working well together as a community.
> So,
> > > > >> perhaps
> > > > >>> what’s best for the community is to encourage working on trust
> > rather
> > > > >> than
> > > > >>> unnecessary constraints.
> > > > >>>
> > > > >>> -Owen
> > > > >>>
> > > > >>> On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org>
> wrote:
> > > > >>>
> > > > >>> I'm happy to file multiple PRs when I need to merge multiple
> > commits
> > > to
> > > > >>> develop.
> > > > >>>
> > > > >>> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <mh...@pivotal.io>
> > > > wrote:
> > > > >>>
> > > > >>> This change to disable all but squash-merge would be really easy
> to
> > > > >>> revert. How about we try it for a while and see? If people decide
> > it
> > > is
> > > > >>> really limiting them, we can change it back. Let’s do it for 1
> > month
> > > > and
> > > > >>> see how it goes. Does that sound reasonable?
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Mark
> > > > >>>
> > > > >>> On Dec 30, 2019, at 5:25 PM, Owen Nichols <on...@pivotal.io>
> > > wrote:
> > > > >>>
> > > > >>> Given that we adopted <
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
> > > > >>>>
> > > > >>> and still wish to continue <
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
> > > > >>>>
> > > > >>> having branch protection rules to ensure every commit landing in
> > > > develop
> > > > >>> has passed the required PR checks, it seems like that decision
> > alone
> > > > >>> mandates that we disable all merge mechanisms other than
> > > > >> squash-and-merge.
> > > > >>>
> > > > >>>
> > > > >>> Allowing merge commits or rebase merges bypasses branch
> protection
> > > for
> > > > >>>
> > > > >>> all commits other than the final one in the merge or rebase set.
> > > Given
> > > > >>> that we decided <
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
> > > > >>>>
> > > > >>> that bypassing PR checks should never be allowed, keeping this
> > > loophole
> > > > >>> open seems untenable.
> > > > >>>
> > > > >>>
> > > > >>> This is not just hypothetical — this loophole is causing real
> > > problems.
> > > > >>>
> > > > >>> We now have commits on develop that don’t compile. For example:
> > > > >>>
> > > > >>> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> > > > >>> ./gradlew devBuild
> > > > >>> ...spotlessJava FAILED
> > > > >>> We implemented branch protections to make this impossible, right?
> > > > >>>
> > > > >>> We can very easily close this loophole by disabling all but the
> > > > >>>
> > > > >>> Squash&Merge button for PRs. This will not make more work for
> any
> > > > >>> developer. If you want to get multiple commits onto develop,
> > simply
> > > > >> submit
> > > > >>> each as a separate PR — that is the only way to assure that
> > required
> > > PR
> > > > >>> checks have passed for each.
> > > > >>>
> > > > >>>
> > > > >>> On the other hand, if we as a Geode community feel strongly that
> > > > >>>
> > > > >>> bypassing branch protection via merge commits and rebase commits
> is
> > > > >>> important to allow, why not also allow arbitrary overrides (or
> get
> > > rid
> > > > of
> > > > >>> branch protection entirely)?
> > > > >>>
> > > > >>>
> > > > >>> -Owen
> > > > >>>
> > > > >>> On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io>
> > > wrote:
> > > > >>>
> > > > >>> Just FWIW, the situation described of having multiple commits in
> a
> > > > >>>
> > > > >>> single
> > > > >>>
> > > > >>> PR with separate associated JIRA tickets is still kind of
> > > problematic.
> > > > >>>
> > > > >>> It
> > > > >>>
> > > > >>> could well be the case that the commits are interdependent, thus
> > when
> > > > >>> bisecting etc it's still not possible to revert the fix for a
> > single
> > > > >>> bug/feature/whatever atomically. It's all good, though, I'm
> > > satisfied
> > > > >>>
> > > > >>> no
> > > > >>>
> > > > >>> one's forcing me to adopt practice I'm opposed to. Apologies for
> > > > >>>
> > > > >>> getting
> > > > >>>
> > > > >>> my feathers a little ruffled, or if I ruffled anyone else's in
> > > return.
> > > > >>>
> > > > >>> Thanks,
> > > > >>>
> > > > >>> Blake
> > > > >>>
> > > > >>>
> > > > >>> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io>
> > > wrote:
> > > > >>>
> > > > >>> Hi Dan,
> > > > >>>
> > > > >>> When we do squash merge all the commit messages are preserved and
> > > also
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> co-authored tag works when we do squash merge.
> > > > >>> So the authorship and history are preserved.
> > > > >>>
> > > > >>> In my own personal experience and reverts and pinpointing
> > regression
> > > > >>> failures are tough when the commits are spread out. Also, reverts
> > are
> > > > >>> easier when it is just one commit while we are bisecting
> failures.
> > > > >>>
> > > > >>>
> > > > >>> Regards
> > > > >>> Naba
> > > > >>>
> > > > >>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io>
> > > wrote:
> > > > >>>
> > > > >>> I'll change to -0.
> > > > >>>
> > > > >>> I think merge commits are a nice way to record history in some
> > cases,
> > > > >>>
> > > > >>> and
> > > > >>>
> > > > >>> can also be a way to avoid messy conflicts that come with rebase.
> > > > >>>
> > > > >>> Merge
> > > > >>>
> > > > >>> commits also preserve authorship of commits (compared to
> > > > >>>
> > > > >>> squash-merge),
> > > > >>>
> > > > >>> which I think is valuable as an open source community that is
> > trying
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> keep track of outside contributions.
> > > > >>>
> > > > >>> That said, if the rest of y'all feel it will help to disable the
> > > > >>>
> > > > >>> button,
> > > > >>>
> > > > >>> I
> > > > >>>
> > > > >>> won't stand in the way.
> > > > >>>
> > > > >>> -Dan
> > > > >>>
> > > > >>> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <
> abaker@pivotal.io>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>>
> > > > >>> Whether we are talking about the geode/ repository or the
> > > > >>>
> > > > >>> geode-native/
> > > > >>>
> > > > >>> repository we are all one GEODE community.
> > > > >>>
> > > > >>> The idea of a native client team may matter in some contexts but
> in
> > > > >>>
> > > > >>> this
> > > > >>>
> > > > >>> space we are all GEODE contributors.
> > > > >>>
> > > > >>> Adopting a common approach across our repos will make it easier
> for
> > > > >>>
> > > > >>> new
> > > > >>>
> > > > >>> contributors to engage, learn our norms, and join our efforts.
> > > > >>>
> > > > >>> $0.02,
> > > > >>> Anthony
> > > > >>>
> > > > >>>
> > > > >>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>>
> > > > >>> Is this a policy the native client team must abide by, as well?
> It
> > > > >>>
> > > > >>> varies
> > > > >>>
> > > > >>> slightly with what we've been doing, and all other things being
> > > > >>>
> > > > >>> equal I
> > > > >>>
> > > > >>> see
> > > > >>>
> > > > >>> no reason for us to change that. If I am to have any measure of
> > > > >>>
> > > > >>> control
> > > > >>>
> > > > >>> over the nc repository, I will definitely enforce a 1:1
> > > > >>>
> > > > >>> correspondence
> > > > >>>
> > > > >>> between commits to develop and JIRA tickets. IMO, if your
> > > > >>>
> > > > >>> refactoring
> > > > >>>
> > > > >>> in a
> > > > >>>
> > > > >>> PR is sufficiently large or complex that it's difficult to tease
> it
> > > > >>>
> > > > >>> out
> > > > >>>
> > > > >>> from the bug you're fixing or feature you're implementing, it
> > merits
> > > > >>>
> > > > >>> its
> > > > >>>
> > > > >>> own JIRA ticket and a separate PR. If your "actual" fix then
> > > > >>>
> > > > >>> becomes
> > > > >>>
> > > > >>> dependent on the refactored code, that's a price I'm willing to
> pay
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> keep
> > > > >>>
> > > > >>> history clean.
> > > > >>>
> > > > >>> On the other hand, I see no real value in squashing to a single
> > > > >>>
> > > > >>> commit
> > > > >>>
> > > > >>> prior to submitting a PR, since your view of the changes on
> GitHub
> > > > >>>
> > > > >>> is
> > > > >>>
> > > > >>> essentially the same either way. We haven't enforced this on the
> > nc
> > > > >>>
> > > > >>> repo,
> > > > >>>
> > > > >>> and I'd prefer to keep it that way.
> > > > >>>
> > > > >>> Thanks,
> > > > >>>
> > > > >>> Blake
> > > > >>>
> > > > >>>
> > > > >>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>>
> > > > >>> Merge commit is the new contributor's default setting. When we
> are
> > > > >>>
> > > > >>> merging
> > > > >>>
> > > > >>> new contributor's PR, since we are so used to THINKING
> > > > >>>
> > > > >>> "squash-and-merge"
> > > > >>>
> > > > >>> is the default, we forgot to check what the button really says
> when
> > > > >>>
> > > > >>> we
> > > > >>>
> > > > >>> are
> > > > >>>
> > > > >>> merging other people's PR.
> > > > >>>
> > > > >>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > > > >>>
> > > > >>> eburghardt@pivotal.io>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>> I'm a proponent of using squash-and-merge, and once a person has
> > > > >>>
> > > > >>> chosen
> > > > >>>
> > > > >>> this option once it comes up by default afterwards...
> > > > >>>
> > > > >>> Owen, I don't think you have consensus to put forth this PR,
> > > > >>>
> > > > >>> there
> > > > >>>
> > > > >>> are
> > > > >>>
> > > > >>> -1s
> > > > >>>
> > > > >>> above... (early voting)
> > > > >>>
> > > > >>> maybe we'll be better off socializing the norm of
> squash-and-merge
> > > > >>>
> > > > >>> and
> > > > >>>
> > > > >>> gaining a natural consensus that way...
> > > > >>>
> > > > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
> > > > >>>
> > > > >>> onichols@pivotal.io
> > > > >>>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>>
> > > > >>> The proposed action manifests as a commit to the Geode git
> > > > >>>
> > > > >>> repository,
> > > > >>>
> > > > >>> so
> > > > >>>
> > > > >>> a PR is an acceptable vehicle for voting in this case.
> > > > >>>
> > > > >>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > > > >>>
> > > > >>> bschuchardt@pivotal.io>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>>
> > > > >>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> > > > >>>
> > > > >>> thread
> > > > >>>
> > > > >>> and a request to "vote" using a PR. This all seems out of order
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> me.
> > > > >>>
> > > > >>> Our votes are supposed to be on the email list, aren't they? and
> > > > >>>
> > > > >>> I
> > > > >>>
> > > > >>> haven't
> > > > >>>
> > > > >>> seen a VOTE request.
> > > > >>>
> > > > >>>
> > > > >>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > > > >>>
> > > > >>> +1
> > > > >>>
> > > > >>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
> > > > >>>
> > > > >>> onichols@pivotal.io
> > > > >>>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>>
> > > > >>> Based on the feedback so far, I will amend the proposal to
> > > > >>>
> > > > >>> drop
> > > > >>>
> > > > >>> item
> > > > >>>
> > > > >>> 2).
> > > > >>>
> > > > >>> Therefore, the current ability to create merge commits using
> > > > >>>
> > > > >>> command-line
> > > > >>>
> > > > >>> git will remain available.
> > > > >>>
> > > > >>> The proposal as amended is now:
> > > > >>>
> > > > >>> Change GitHub settings to make "Squash and merge" the default
> > > > >>> (by removing “Create a merge commit” option).
> > > > >>>
> > > > >>> Update the PR template to change the text "Is your initial
> > > > >>>
> > > > >>> contribution
> > > > >>>
> > > > >>> a single, squashed commit” to “Is your initial contribution
> > > > >>>
> > > > >>> squashed
> > > > >>>
> > > > >>> for
> > > > >>>
> > > > >>> ease of review (e.g. a single commit, or a ‘refactoring’
> > > > >>>
> > > > >>> commit
> > > > >>>
> > > > >>> plus a
> > > > >>>
> > > > >>> ‘fix’ commit)"
> > > > >>>
> > > > >>>
> > > > >>> As Naba suggested, we can try it, and if we don’t like it,
> > > > >>>
> > > > >>> it’s
> > > > >>>
> > > > >>> simple
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> revert.
> > > > >>>
> > > > >>> I’ve create a PR for the proposed change here:
> > > > >>> https://github.com/apache/geode/pull/4513
> > > > >>>
> > > > >>> Please use the PR to vote for against this proposal. It will
> > > > >>>
> > > > >>> not
> > > > >>>
> > > > >>> be
> > > > >>>
> > > > >>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
> > > > >>>
> > > > >>> that
> > > > >>>
> > > > >>> time)
> > > > >>>
> > > > >>>
> > > > >>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>>
> > > > >>> +1
> > > > >>>
> > > > >>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
> > > > >>>
> > > > >>> onichols@pivotal.io>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>>
> > > > >>> Hi Bruce, this proposal will not waste a single second of
> > > > >>>
> > > > >>> your
> > > > >>>
> > > > >>> time. It
> > > > >>>
> > > > >>> just prevents people from accidentally pressing a button
> > > > >>>
> > > > >>> that
> > > > >>>
> > > > >>> we
> > > > >>>
> > > > >>> have
> > > > >>>
> > > > >>> already agreed should never be pressed, but because we never
> > > > >>>
> > > > >>> configured
> > > > >>>
> > > > >>> our
> > > > >>>
> > > > >>> GitHub to match our stated policy, is currently the default.
> > > > >>>
> > > > >>> However, it will save a lot of time and frustration for
> > > > >>>
> > > > >>> anyone
> > > > >>>
> > > > >>> needing
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> bisect failures, revert, or cherry-pick changes, which has
> > > > >>>
> > > > >>> merit
> > > > >>>
> > > > >>> even if
> > > > >>>
> > > > >>> you personally never do any of those three things.
> > > > >>>
> > > > >>> Please start a separate thread if you would like to revisit
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> community
> > > > >>>
> > > > >>> decision to require passing PR checks.
> > > > >>>
> > > > >>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > > > >>>
> > > > >>> bschuchardt@pivotal.io>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>> I agree with Jake. I would go further by saying that I see
> > > > >>>
> > > > >>> very
> > > > >>>
> > > > >>> little
> > > > >>>
> > > > >>> merit in this proposal. I think we're getting more and more
> > > > >>>
> > > > >>> bureaucratic
> > > > >>>
> > > > >>> in our process and that it stifles productivity. I was
> > > > >>>
> > > > >>> recently
> > > > >>>
> > > > >>> forced
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> spend three days fixing tests in which I had changed an
> > > > >>>
> > > > >>> import
> > > > >>>
> > > > >>> statement
> > > > >>>
> > > > >>> before they would pass stress testing. I'm glad the tests
> > > > >>>
> > > > >>> now
> > > > >>>
> > > > >>> pass
> > > > >>>
> > > > >>> reliably but I was very frustrated by the process.
> > > > >>>
> > > > >>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > > > >>>
> > > > >>> I’m in agreement with Dan. Changes to the infrastructure
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> flat
> > > > >>>
> > > > >>> out
> > > > >>>
> > > > >>> prevent things that should be self policing is annoying.
> > > > >>>
> > > > >>> This
> > > > >>>
> > > > >>> PR
> > > > >>>
> > > > >>> review
> > > > >>>
> > > > >>> lock we have had already cost us valuable time waiting for
> > > > >>>
> > > > >>> PR
> > > > >>>
> > > > >>> pipelines
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> pass that have no relevance to the commit, like CI work: I’d
> > > > >>>
> > > > >>> hat
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> see
> > > > >>>
> > > > >>> yet
> > > > >>>
> > > > >>> another process enforced that Kees us from getting work done
> > > > >>>
> > > > >>> when
> > > > >>>
> > > > >>> necessary.
> > > > >>>
> > > > >>> -Jake
> > > > >>>
> > > > >>>
> > > > >>> On Dec 19, 2019, at 4:43 PM, Dan Smith <
> > > > >>>
> > > > >>> dsmith@pivotal.io
> > > > >>>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>>
> > > > >>> -1 to (1) and (2).
> > > > >>>
> > > > >>> I think merge commits are appropriate in certain
> > > > >>>
> > > > >>> circumstances,
> > > > >>>
> > > > >>> so I
> > > > >>>
> > > > >>> don't
> > > > >>>
> > > > >>> think we should make a blanket restriction. In fact I
> > > > >>>
> > > > >>> think
> > > > >>>
> > > > >>> our
> > > > >>>
> > > > >>> release
> > > > >>>
> > > > >>> process involves some merges.
> > > > >>>
> > > > >>> I think setting standards on what is reasonable to be an
> > > > >>>
> > > > >>> individual
> > > > >>>
> > > > >>> commit
> > > > >>>
> > > > >>> will do a lot more to clean up our history than blocking
> > > > >>>
> > > > >>> merges.
> > > > >>>
> > > > >>> We'd
> > > > >>>
> > > > >>> rather not see commits like "Spotless Apply" in the
> > > > >>>
> > > > >>> history,
> > > > >>>
> > > > >>> but
> > > > >>>
> > > > >>> if
> > > > >>>
> > > > >>> reasonably separate and well written commits come in as
> > > > >>>
> > > > >>> part
> > > > >>>
> > > > >>> of
> > > > >>>
> > > > >>> a
> > > > >>>
> > > > >>> merge, I
> > > > >>>
> > > > >>> think that's fine.
> > > > >>>
> > > > >>> -Dan
> > > > >>>
> > > > >>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> > > > >>>
> > > > >>> jiliao@pivotal.io
> > > > >>>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>> +1
> > > > >>>
> > > > >>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> > > > >>>
> > > > >>> onichols@pivotal.io
> > > > >>>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>> I’d like to advance this topic from an informal
> > > > >>>
> > > > >>> request/discussion
> > > > >>>
> > > > >>> to a
> > > > >>>
> > > > >>> discussion of a concrete proposal.
> > > > >>>
> > > > >>> To recap, it sounds like there is general agreement
> > > > >>>
> > > > >>> that
> > > > >>>
> > > > >>> commit
> > > > >>>
> > > > >>> history
> > > > >>>
> > > > >>> on
> > > > >>>
> > > > >>> develop should be linear (no merge commits), and that
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> biggest
> > > > >>>
> > > > >>> obstacle
> > > > >>>
> > > > >>> to this is that the PR merge button in GitHub creates a
> > > > >>>
> > > > >>> merge
> > > > >>>
> > > > >>> commit
> > > > >>>
> > > > >>> by
> > > > >>>
> > > > >>> default.
> > > > >>>
> > > > >>> I propose the following changes:
> > > > >>> 1) Change GitHub settings to remove the ability to
> > > > >>>
> > > > >>> create
> > > > >>>
> > > > >>> a
> > > > >>>
> > > > >>> merge
> > > > >>>
> > > > >>> commit.
> > > > >>>
> > > > >>> This will make Squash & Merge the default.
> > > > >>>
> > > > >>> 2) Change GitHub settings to require linear history on
> > > > >>>
> > > > >>> develop.
> > > > >>>
> > > > >>> This
> > > > >>>
> > > > >>> prevents merge commits via command-line (not
> > > > >>>
> > > > >>> recommended,
> > > > >>>
> > > > >>> but
> > > > >>>
> > > > >>> wiki
> > > > >>>
> > > > >>> still
> > > > >>>
> > > > >>> has instructions for merging PRs this way).
> > > > >>>
> > > > >>> 3) Update the PR template to change the text "Is your
> > > > >>>
> > > > >>> initial
> > > > >>>
> > > > >>> contribution
> > > > >>>
> > > > >>> a single, squashed commit” to “Is your initial
> > > > >>>
> > > > >>> contribution
> > > > >>>
> > > > >>> squashed
> > > > >>>
> > > > >>> for
> > > > >>>
> > > > >>> ease of review (e.g. a single commit, or a
> > > > >>>
> > > > >>> ‘refactoring’
> > > > >>>
> > > > >>> commit
> > > > >>>
> > > > >>> plus
> > > > >>>
> > > > >>> a
> > > > >>>
> > > > >>> ‘fix’ commit)"
> > > > >>>
> > > > >>> For clarity, I am proposing no-change in the following
> > > > >>>
> > > > >>> areas:
> > > > >>>
> > > > >>> i) Leave Rebase & Merge as an option for PRs that have
> > > > >>>
> > > > >>> been
> > > > >>>
> > > > >>> structured to
> > > > >>>
> > > > >>> benefit from it (this can make it easier in a bisect to
> > > > >>>
> > > > >>> see
> > > > >>>
> > > > >>> whether
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> refactoring or the “fix” broke something).
> > > > >>> ii) Leave existing wording in the wiki as-is [stating
> > > > >>>
> > > > >>> that
> > > > >>>
> > > > >>> squashing
> > > > >>>
> > > > >>> is
> > > > >>>
> > > > >>> preferred].
> > > > >>>
> > > > >>>
> > > > >>> Please comment via this email thread.
> > > > >>> -Owen
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> > > > >>>
> > > > >>> klund@apache.org>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>>
> > > > >>> I think it's already resolved Udo ;)
> > > > >>>
> > > > >>> Here's the problem, if I fixup a dunit test by
> > > > >>>
> > > > >>> removing
> > > > >>>
> > > > >>> all
> > > > >>>
> > > > >>> uses
> > > > >>>
> > > > >>> of
> > > > >>>
> > > > >>> "this."
> > > > >>>
> > > > >>> and I rename the dunit test, then git doesn't remember
> > > > >>>
> > > > >>> that
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> file
> > > > >>>
> > > > >>> is a
> > > > >>>
> > > > >>> rename -- it forever afterwards interprets it as a new
> > > > >>>
> > > > >>> file
> > > > >>>
> > > > >>> that I
> > > > >>>
> > > > >>> created
> > > > >>>
> > > > >>> if I touch more than 50% of the lines (which "this."
> > > > >>>
> > > > >>> can
> > > > >>>
> > > > >>> easily
> > > > >>>
> > > > >>> do). If
> > > > >>>
> > > > >>> we
> > > > >>>
> > > > >>> squash two commits: the rename and the cleanup of that
> > > > >>>
> > > > >>> dunit
> > > > >>>
> > > > >>> test
> > > > >>>
> > > > >>> --
> > > > >>>
> > > > >>> then
> > > > >>>
> > > > >>> we effectively lose the history of that file and it
> > > > >>>
> > > > >>> shows
> > > > >>>
> > > > >>> that
> > > > >>>
> > > > >>> I
> > > > >>>
> > > > >>> created
> > > > >>>
> > > > >>> a
> > > > >>>
> > > > >>> new file.
> > > > >>>
> > > > >>> Also for the record, I've been working on Geode since
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> beginning
> > > > >>>
> > > > >>> and I
> > > > >>>
> > > > >>> was never made aware of this change in our process. I
> > > > >>>
> > > > >>> never
> > > > >>>
> > > > >>> voted
> > > > >>>
> > > > >>> on
> > > > >>>
> > > > >>> it.
> > > > >>>
> > > > >>> I'm not a big fan of changing various details in our
> > > > >>>
> > > > >>> process
> > > > >>>
> > > > >>> every
> > > > >>>
> > > > >>> single
> > > > >>>
> > > > >>> week. It's very easy to miss these discussions unless
> > > > >>>
> > > > >>> someone
> > > > >>>
> > > > >>> points it
> > > > >>>
> > > > >>> out
> > > > >>>
> > > > >>> to me.
> > > > >>>
> > > > >>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > > > >>>
> > > > >>> ukohlmeyer@pivotal.io>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>> I'm not sure what this discussion is about... WE, as
> > > > >>>
> > > > >>> a
> > > > >>>
> > > > >>> community,
> > > > >>>
> > > > >>> have
> > > > >>>
> > > > >>> agreed in common practices, in two place no less...
> > > > >>>
> > > > >>> 1) Quoting our PR template
> > > > >>>
> > > > >>>
> > > > >>> For all changes:
> > > > >>>
> > > > >>> *
> > > > >>>
> > > > >>> Is there a JIRA ticket associated with this PR? Is it
> > > > >>>
> > > > >>> referenced
> > > > >>>
> > > > >>> in
> > > > >>>
> > > > >>> the commit message?
> > > > >>>
> > > > >>> *
> > > > >>>
> > > > >>> Has your PR been rebased against the latest commit
> > > > >>>
> > > > >>> within
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> target
> > > > >>>
> > > > >>> branch (typically|develop|)?
> > > > >>>
> > > > >>> *
> > > > >>>
> > > > >>> ***Is your initial contribution a single, squashed
> > > > >>>
> > > > >>> commit?*
> > > > >>>
> > > > >>>
> > > > >>> *
> > > > >>>
> > > > >>> Does|gradlew build|run cleanly?
> > > > >>>
> > > > >>> *
> > > > >>>
> > > > >>> Have you written or updated unit tests to verify your
> > > > >>>
> > > > >>> changes?
> > > > >>>
> > > > >>>
> > > > >>> *
> > > > >>>
> > > > >>> If adding new dependencies to the code, are these
> > > > >>>
> > > > >>> dependencies
> > > > >>>
> > > > >>> licensed in a way that is compatible for inclusion
> > > > >>>
> > > > >>> underASF
> > > > >>>
> > > > >>> 2.0
> > > > >>>
> > > > >>> <
> > > > >>>
> > > > >>> http://www.apache.org/legal/resolved.html#category-a
> > > > >>>
> > > > >>> ?
> > > > >>>
> > > > >>>
> > > > >>> On our PR template we call out that the initial PR
> > > > >>>
> > > > >>> commit
> > > > >>>
> > > > >>> should
> > > > >>>
> > > > >>> be
> > > > >>>
> > > > >>> squashed.
> > > > >>>
> > > > >>> 2)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > > >>>
> > > > >>> <
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > > >>>
> > > > >>> -- See "Accepting a PR Using the Command Line" -
> > > > >>>
> > > > >>> Point
> > > > >>>
> > > > >>> #3.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> @Kirk, if each of your commits "stands alone", I
> > > > >>>
> > > > >>> commend
> > > > >>>
> > > > >>> you
> > > > >>>
> > > > >>> on
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> diligence, but in reality, they should either then be
> > > > >>>
> > > > >>> stand
> > > > >>>
> > > > >>> alone
> > > > >>>
> > > > >>> PR's
> > > > >>>
> > > > >>> or just extra work created for yourself.
> > > > >>>
> > > > >>> If we want to change the way we have agreed upon we
> > > > >>>
> > > > >>> submit/commit/merge
> > > > >>>
> > > > >>> changes back into develop... Then this is another
> > > > >>>
> > > > >>> discussion
> > > > >>>
> > > > >>> thread,
> > > > >>>
> > > > >>> until then, I think we should all remind ourselves on
> > > > >>>
> > > > >>> our
> > > > >>>
> > > > >>> agreed
> > > > >>>
> > > > >>> contributions code of conduct.
> > > > >>>
> > > > >>> --Udo
> > > > >>>
> > > > >>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > > > >>>
> > > > >>> Kirk, I believe that creating a Pull Request with
> > > > >>>
> > > > >>> multiple
> > > > >>>
> > > > >>> commits is
> > > > >>>
> > > > >>> ok.
> > > > >>>
> > > > >>> It's just in the end that when it's being pushed to
> > > > >>>
> > > > >>> develop
> > > > >>>
> > > > >>> branch,
> > > > >>>
> > > > >>> it
> > > > >>>
> > > > >>> needs to be squash merged. I believe that is what
> > > > >>>
> > > > >>> you
> > > > >>>
> > > > >>> have
> > > > >>>
> > > > >>> mentioned
> > > > >>>
> > > > >>> in
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> first paragraph, and I am more than happy with that.
> > > > >>> If you can see in the first screenshot comparison
> > > > >>>
> > > > >>> that
> > > > >>>
> > > > >>> I
> > > > >>>
> > > > >>> had
> > > > >>>
> > > > >>> attached
> > > > >>>
> > > > >>> in
> > > > >>>
> > > > >>> the first email in this thread is what I want to
> > > > >>>
> > > > >>> avoid.
> > > > >>>
> > > > >>>
> > > > >>> Thank you for your feedback.
> > > > >>>
> > > > >>> Regards
> > > > >>> Naba
> > > > >>>
> > > > >>>
> > > > >>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> > > > >>>
> > > > >>> klund@apache.org>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>> Whenever I submit a PR with multiple commits that I
> > > > >>>
> > > > >>> intend
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> rebase
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> develop, I always try to ensure that each commit
> > > > >>>
> > > > >>> stands
> > > > >>>
> > > > >>> alone
> > > > >>>
> > > > >>> as
> > > > >>>
> > > > >>> is
> > > > >>>
> > > > >>> (compiles and passes tests). Separating file
> > > > >>>
> > > > >>> renames
> > > > >>>
> > > > >>> and
> > > > >>>
> > > > >>> refactoring
> > > > >>>
> > > > >>> from
> > > > >>>
> > > > >>> behavior changes into different commits seems very
> > > > >>>
> > > > >>> valuable
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> me,
> > > > >>>
> > > > >>> and
> > > > >>>
> > > > >>> I've
> > > > >>>
> > > > >>> had trouble getting people to review PRs without
> > > > >>>
> > > > >>> this
> > > > >>>
> > > > >>> separation
> > > > >>>
> > > > >>> (but
> > > > >>>
> > > > >>> it
> > > > >>>
> > > > >>> could be squashed as it's merged to develop).
> > > > >>>
> > > > >>> It sounds to me like the real problem is (a) some
> > > > >>>
> > > > >>> PRs
> > > > >>>
> > > > >>> have
> > > > >>>
> > > > >>> multiple
> > > > >>>
> > > > >>> commits
> > > > >>>
> > > > >>> that don't compile or don't pass tests, and (b)
> > > > >>>
> > > > >>> some
> > > > >>>
> > > > >>> PRs
> > > > >>>
> > > > >>> that
> > > > >>>
> > > > >>> should
> > > > >>>
> > > > >>> be
> > > > >>>
> > > > >>> merged with squash are not (by accident most
> > > > >>>
> > > > >>> likely).
> > > > >>>
> > > > >>>
> > > > >>> I can submit multiple PRs instead of one PR with
> > > > >>>
> > > > >>> multiple
> > > > >>>
> > > > >>> commits.
> > > > >>>
> > > > >>> So
> > > > >>>
> > > > >>> I'll
> > > > >>>
> > > > >>> change my response to -0 if that helps prevent
> > > > >>>
> > > > >>> commits
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> develop
> > > > >>>
> > > > >>> that
> > > > >>>
> > > > >>> don't compile or pass tests. Without preventing
> > > > >>>
> > > > >>> rebase
> > > > >>>
> > > > >>> or
> > > > >>>
> > > > >>> merge
> > > > >>>
> > > > >>> commits
> > > > >>>
> > > > >>> from github, I'm not sure how we can really enforce
> > > > >>>
> > > > >>> this
> > > > >>>
> > > > >>> or
> > > > >>>
> > > > >>> prevent
> > > > >>>
> > > > >>> (b)
> > > > >>>
> > > > >>> above.
> > > > >>>
> > > > >>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > > > >>>
> > > > >>> amurmann@pivotal.io>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>> I wonder if Kirk's and Naba's statements are
> > > > >>>
> > > > >>> necessarily
> > > > >>>
> > > > >>> at
> > > > >>>
> > > > >>> odds.
> > > > >>>
> > > > >>> Make the change easy (warning: this may be hard),
> > > > >>>
> > > > >>> then
> > > > >>>
> > > > >>> make
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> easy
> > > > >>>
> > > > >>> change."
> > > > >>>
> > > > >>> -Kent Beck
> > > > >>>
> > > > >>> Following Kent Beck's advise might reasonably
> > > > >>>
> > > > >>> split
> > > > >>>
> > > > >>> into
> > > > >>>
> > > > >>> two
> > > > >>>
> > > > >>> commits.
> > > > >>>
> > > > >>> One
> > > > >>>
> > > > >>> refactor commit and a separate commit that
> > > > >>>
> > > > >>> introduces
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> actual
> > > > >>>
> > > > >>> change.
> > > > >>>
> > > > >>> They should be individually revertible and might
> > > > >>>
> > > > >>> be
> > > > >>>
> > > > >>> easier
> > > > >>>
> > > > >>> understood
> > > > >>>
> > > > >>> if
> > > > >>>
> > > > >>> split out. I vividly remember a change on our code
> > > > >>>
> > > > >>> base
> > > > >>>
> > > > >>> where
> > > > >>>
> > > > >>> someone
> > > > >>>
> > > > >>> did a
> > > > >>>
> > > > >>> huge amount of refactoring that resulted than in
> > > > >>>
> > > > >>> one
> > > > >>>
> > > > >>> parameter
> > > > >>>
> > > > >>> changing
> > > > >>>
> > > > >>> in
> > > > >>>
> > > > >>> order to get the desired functionality change. If
> > > > >>>
> > > > >>> that
> > > > >>>
> > > > >>> was
> > > > >>>
> > > > >>> in
> > > > >>>
> > > > >>> one
> > > > >>>
> > > > >>> commit,
> > > > >>>
> > > > >>> it would be hard to see the actual change. If
> > > > >>>
> > > > >>> split
> > > > >>>
> > > > >>> out,
> > > > >>>
> > > > >>> it's
> > > > >>>
> > > > >>> beautiful
> > > > >>>
> > > > >>> and
> > > > >>>
> > > > >>> crystal clear.
> > > > >>>
> > > > >>> I am unsure how that would be reflected in terms
> > > > >>>
> > > > >>> of
> > > > >>>
> > > > >>> JIRA
> > > > >>>
> > > > >>> ticket
> > > > >>>
> > > > >>> references.
> > > > >>>
> > > > >>> Usually we assume that if there is a commit with
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> ticket
> > > > >>>
> > > > >>> number,
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> issue is resolved. Maybe the key here is to create
> > > > >>>
> > > > >>> a
> > > > >>>
> > > > >>> separate
> > > > >>>
> > > > >>> refactoring
> > > > >>>
> > > > >>> ticket.
> > > > >>>
> > > > >>> Would that allow us to have our cake and eat it
> > > > >>>
> > > > >>> too?
> > > > >>>
> > > > >>>
> > > > >>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> > > > >>>
> > > > >>> nnag@pivotal.io>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>> It is to help with bisect operations when things
> > > > >>>
> > > > >>> start
> > > > >>>
> > > > >>> failing
> > > > >>>
> > > > >>> ...
> > > > >>>
> > > > >>> helps
> > > > >>>
> > > > >>> us
> > > > >>>
> > > > >>> it revert and build faster.
> > > > >>> also with cherry picking features / fixes to
> > > > >>>
> > > > >>> previous
> > > > >>>
> > > > >>> versions
> > > > >>>
> > > > >>> .
> > > > >>>
> > > > >>> And keeping the git history clean with no
> > > > >>>
> > > > >>> unnecessary
> > > > >>>
> > > > >>> “merge
> > > > >>>
> > > > >>> commits”.
> > > > >>>
> > > > >>> Regards
> > > > >>> Naba
> > > > >>>
> > > > >>>
> > > > >>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> > > > >>>
> > > > >>> klund@apache.org>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>> -1 I really like to sometimes have more than 1
> > > > >>>
> > > > >>> commit
> > > > >>>
> > > > >>> in
> > > > >>>
> > > > >>> a
> > > > >>>
> > > > >>> PR
> > > > >>>
> > > > >>> and
> > > > >>>
> > > > >>> keep
> > > > >>>
> > > > >>> them
> > > > >>>
> > > > >>> separate when they merge to develop
> > > > >>>
> > > > >>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> > > > >>>
> > > > >>> nnag@pivotal.io>
> > > > >>>
> > > > >>> wrote:
> > > > >>>
> > > > >>> Hi Geode Committers,
> > > > >>>
> > > > >>> A kind request for using squash commit instead
> > > > >>>
> > > > >>> of
> > > > >>>
> > > > >>> using
> > > > >>>
> > > > >>> merge.
> > > > >>>
> > > > >>> This will really help us in our bisect
> > > > >>>
> > > > >>> operations
> > > > >>>
> > > > >>> when a
> > > > >>>
> > > > >>> regression/flakiness in the product is
> > > > >>>
> > > > >>> introduced.
> > > > >>>
> > > > >>> We
> > > > >>>
> > > > >>> can
> > > > >>>
> > > > >>> automate
> > > > >>>
> > > > >>> and
> > > > >>>
> > > > >>> go
> > > > >>>
> > > > >>> through fewer commits faster, avoiding commits
> > > > >>>
> > > > >>> like
> > > > >>>
> > > > >>> "spotless
> > > > >>>
> > > > >>> fix"
> > > > >>>
> > > > >>> and
> > > > >>>
> > > > >>> "re-trigger precheck-in" or other minor commits
> > > > >>>
> > > > >>> in
> > > > >>>
> > > > >>> the
> > > > >>>
> > > > >>> merged
> > > > >>>
> > > > >>> branch.
> > > > >>>
> > > > >>> Also, please use the commit format : (helps us
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> know
> > > > >>>
> > > > >>> who
> > > > >>>
> > > > >>> worked
> > > > >>>
> > > > >>> on
> > > > >>>
> > > > >>> it,
> > > > >>>
> > > > >>> what is the history)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> * GEODE-xxxx: <brief intro >
> > > > >>> * explanation line 1
> > > > >>>
> > > > >>> *
> > > > >>>
> > > > >>> explanation
> > > > >>>
> > > > >>> line
> > > > >>>
> > > > >>> 2*
> > > > >>>
> > > > >>> This is not a rule or anything, but a request
> > > > >>>
> > > > >>> to
> > > > >>>
> > > > >>> help
> > > > >>>
> > > > >>> out
> > > > >>>
> > > > >>> your
> > > > >>>
> > > > >>> fellow
> > > > >>>
> > > > >>> committers in quickly detecting a problem.
> > > > >>>
> > > > >>> For inspiration, we can look into Apache Kafka
> > > > >>>
> > > > >>> /
> > > > >>>
> > > > >>> Spark
> > > > >>>
> > > > >>> where
> > > > >>>
> > > > >>> they
> > > > >>>
> > > > >>> have
> > > > >>>
> > > > >>> a
> > > > >>>
> > > > >>> complete linear graph for their main branch
> > > > >>>
> > > > >>> HEAD
> > > > >>>
> > > > >>> [see
> > > > >>>
> > > > >>> attachment]
> > > > >>>
> > > > >>> Regards
> > > > >>> Naba.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>>
> > > > >>> Ju@N
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>> Cheers
> > > > >>>
> > > > >>> Jinmei
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
It sounds like there is value in being able to deliver un-squashed PRs, and
we believe the richer commit message history outweighs any potential
inconvenience to bisect operations (as Aaron pointed out, finer-grained
commits should generally be to the benefit of bisect operations).
We will leave all 3 merge options enabled in GitHub.
On Tue, Dec 31, 2019 at 7:27 PM Dan Smith <ds...@pivotal.io> wrote:
> I also tend to do the same workflow Aaron described - make a refactoring
> change to support a feature followed by the actual change I want to make.
> It makes the history a lot clearer because refactoring tends to touch a lot
> of files, so it's nice to have those changes clearly marked as a
> refactoring that should not change behavior.
>
> It's possible to do this as to separate PRs, but that drags out the process
> because you have to get the first in merged before you create the second.
> That encourages bunching changes in a single squashed commit, which makes
> git blame less useful.
>
>
> -Dan
>
> On Tue, Dec 31, 2019, 6:36 PM Nabarun Nag <nn...@apache.org> wrote:
>
> > Aaron ,
> >
> > Is it not the case currently? If I am working on a feature modifying
> class
> > X and another developer makes some refactoring changes on class X and
> > pushes it to develop, won't I have to resolve the merge commits anyway.
> >
> >
> > Regards
> > Naba
> >
> >
> > On Tue, Dec 31, 2019 at 6:01 PM Aaron Lindsey <aa...@apache.org>
> > wrote:
> >
> > > Suppose I’m refactoring the same classes I’m touching for the feature.
> I
> > > do the refactoring on one branch and submit a PR for that. Then I
> > implement
> > > the feature on another branch which is based on develop and does not
> have
> > > the refactoring changes since those are not merged yet. I’ll have to
> > > resolve conflicts on the second PR that I merge.
> > >
> > > Having interdependent PRs where one PR branch is based on another PR
> > > branch is not something I’ve tried. That requires more overhead in
> having
> > > to create more PRs and branches. And if you have N interdependent PRs,
> > you
> > > have to do N-1 merges each time a PR is merged to develop (to update
> the
> > > other branches). It could be done, but is it worth the hassle?
> > >
> > > One more point about rebase-and-merge is that it seems like this would
> > > make bisecting a failure easier since there would be smaller commits.
> > >
> > > Aaron
> > >
> > > > On Dec 31, 2019, at 5:41 PM, Owen Nichols <on...@pivotal.io>
> wrote:
> > > >
> > > > Can you elaborate on why you would have to deal with conflicts if the
> > > > refactoring work was kept as a separate PR from the fix?
> > > >
> > > > As with many git workflows, there’s an easy way and a hard way to
> > manage
> > > > interdependent PRs (tl;dr only merge, never rebase!). I wonder if
> this
> > > > points out an opportunity for a “tips and tricks” page on the Geode
> > wiki.
> > > >
> > > > On Tue, Dec 31, 2019 at 5:22 PM Aaron Lindsey <
> aaronlindsey@apache.org
> > >
> > > > wrote:
> > > >
> > > >> -0.9
> > > >>
> > > >> I’m not in favor of the revised proposal that disallows
> > > rebase-and-merge.
> > > >> Say I am working on a PR and I have a refactor commit and another
> > commit
> > > >> which implements a new feature. I don’t want those commits to get
> > > squashed
> > > >> because that makes it hard to understand the diff. However, if I
> make
> > > those
> > > >> commits as two separate PRs then I am going to have to deal with
> > > conflicts.
> > > >>
> > > >> I’m not sure when we made it a rule that every commit in develop had
> > to
> > > >> compile and pass tests. I know we implemented a rule that all PRs
> had
> > to
> > > >> pass certain checks, but I never thought that rule implied all
> commits
> > > had
> > > >> to pass those checks.
> > > >>
> > > >> In general I just don’t see the problem with rebase-and-merge and
> this
> > > >> feels like an unnecessary restriction, but I will go with it if
> that’s
> > > what
> > > >> everyone wants to do.
> > > >>
> > > >> Aaron
> > > >>
> > > >>> On Dec 31, 2019, at 3:09 PM, Owen Nichols <on...@pivotal.io>
> > wrote:
> > > >>>
> > > >>> To recap, this proposal is now revised to remove 2 of the 3 merge
> > > options
> > > >>> from GitHub, leaving only Squash and Merge. PR #4513
> > > >>> <https://github.com/apache/geode/pull/4513> serves as an exhibit
> of
> > > >> what is
> > > >>> proposed (it is not to be merged unless discussion leads to
> consensus
> > > >> and a
> > > >>> successful vote). Please use the dev list (not the PR) for all
> > > >> discussion
> > > >>> (and voting, if we get that far).
> > > >>>
> > > >>> Squash and merge is already used almost exclusively by the Geode
> > > >> community,
> > > >>> with any exceptions tending to be accidental more often than
> > > intentional.
> > > >>> However, some have raised the concern that implementing this
> > > restriction
> > > >>> could result in harm or wasted time. Can someone give an example
> of
> > a
> > > >> such
> > > >>> a scenario?
> > > >>>
> > > >>> It seems there is a divide here between junior and senior community
> > > >>> members. Newer committers appreciate additional guardrails to
> > protect
> > > >> them
> > > >>> from accidentally doing the wrong thing, while those with more
> > > experience
> > > >>> want to be able to work unencumbered by restrictions of any kind.
> > > >>>
> > > >>> Our welcome email to new committers states “We like to work on
> trust
> > > >> rather
> > > >>> than unnecessary constraints...Being a committer enables you to
> more
> > > >> easily
> > > >>> make changes without needing to go through the patch submission
> > > process”.
> > > >>> I can see this as an argument against this proposal (perhaps even
> an
> > > >>> argument against any form of branch protection).
> > > >>>
> > > >>> In the scheme of things, this proposal makes very little
> difference.
> > > >> There
> > > >>> are still other ways to get non-compiling commits onto develop
> (e.g.
> > > >>> waiting a long time between running PR checks and merging to
> > develop).
> > > >>> What’s more important is working well together as a community. So,
> > > >> perhaps
> > > >>> what’s best for the community is to encourage working on trust
> rather
> > > >> than
> > > >>> unnecessary constraints.
> > > >>>
> > > >>> -Owen
> > > >>>
> > > >>> On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org> wrote:
> > > >>>
> > > >>> I'm happy to file multiple PRs when I need to merge multiple
> commits
> > to
> > > >>> develop.
> > > >>>
> > > >>> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <mh...@pivotal.io>
> > > wrote:
> > > >>>
> > > >>> This change to disable all but squash-merge would be really easy to
> > > >>> revert. How about we try it for a while and see? If people decide
> it
> > is
> > > >>> really limiting them, we can change it back. Let’s do it for 1
> month
> > > and
> > > >>> see how it goes. Does that sound reasonable?
> > > >>>
> > > >>> Thanks,
> > > >>> Mark
> > > >>>
> > > >>> On Dec 30, 2019, at 5:25 PM, Owen Nichols <on...@pivotal.io>
> > wrote:
> > > >>>
> > > >>> Given that we adopted <
> > > >>>
> > > >>>
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
> > > >>>>
> > > >>> and still wish to continue <
> > > >>>
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
> > > >>>>
> > > >>> having branch protection rules to ensure every commit landing in
> > > develop
> > > >>> has passed the required PR checks, it seems like that decision
> alone
> > > >>> mandates that we disable all merge mechanisms other than
> > > >> squash-and-merge.
> > > >>>
> > > >>>
> > > >>> Allowing merge commits or rebase merges bypasses branch protection
> > for
> > > >>>
> > > >>> all commits other than the final one in the merge or rebase set.
> > Given
> > > >>> that we decided <
> > > >>>
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
> > > >>>>
> > > >>> that bypassing PR checks should never be allowed, keeping this
> > loophole
> > > >>> open seems untenable.
> > > >>>
> > > >>>
> > > >>> This is not just hypothetical — this loophole is causing real
> > problems.
> > > >>>
> > > >>> We now have commits on develop that don’t compile. For example:
> > > >>>
> > > >>> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> > > >>> ./gradlew devBuild
> > > >>> ...spotlessJava FAILED
> > > >>> We implemented branch protections to make this impossible, right?
> > > >>>
> > > >>> We can very easily close this loophole by disabling all but the
> > > >>>
> > > >>> Squash&Merge button for PRs. This will not make more work for any
> > > >>> developer. If you want to get multiple commits onto develop,
> simply
> > > >> submit
> > > >>> each as a separate PR — that is the only way to assure that
> required
> > PR
> > > >>> checks have passed for each.
> > > >>>
> > > >>>
> > > >>> On the other hand, if we as a Geode community feel strongly that
> > > >>>
> > > >>> bypassing branch protection via merge commits and rebase commits is
> > > >>> important to allow, why not also allow arbitrary overrides (or get
> > rid
> > > of
> > > >>> branch protection entirely)?
> > > >>>
> > > >>>
> > > >>> -Owen
> > > >>>
> > > >>> On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io>
> > wrote:
> > > >>>
> > > >>> Just FWIW, the situation described of having multiple commits in a
> > > >>>
> > > >>> single
> > > >>>
> > > >>> PR with separate associated JIRA tickets is still kind of
> > problematic.
> > > >>>
> > > >>> It
> > > >>>
> > > >>> could well be the case that the commits are interdependent, thus
> when
> > > >>> bisecting etc it's still not possible to revert the fix for a
> single
> > > >>> bug/feature/whatever atomically. It's all good, though, I'm
> > satisfied
> > > >>>
> > > >>> no
> > > >>>
> > > >>> one's forcing me to adopt practice I'm opposed to. Apologies for
> > > >>>
> > > >>> getting
> > > >>>
> > > >>> my feathers a little ruffled, or if I ruffled anyone else's in
> > return.
> > > >>>
> > > >>> Thanks,
> > > >>>
> > > >>> Blake
> > > >>>
> > > >>>
> > > >>> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io>
> > wrote:
> > > >>>
> > > >>> Hi Dan,
> > > >>>
> > > >>> When we do squash merge all the commit messages are preserved and
> > also
> > > >>>
> > > >>> the
> > > >>>
> > > >>> co-authored tag works when we do squash merge.
> > > >>> So the authorship and history are preserved.
> > > >>>
> > > >>> In my own personal experience and reverts and pinpointing
> regression
> > > >>> failures are tough when the commits are spread out. Also, reverts
> are
> > > >>> easier when it is just one commit while we are bisecting failures.
> > > >>>
> > > >>>
> > > >>> Regards
> > > >>> Naba
> > > >>>
> > > >>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io>
> > wrote:
> > > >>>
> > > >>> I'll change to -0.
> > > >>>
> > > >>> I think merge commits are a nice way to record history in some
> cases,
> > > >>>
> > > >>> and
> > > >>>
> > > >>> can also be a way to avoid messy conflicts that come with rebase.
> > > >>>
> > > >>> Merge
> > > >>>
> > > >>> commits also preserve authorship of commits (compared to
> > > >>>
> > > >>> squash-merge),
> > > >>>
> > > >>> which I think is valuable as an open source community that is
> trying
> > > >>>
> > > >>> to
> > > >>>
> > > >>> keep track of outside contributions.
> > > >>>
> > > >>> That said, if the rest of y'all feel it will help to disable the
> > > >>>
> > > >>> button,
> > > >>>
> > > >>> I
> > > >>>
> > > >>> won't stand in the way.
> > > >>>
> > > >>> -Dan
> > > >>>
> > > >>> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>>
> > > >>> Whether we are talking about the geode/ repository or the
> > > >>>
> > > >>> geode-native/
> > > >>>
> > > >>> repository we are all one GEODE community.
> > > >>>
> > > >>> The idea of a native client team may matter in some contexts but in
> > > >>>
> > > >>> this
> > > >>>
> > > >>> space we are all GEODE contributors.
> > > >>>
> > > >>> Adopting a common approach across our repos will make it easier for
> > > >>>
> > > >>> new
> > > >>>
> > > >>> contributors to engage, learn our norms, and join our efforts.
> > > >>>
> > > >>> $0.02,
> > > >>> Anthony
> > > >>>
> > > >>>
> > > >>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>>
> > > >>> Is this a policy the native client team must abide by, as well? It
> > > >>>
> > > >>> varies
> > > >>>
> > > >>> slightly with what we've been doing, and all other things being
> > > >>>
> > > >>> equal I
> > > >>>
> > > >>> see
> > > >>>
> > > >>> no reason for us to change that. If I am to have any measure of
> > > >>>
> > > >>> control
> > > >>>
> > > >>> over the nc repository, I will definitely enforce a 1:1
> > > >>>
> > > >>> correspondence
> > > >>>
> > > >>> between commits to develop and JIRA tickets. IMO, if your
> > > >>>
> > > >>> refactoring
> > > >>>
> > > >>> in a
> > > >>>
> > > >>> PR is sufficiently large or complex that it's difficult to tease it
> > > >>>
> > > >>> out
> > > >>>
> > > >>> from the bug you're fixing or feature you're implementing, it
> merits
> > > >>>
> > > >>> its
> > > >>>
> > > >>> own JIRA ticket and a separate PR. If your "actual" fix then
> > > >>>
> > > >>> becomes
> > > >>>
> > > >>> dependent on the refactored code, that's a price I'm willing to pay
> > > >>>
> > > >>> to
> > > >>>
> > > >>> keep
> > > >>>
> > > >>> history clean.
> > > >>>
> > > >>> On the other hand, I see no real value in squashing to a single
> > > >>>
> > > >>> commit
> > > >>>
> > > >>> prior to submitting a PR, since your view of the changes on GitHub
> > > >>>
> > > >>> is
> > > >>>
> > > >>> essentially the same either way. We haven't enforced this on the
> nc
> > > >>>
> > > >>> repo,
> > > >>>
> > > >>> and I'd prefer to keep it that way.
> > > >>>
> > > >>> Thanks,
> > > >>>
> > > >>> Blake
> > > >>>
> > > >>>
> > > >>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>>
> > > >>> Merge commit is the new contributor's default setting. When we are
> > > >>>
> > > >>> merging
> > > >>>
> > > >>> new contributor's PR, since we are so used to THINKING
> > > >>>
> > > >>> "squash-and-merge"
> > > >>>
> > > >>> is the default, we forgot to check what the button really says when
> > > >>>
> > > >>> we
> > > >>>
> > > >>> are
> > > >>>
> > > >>> merging other people's PR.
> > > >>>
> > > >>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > > >>>
> > > >>> eburghardt@pivotal.io>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>> I'm a proponent of using squash-and-merge, and once a person has
> > > >>>
> > > >>> chosen
> > > >>>
> > > >>> this option once it comes up by default afterwards...
> > > >>>
> > > >>> Owen, I don't think you have consensus to put forth this PR,
> > > >>>
> > > >>> there
> > > >>>
> > > >>> are
> > > >>>
> > > >>> -1s
> > > >>>
> > > >>> above... (early voting)
> > > >>>
> > > >>> maybe we'll be better off socializing the norm of squash-and-merge
> > > >>>
> > > >>> and
> > > >>>
> > > >>> gaining a natural consensus that way...
> > > >>>
> > > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
> > > >>>
> > > >>> onichols@pivotal.io
> > > >>>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>>
> > > >>> The proposed action manifests as a commit to the Geode git
> > > >>>
> > > >>> repository,
> > > >>>
> > > >>> so
> > > >>>
> > > >>> a PR is an acceptable vehicle for voting in this case.
> > > >>>
> > > >>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > > >>>
> > > >>> bschuchardt@pivotal.io>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>>
> > > >>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> > > >>>
> > > >>> thread
> > > >>>
> > > >>> and a request to "vote" using a PR. This all seems out of order
> > > >>>
> > > >>> to
> > > >>>
> > > >>> me.
> > > >>>
> > > >>> Our votes are supposed to be on the email list, aren't they? and
> > > >>>
> > > >>> I
> > > >>>
> > > >>> haven't
> > > >>>
> > > >>> seen a VOTE request.
> > > >>>
> > > >>>
> > > >>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > > >>>
> > > >>> +1
> > > >>>
> > > >>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
> > > >>>
> > > >>> onichols@pivotal.io
> > > >>>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>>
> > > >>> Based on the feedback so far, I will amend the proposal to
> > > >>>
> > > >>> drop
> > > >>>
> > > >>> item
> > > >>>
> > > >>> 2).
> > > >>>
> > > >>> Therefore, the current ability to create merge commits using
> > > >>>
> > > >>> command-line
> > > >>>
> > > >>> git will remain available.
> > > >>>
> > > >>> The proposal as amended is now:
> > > >>>
> > > >>> Change GitHub settings to make "Squash and merge" the default
> > > >>> (by removing “Create a merge commit” option).
> > > >>>
> > > >>> Update the PR template to change the text "Is your initial
> > > >>>
> > > >>> contribution
> > > >>>
> > > >>> a single, squashed commit” to “Is your initial contribution
> > > >>>
> > > >>> squashed
> > > >>>
> > > >>> for
> > > >>>
> > > >>> ease of review (e.g. a single commit, or a ‘refactoring’
> > > >>>
> > > >>> commit
> > > >>>
> > > >>> plus a
> > > >>>
> > > >>> ‘fix’ commit)"
> > > >>>
> > > >>>
> > > >>> As Naba suggested, we can try it, and if we don’t like it,
> > > >>>
> > > >>> it’s
> > > >>>
> > > >>> simple
> > > >>>
> > > >>> to
> > > >>>
> > > >>> revert.
> > > >>>
> > > >>> I’ve create a PR for the proposed change here:
> > > >>> https://github.com/apache/geode/pull/4513
> > > >>>
> > > >>> Please use the PR to vote for against this proposal. It will
> > > >>>
> > > >>> not
> > > >>>
> > > >>> be
> > > >>>
> > > >>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
> > > >>>
> > > >>> that
> > > >>>
> > > >>> time)
> > > >>>
> > > >>>
> > > >>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>>
> > > >>> +1
> > > >>>
> > > >>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
> > > >>>
> > > >>> onichols@pivotal.io>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>>
> > > >>> Hi Bruce, this proposal will not waste a single second of
> > > >>>
> > > >>> your
> > > >>>
> > > >>> time. It
> > > >>>
> > > >>> just prevents people from accidentally pressing a button
> > > >>>
> > > >>> that
> > > >>>
> > > >>> we
> > > >>>
> > > >>> have
> > > >>>
> > > >>> already agreed should never be pressed, but because we never
> > > >>>
> > > >>> configured
> > > >>>
> > > >>> our
> > > >>>
> > > >>> GitHub to match our stated policy, is currently the default.
> > > >>>
> > > >>> However, it will save a lot of time and frustration for
> > > >>>
> > > >>> anyone
> > > >>>
> > > >>> needing
> > > >>>
> > > >>> to
> > > >>>
> > > >>> bisect failures, revert, or cherry-pick changes, which has
> > > >>>
> > > >>> merit
> > > >>>
> > > >>> even if
> > > >>>
> > > >>> you personally never do any of those three things.
> > > >>>
> > > >>> Please start a separate thread if you would like to revisit
> > > >>>
> > > >>> the
> > > >>>
> > > >>> community
> > > >>>
> > > >>> decision to require passing PR checks.
> > > >>>
> > > >>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > > >>>
> > > >>> bschuchardt@pivotal.io>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>> I agree with Jake. I would go further by saying that I see
> > > >>>
> > > >>> very
> > > >>>
> > > >>> little
> > > >>>
> > > >>> merit in this proposal. I think we're getting more and more
> > > >>>
> > > >>> bureaucratic
> > > >>>
> > > >>> in our process and that it stifles productivity. I was
> > > >>>
> > > >>> recently
> > > >>>
> > > >>> forced
> > > >>>
> > > >>> to
> > > >>>
> > > >>> spend three days fixing tests in which I had changed an
> > > >>>
> > > >>> import
> > > >>>
> > > >>> statement
> > > >>>
> > > >>> before they would pass stress testing. I'm glad the tests
> > > >>>
> > > >>> now
> > > >>>
> > > >>> pass
> > > >>>
> > > >>> reliably but I was very frustrated by the process.
> > > >>>
> > > >>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > > >>>
> > > >>> I’m in agreement with Dan. Changes to the infrastructure
> > > >>>
> > > >>> to
> > > >>>
> > > >>> flat
> > > >>>
> > > >>> out
> > > >>>
> > > >>> prevent things that should be self policing is annoying.
> > > >>>
> > > >>> This
> > > >>>
> > > >>> PR
> > > >>>
> > > >>> review
> > > >>>
> > > >>> lock we have had already cost us valuable time waiting for
> > > >>>
> > > >>> PR
> > > >>>
> > > >>> pipelines
> > > >>>
> > > >>> to
> > > >>>
> > > >>> pass that have no relevance to the commit, like CI work: I’d
> > > >>>
> > > >>> hat
> > > >>>
> > > >>> to
> > > >>>
> > > >>> see
> > > >>>
> > > >>> yet
> > > >>>
> > > >>> another process enforced that Kees us from getting work done
> > > >>>
> > > >>> when
> > > >>>
> > > >>> necessary.
> > > >>>
> > > >>> -Jake
> > > >>>
> > > >>>
> > > >>> On Dec 19, 2019, at 4:43 PM, Dan Smith <
> > > >>>
> > > >>> dsmith@pivotal.io
> > > >>>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>>
> > > >>> -1 to (1) and (2).
> > > >>>
> > > >>> I think merge commits are appropriate in certain
> > > >>>
> > > >>> circumstances,
> > > >>>
> > > >>> so I
> > > >>>
> > > >>> don't
> > > >>>
> > > >>> think we should make a blanket restriction. In fact I
> > > >>>
> > > >>> think
> > > >>>
> > > >>> our
> > > >>>
> > > >>> release
> > > >>>
> > > >>> process involves some merges.
> > > >>>
> > > >>> I think setting standards on what is reasonable to be an
> > > >>>
> > > >>> individual
> > > >>>
> > > >>> commit
> > > >>>
> > > >>> will do a lot more to clean up our history than blocking
> > > >>>
> > > >>> merges.
> > > >>>
> > > >>> We'd
> > > >>>
> > > >>> rather not see commits like "Spotless Apply" in the
> > > >>>
> > > >>> history,
> > > >>>
> > > >>> but
> > > >>>
> > > >>> if
> > > >>>
> > > >>> reasonably separate and well written commits come in as
> > > >>>
> > > >>> part
> > > >>>
> > > >>> of
> > > >>>
> > > >>> a
> > > >>>
> > > >>> merge, I
> > > >>>
> > > >>> think that's fine.
> > > >>>
> > > >>> -Dan
> > > >>>
> > > >>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> > > >>>
> > > >>> jiliao@pivotal.io
> > > >>>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>> +1
> > > >>>
> > > >>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> > > >>>
> > > >>> onichols@pivotal.io
> > > >>>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>> I’d like to advance this topic from an informal
> > > >>>
> > > >>> request/discussion
> > > >>>
> > > >>> to a
> > > >>>
> > > >>> discussion of a concrete proposal.
> > > >>>
> > > >>> To recap, it sounds like there is general agreement
> > > >>>
> > > >>> that
> > > >>>
> > > >>> commit
> > > >>>
> > > >>> history
> > > >>>
> > > >>> on
> > > >>>
> > > >>> develop should be linear (no merge commits), and that
> > > >>>
> > > >>> the
> > > >>>
> > > >>> biggest
> > > >>>
> > > >>> obstacle
> > > >>>
> > > >>> to this is that the PR merge button in GitHub creates a
> > > >>>
> > > >>> merge
> > > >>>
> > > >>> commit
> > > >>>
> > > >>> by
> > > >>>
> > > >>> default.
> > > >>>
> > > >>> I propose the following changes:
> > > >>> 1) Change GitHub settings to remove the ability to
> > > >>>
> > > >>> create
> > > >>>
> > > >>> a
> > > >>>
> > > >>> merge
> > > >>>
> > > >>> commit.
> > > >>>
> > > >>> This will make Squash & Merge the default.
> > > >>>
> > > >>> 2) Change GitHub settings to require linear history on
> > > >>>
> > > >>> develop.
> > > >>>
> > > >>> This
> > > >>>
> > > >>> prevents merge commits via command-line (not
> > > >>>
> > > >>> recommended,
> > > >>>
> > > >>> but
> > > >>>
> > > >>> wiki
> > > >>>
> > > >>> still
> > > >>>
> > > >>> has instructions for merging PRs this way).
> > > >>>
> > > >>> 3) Update the PR template to change the text "Is your
> > > >>>
> > > >>> initial
> > > >>>
> > > >>> contribution
> > > >>>
> > > >>> a single, squashed commit” to “Is your initial
> > > >>>
> > > >>> contribution
> > > >>>
> > > >>> squashed
> > > >>>
> > > >>> for
> > > >>>
> > > >>> ease of review (e.g. a single commit, or a
> > > >>>
> > > >>> ‘refactoring’
> > > >>>
> > > >>> commit
> > > >>>
> > > >>> plus
> > > >>>
> > > >>> a
> > > >>>
> > > >>> ‘fix’ commit)"
> > > >>>
> > > >>> For clarity, I am proposing no-change in the following
> > > >>>
> > > >>> areas:
> > > >>>
> > > >>> i) Leave Rebase & Merge as an option for PRs that have
> > > >>>
> > > >>> been
> > > >>>
> > > >>> structured to
> > > >>>
> > > >>> benefit from it (this can make it easier in a bisect to
> > > >>>
> > > >>> see
> > > >>>
> > > >>> whether
> > > >>>
> > > >>> the
> > > >>>
> > > >>> refactoring or the “fix” broke something).
> > > >>> ii) Leave existing wording in the wiki as-is [stating
> > > >>>
> > > >>> that
> > > >>>
> > > >>> squashing
> > > >>>
> > > >>> is
> > > >>>
> > > >>> preferred].
> > > >>>
> > > >>>
> > > >>> Please comment via this email thread.
> > > >>> -Owen
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> > > >>>
> > > >>> klund@apache.org>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>>
> > > >>> I think it's already resolved Udo ;)
> > > >>>
> > > >>> Here's the problem, if I fixup a dunit test by
> > > >>>
> > > >>> removing
> > > >>>
> > > >>> all
> > > >>>
> > > >>> uses
> > > >>>
> > > >>> of
> > > >>>
> > > >>> "this."
> > > >>>
> > > >>> and I rename the dunit test, then git doesn't remember
> > > >>>
> > > >>> that
> > > >>>
> > > >>> the
> > > >>>
> > > >>> file
> > > >>>
> > > >>> is a
> > > >>>
> > > >>> rename -- it forever afterwards interprets it as a new
> > > >>>
> > > >>> file
> > > >>>
> > > >>> that I
> > > >>>
> > > >>> created
> > > >>>
> > > >>> if I touch more than 50% of the lines (which "this."
> > > >>>
> > > >>> can
> > > >>>
> > > >>> easily
> > > >>>
> > > >>> do). If
> > > >>>
> > > >>> we
> > > >>>
> > > >>> squash two commits: the rename and the cleanup of that
> > > >>>
> > > >>> dunit
> > > >>>
> > > >>> test
> > > >>>
> > > >>> --
> > > >>>
> > > >>> then
> > > >>>
> > > >>> we effectively lose the history of that file and it
> > > >>>
> > > >>> shows
> > > >>>
> > > >>> that
> > > >>>
> > > >>> I
> > > >>>
> > > >>> created
> > > >>>
> > > >>> a
> > > >>>
> > > >>> new file.
> > > >>>
> > > >>> Also for the record, I've been working on Geode since
> > > >>>
> > > >>> the
> > > >>>
> > > >>> beginning
> > > >>>
> > > >>> and I
> > > >>>
> > > >>> was never made aware of this change in our process. I
> > > >>>
> > > >>> never
> > > >>>
> > > >>> voted
> > > >>>
> > > >>> on
> > > >>>
> > > >>> it.
> > > >>>
> > > >>> I'm not a big fan of changing various details in our
> > > >>>
> > > >>> process
> > > >>>
> > > >>> every
> > > >>>
> > > >>> single
> > > >>>
> > > >>> week. It's very easy to miss these discussions unless
> > > >>>
> > > >>> someone
> > > >>>
> > > >>> points it
> > > >>>
> > > >>> out
> > > >>>
> > > >>> to me.
> > > >>>
> > > >>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > > >>>
> > > >>> ukohlmeyer@pivotal.io>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>> I'm not sure what this discussion is about... WE, as
> > > >>>
> > > >>> a
> > > >>>
> > > >>> community,
> > > >>>
> > > >>> have
> > > >>>
> > > >>> agreed in common practices, in two place no less...
> > > >>>
> > > >>> 1) Quoting our PR template
> > > >>>
> > > >>>
> > > >>> For all changes:
> > > >>>
> > > >>> *
> > > >>>
> > > >>> Is there a JIRA ticket associated with this PR? Is it
> > > >>>
> > > >>> referenced
> > > >>>
> > > >>> in
> > > >>>
> > > >>> the commit message?
> > > >>>
> > > >>> *
> > > >>>
> > > >>> Has your PR been rebased against the latest commit
> > > >>>
> > > >>> within
> > > >>>
> > > >>> the
> > > >>>
> > > >>> target
> > > >>>
> > > >>> branch (typically|develop|)?
> > > >>>
> > > >>> *
> > > >>>
> > > >>> ***Is your initial contribution a single, squashed
> > > >>>
> > > >>> commit?*
> > > >>>
> > > >>>
> > > >>> *
> > > >>>
> > > >>> Does|gradlew build|run cleanly?
> > > >>>
> > > >>> *
> > > >>>
> > > >>> Have you written or updated unit tests to verify your
> > > >>>
> > > >>> changes?
> > > >>>
> > > >>>
> > > >>> *
> > > >>>
> > > >>> If adding new dependencies to the code, are these
> > > >>>
> > > >>> dependencies
> > > >>>
> > > >>> licensed in a way that is compatible for inclusion
> > > >>>
> > > >>> underASF
> > > >>>
> > > >>> 2.0
> > > >>>
> > > >>> <
> > > >>>
> > > >>> http://www.apache.org/legal/resolved.html#category-a
> > > >>>
> > > >>> ?
> > > >>>
> > > >>>
> > > >>> On our PR template we call out that the initial PR
> > > >>>
> > > >>> commit
> > > >>>
> > > >>> should
> > > >>>
> > > >>> be
> > > >>>
> > > >>> squashed.
> > > >>>
> > > >>> 2)
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > >>>
> > > >>> <
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > >>>
> > > >>> -- See "Accepting a PR Using the Command Line" -
> > > >>>
> > > >>> Point
> > > >>>
> > > >>> #3.
> > > >>>
> > > >>>
> > > >>>
> > > >>> @Kirk, if each of your commits "stands alone", I
> > > >>>
> > > >>> commend
> > > >>>
> > > >>> you
> > > >>>
> > > >>> on
> > > >>>
> > > >>> the
> > > >>>
> > > >>> diligence, but in reality, they should either then be
> > > >>>
> > > >>> stand
> > > >>>
> > > >>> alone
> > > >>>
> > > >>> PR's
> > > >>>
> > > >>> or just extra work created for yourself.
> > > >>>
> > > >>> If we want to change the way we have agreed upon we
> > > >>>
> > > >>> submit/commit/merge
> > > >>>
> > > >>> changes back into develop... Then this is another
> > > >>>
> > > >>> discussion
> > > >>>
> > > >>> thread,
> > > >>>
> > > >>> until then, I think we should all remind ourselves on
> > > >>>
> > > >>> our
> > > >>>
> > > >>> agreed
> > > >>>
> > > >>> contributions code of conduct.
> > > >>>
> > > >>> --Udo
> > > >>>
> > > >>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > > >>>
> > > >>> Kirk, I believe that creating a Pull Request with
> > > >>>
> > > >>> multiple
> > > >>>
> > > >>> commits is
> > > >>>
> > > >>> ok.
> > > >>>
> > > >>> It's just in the end that when it's being pushed to
> > > >>>
> > > >>> develop
> > > >>>
> > > >>> branch,
> > > >>>
> > > >>> it
> > > >>>
> > > >>> needs to be squash merged. I believe that is what
> > > >>>
> > > >>> you
> > > >>>
> > > >>> have
> > > >>>
> > > >>> mentioned
> > > >>>
> > > >>> in
> > > >>>
> > > >>> the
> > > >>>
> > > >>> first paragraph, and I am more than happy with that.
> > > >>> If you can see in the first screenshot comparison
> > > >>>
> > > >>> that
> > > >>>
> > > >>> I
> > > >>>
> > > >>> had
> > > >>>
> > > >>> attached
> > > >>>
> > > >>> in
> > > >>>
> > > >>> the first email in this thread is what I want to
> > > >>>
> > > >>> avoid.
> > > >>>
> > > >>>
> > > >>> Thank you for your feedback.
> > > >>>
> > > >>> Regards
> > > >>> Naba
> > > >>>
> > > >>>
> > > >>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> > > >>>
> > > >>> klund@apache.org>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>> Whenever I submit a PR with multiple commits that I
> > > >>>
> > > >>> intend
> > > >>>
> > > >>> to
> > > >>>
> > > >>> rebase
> > > >>>
> > > >>> to
> > > >>>
> > > >>> develop, I always try to ensure that each commit
> > > >>>
> > > >>> stands
> > > >>>
> > > >>> alone
> > > >>>
> > > >>> as
> > > >>>
> > > >>> is
> > > >>>
> > > >>> (compiles and passes tests). Separating file
> > > >>>
> > > >>> renames
> > > >>>
> > > >>> and
> > > >>>
> > > >>> refactoring
> > > >>>
> > > >>> from
> > > >>>
> > > >>> behavior changes into different commits seems very
> > > >>>
> > > >>> valuable
> > > >>>
> > > >>> to
> > > >>>
> > > >>> me,
> > > >>>
> > > >>> and
> > > >>>
> > > >>> I've
> > > >>>
> > > >>> had trouble getting people to review PRs without
> > > >>>
> > > >>> this
> > > >>>
> > > >>> separation
> > > >>>
> > > >>> (but
> > > >>>
> > > >>> it
> > > >>>
> > > >>> could be squashed as it's merged to develop).
> > > >>>
> > > >>> It sounds to me like the real problem is (a) some
> > > >>>
> > > >>> PRs
> > > >>>
> > > >>> have
> > > >>>
> > > >>> multiple
> > > >>>
> > > >>> commits
> > > >>>
> > > >>> that don't compile or don't pass tests, and (b)
> > > >>>
> > > >>> some
> > > >>>
> > > >>> PRs
> > > >>>
> > > >>> that
> > > >>>
> > > >>> should
> > > >>>
> > > >>> be
> > > >>>
> > > >>> merged with squash are not (by accident most
> > > >>>
> > > >>> likely).
> > > >>>
> > > >>>
> > > >>> I can submit multiple PRs instead of one PR with
> > > >>>
> > > >>> multiple
> > > >>>
> > > >>> commits.
> > > >>>
> > > >>> So
> > > >>>
> > > >>> I'll
> > > >>>
> > > >>> change my response to -0 if that helps prevent
> > > >>>
> > > >>> commits
> > > >>>
> > > >>> to
> > > >>>
> > > >>> develop
> > > >>>
> > > >>> that
> > > >>>
> > > >>> don't compile or pass tests. Without preventing
> > > >>>
> > > >>> rebase
> > > >>>
> > > >>> or
> > > >>>
> > > >>> merge
> > > >>>
> > > >>> commits
> > > >>>
> > > >>> from github, I'm not sure how we can really enforce
> > > >>>
> > > >>> this
> > > >>>
> > > >>> or
> > > >>>
> > > >>> prevent
> > > >>>
> > > >>> (b)
> > > >>>
> > > >>> above.
> > > >>>
> > > >>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > > >>>
> > > >>> amurmann@pivotal.io>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>> I wonder if Kirk's and Naba's statements are
> > > >>>
> > > >>> necessarily
> > > >>>
> > > >>> at
> > > >>>
> > > >>> odds.
> > > >>>
> > > >>> Make the change easy (warning: this may be hard),
> > > >>>
> > > >>> then
> > > >>>
> > > >>> make
> > > >>>
> > > >>> the
> > > >>>
> > > >>> easy
> > > >>>
> > > >>> change."
> > > >>>
> > > >>> -Kent Beck
> > > >>>
> > > >>> Following Kent Beck's advise might reasonably
> > > >>>
> > > >>> split
> > > >>>
> > > >>> into
> > > >>>
> > > >>> two
> > > >>>
> > > >>> commits.
> > > >>>
> > > >>> One
> > > >>>
> > > >>> refactor commit and a separate commit that
> > > >>>
> > > >>> introduces
> > > >>>
> > > >>> the
> > > >>>
> > > >>> actual
> > > >>>
> > > >>> change.
> > > >>>
> > > >>> They should be individually revertible and might
> > > >>>
> > > >>> be
> > > >>>
> > > >>> easier
> > > >>>
> > > >>> understood
> > > >>>
> > > >>> if
> > > >>>
> > > >>> split out. I vividly remember a change on our code
> > > >>>
> > > >>> base
> > > >>>
> > > >>> where
> > > >>>
> > > >>> someone
> > > >>>
> > > >>> did a
> > > >>>
> > > >>> huge amount of refactoring that resulted than in
> > > >>>
> > > >>> one
> > > >>>
> > > >>> parameter
> > > >>>
> > > >>> changing
> > > >>>
> > > >>> in
> > > >>>
> > > >>> order to get the desired functionality change. If
> > > >>>
> > > >>> that
> > > >>>
> > > >>> was
> > > >>>
> > > >>> in
> > > >>>
> > > >>> one
> > > >>>
> > > >>> commit,
> > > >>>
> > > >>> it would be hard to see the actual change. If
> > > >>>
> > > >>> split
> > > >>>
> > > >>> out,
> > > >>>
> > > >>> it's
> > > >>>
> > > >>> beautiful
> > > >>>
> > > >>> and
> > > >>>
> > > >>> crystal clear.
> > > >>>
> > > >>> I am unsure how that would be reflected in terms
> > > >>>
> > > >>> of
> > > >>>
> > > >>> JIRA
> > > >>>
> > > >>> ticket
> > > >>>
> > > >>> references.
> > > >>>
> > > >>> Usually we assume that if there is a commit with
> > > >>>
> > > >>> the
> > > >>>
> > > >>> ticket
> > > >>>
> > > >>> number,
> > > >>>
> > > >>> the
> > > >>>
> > > >>> issue is resolved. Maybe the key here is to create
> > > >>>
> > > >>> a
> > > >>>
> > > >>> separate
> > > >>>
> > > >>> refactoring
> > > >>>
> > > >>> ticket.
> > > >>>
> > > >>> Would that allow us to have our cake and eat it
> > > >>>
> > > >>> too?
> > > >>>
> > > >>>
> > > >>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> > > >>>
> > > >>> nnag@pivotal.io>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>> It is to help with bisect operations when things
> > > >>>
> > > >>> start
> > > >>>
> > > >>> failing
> > > >>>
> > > >>> ...
> > > >>>
> > > >>> helps
> > > >>>
> > > >>> us
> > > >>>
> > > >>> it revert and build faster.
> > > >>> also with cherry picking features / fixes to
> > > >>>
> > > >>> previous
> > > >>>
> > > >>> versions
> > > >>>
> > > >>> .
> > > >>>
> > > >>> And keeping the git history clean with no
> > > >>>
> > > >>> unnecessary
> > > >>>
> > > >>> “merge
> > > >>>
> > > >>> commits”.
> > > >>>
> > > >>> Regards
> > > >>> Naba
> > > >>>
> > > >>>
> > > >>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> > > >>>
> > > >>> klund@apache.org>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>> -1 I really like to sometimes have more than 1
> > > >>>
> > > >>> commit
> > > >>>
> > > >>> in
> > > >>>
> > > >>> a
> > > >>>
> > > >>> PR
> > > >>>
> > > >>> and
> > > >>>
> > > >>> keep
> > > >>>
> > > >>> them
> > > >>>
> > > >>> separate when they merge to develop
> > > >>>
> > > >>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> > > >>>
> > > >>> nnag@pivotal.io>
> > > >>>
> > > >>> wrote:
> > > >>>
> > > >>> Hi Geode Committers,
> > > >>>
> > > >>> A kind request for using squash commit instead
> > > >>>
> > > >>> of
> > > >>>
> > > >>> using
> > > >>>
> > > >>> merge.
> > > >>>
> > > >>> This will really help us in our bisect
> > > >>>
> > > >>> operations
> > > >>>
> > > >>> when a
> > > >>>
> > > >>> regression/flakiness in the product is
> > > >>>
> > > >>> introduced.
> > > >>>
> > > >>> We
> > > >>>
> > > >>> can
> > > >>>
> > > >>> automate
> > > >>>
> > > >>> and
> > > >>>
> > > >>> go
> > > >>>
> > > >>> through fewer commits faster, avoiding commits
> > > >>>
> > > >>> like
> > > >>>
> > > >>> "spotless
> > > >>>
> > > >>> fix"
> > > >>>
> > > >>> and
> > > >>>
> > > >>> "re-trigger precheck-in" or other minor commits
> > > >>>
> > > >>> in
> > > >>>
> > > >>> the
> > > >>>
> > > >>> merged
> > > >>>
> > > >>> branch.
> > > >>>
> > > >>> Also, please use the commit format : (helps us
> > > >>>
> > > >>> to
> > > >>>
> > > >>> know
> > > >>>
> > > >>> who
> > > >>>
> > > >>> worked
> > > >>>
> > > >>> on
> > > >>>
> > > >>> it,
> > > >>>
> > > >>> what is the history)
> > > >>>
> > > >>>
> > > >>>
> > > >>> * GEODE-xxxx: <brief intro >
> > > >>> * explanation line 1
> > > >>>
> > > >>> *
> > > >>>
> > > >>> explanation
> > > >>>
> > > >>> line
> > > >>>
> > > >>> 2*
> > > >>>
> > > >>> This is not a rule or anything, but a request
> > > >>>
> > > >>> to
> > > >>>
> > > >>> help
> > > >>>
> > > >>> out
> > > >>>
> > > >>> your
> > > >>>
> > > >>> fellow
> > > >>>
> > > >>> committers in quickly detecting a problem.
> > > >>>
> > > >>> For inspiration, we can look into Apache Kafka
> > > >>>
> > > >>> /
> > > >>>
> > > >>> Spark
> > > >>>
> > > >>> where
> > > >>>
> > > >>> they
> > > >>>
> > > >>> have
> > > >>>
> > > >>> a
> > > >>>
> > > >>> complete linear graph for their main branch
> > > >>>
> > > >>> HEAD
> > > >>>
> > > >>> [see
> > > >>>
> > > >>> attachment]
> > > >>>
> > > >>> Regards
> > > >>> Naba.
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>>
> > > >>> Ju@N
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Cheers
> > > >>>
> > > >>> Jinmei
> > > >>
> > > >>
> > >
> > >
> >
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Dan Smith <ds...@pivotal.io>.
I also tend to do the same workflow Aaron described - make a refactoring
change to support a feature followed by the actual change I want to make.
It makes the history a lot clearer because refactoring tends to touch a lot
of files, so it's nice to have those changes clearly marked as a
refactoring that should not change behavior.
It's possible to do this as to separate PRs, but that drags out the process
because you have to get the first in merged before you create the second.
That encourages bunching changes in a single squashed commit, which makes
git blame less useful.
-Dan
On Tue, Dec 31, 2019, 6:36 PM Nabarun Nag <nn...@apache.org> wrote:
> Aaron ,
>
> Is it not the case currently? If I am working on a feature modifying class
> X and another developer makes some refactoring changes on class X and
> pushes it to develop, won't I have to resolve the merge commits anyway.
>
>
> Regards
> Naba
>
>
> On Tue, Dec 31, 2019 at 6:01 PM Aaron Lindsey <aa...@apache.org>
> wrote:
>
> > Suppose I’m refactoring the same classes I’m touching for the feature. I
> > do the refactoring on one branch and submit a PR for that. Then I
> implement
> > the feature on another branch which is based on develop and does not have
> > the refactoring changes since those are not merged yet. I’ll have to
> > resolve conflicts on the second PR that I merge.
> >
> > Having interdependent PRs where one PR branch is based on another PR
> > branch is not something I’ve tried. That requires more overhead in having
> > to create more PRs and branches. And if you have N interdependent PRs,
> you
> > have to do N-1 merges each time a PR is merged to develop (to update the
> > other branches). It could be done, but is it worth the hassle?
> >
> > One more point about rebase-and-merge is that it seems like this would
> > make bisecting a failure easier since there would be smaller commits.
> >
> > Aaron
> >
> > > On Dec 31, 2019, at 5:41 PM, Owen Nichols <on...@pivotal.io> wrote:
> > >
> > > Can you elaborate on why you would have to deal with conflicts if the
> > > refactoring work was kept as a separate PR from the fix?
> > >
> > > As with many git workflows, there’s an easy way and a hard way to
> manage
> > > interdependent PRs (tl;dr only merge, never rebase!). I wonder if this
> > > points out an opportunity for a “tips and tricks” page on the Geode
> wiki.
> > >
> > > On Tue, Dec 31, 2019 at 5:22 PM Aaron Lindsey <aaronlindsey@apache.org
> >
> > > wrote:
> > >
> > >> -0.9
> > >>
> > >> I’m not in favor of the revised proposal that disallows
> > rebase-and-merge.
> > >> Say I am working on a PR and I have a refactor commit and another
> commit
> > >> which implements a new feature. I don’t want those commits to get
> > squashed
> > >> because that makes it hard to understand the diff. However, if I make
> > those
> > >> commits as two separate PRs then I am going to have to deal with
> > conflicts.
> > >>
> > >> I’m not sure when we made it a rule that every commit in develop had
> to
> > >> compile and pass tests. I know we implemented a rule that all PRs had
> to
> > >> pass certain checks, but I never thought that rule implied all commits
> > had
> > >> to pass those checks.
> > >>
> > >> In general I just don’t see the problem with rebase-and-merge and this
> > >> feels like an unnecessary restriction, but I will go with it if that’s
> > what
> > >> everyone wants to do.
> > >>
> > >> Aaron
> > >>
> > >>> On Dec 31, 2019, at 3:09 PM, Owen Nichols <on...@pivotal.io>
> wrote:
> > >>>
> > >>> To recap, this proposal is now revised to remove 2 of the 3 merge
> > options
> > >>> from GitHub, leaving only Squash and Merge. PR #4513
> > >>> <https://github.com/apache/geode/pull/4513> serves as an exhibit of
> > >> what is
> > >>> proposed (it is not to be merged unless discussion leads to consensus
> > >> and a
> > >>> successful vote). Please use the dev list (not the PR) for all
> > >> discussion
> > >>> (and voting, if we get that far).
> > >>>
> > >>> Squash and merge is already used almost exclusively by the Geode
> > >> community,
> > >>> with any exceptions tending to be accidental more often than
> > intentional.
> > >>> However, some have raised the concern that implementing this
> > restriction
> > >>> could result in harm or wasted time. Can someone give an example of
> a
> > >> such
> > >>> a scenario?
> > >>>
> > >>> It seems there is a divide here between junior and senior community
> > >>> members. Newer committers appreciate additional guardrails to
> protect
> > >> them
> > >>> from accidentally doing the wrong thing, while those with more
> > experience
> > >>> want to be able to work unencumbered by restrictions of any kind.
> > >>>
> > >>> Our welcome email to new committers states “We like to work on trust
> > >> rather
> > >>> than unnecessary constraints...Being a committer enables you to more
> > >> easily
> > >>> make changes without needing to go through the patch submission
> > process”.
> > >>> I can see this as an argument against this proposal (perhaps even an
> > >>> argument against any form of branch protection).
> > >>>
> > >>> In the scheme of things, this proposal makes very little difference.
> > >> There
> > >>> are still other ways to get non-compiling commits onto develop (e.g.
> > >>> waiting a long time between running PR checks and merging to
> develop).
> > >>> What’s more important is working well together as a community. So,
> > >> perhaps
> > >>> what’s best for the community is to encourage working on trust rather
> > >> than
> > >>> unnecessary constraints.
> > >>>
> > >>> -Owen
> > >>>
> > >>> On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org> wrote:
> > >>>
> > >>> I'm happy to file multiple PRs when I need to merge multiple commits
> to
> > >>> develop.
> > >>>
> > >>> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <mh...@pivotal.io>
> > wrote:
> > >>>
> > >>> This change to disable all but squash-merge would be really easy to
> > >>> revert. How about we try it for a while and see? If people decide it
> is
> > >>> really limiting them, we can change it back. Let’s do it for 1 month
> > and
> > >>> see how it goes. Does that sound reasonable?
> > >>>
> > >>> Thanks,
> > >>> Mark
> > >>>
> > >>> On Dec 30, 2019, at 5:25 PM, Owen Nichols <on...@pivotal.io>
> wrote:
> > >>>
> > >>> Given that we adopted <
> > >>>
> > >>>
> > >>
> >
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
> > >>>>
> > >>> and still wish to continue <
> > >>>
> > >>
> >
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
> > >>>>
> > >>> having branch protection rules to ensure every commit landing in
> > develop
> > >>> has passed the required PR checks, it seems like that decision alone
> > >>> mandates that we disable all merge mechanisms other than
> > >> squash-and-merge.
> > >>>
> > >>>
> > >>> Allowing merge commits or rebase merges bypasses branch protection
> for
> > >>>
> > >>> all commits other than the final one in the merge or rebase set.
> Given
> > >>> that we decided <
> > >>>
> > >>
> >
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
> > >>>>
> > >>> that bypassing PR checks should never be allowed, keeping this
> loophole
> > >>> open seems untenable.
> > >>>
> > >>>
> > >>> This is not just hypothetical — this loophole is causing real
> problems.
> > >>>
> > >>> We now have commits on develop that don’t compile. For example:
> > >>>
> > >>> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> > >>> ./gradlew devBuild
> > >>> ...spotlessJava FAILED
> > >>> We implemented branch protections to make this impossible, right?
> > >>>
> > >>> We can very easily close this loophole by disabling all but the
> > >>>
> > >>> Squash&Merge button for PRs. This will not make more work for any
> > >>> developer. If you want to get multiple commits onto develop, simply
> > >> submit
> > >>> each as a separate PR — that is the only way to assure that required
> PR
> > >>> checks have passed for each.
> > >>>
> > >>>
> > >>> On the other hand, if we as a Geode community feel strongly that
> > >>>
> > >>> bypassing branch protection via merge commits and rebase commits is
> > >>> important to allow, why not also allow arbitrary overrides (or get
> rid
> > of
> > >>> branch protection entirely)?
> > >>>
> > >>>
> > >>> -Owen
> > >>>
> > >>> On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io>
> wrote:
> > >>>
> > >>> Just FWIW, the situation described of having multiple commits in a
> > >>>
> > >>> single
> > >>>
> > >>> PR with separate associated JIRA tickets is still kind of
> problematic.
> > >>>
> > >>> It
> > >>>
> > >>> could well be the case that the commits are interdependent, thus when
> > >>> bisecting etc it's still not possible to revert the fix for a single
> > >>> bug/feature/whatever atomically. It's all good, though, I'm
> satisfied
> > >>>
> > >>> no
> > >>>
> > >>> one's forcing me to adopt practice I'm opposed to. Apologies for
> > >>>
> > >>> getting
> > >>>
> > >>> my feathers a little ruffled, or if I ruffled anyone else's in
> return.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Blake
> > >>>
> > >>>
> > >>> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io>
> wrote:
> > >>>
> > >>> Hi Dan,
> > >>>
> > >>> When we do squash merge all the commit messages are preserved and
> also
> > >>>
> > >>> the
> > >>>
> > >>> co-authored tag works when we do squash merge.
> > >>> So the authorship and history are preserved.
> > >>>
> > >>> In my own personal experience and reverts and pinpointing regression
> > >>> failures are tough when the commits are spread out. Also, reverts are
> > >>> easier when it is just one commit while we are bisecting failures.
> > >>>
> > >>>
> > >>> Regards
> > >>> Naba
> > >>>
> > >>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io>
> wrote:
> > >>>
> > >>> I'll change to -0.
> > >>>
> > >>> I think merge commits are a nice way to record history in some cases,
> > >>>
> > >>> and
> > >>>
> > >>> can also be a way to avoid messy conflicts that come with rebase.
> > >>>
> > >>> Merge
> > >>>
> > >>> commits also preserve authorship of commits (compared to
> > >>>
> > >>> squash-merge),
> > >>>
> > >>> which I think is valuable as an open source community that is trying
> > >>>
> > >>> to
> > >>>
> > >>> keep track of outside contributions.
> > >>>
> > >>> That said, if the rest of y'all feel it will help to disable the
> > >>>
> > >>> button,
> > >>>
> > >>> I
> > >>>
> > >>> won't stand in the way.
> > >>>
> > >>> -Dan
> > >>>
> > >>> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
> > >>>
> > >>> wrote:
> > >>>
> > >>>
> > >>> Whether we are talking about the geode/ repository or the
> > >>>
> > >>> geode-native/
> > >>>
> > >>> repository we are all one GEODE community.
> > >>>
> > >>> The idea of a native client team may matter in some contexts but in
> > >>>
> > >>> this
> > >>>
> > >>> space we are all GEODE contributors.
> > >>>
> > >>> Adopting a common approach across our repos will make it easier for
> > >>>
> > >>> new
> > >>>
> > >>> contributors to engage, learn our norms, and join our efforts.
> > >>>
> > >>> $0.02,
> > >>> Anthony
> > >>>
> > >>>
> > >>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
> > >>>
> > >>> wrote:
> > >>>
> > >>>
> > >>> Is this a policy the native client team must abide by, as well? It
> > >>>
> > >>> varies
> > >>>
> > >>> slightly with what we've been doing, and all other things being
> > >>>
> > >>> equal I
> > >>>
> > >>> see
> > >>>
> > >>> no reason for us to change that. If I am to have any measure of
> > >>>
> > >>> control
> > >>>
> > >>> over the nc repository, I will definitely enforce a 1:1
> > >>>
> > >>> correspondence
> > >>>
> > >>> between commits to develop and JIRA tickets. IMO, if your
> > >>>
> > >>> refactoring
> > >>>
> > >>> in a
> > >>>
> > >>> PR is sufficiently large or complex that it's difficult to tease it
> > >>>
> > >>> out
> > >>>
> > >>> from the bug you're fixing or feature you're implementing, it merits
> > >>>
> > >>> its
> > >>>
> > >>> own JIRA ticket and a separate PR. If your "actual" fix then
> > >>>
> > >>> becomes
> > >>>
> > >>> dependent on the refactored code, that's a price I'm willing to pay
> > >>>
> > >>> to
> > >>>
> > >>> keep
> > >>>
> > >>> history clean.
> > >>>
> > >>> On the other hand, I see no real value in squashing to a single
> > >>>
> > >>> commit
> > >>>
> > >>> prior to submitting a PR, since your view of the changes on GitHub
> > >>>
> > >>> is
> > >>>
> > >>> essentially the same either way. We haven't enforced this on the nc
> > >>>
> > >>> repo,
> > >>>
> > >>> and I'd prefer to keep it that way.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Blake
> > >>>
> > >>>
> > >>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
> > >>>
> > >>> wrote:
> > >>>
> > >>>
> > >>> Merge commit is the new contributor's default setting. When we are
> > >>>
> > >>> merging
> > >>>
> > >>> new contributor's PR, since we are so used to THINKING
> > >>>
> > >>> "squash-and-merge"
> > >>>
> > >>> is the default, we forgot to check what the button really says when
> > >>>
> > >>> we
> > >>>
> > >>> are
> > >>>
> > >>> merging other people's PR.
> > >>>
> > >>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > >>>
> > >>> eburghardt@pivotal.io>
> > >>>
> > >>> wrote:
> > >>>
> > >>> I'm a proponent of using squash-and-merge, and once a person has
> > >>>
> > >>> chosen
> > >>>
> > >>> this option once it comes up by default afterwards...
> > >>>
> > >>> Owen, I don't think you have consensus to put forth this PR,
> > >>>
> > >>> there
> > >>>
> > >>> are
> > >>>
> > >>> -1s
> > >>>
> > >>> above... (early voting)
> > >>>
> > >>> maybe we'll be better off socializing the norm of squash-and-merge
> > >>>
> > >>> and
> > >>>
> > >>> gaining a natural consensus that way...
> > >>>
> > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
> > >>>
> > >>> onichols@pivotal.io
> > >>>
> > >>>
> > >>> wrote:
> > >>>
> > >>>
> > >>> The proposed action manifests as a commit to the Geode git
> > >>>
> > >>> repository,
> > >>>
> > >>> so
> > >>>
> > >>> a PR is an acceptable vehicle for voting in this case.
> > >>>
> > >>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > >>>
> > >>> bschuchardt@pivotal.io>
> > >>>
> > >>> wrote:
> > >>>
> > >>>
> > >>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> > >>>
> > >>> thread
> > >>>
> > >>> and a request to "vote" using a PR. This all seems out of order
> > >>>
> > >>> to
> > >>>
> > >>> me.
> > >>>
> > >>> Our votes are supposed to be on the email list, aren't they? and
> > >>>
> > >>> I
> > >>>
> > >>> haven't
> > >>>
> > >>> seen a VOTE request.
> > >>>
> > >>>
> > >>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > >>>
> > >>> +1
> > >>>
> > >>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
> > >>>
> > >>> onichols@pivotal.io
> > >>>
> > >>>
> > >>> wrote:
> > >>>
> > >>>
> > >>> Based on the feedback so far, I will amend the proposal to
> > >>>
> > >>> drop
> > >>>
> > >>> item
> > >>>
> > >>> 2).
> > >>>
> > >>> Therefore, the current ability to create merge commits using
> > >>>
> > >>> command-line
> > >>>
> > >>> git will remain available.
> > >>>
> > >>> The proposal as amended is now:
> > >>>
> > >>> Change GitHub settings to make "Squash and merge" the default
> > >>> (by removing “Create a merge commit” option).
> > >>>
> > >>> Update the PR template to change the text "Is your initial
> > >>>
> > >>> contribution
> > >>>
> > >>> a single, squashed commit” to “Is your initial contribution
> > >>>
> > >>> squashed
> > >>>
> > >>> for
> > >>>
> > >>> ease of review (e.g. a single commit, or a ‘refactoring’
> > >>>
> > >>> commit
> > >>>
> > >>> plus a
> > >>>
> > >>> ‘fix’ commit)"
> > >>>
> > >>>
> > >>> As Naba suggested, we can try it, and if we don’t like it,
> > >>>
> > >>> it’s
> > >>>
> > >>> simple
> > >>>
> > >>> to
> > >>>
> > >>> revert.
> > >>>
> > >>> I’ve create a PR for the proposed change here:
> > >>> https://github.com/apache/geode/pull/4513
> > >>>
> > >>> Please use the PR to vote for against this proposal. It will
> > >>>
> > >>> not
> > >>>
> > >>> be
> > >>>
> > >>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
> > >>>
> > >>> that
> > >>>
> > >>> time)
> > >>>
> > >>>
> > >>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
> > >>>
> > >>> wrote:
> > >>>
> > >>>
> > >>> +1
> > >>>
> > >>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
> > >>>
> > >>> onichols@pivotal.io>
> > >>>
> > >>> wrote:
> > >>>
> > >>>
> > >>> Hi Bruce, this proposal will not waste a single second of
> > >>>
> > >>> your
> > >>>
> > >>> time. It
> > >>>
> > >>> just prevents people from accidentally pressing a button
> > >>>
> > >>> that
> > >>>
> > >>> we
> > >>>
> > >>> have
> > >>>
> > >>> already agreed should never be pressed, but because we never
> > >>>
> > >>> configured
> > >>>
> > >>> our
> > >>>
> > >>> GitHub to match our stated policy, is currently the default.
> > >>>
> > >>> However, it will save a lot of time and frustration for
> > >>>
> > >>> anyone
> > >>>
> > >>> needing
> > >>>
> > >>> to
> > >>>
> > >>> bisect failures, revert, or cherry-pick changes, which has
> > >>>
> > >>> merit
> > >>>
> > >>> even if
> > >>>
> > >>> you personally never do any of those three things.
> > >>>
> > >>> Please start a separate thread if you would like to revisit
> > >>>
> > >>> the
> > >>>
> > >>> community
> > >>>
> > >>> decision to require passing PR checks.
> > >>>
> > >>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > >>>
> > >>> bschuchardt@pivotal.io>
> > >>>
> > >>> wrote:
> > >>>
> > >>> I agree with Jake. I would go further by saying that I see
> > >>>
> > >>> very
> > >>>
> > >>> little
> > >>>
> > >>> merit in this proposal. I think we're getting more and more
> > >>>
> > >>> bureaucratic
> > >>>
> > >>> in our process and that it stifles productivity. I was
> > >>>
> > >>> recently
> > >>>
> > >>> forced
> > >>>
> > >>> to
> > >>>
> > >>> spend three days fixing tests in which I had changed an
> > >>>
> > >>> import
> > >>>
> > >>> statement
> > >>>
> > >>> before they would pass stress testing. I'm glad the tests
> > >>>
> > >>> now
> > >>>
> > >>> pass
> > >>>
> > >>> reliably but I was very frustrated by the process.
> > >>>
> > >>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > >>>
> > >>> I’m in agreement with Dan. Changes to the infrastructure
> > >>>
> > >>> to
> > >>>
> > >>> flat
> > >>>
> > >>> out
> > >>>
> > >>> prevent things that should be self policing is annoying.
> > >>>
> > >>> This
> > >>>
> > >>> PR
> > >>>
> > >>> review
> > >>>
> > >>> lock we have had already cost us valuable time waiting for
> > >>>
> > >>> PR
> > >>>
> > >>> pipelines
> > >>>
> > >>> to
> > >>>
> > >>> pass that have no relevance to the commit, like CI work: I’d
> > >>>
> > >>> hat
> > >>>
> > >>> to
> > >>>
> > >>> see
> > >>>
> > >>> yet
> > >>>
> > >>> another process enforced that Kees us from getting work done
> > >>>
> > >>> when
> > >>>
> > >>> necessary.
> > >>>
> > >>> -Jake
> > >>>
> > >>>
> > >>> On Dec 19, 2019, at 4:43 PM, Dan Smith <
> > >>>
> > >>> dsmith@pivotal.io
> > >>>
> > >>>
> > >>> wrote:
> > >>>
> > >>>
> > >>> -1 to (1) and (2).
> > >>>
> > >>> I think merge commits are appropriate in certain
> > >>>
> > >>> circumstances,
> > >>>
> > >>> so I
> > >>>
> > >>> don't
> > >>>
> > >>> think we should make a blanket restriction. In fact I
> > >>>
> > >>> think
> > >>>
> > >>> our
> > >>>
> > >>> release
> > >>>
> > >>> process involves some merges.
> > >>>
> > >>> I think setting standards on what is reasonable to be an
> > >>>
> > >>> individual
> > >>>
> > >>> commit
> > >>>
> > >>> will do a lot more to clean up our history than blocking
> > >>>
> > >>> merges.
> > >>>
> > >>> We'd
> > >>>
> > >>> rather not see commits like "Spotless Apply" in the
> > >>>
> > >>> history,
> > >>>
> > >>> but
> > >>>
> > >>> if
> > >>>
> > >>> reasonably separate and well written commits come in as
> > >>>
> > >>> part
> > >>>
> > >>> of
> > >>>
> > >>> a
> > >>>
> > >>> merge, I
> > >>>
> > >>> think that's fine.
> > >>>
> > >>> -Dan
> > >>>
> > >>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> > >>>
> > >>> jiliao@pivotal.io
> > >>>
> > >>>
> > >>> wrote:
> > >>>
> > >>> +1
> > >>>
> > >>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> > >>>
> > >>> onichols@pivotal.io
> > >>>
> > >>>
> > >>> wrote:
> > >>>
> > >>> I’d like to advance this topic from an informal
> > >>>
> > >>> request/discussion
> > >>>
> > >>> to a
> > >>>
> > >>> discussion of a concrete proposal.
> > >>>
> > >>> To recap, it sounds like there is general agreement
> > >>>
> > >>> that
> > >>>
> > >>> commit
> > >>>
> > >>> history
> > >>>
> > >>> on
> > >>>
> > >>> develop should be linear (no merge commits), and that
> > >>>
> > >>> the
> > >>>
> > >>> biggest
> > >>>
> > >>> obstacle
> > >>>
> > >>> to this is that the PR merge button in GitHub creates a
> > >>>
> > >>> merge
> > >>>
> > >>> commit
> > >>>
> > >>> by
> > >>>
> > >>> default.
> > >>>
> > >>> I propose the following changes:
> > >>> 1) Change GitHub settings to remove the ability to
> > >>>
> > >>> create
> > >>>
> > >>> a
> > >>>
> > >>> merge
> > >>>
> > >>> commit.
> > >>>
> > >>> This will make Squash & Merge the default.
> > >>>
> > >>> 2) Change GitHub settings to require linear history on
> > >>>
> > >>> develop.
> > >>>
> > >>> This
> > >>>
> > >>> prevents merge commits via command-line (not
> > >>>
> > >>> recommended,
> > >>>
> > >>> but
> > >>>
> > >>> wiki
> > >>>
> > >>> still
> > >>>
> > >>> has instructions for merging PRs this way).
> > >>>
> > >>> 3) Update the PR template to change the text "Is your
> > >>>
> > >>> initial
> > >>>
> > >>> contribution
> > >>>
> > >>> a single, squashed commit” to “Is your initial
> > >>>
> > >>> contribution
> > >>>
> > >>> squashed
> > >>>
> > >>> for
> > >>>
> > >>> ease of review (e.g. a single commit, or a
> > >>>
> > >>> ‘refactoring’
> > >>>
> > >>> commit
> > >>>
> > >>> plus
> > >>>
> > >>> a
> > >>>
> > >>> ‘fix’ commit)"
> > >>>
> > >>> For clarity, I am proposing no-change in the following
> > >>>
> > >>> areas:
> > >>>
> > >>> i) Leave Rebase & Merge as an option for PRs that have
> > >>>
> > >>> been
> > >>>
> > >>> structured to
> > >>>
> > >>> benefit from it (this can make it easier in a bisect to
> > >>>
> > >>> see
> > >>>
> > >>> whether
> > >>>
> > >>> the
> > >>>
> > >>> refactoring or the “fix” broke something).
> > >>> ii) Leave existing wording in the wiki as-is [stating
> > >>>
> > >>> that
> > >>>
> > >>> squashing
> > >>>
> > >>> is
> > >>>
> > >>> preferred].
> > >>>
> > >>>
> > >>> Please comment via this email thread.
> > >>> -Owen
> > >>>
> > >>>
> > >>>
> > >>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> > >>>
> > >>> klund@apache.org>
> > >>>
> > >>> wrote:
> > >>>
> > >>>
> > >>> I think it's already resolved Udo ;)
> > >>>
> > >>> Here's the problem, if I fixup a dunit test by
> > >>>
> > >>> removing
> > >>>
> > >>> all
> > >>>
> > >>> uses
> > >>>
> > >>> of
> > >>>
> > >>> "this."
> > >>>
> > >>> and I rename the dunit test, then git doesn't remember
> > >>>
> > >>> that
> > >>>
> > >>> the
> > >>>
> > >>> file
> > >>>
> > >>> is a
> > >>>
> > >>> rename -- it forever afterwards interprets it as a new
> > >>>
> > >>> file
> > >>>
> > >>> that I
> > >>>
> > >>> created
> > >>>
> > >>> if I touch more than 50% of the lines (which "this."
> > >>>
> > >>> can
> > >>>
> > >>> easily
> > >>>
> > >>> do). If
> > >>>
> > >>> we
> > >>>
> > >>> squash two commits: the rename and the cleanup of that
> > >>>
> > >>> dunit
> > >>>
> > >>> test
> > >>>
> > >>> --
> > >>>
> > >>> then
> > >>>
> > >>> we effectively lose the history of that file and it
> > >>>
> > >>> shows
> > >>>
> > >>> that
> > >>>
> > >>> I
> > >>>
> > >>> created
> > >>>
> > >>> a
> > >>>
> > >>> new file.
> > >>>
> > >>> Also for the record, I've been working on Geode since
> > >>>
> > >>> the
> > >>>
> > >>> beginning
> > >>>
> > >>> and I
> > >>>
> > >>> was never made aware of this change in our process. I
> > >>>
> > >>> never
> > >>>
> > >>> voted
> > >>>
> > >>> on
> > >>>
> > >>> it.
> > >>>
> > >>> I'm not a big fan of changing various details in our
> > >>>
> > >>> process
> > >>>
> > >>> every
> > >>>
> > >>> single
> > >>>
> > >>> week. It's very easy to miss these discussions unless
> > >>>
> > >>> someone
> > >>>
> > >>> points it
> > >>>
> > >>> out
> > >>>
> > >>> to me.
> > >>>
> > >>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > >>>
> > >>> ukohlmeyer@pivotal.io>
> > >>>
> > >>> wrote:
> > >>>
> > >>> I'm not sure what this discussion is about... WE, as
> > >>>
> > >>> a
> > >>>
> > >>> community,
> > >>>
> > >>> have
> > >>>
> > >>> agreed in common practices, in two place no less...
> > >>>
> > >>> 1) Quoting our PR template
> > >>>
> > >>>
> > >>> For all changes:
> > >>>
> > >>> *
> > >>>
> > >>> Is there a JIRA ticket associated with this PR? Is it
> > >>>
> > >>> referenced
> > >>>
> > >>> in
> > >>>
> > >>> the commit message?
> > >>>
> > >>> *
> > >>>
> > >>> Has your PR been rebased against the latest commit
> > >>>
> > >>> within
> > >>>
> > >>> the
> > >>>
> > >>> target
> > >>>
> > >>> branch (typically|develop|)?
> > >>>
> > >>> *
> > >>>
> > >>> ***Is your initial contribution a single, squashed
> > >>>
> > >>> commit?*
> > >>>
> > >>>
> > >>> *
> > >>>
> > >>> Does|gradlew build|run cleanly?
> > >>>
> > >>> *
> > >>>
> > >>> Have you written or updated unit tests to verify your
> > >>>
> > >>> changes?
> > >>>
> > >>>
> > >>> *
> > >>>
> > >>> If adding new dependencies to the code, are these
> > >>>
> > >>> dependencies
> > >>>
> > >>> licensed in a way that is compatible for inclusion
> > >>>
> > >>> underASF
> > >>>
> > >>> 2.0
> > >>>
> > >>> <
> > >>>
> > >>> http://www.apache.org/legal/resolved.html#category-a
> > >>>
> > >>> ?
> > >>>
> > >>>
> > >>> On our PR template we call out that the initial PR
> > >>>
> > >>> commit
> > >>>
> > >>> should
> > >>>
> > >>> be
> > >>>
> > >>> squashed.
> > >>>
> > >>> 2)
> > >>>
> > >>>
> > >>>
> > >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>
> > >>> <
> > >>>
> > >>>
> > >>>
> > >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>
> > >>> -- See "Accepting a PR Using the Command Line" -
> > >>>
> > >>> Point
> > >>>
> > >>> #3.
> > >>>
> > >>>
> > >>>
> > >>> @Kirk, if each of your commits "stands alone", I
> > >>>
> > >>> commend
> > >>>
> > >>> you
> > >>>
> > >>> on
> > >>>
> > >>> the
> > >>>
> > >>> diligence, but in reality, they should either then be
> > >>>
> > >>> stand
> > >>>
> > >>> alone
> > >>>
> > >>> PR's
> > >>>
> > >>> or just extra work created for yourself.
> > >>>
> > >>> If we want to change the way we have agreed upon we
> > >>>
> > >>> submit/commit/merge
> > >>>
> > >>> changes back into develop... Then this is another
> > >>>
> > >>> discussion
> > >>>
> > >>> thread,
> > >>>
> > >>> until then, I think we should all remind ourselves on
> > >>>
> > >>> our
> > >>>
> > >>> agreed
> > >>>
> > >>> contributions code of conduct.
> > >>>
> > >>> --Udo
> > >>>
> > >>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > >>>
> > >>> Kirk, I believe that creating a Pull Request with
> > >>>
> > >>> multiple
> > >>>
> > >>> commits is
> > >>>
> > >>> ok.
> > >>>
> > >>> It's just in the end that when it's being pushed to
> > >>>
> > >>> develop
> > >>>
> > >>> branch,
> > >>>
> > >>> it
> > >>>
> > >>> needs to be squash merged. I believe that is what
> > >>>
> > >>> you
> > >>>
> > >>> have
> > >>>
> > >>> mentioned
> > >>>
> > >>> in
> > >>>
> > >>> the
> > >>>
> > >>> first paragraph, and I am more than happy with that.
> > >>> If you can see in the first screenshot comparison
> > >>>
> > >>> that
> > >>>
> > >>> I
> > >>>
> > >>> had
> > >>>
> > >>> attached
> > >>>
> > >>> in
> > >>>
> > >>> the first email in this thread is what I want to
> > >>>
> > >>> avoid.
> > >>>
> > >>>
> > >>> Thank you for your feedback.
> > >>>
> > >>> Regards
> > >>> Naba
> > >>>
> > >>>
> > >>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> > >>>
> > >>> klund@apache.org>
> > >>>
> > >>> wrote:
> > >>>
> > >>> Whenever I submit a PR with multiple commits that I
> > >>>
> > >>> intend
> > >>>
> > >>> to
> > >>>
> > >>> rebase
> > >>>
> > >>> to
> > >>>
> > >>> develop, I always try to ensure that each commit
> > >>>
> > >>> stands
> > >>>
> > >>> alone
> > >>>
> > >>> as
> > >>>
> > >>> is
> > >>>
> > >>> (compiles and passes tests). Separating file
> > >>>
> > >>> renames
> > >>>
> > >>> and
> > >>>
> > >>> refactoring
> > >>>
> > >>> from
> > >>>
> > >>> behavior changes into different commits seems very
> > >>>
> > >>> valuable
> > >>>
> > >>> to
> > >>>
> > >>> me,
> > >>>
> > >>> and
> > >>>
> > >>> I've
> > >>>
> > >>> had trouble getting people to review PRs without
> > >>>
> > >>> this
> > >>>
> > >>> separation
> > >>>
> > >>> (but
> > >>>
> > >>> it
> > >>>
> > >>> could be squashed as it's merged to develop).
> > >>>
> > >>> It sounds to me like the real problem is (a) some
> > >>>
> > >>> PRs
> > >>>
> > >>> have
> > >>>
> > >>> multiple
> > >>>
> > >>> commits
> > >>>
> > >>> that don't compile or don't pass tests, and (b)
> > >>>
> > >>> some
> > >>>
> > >>> PRs
> > >>>
> > >>> that
> > >>>
> > >>> should
> > >>>
> > >>> be
> > >>>
> > >>> merged with squash are not (by accident most
> > >>>
> > >>> likely).
> > >>>
> > >>>
> > >>> I can submit multiple PRs instead of one PR with
> > >>>
> > >>> multiple
> > >>>
> > >>> commits.
> > >>>
> > >>> So
> > >>>
> > >>> I'll
> > >>>
> > >>> change my response to -0 if that helps prevent
> > >>>
> > >>> commits
> > >>>
> > >>> to
> > >>>
> > >>> develop
> > >>>
> > >>> that
> > >>>
> > >>> don't compile or pass tests. Without preventing
> > >>>
> > >>> rebase
> > >>>
> > >>> or
> > >>>
> > >>> merge
> > >>>
> > >>> commits
> > >>>
> > >>> from github, I'm not sure how we can really enforce
> > >>>
> > >>> this
> > >>>
> > >>> or
> > >>>
> > >>> prevent
> > >>>
> > >>> (b)
> > >>>
> > >>> above.
> > >>>
> > >>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > >>>
> > >>> amurmann@pivotal.io>
> > >>>
> > >>> wrote:
> > >>>
> > >>> I wonder if Kirk's and Naba's statements are
> > >>>
> > >>> necessarily
> > >>>
> > >>> at
> > >>>
> > >>> odds.
> > >>>
> > >>> Make the change easy (warning: this may be hard),
> > >>>
> > >>> then
> > >>>
> > >>> make
> > >>>
> > >>> the
> > >>>
> > >>> easy
> > >>>
> > >>> change."
> > >>>
> > >>> -Kent Beck
> > >>>
> > >>> Following Kent Beck's advise might reasonably
> > >>>
> > >>> split
> > >>>
> > >>> into
> > >>>
> > >>> two
> > >>>
> > >>> commits.
> > >>>
> > >>> One
> > >>>
> > >>> refactor commit and a separate commit that
> > >>>
> > >>> introduces
> > >>>
> > >>> the
> > >>>
> > >>> actual
> > >>>
> > >>> change.
> > >>>
> > >>> They should be individually revertible and might
> > >>>
> > >>> be
> > >>>
> > >>> easier
> > >>>
> > >>> understood
> > >>>
> > >>> if
> > >>>
> > >>> split out. I vividly remember a change on our code
> > >>>
> > >>> base
> > >>>
> > >>> where
> > >>>
> > >>> someone
> > >>>
> > >>> did a
> > >>>
> > >>> huge amount of refactoring that resulted than in
> > >>>
> > >>> one
> > >>>
> > >>> parameter
> > >>>
> > >>> changing
> > >>>
> > >>> in
> > >>>
> > >>> order to get the desired functionality change. If
> > >>>
> > >>> that
> > >>>
> > >>> was
> > >>>
> > >>> in
> > >>>
> > >>> one
> > >>>
> > >>> commit,
> > >>>
> > >>> it would be hard to see the actual change. If
> > >>>
> > >>> split
> > >>>
> > >>> out,
> > >>>
> > >>> it's
> > >>>
> > >>> beautiful
> > >>>
> > >>> and
> > >>>
> > >>> crystal clear.
> > >>>
> > >>> I am unsure how that would be reflected in terms
> > >>>
> > >>> of
> > >>>
> > >>> JIRA
> > >>>
> > >>> ticket
> > >>>
> > >>> references.
> > >>>
> > >>> Usually we assume that if there is a commit with
> > >>>
> > >>> the
> > >>>
> > >>> ticket
> > >>>
> > >>> number,
> > >>>
> > >>> the
> > >>>
> > >>> issue is resolved. Maybe the key here is to create
> > >>>
> > >>> a
> > >>>
> > >>> separate
> > >>>
> > >>> refactoring
> > >>>
> > >>> ticket.
> > >>>
> > >>> Would that allow us to have our cake and eat it
> > >>>
> > >>> too?
> > >>>
> > >>>
> > >>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> > >>>
> > >>> nnag@pivotal.io>
> > >>>
> > >>> wrote:
> > >>>
> > >>> It is to help with bisect operations when things
> > >>>
> > >>> start
> > >>>
> > >>> failing
> > >>>
> > >>> ...
> > >>>
> > >>> helps
> > >>>
> > >>> us
> > >>>
> > >>> it revert and build faster.
> > >>> also with cherry picking features / fixes to
> > >>>
> > >>> previous
> > >>>
> > >>> versions
> > >>>
> > >>> .
> > >>>
> > >>> And keeping the git history clean with no
> > >>>
> > >>> unnecessary
> > >>>
> > >>> “merge
> > >>>
> > >>> commits”.
> > >>>
> > >>> Regards
> > >>> Naba
> > >>>
> > >>>
> > >>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> > >>>
> > >>> klund@apache.org>
> > >>>
> > >>> wrote:
> > >>>
> > >>> -1 I really like to sometimes have more than 1
> > >>>
> > >>> commit
> > >>>
> > >>> in
> > >>>
> > >>> a
> > >>>
> > >>> PR
> > >>>
> > >>> and
> > >>>
> > >>> keep
> > >>>
> > >>> them
> > >>>
> > >>> separate when they merge to develop
> > >>>
> > >>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> > >>>
> > >>> nnag@pivotal.io>
> > >>>
> > >>> wrote:
> > >>>
> > >>> Hi Geode Committers,
> > >>>
> > >>> A kind request for using squash commit instead
> > >>>
> > >>> of
> > >>>
> > >>> using
> > >>>
> > >>> merge.
> > >>>
> > >>> This will really help us in our bisect
> > >>>
> > >>> operations
> > >>>
> > >>> when a
> > >>>
> > >>> regression/flakiness in the product is
> > >>>
> > >>> introduced.
> > >>>
> > >>> We
> > >>>
> > >>> can
> > >>>
> > >>> automate
> > >>>
> > >>> and
> > >>>
> > >>> go
> > >>>
> > >>> through fewer commits faster, avoiding commits
> > >>>
> > >>> like
> > >>>
> > >>> "spotless
> > >>>
> > >>> fix"
> > >>>
> > >>> and
> > >>>
> > >>> "re-trigger precheck-in" or other minor commits
> > >>>
> > >>> in
> > >>>
> > >>> the
> > >>>
> > >>> merged
> > >>>
> > >>> branch.
> > >>>
> > >>> Also, please use the commit format : (helps us
> > >>>
> > >>> to
> > >>>
> > >>> know
> > >>>
> > >>> who
> > >>>
> > >>> worked
> > >>>
> > >>> on
> > >>>
> > >>> it,
> > >>>
> > >>> what is the history)
> > >>>
> > >>>
> > >>>
> > >>> * GEODE-xxxx: <brief intro >
> > >>> * explanation line 1
> > >>>
> > >>> *
> > >>>
> > >>> explanation
> > >>>
> > >>> line
> > >>>
> > >>> 2*
> > >>>
> > >>> This is not a rule or anything, but a request
> > >>>
> > >>> to
> > >>>
> > >>> help
> > >>>
> > >>> out
> > >>>
> > >>> your
> > >>>
> > >>> fellow
> > >>>
> > >>> committers in quickly detecting a problem.
> > >>>
> > >>> For inspiration, we can look into Apache Kafka
> > >>>
> > >>> /
> > >>>
> > >>> Spark
> > >>>
> > >>> where
> > >>>
> > >>> they
> > >>>
> > >>> have
> > >>>
> > >>> a
> > >>>
> > >>> complete linear graph for their main branch
> > >>>
> > >>> HEAD
> > >>>
> > >>> [see
> > >>>
> > >>> attachment]
> > >>>
> > >>> Regards
> > >>> Naba.
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>>
> > >>> Ju@N
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Cheers
> > >>>
> > >>> Jinmei
> > >>
> > >>
> >
> >
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Nabarun Nag <nn...@apache.org>.
Aaron ,
Is it not the case currently? If I am working on a feature modifying class
X and another developer makes some refactoring changes on class X and
pushes it to develop, won't I have to resolve the merge commits anyway.
Regards
Naba
On Tue, Dec 31, 2019 at 6:01 PM Aaron Lindsey <aa...@apache.org>
wrote:
> Suppose I’m refactoring the same classes I’m touching for the feature. I
> do the refactoring on one branch and submit a PR for that. Then I implement
> the feature on another branch which is based on develop and does not have
> the refactoring changes since those are not merged yet. I’ll have to
> resolve conflicts on the second PR that I merge.
>
> Having interdependent PRs where one PR branch is based on another PR
> branch is not something I’ve tried. That requires more overhead in having
> to create more PRs and branches. And if you have N interdependent PRs, you
> have to do N-1 merges each time a PR is merged to develop (to update the
> other branches). It could be done, but is it worth the hassle?
>
> One more point about rebase-and-merge is that it seems like this would
> make bisecting a failure easier since there would be smaller commits.
>
> Aaron
>
> > On Dec 31, 2019, at 5:41 PM, Owen Nichols <on...@pivotal.io> wrote:
> >
> > Can you elaborate on why you would have to deal with conflicts if the
> > refactoring work was kept as a separate PR from the fix?
> >
> > As with many git workflows, there’s an easy way and a hard way to manage
> > interdependent PRs (tl;dr only merge, never rebase!). I wonder if this
> > points out an opportunity for a “tips and tricks” page on the Geode wiki.
> >
> > On Tue, Dec 31, 2019 at 5:22 PM Aaron Lindsey <aa...@apache.org>
> > wrote:
> >
> >> -0.9
> >>
> >> I’m not in favor of the revised proposal that disallows
> rebase-and-merge.
> >> Say I am working on a PR and I have a refactor commit and another commit
> >> which implements a new feature. I don’t want those commits to get
> squashed
> >> because that makes it hard to understand the diff. However, if I make
> those
> >> commits as two separate PRs then I am going to have to deal with
> conflicts.
> >>
> >> I’m not sure when we made it a rule that every commit in develop had to
> >> compile and pass tests. I know we implemented a rule that all PRs had to
> >> pass certain checks, but I never thought that rule implied all commits
> had
> >> to pass those checks.
> >>
> >> In general I just don’t see the problem with rebase-and-merge and this
> >> feels like an unnecessary restriction, but I will go with it if that’s
> what
> >> everyone wants to do.
> >>
> >> Aaron
> >>
> >>> On Dec 31, 2019, at 3:09 PM, Owen Nichols <on...@pivotal.io> wrote:
> >>>
> >>> To recap, this proposal is now revised to remove 2 of the 3 merge
> options
> >>> from GitHub, leaving only Squash and Merge. PR #4513
> >>> <https://github.com/apache/geode/pull/4513> serves as an exhibit of
> >> what is
> >>> proposed (it is not to be merged unless discussion leads to consensus
> >> and a
> >>> successful vote). Please use the dev list (not the PR) for all
> >> discussion
> >>> (and voting, if we get that far).
> >>>
> >>> Squash and merge is already used almost exclusively by the Geode
> >> community,
> >>> with any exceptions tending to be accidental more often than
> intentional.
> >>> However, some have raised the concern that implementing this
> restriction
> >>> could result in harm or wasted time. Can someone give an example of a
> >> such
> >>> a scenario?
> >>>
> >>> It seems there is a divide here between junior and senior community
> >>> members. Newer committers appreciate additional guardrails to protect
> >> them
> >>> from accidentally doing the wrong thing, while those with more
> experience
> >>> want to be able to work unencumbered by restrictions of any kind.
> >>>
> >>> Our welcome email to new committers states “We like to work on trust
> >> rather
> >>> than unnecessary constraints...Being a committer enables you to more
> >> easily
> >>> make changes without needing to go through the patch submission
> process”.
> >>> I can see this as an argument against this proposal (perhaps even an
> >>> argument against any form of branch protection).
> >>>
> >>> In the scheme of things, this proposal makes very little difference.
> >> There
> >>> are still other ways to get non-compiling commits onto develop (e.g.
> >>> waiting a long time between running PR checks and merging to develop).
> >>> What’s more important is working well together as a community. So,
> >> perhaps
> >>> what’s best for the community is to encourage working on trust rather
> >> than
> >>> unnecessary constraints.
> >>>
> >>> -Owen
> >>>
> >>> On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org> wrote:
> >>>
> >>> I'm happy to file multiple PRs when I need to merge multiple commits to
> >>> develop.
> >>>
> >>> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <mh...@pivotal.io>
> wrote:
> >>>
> >>> This change to disable all but squash-merge would be really easy to
> >>> revert. How about we try it for a while and see? If people decide it is
> >>> really limiting them, we can change it back. Let’s do it for 1 month
> and
> >>> see how it goes. Does that sound reasonable?
> >>>
> >>> Thanks,
> >>> Mark
> >>>
> >>> On Dec 30, 2019, at 5:25 PM, Owen Nichols <on...@pivotal.io> wrote:
> >>>
> >>> Given that we adopted <
> >>>
> >>>
> >>
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
> >>>>
> >>> and still wish to continue <
> >>>
> >>
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
> >>>>
> >>> having branch protection rules to ensure every commit landing in
> develop
> >>> has passed the required PR checks, it seems like that decision alone
> >>> mandates that we disable all merge mechanisms other than
> >> squash-and-merge.
> >>>
> >>>
> >>> Allowing merge commits or rebase merges bypasses branch protection for
> >>>
> >>> all commits other than the final one in the merge or rebase set. Given
> >>> that we decided <
> >>>
> >>
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
> >>>>
> >>> that bypassing PR checks should never be allowed, keeping this loophole
> >>> open seems untenable.
> >>>
> >>>
> >>> This is not just hypothetical — this loophole is causing real problems.
> >>>
> >>> We now have commits on develop that don’t compile. For example:
> >>>
> >>> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> >>> ./gradlew devBuild
> >>> ...spotlessJava FAILED
> >>> We implemented branch protections to make this impossible, right?
> >>>
> >>> We can very easily close this loophole by disabling all but the
> >>>
> >>> Squash&Merge button for PRs. This will not make more work for any
> >>> developer. If you want to get multiple commits onto develop, simply
> >> submit
> >>> each as a separate PR — that is the only way to assure that required PR
> >>> checks have passed for each.
> >>>
> >>>
> >>> On the other hand, if we as a Geode community feel strongly that
> >>>
> >>> bypassing branch protection via merge commits and rebase commits is
> >>> important to allow, why not also allow arbitrary overrides (or get rid
> of
> >>> branch protection entirely)?
> >>>
> >>>
> >>> -Owen
> >>>
> >>> On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io> wrote:
> >>>
> >>> Just FWIW, the situation described of having multiple commits in a
> >>>
> >>> single
> >>>
> >>> PR with separate associated JIRA tickets is still kind of problematic.
> >>>
> >>> It
> >>>
> >>> could well be the case that the commits are interdependent, thus when
> >>> bisecting etc it's still not possible to revert the fix for a single
> >>> bug/feature/whatever atomically. It's all good, though, I'm satisfied
> >>>
> >>> no
> >>>
> >>> one's forcing me to adopt practice I'm opposed to. Apologies for
> >>>
> >>> getting
> >>>
> >>> my feathers a little ruffled, or if I ruffled anyone else's in return.
> >>>
> >>> Thanks,
> >>>
> >>> Blake
> >>>
> >>>
> >>> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >>>
> >>> Hi Dan,
> >>>
> >>> When we do squash merge all the commit messages are preserved and also
> >>>
> >>> the
> >>>
> >>> co-authored tag works when we do squash merge.
> >>> So the authorship and history are preserved.
> >>>
> >>> In my own personal experience and reverts and pinpointing regression
> >>> failures are tough when the commits are spread out. Also, reverts are
> >>> easier when it is just one commit while we are bisecting failures.
> >>>
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io> wrote:
> >>>
> >>> I'll change to -0.
> >>>
> >>> I think merge commits are a nice way to record history in some cases,
> >>>
> >>> and
> >>>
> >>> can also be a way to avoid messy conflicts that come with rebase.
> >>>
> >>> Merge
> >>>
> >>> commits also preserve authorship of commits (compared to
> >>>
> >>> squash-merge),
> >>>
> >>> which I think is valuable as an open source community that is trying
> >>>
> >>> to
> >>>
> >>> keep track of outside contributions.
> >>>
> >>> That said, if the rest of y'all feel it will help to disable the
> >>>
> >>> button,
> >>>
> >>> I
> >>>
> >>> won't stand in the way.
> >>>
> >>> -Dan
> >>>
> >>> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> Whether we are talking about the geode/ repository or the
> >>>
> >>> geode-native/
> >>>
> >>> repository we are all one GEODE community.
> >>>
> >>> The idea of a native client team may matter in some contexts but in
> >>>
> >>> this
> >>>
> >>> space we are all GEODE contributors.
> >>>
> >>> Adopting a common approach across our repos will make it easier for
> >>>
> >>> new
> >>>
> >>> contributors to engage, learn our norms, and join our efforts.
> >>>
> >>> $0.02,
> >>> Anthony
> >>>
> >>>
> >>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> Is this a policy the native client team must abide by, as well? It
> >>>
> >>> varies
> >>>
> >>> slightly with what we've been doing, and all other things being
> >>>
> >>> equal I
> >>>
> >>> see
> >>>
> >>> no reason for us to change that. If I am to have any measure of
> >>>
> >>> control
> >>>
> >>> over the nc repository, I will definitely enforce a 1:1
> >>>
> >>> correspondence
> >>>
> >>> between commits to develop and JIRA tickets. IMO, if your
> >>>
> >>> refactoring
> >>>
> >>> in a
> >>>
> >>> PR is sufficiently large or complex that it's difficult to tease it
> >>>
> >>> out
> >>>
> >>> from the bug you're fixing or feature you're implementing, it merits
> >>>
> >>> its
> >>>
> >>> own JIRA ticket and a separate PR. If your "actual" fix then
> >>>
> >>> becomes
> >>>
> >>> dependent on the refactored code, that's a price I'm willing to pay
> >>>
> >>> to
> >>>
> >>> keep
> >>>
> >>> history clean.
> >>>
> >>> On the other hand, I see no real value in squashing to a single
> >>>
> >>> commit
> >>>
> >>> prior to submitting a PR, since your view of the changes on GitHub
> >>>
> >>> is
> >>>
> >>> essentially the same either way. We haven't enforced this on the nc
> >>>
> >>> repo,
> >>>
> >>> and I'd prefer to keep it that way.
> >>>
> >>> Thanks,
> >>>
> >>> Blake
> >>>
> >>>
> >>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> Merge commit is the new contributor's default setting. When we are
> >>>
> >>> merging
> >>>
> >>> new contributor's PR, since we are so used to THINKING
> >>>
> >>> "squash-and-merge"
> >>>
> >>> is the default, we forgot to check what the button really says when
> >>>
> >>> we
> >>>
> >>> are
> >>>
> >>> merging other people's PR.
> >>>
> >>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> >>>
> >>> eburghardt@pivotal.io>
> >>>
> >>> wrote:
> >>>
> >>> I'm a proponent of using squash-and-merge, and once a person has
> >>>
> >>> chosen
> >>>
> >>> this option once it comes up by default afterwards...
> >>>
> >>> Owen, I don't think you have consensus to put forth this PR,
> >>>
> >>> there
> >>>
> >>> are
> >>>
> >>> -1s
> >>>
> >>> above... (early voting)
> >>>
> >>> maybe we'll be better off socializing the norm of squash-and-merge
> >>>
> >>> and
> >>>
> >>> gaining a natural consensus that way...
> >>>
> >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
> >>>
> >>> onichols@pivotal.io
> >>>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> The proposed action manifests as a commit to the Geode git
> >>>
> >>> repository,
> >>>
> >>> so
> >>>
> >>> a PR is an acceptable vehicle for voting in this case.
> >>>
> >>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> >>>
> >>> bschuchardt@pivotal.io>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> >>>
> >>> thread
> >>>
> >>> and a request to "vote" using a PR. This all seems out of order
> >>>
> >>> to
> >>>
> >>> me.
> >>>
> >>> Our votes are supposed to be on the email list, aren't they? and
> >>>
> >>> I
> >>>
> >>> haven't
> >>>
> >>> seen a VOTE request.
> >>>
> >>>
> >>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> >>>
> >>> +1
> >>>
> >>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
> >>>
> >>> onichols@pivotal.io
> >>>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> Based on the feedback so far, I will amend the proposal to
> >>>
> >>> drop
> >>>
> >>> item
> >>>
> >>> 2).
> >>>
> >>> Therefore, the current ability to create merge commits using
> >>>
> >>> command-line
> >>>
> >>> git will remain available.
> >>>
> >>> The proposal as amended is now:
> >>>
> >>> Change GitHub settings to make "Squash and merge" the default
> >>> (by removing “Create a merge commit” option).
> >>>
> >>> Update the PR template to change the text "Is your initial
> >>>
> >>> contribution
> >>>
> >>> a single, squashed commit” to “Is your initial contribution
> >>>
> >>> squashed
> >>>
> >>> for
> >>>
> >>> ease of review (e.g. a single commit, or a ‘refactoring’
> >>>
> >>> commit
> >>>
> >>> plus a
> >>>
> >>> ‘fix’ commit)"
> >>>
> >>>
> >>> As Naba suggested, we can try it, and if we don’t like it,
> >>>
> >>> it’s
> >>>
> >>> simple
> >>>
> >>> to
> >>>
> >>> revert.
> >>>
> >>> I’ve create a PR for the proposed change here:
> >>> https://github.com/apache/geode/pull/4513
> >>>
> >>> Please use the PR to vote for against this proposal. It will
> >>>
> >>> not
> >>>
> >>> be
> >>>
> >>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
> >>>
> >>> that
> >>>
> >>> time)
> >>>
> >>>
> >>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> +1
> >>>
> >>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
> >>>
> >>> onichols@pivotal.io>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> Hi Bruce, this proposal will not waste a single second of
> >>>
> >>> your
> >>>
> >>> time. It
> >>>
> >>> just prevents people from accidentally pressing a button
> >>>
> >>> that
> >>>
> >>> we
> >>>
> >>> have
> >>>
> >>> already agreed should never be pressed, but because we never
> >>>
> >>> configured
> >>>
> >>> our
> >>>
> >>> GitHub to match our stated policy, is currently the default.
> >>>
> >>> However, it will save a lot of time and frustration for
> >>>
> >>> anyone
> >>>
> >>> needing
> >>>
> >>> to
> >>>
> >>> bisect failures, revert, or cherry-pick changes, which has
> >>>
> >>> merit
> >>>
> >>> even if
> >>>
> >>> you personally never do any of those three things.
> >>>
> >>> Please start a separate thread if you would like to revisit
> >>>
> >>> the
> >>>
> >>> community
> >>>
> >>> decision to require passing PR checks.
> >>>
> >>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> >>>
> >>> bschuchardt@pivotal.io>
> >>>
> >>> wrote:
> >>>
> >>> I agree with Jake. I would go further by saying that I see
> >>>
> >>> very
> >>>
> >>> little
> >>>
> >>> merit in this proposal. I think we're getting more and more
> >>>
> >>> bureaucratic
> >>>
> >>> in our process and that it stifles productivity. I was
> >>>
> >>> recently
> >>>
> >>> forced
> >>>
> >>> to
> >>>
> >>> spend three days fixing tests in which I had changed an
> >>>
> >>> import
> >>>
> >>> statement
> >>>
> >>> before they would pass stress testing. I'm glad the tests
> >>>
> >>> now
> >>>
> >>> pass
> >>>
> >>> reliably but I was very frustrated by the process.
> >>>
> >>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> >>>
> >>> I’m in agreement with Dan. Changes to the infrastructure
> >>>
> >>> to
> >>>
> >>> flat
> >>>
> >>> out
> >>>
> >>> prevent things that should be self policing is annoying.
> >>>
> >>> This
> >>>
> >>> PR
> >>>
> >>> review
> >>>
> >>> lock we have had already cost us valuable time waiting for
> >>>
> >>> PR
> >>>
> >>> pipelines
> >>>
> >>> to
> >>>
> >>> pass that have no relevance to the commit, like CI work: I’d
> >>>
> >>> hat
> >>>
> >>> to
> >>>
> >>> see
> >>>
> >>> yet
> >>>
> >>> another process enforced that Kees us from getting work done
> >>>
> >>> when
> >>>
> >>> necessary.
> >>>
> >>> -Jake
> >>>
> >>>
> >>> On Dec 19, 2019, at 4:43 PM, Dan Smith <
> >>>
> >>> dsmith@pivotal.io
> >>>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> -1 to (1) and (2).
> >>>
> >>> I think merge commits are appropriate in certain
> >>>
> >>> circumstances,
> >>>
> >>> so I
> >>>
> >>> don't
> >>>
> >>> think we should make a blanket restriction. In fact I
> >>>
> >>> think
> >>>
> >>> our
> >>>
> >>> release
> >>>
> >>> process involves some merges.
> >>>
> >>> I think setting standards on what is reasonable to be an
> >>>
> >>> individual
> >>>
> >>> commit
> >>>
> >>> will do a lot more to clean up our history than blocking
> >>>
> >>> merges.
> >>>
> >>> We'd
> >>>
> >>> rather not see commits like "Spotless Apply" in the
> >>>
> >>> history,
> >>>
> >>> but
> >>>
> >>> if
> >>>
> >>> reasonably separate and well written commits come in as
> >>>
> >>> part
> >>>
> >>> of
> >>>
> >>> a
> >>>
> >>> merge, I
> >>>
> >>> think that's fine.
> >>>
> >>> -Dan
> >>>
> >>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> >>>
> >>> jiliao@pivotal.io
> >>>
> >>>
> >>> wrote:
> >>>
> >>> +1
> >>>
> >>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> >>>
> >>> onichols@pivotal.io
> >>>
> >>>
> >>> wrote:
> >>>
> >>> I’d like to advance this topic from an informal
> >>>
> >>> request/discussion
> >>>
> >>> to a
> >>>
> >>> discussion of a concrete proposal.
> >>>
> >>> To recap, it sounds like there is general agreement
> >>>
> >>> that
> >>>
> >>> commit
> >>>
> >>> history
> >>>
> >>> on
> >>>
> >>> develop should be linear (no merge commits), and that
> >>>
> >>> the
> >>>
> >>> biggest
> >>>
> >>> obstacle
> >>>
> >>> to this is that the PR merge button in GitHub creates a
> >>>
> >>> merge
> >>>
> >>> commit
> >>>
> >>> by
> >>>
> >>> default.
> >>>
> >>> I propose the following changes:
> >>> 1) Change GitHub settings to remove the ability to
> >>>
> >>> create
> >>>
> >>> a
> >>>
> >>> merge
> >>>
> >>> commit.
> >>>
> >>> This will make Squash & Merge the default.
> >>>
> >>> 2) Change GitHub settings to require linear history on
> >>>
> >>> develop.
> >>>
> >>> This
> >>>
> >>> prevents merge commits via command-line (not
> >>>
> >>> recommended,
> >>>
> >>> but
> >>>
> >>> wiki
> >>>
> >>> still
> >>>
> >>> has instructions for merging PRs this way).
> >>>
> >>> 3) Update the PR template to change the text "Is your
> >>>
> >>> initial
> >>>
> >>> contribution
> >>>
> >>> a single, squashed commit” to “Is your initial
> >>>
> >>> contribution
> >>>
> >>> squashed
> >>>
> >>> for
> >>>
> >>> ease of review (e.g. a single commit, or a
> >>>
> >>> ‘refactoring’
> >>>
> >>> commit
> >>>
> >>> plus
> >>>
> >>> a
> >>>
> >>> ‘fix’ commit)"
> >>>
> >>> For clarity, I am proposing no-change in the following
> >>>
> >>> areas:
> >>>
> >>> i) Leave Rebase & Merge as an option for PRs that have
> >>>
> >>> been
> >>>
> >>> structured to
> >>>
> >>> benefit from it (this can make it easier in a bisect to
> >>>
> >>> see
> >>>
> >>> whether
> >>>
> >>> the
> >>>
> >>> refactoring or the “fix” broke something).
> >>> ii) Leave existing wording in the wiki as-is [stating
> >>>
> >>> that
> >>>
> >>> squashing
> >>>
> >>> is
> >>>
> >>> preferred].
> >>>
> >>>
> >>> Please comment via this email thread.
> >>> -Owen
> >>>
> >>>
> >>>
> >>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> >>>
> >>> klund@apache.org>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> I think it's already resolved Udo ;)
> >>>
> >>> Here's the problem, if I fixup a dunit test by
> >>>
> >>> removing
> >>>
> >>> all
> >>>
> >>> uses
> >>>
> >>> of
> >>>
> >>> "this."
> >>>
> >>> and I rename the dunit test, then git doesn't remember
> >>>
> >>> that
> >>>
> >>> the
> >>>
> >>> file
> >>>
> >>> is a
> >>>
> >>> rename -- it forever afterwards interprets it as a new
> >>>
> >>> file
> >>>
> >>> that I
> >>>
> >>> created
> >>>
> >>> if I touch more than 50% of the lines (which "this."
> >>>
> >>> can
> >>>
> >>> easily
> >>>
> >>> do). If
> >>>
> >>> we
> >>>
> >>> squash two commits: the rename and the cleanup of that
> >>>
> >>> dunit
> >>>
> >>> test
> >>>
> >>> --
> >>>
> >>> then
> >>>
> >>> we effectively lose the history of that file and it
> >>>
> >>> shows
> >>>
> >>> that
> >>>
> >>> I
> >>>
> >>> created
> >>>
> >>> a
> >>>
> >>> new file.
> >>>
> >>> Also for the record, I've been working on Geode since
> >>>
> >>> the
> >>>
> >>> beginning
> >>>
> >>> and I
> >>>
> >>> was never made aware of this change in our process. I
> >>>
> >>> never
> >>>
> >>> voted
> >>>
> >>> on
> >>>
> >>> it.
> >>>
> >>> I'm not a big fan of changing various details in our
> >>>
> >>> process
> >>>
> >>> every
> >>>
> >>> single
> >>>
> >>> week. It's very easy to miss these discussions unless
> >>>
> >>> someone
> >>>
> >>> points it
> >>>
> >>> out
> >>>
> >>> to me.
> >>>
> >>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> >>>
> >>> ukohlmeyer@pivotal.io>
> >>>
> >>> wrote:
> >>>
> >>> I'm not sure what this discussion is about... WE, as
> >>>
> >>> a
> >>>
> >>> community,
> >>>
> >>> have
> >>>
> >>> agreed in common practices, in two place no less...
> >>>
> >>> 1) Quoting our PR template
> >>>
> >>>
> >>> For all changes:
> >>>
> >>> *
> >>>
> >>> Is there a JIRA ticket associated with this PR? Is it
> >>>
> >>> referenced
> >>>
> >>> in
> >>>
> >>> the commit message?
> >>>
> >>> *
> >>>
> >>> Has your PR been rebased against the latest commit
> >>>
> >>> within
> >>>
> >>> the
> >>>
> >>> target
> >>>
> >>> branch (typically|develop|)?
> >>>
> >>> *
> >>>
> >>> ***Is your initial contribution a single, squashed
> >>>
> >>> commit?*
> >>>
> >>>
> >>> *
> >>>
> >>> Does|gradlew build|run cleanly?
> >>>
> >>> *
> >>>
> >>> Have you written or updated unit tests to verify your
> >>>
> >>> changes?
> >>>
> >>>
> >>> *
> >>>
> >>> If adding new dependencies to the code, are these
> >>>
> >>> dependencies
> >>>
> >>> licensed in a way that is compatible for inclusion
> >>>
> >>> underASF
> >>>
> >>> 2.0
> >>>
> >>> <
> >>>
> >>> http://www.apache.org/legal/resolved.html#category-a
> >>>
> >>> ?
> >>>
> >>>
> >>> On our PR template we call out that the initial PR
> >>>
> >>> commit
> >>>
> >>> should
> >>>
> >>> be
> >>>
> >>> squashed.
> >>>
> >>> 2)
> >>>
> >>>
> >>>
> >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>
> >>> <
> >>>
> >>>
> >>>
> >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>
> >>> -- See "Accepting a PR Using the Command Line" -
> >>>
> >>> Point
> >>>
> >>> #3.
> >>>
> >>>
> >>>
> >>> @Kirk, if each of your commits "stands alone", I
> >>>
> >>> commend
> >>>
> >>> you
> >>>
> >>> on
> >>>
> >>> the
> >>>
> >>> diligence, but in reality, they should either then be
> >>>
> >>> stand
> >>>
> >>> alone
> >>>
> >>> PR's
> >>>
> >>> or just extra work created for yourself.
> >>>
> >>> If we want to change the way we have agreed upon we
> >>>
> >>> submit/commit/merge
> >>>
> >>> changes back into develop... Then this is another
> >>>
> >>> discussion
> >>>
> >>> thread,
> >>>
> >>> until then, I think we should all remind ourselves on
> >>>
> >>> our
> >>>
> >>> agreed
> >>>
> >>> contributions code of conduct.
> >>>
> >>> --Udo
> >>>
> >>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >>>
> >>> Kirk, I believe that creating a Pull Request with
> >>>
> >>> multiple
> >>>
> >>> commits is
> >>>
> >>> ok.
> >>>
> >>> It's just in the end that when it's being pushed to
> >>>
> >>> develop
> >>>
> >>> branch,
> >>>
> >>> it
> >>>
> >>> needs to be squash merged. I believe that is what
> >>>
> >>> you
> >>>
> >>> have
> >>>
> >>> mentioned
> >>>
> >>> in
> >>>
> >>> the
> >>>
> >>> first paragraph, and I am more than happy with that.
> >>> If you can see in the first screenshot comparison
> >>>
> >>> that
> >>>
> >>> I
> >>>
> >>> had
> >>>
> >>> attached
> >>>
> >>> in
> >>>
> >>> the first email in this thread is what I want to
> >>>
> >>> avoid.
> >>>
> >>>
> >>> Thank you for your feedback.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>>
> >>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> >>>
> >>> klund@apache.org>
> >>>
> >>> wrote:
> >>>
> >>> Whenever I submit a PR with multiple commits that I
> >>>
> >>> intend
> >>>
> >>> to
> >>>
> >>> rebase
> >>>
> >>> to
> >>>
> >>> develop, I always try to ensure that each commit
> >>>
> >>> stands
> >>>
> >>> alone
> >>>
> >>> as
> >>>
> >>> is
> >>>
> >>> (compiles and passes tests). Separating file
> >>>
> >>> renames
> >>>
> >>> and
> >>>
> >>> refactoring
> >>>
> >>> from
> >>>
> >>> behavior changes into different commits seems very
> >>>
> >>> valuable
> >>>
> >>> to
> >>>
> >>> me,
> >>>
> >>> and
> >>>
> >>> I've
> >>>
> >>> had trouble getting people to review PRs without
> >>>
> >>> this
> >>>
> >>> separation
> >>>
> >>> (but
> >>>
> >>> it
> >>>
> >>> could be squashed as it's merged to develop).
> >>>
> >>> It sounds to me like the real problem is (a) some
> >>>
> >>> PRs
> >>>
> >>> have
> >>>
> >>> multiple
> >>>
> >>> commits
> >>>
> >>> that don't compile or don't pass tests, and (b)
> >>>
> >>> some
> >>>
> >>> PRs
> >>>
> >>> that
> >>>
> >>> should
> >>>
> >>> be
> >>>
> >>> merged with squash are not (by accident most
> >>>
> >>> likely).
> >>>
> >>>
> >>> I can submit multiple PRs instead of one PR with
> >>>
> >>> multiple
> >>>
> >>> commits.
> >>>
> >>> So
> >>>
> >>> I'll
> >>>
> >>> change my response to -0 if that helps prevent
> >>>
> >>> commits
> >>>
> >>> to
> >>>
> >>> develop
> >>>
> >>> that
> >>>
> >>> don't compile or pass tests. Without preventing
> >>>
> >>> rebase
> >>>
> >>> or
> >>>
> >>> merge
> >>>
> >>> commits
> >>>
> >>> from github, I'm not sure how we can really enforce
> >>>
> >>> this
> >>>
> >>> or
> >>>
> >>> prevent
> >>>
> >>> (b)
> >>>
> >>> above.
> >>>
> >>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >>>
> >>> amurmann@pivotal.io>
> >>>
> >>> wrote:
> >>>
> >>> I wonder if Kirk's and Naba's statements are
> >>>
> >>> necessarily
> >>>
> >>> at
> >>>
> >>> odds.
> >>>
> >>> Make the change easy (warning: this may be hard),
> >>>
> >>> then
> >>>
> >>> make
> >>>
> >>> the
> >>>
> >>> easy
> >>>
> >>> change."
> >>>
> >>> -Kent Beck
> >>>
> >>> Following Kent Beck's advise might reasonably
> >>>
> >>> split
> >>>
> >>> into
> >>>
> >>> two
> >>>
> >>> commits.
> >>>
> >>> One
> >>>
> >>> refactor commit and a separate commit that
> >>>
> >>> introduces
> >>>
> >>> the
> >>>
> >>> actual
> >>>
> >>> change.
> >>>
> >>> They should be individually revertible and might
> >>>
> >>> be
> >>>
> >>> easier
> >>>
> >>> understood
> >>>
> >>> if
> >>>
> >>> split out. I vividly remember a change on our code
> >>>
> >>> base
> >>>
> >>> where
> >>>
> >>> someone
> >>>
> >>> did a
> >>>
> >>> huge amount of refactoring that resulted than in
> >>>
> >>> one
> >>>
> >>> parameter
> >>>
> >>> changing
> >>>
> >>> in
> >>>
> >>> order to get the desired functionality change. If
> >>>
> >>> that
> >>>
> >>> was
> >>>
> >>> in
> >>>
> >>> one
> >>>
> >>> commit,
> >>>
> >>> it would be hard to see the actual change. If
> >>>
> >>> split
> >>>
> >>> out,
> >>>
> >>> it's
> >>>
> >>> beautiful
> >>>
> >>> and
> >>>
> >>> crystal clear.
> >>>
> >>> I am unsure how that would be reflected in terms
> >>>
> >>> of
> >>>
> >>> JIRA
> >>>
> >>> ticket
> >>>
> >>> references.
> >>>
> >>> Usually we assume that if there is a commit with
> >>>
> >>> the
> >>>
> >>> ticket
> >>>
> >>> number,
> >>>
> >>> the
> >>>
> >>> issue is resolved. Maybe the key here is to create
> >>>
> >>> a
> >>>
> >>> separate
> >>>
> >>> refactoring
> >>>
> >>> ticket.
> >>>
> >>> Would that allow us to have our cake and eat it
> >>>
> >>> too?
> >>>
> >>>
> >>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> >>>
> >>> nnag@pivotal.io>
> >>>
> >>> wrote:
> >>>
> >>> It is to help with bisect operations when things
> >>>
> >>> start
> >>>
> >>> failing
> >>>
> >>> ...
> >>>
> >>> helps
> >>>
> >>> us
> >>>
> >>> it revert and build faster.
> >>> also with cherry picking features / fixes to
> >>>
> >>> previous
> >>>
> >>> versions
> >>>
> >>> .
> >>>
> >>> And keeping the git history clean with no
> >>>
> >>> unnecessary
> >>>
> >>> “merge
> >>>
> >>> commits”.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>>
> >>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> >>>
> >>> klund@apache.org>
> >>>
> >>> wrote:
> >>>
> >>> -1 I really like to sometimes have more than 1
> >>>
> >>> commit
> >>>
> >>> in
> >>>
> >>> a
> >>>
> >>> PR
> >>>
> >>> and
> >>>
> >>> keep
> >>>
> >>> them
> >>>
> >>> separate when they merge to develop
> >>>
> >>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> >>>
> >>> nnag@pivotal.io>
> >>>
> >>> wrote:
> >>>
> >>> Hi Geode Committers,
> >>>
> >>> A kind request for using squash commit instead
> >>>
> >>> of
> >>>
> >>> using
> >>>
> >>> merge.
> >>>
> >>> This will really help us in our bisect
> >>>
> >>> operations
> >>>
> >>> when a
> >>>
> >>> regression/flakiness in the product is
> >>>
> >>> introduced.
> >>>
> >>> We
> >>>
> >>> can
> >>>
> >>> automate
> >>>
> >>> and
> >>>
> >>> go
> >>>
> >>> through fewer commits faster, avoiding commits
> >>>
> >>> like
> >>>
> >>> "spotless
> >>>
> >>> fix"
> >>>
> >>> and
> >>>
> >>> "re-trigger precheck-in" or other minor commits
> >>>
> >>> in
> >>>
> >>> the
> >>>
> >>> merged
> >>>
> >>> branch.
> >>>
> >>> Also, please use the commit format : (helps us
> >>>
> >>> to
> >>>
> >>> know
> >>>
> >>> who
> >>>
> >>> worked
> >>>
> >>> on
> >>>
> >>> it,
> >>>
> >>> what is the history)
> >>>
> >>>
> >>>
> >>> * GEODE-xxxx: <brief intro >
> >>> * explanation line 1
> >>>
> >>> *
> >>>
> >>> explanation
> >>>
> >>> line
> >>>
> >>> 2*
> >>>
> >>> This is not a rule or anything, but a request
> >>>
> >>> to
> >>>
> >>> help
> >>>
> >>> out
> >>>
> >>> your
> >>>
> >>> fellow
> >>>
> >>> committers in quickly detecting a problem.
> >>>
> >>> For inspiration, we can look into Apache Kafka
> >>>
> >>> /
> >>>
> >>> Spark
> >>>
> >>> where
> >>>
> >>> they
> >>>
> >>> have
> >>>
> >>> a
> >>>
> >>> complete linear graph for their main branch
> >>>
> >>> HEAD
> >>>
> >>> [see
> >>>
> >>> attachment]
> >>>
> >>> Regards
> >>> Naba.
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Ju@N
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Cheers
> >>>
> >>> Jinmei
> >>
> >>
>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Aaron Lindsey <aa...@apache.org>.
Suppose I’m refactoring the same classes I’m touching for the feature. I do the refactoring on one branch and submit a PR for that. Then I implement the feature on another branch which is based on develop and does not have the refactoring changes since those are not merged yet. I’ll have to resolve conflicts on the second PR that I merge.
Having interdependent PRs where one PR branch is based on another PR branch is not something I’ve tried. That requires more overhead in having to create more PRs and branches. And if you have N interdependent PRs, you have to do N-1 merges each time a PR is merged to develop (to update the other branches). It could be done, but is it worth the hassle?
One more point about rebase-and-merge is that it seems like this would make bisecting a failure easier since there would be smaller commits.
Aaron
> On Dec 31, 2019, at 5:41 PM, Owen Nichols <on...@pivotal.io> wrote:
>
> Can you elaborate on why you would have to deal with conflicts if the
> refactoring work was kept as a separate PR from the fix?
>
> As with many git workflows, there’s an easy way and a hard way to manage
> interdependent PRs (tl;dr only merge, never rebase!). I wonder if this
> points out an opportunity for a “tips and tricks” page on the Geode wiki.
>
> On Tue, Dec 31, 2019 at 5:22 PM Aaron Lindsey <aa...@apache.org>
> wrote:
>
>> -0.9
>>
>> I’m not in favor of the revised proposal that disallows rebase-and-merge.
>> Say I am working on a PR and I have a refactor commit and another commit
>> which implements a new feature. I don’t want those commits to get squashed
>> because that makes it hard to understand the diff. However, if I make those
>> commits as two separate PRs then I am going to have to deal with conflicts.
>>
>> I’m not sure when we made it a rule that every commit in develop had to
>> compile and pass tests. I know we implemented a rule that all PRs had to
>> pass certain checks, but I never thought that rule implied all commits had
>> to pass those checks.
>>
>> In general I just don’t see the problem with rebase-and-merge and this
>> feels like an unnecessary restriction, but I will go with it if that’s what
>> everyone wants to do.
>>
>> Aaron
>>
>>> On Dec 31, 2019, at 3:09 PM, Owen Nichols <on...@pivotal.io> wrote:
>>>
>>> To recap, this proposal is now revised to remove 2 of the 3 merge options
>>> from GitHub, leaving only Squash and Merge. PR #4513
>>> <https://github.com/apache/geode/pull/4513> serves as an exhibit of
>> what is
>>> proposed (it is not to be merged unless discussion leads to consensus
>> and a
>>> successful vote). Please use the dev list (not the PR) for all
>> discussion
>>> (and voting, if we get that far).
>>>
>>> Squash and merge is already used almost exclusively by the Geode
>> community,
>>> with any exceptions tending to be accidental more often than intentional.
>>> However, some have raised the concern that implementing this restriction
>>> could result in harm or wasted time. Can someone give an example of a
>> such
>>> a scenario?
>>>
>>> It seems there is a divide here between junior and senior community
>>> members. Newer committers appreciate additional guardrails to protect
>> them
>>> from accidentally doing the wrong thing, while those with more experience
>>> want to be able to work unencumbered by restrictions of any kind.
>>>
>>> Our welcome email to new committers states “We like to work on trust
>> rather
>>> than unnecessary constraints...Being a committer enables you to more
>> easily
>>> make changes without needing to go through the patch submission process”.
>>> I can see this as an argument against this proposal (perhaps even an
>>> argument against any form of branch protection).
>>>
>>> In the scheme of things, this proposal makes very little difference.
>> There
>>> are still other ways to get non-compiling commits onto develop (e.g.
>>> waiting a long time between running PR checks and merging to develop).
>>> What’s more important is working well together as a community. So,
>> perhaps
>>> what’s best for the community is to encourage working on trust rather
>> than
>>> unnecessary constraints.
>>>
>>> -Owen
>>>
>>> On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org> wrote:
>>>
>>> I'm happy to file multiple PRs when I need to merge multiple commits to
>>> develop.
>>>
>>> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <mh...@pivotal.io> wrote:
>>>
>>> This change to disable all but squash-merge would be really easy to
>>> revert. How about we try it for a while and see? If people decide it is
>>> really limiting them, we can change it back. Let’s do it for 1 month and
>>> see how it goes. Does that sound reasonable?
>>>
>>> Thanks,
>>> Mark
>>>
>>> On Dec 30, 2019, at 5:25 PM, Owen Nichols <on...@pivotal.io> wrote:
>>>
>>> Given that we adopted <
>>>
>>>
>> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
>>>>
>>> and still wish to continue <
>>>
>> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
>>>>
>>> having branch protection rules to ensure every commit landing in develop
>>> has passed the required PR checks, it seems like that decision alone
>>> mandates that we disable all merge mechanisms other than
>> squash-and-merge.
>>>
>>>
>>> Allowing merge commits or rebase merges bypasses branch protection for
>>>
>>> all commits other than the final one in the merge or rebase set. Given
>>> that we decided <
>>>
>> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
>>>>
>>> that bypassing PR checks should never be allowed, keeping this loophole
>>> open seems untenable.
>>>
>>>
>>> This is not just hypothetical — this loophole is causing real problems.
>>>
>>> We now have commits on develop that don’t compile. For example:
>>>
>>> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
>>> ./gradlew devBuild
>>> ...spotlessJava FAILED
>>> We implemented branch protections to make this impossible, right?
>>>
>>> We can very easily close this loophole by disabling all but the
>>>
>>> Squash&Merge button for PRs. This will not make more work for any
>>> developer. If you want to get multiple commits onto develop, simply
>> submit
>>> each as a separate PR — that is the only way to assure that required PR
>>> checks have passed for each.
>>>
>>>
>>> On the other hand, if we as a Geode community feel strongly that
>>>
>>> bypassing branch protection via merge commits and rebase commits is
>>> important to allow, why not also allow arbitrary overrides (or get rid of
>>> branch protection entirely)?
>>>
>>>
>>> -Owen
>>>
>>> On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io> wrote:
>>>
>>> Just FWIW, the situation described of having multiple commits in a
>>>
>>> single
>>>
>>> PR with separate associated JIRA tickets is still kind of problematic.
>>>
>>> It
>>>
>>> could well be the case that the commits are interdependent, thus when
>>> bisecting etc it's still not possible to revert the fix for a single
>>> bug/feature/whatever atomically. It's all good, though, I'm satisfied
>>>
>>> no
>>>
>>> one's forcing me to adopt practice I'm opposed to. Apologies for
>>>
>>> getting
>>>
>>> my feathers a little ruffled, or if I ruffled anyone else's in return.
>>>
>>> Thanks,
>>>
>>> Blake
>>>
>>>
>>> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>>
>>> Hi Dan,
>>>
>>> When we do squash merge all the commit messages are preserved and also
>>>
>>> the
>>>
>>> co-authored tag works when we do squash merge.
>>> So the authorship and history are preserved.
>>>
>>> In my own personal experience and reverts and pinpointing regression
>>> failures are tough when the commits are spread out. Also, reverts are
>>> easier when it is just one commit while we are bisecting failures.
>>>
>>>
>>> Regards
>>> Naba
>>>
>>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io> wrote:
>>>
>>> I'll change to -0.
>>>
>>> I think merge commits are a nice way to record history in some cases,
>>>
>>> and
>>>
>>> can also be a way to avoid messy conflicts that come with rebase.
>>>
>>> Merge
>>>
>>> commits also preserve authorship of commits (compared to
>>>
>>> squash-merge),
>>>
>>> which I think is valuable as an open source community that is trying
>>>
>>> to
>>>
>>> keep track of outside contributions.
>>>
>>> That said, if the rest of y'all feel it will help to disable the
>>>
>>> button,
>>>
>>> I
>>>
>>> won't stand in the way.
>>>
>>> -Dan
>>>
>>> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
>>>
>>> wrote:
>>>
>>>
>>> Whether we are talking about the geode/ repository or the
>>>
>>> geode-native/
>>>
>>> repository we are all one GEODE community.
>>>
>>> The idea of a native client team may matter in some contexts but in
>>>
>>> this
>>>
>>> space we are all GEODE contributors.
>>>
>>> Adopting a common approach across our repos will make it easier for
>>>
>>> new
>>>
>>> contributors to engage, learn our norms, and join our efforts.
>>>
>>> $0.02,
>>> Anthony
>>>
>>>
>>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
>>>
>>> wrote:
>>>
>>>
>>> Is this a policy the native client team must abide by, as well? It
>>>
>>> varies
>>>
>>> slightly with what we've been doing, and all other things being
>>>
>>> equal I
>>>
>>> see
>>>
>>> no reason for us to change that. If I am to have any measure of
>>>
>>> control
>>>
>>> over the nc repository, I will definitely enforce a 1:1
>>>
>>> correspondence
>>>
>>> between commits to develop and JIRA tickets. IMO, if your
>>>
>>> refactoring
>>>
>>> in a
>>>
>>> PR is sufficiently large or complex that it's difficult to tease it
>>>
>>> out
>>>
>>> from the bug you're fixing or feature you're implementing, it merits
>>>
>>> its
>>>
>>> own JIRA ticket and a separate PR. If your "actual" fix then
>>>
>>> becomes
>>>
>>> dependent on the refactored code, that's a price I'm willing to pay
>>>
>>> to
>>>
>>> keep
>>>
>>> history clean.
>>>
>>> On the other hand, I see no real value in squashing to a single
>>>
>>> commit
>>>
>>> prior to submitting a PR, since your view of the changes on GitHub
>>>
>>> is
>>>
>>> essentially the same either way. We haven't enforced this on the nc
>>>
>>> repo,
>>>
>>> and I'd prefer to keep it that way.
>>>
>>> Thanks,
>>>
>>> Blake
>>>
>>>
>>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
>>>
>>> wrote:
>>>
>>>
>>> Merge commit is the new contributor's default setting. When we are
>>>
>>> merging
>>>
>>> new contributor's PR, since we are so used to THINKING
>>>
>>> "squash-and-merge"
>>>
>>> is the default, we forgot to check what the button really says when
>>>
>>> we
>>>
>>> are
>>>
>>> merging other people's PR.
>>>
>>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
>>>
>>> eburghardt@pivotal.io>
>>>
>>> wrote:
>>>
>>> I'm a proponent of using squash-and-merge, and once a person has
>>>
>>> chosen
>>>
>>> this option once it comes up by default afterwards...
>>>
>>> Owen, I don't think you have consensus to put forth this PR,
>>>
>>> there
>>>
>>> are
>>>
>>> -1s
>>>
>>> above... (early voting)
>>>
>>> maybe we'll be better off socializing the norm of squash-and-merge
>>>
>>> and
>>>
>>> gaining a natural consensus that way...
>>>
>>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
>>>
>>> onichols@pivotal.io
>>>
>>>
>>> wrote:
>>>
>>>
>>> The proposed action manifests as a commit to the Geode git
>>>
>>> repository,
>>>
>>> so
>>>
>>> a PR is an acceptable vehicle for voting in this case.
>>>
>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
>>>
>>> bschuchardt@pivotal.io>
>>>
>>> wrote:
>>>
>>>
>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
>>>
>>> thread
>>>
>>> and a request to "vote" using a PR. This all seems out of order
>>>
>>> to
>>>
>>> me.
>>>
>>> Our votes are supposed to be on the email list, aren't they? and
>>>
>>> I
>>>
>>> haven't
>>>
>>> seen a VOTE request.
>>>
>>>
>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
>>>
>>> +1
>>>
>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
>>>
>>> onichols@pivotal.io
>>>
>>>
>>> wrote:
>>>
>>>
>>> Based on the feedback so far, I will amend the proposal to
>>>
>>> drop
>>>
>>> item
>>>
>>> 2).
>>>
>>> Therefore, the current ability to create merge commits using
>>>
>>> command-line
>>>
>>> git will remain available.
>>>
>>> The proposal as amended is now:
>>>
>>> Change GitHub settings to make "Squash and merge" the default
>>> (by removing “Create a merge commit” option).
>>>
>>> Update the PR template to change the text "Is your initial
>>>
>>> contribution
>>>
>>> a single, squashed commit” to “Is your initial contribution
>>>
>>> squashed
>>>
>>> for
>>>
>>> ease of review (e.g. a single commit, or a ‘refactoring’
>>>
>>> commit
>>>
>>> plus a
>>>
>>> ‘fix’ commit)"
>>>
>>>
>>> As Naba suggested, we can try it, and if we don’t like it,
>>>
>>> it’s
>>>
>>> simple
>>>
>>> to
>>>
>>> revert.
>>>
>>> I’ve create a PR for the proposed change here:
>>> https://github.com/apache/geode/pull/4513
>>>
>>> Please use the PR to vote for against this proposal. It will
>>>
>>> not
>>>
>>> be
>>>
>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
>>>
>>> that
>>>
>>> time)
>>>
>>>
>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
>>>
>>> wrote:
>>>
>>>
>>> +1
>>>
>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
>>>
>>> onichols@pivotal.io>
>>>
>>> wrote:
>>>
>>>
>>> Hi Bruce, this proposal will not waste a single second of
>>>
>>> your
>>>
>>> time. It
>>>
>>> just prevents people from accidentally pressing a button
>>>
>>> that
>>>
>>> we
>>>
>>> have
>>>
>>> already agreed should never be pressed, but because we never
>>>
>>> configured
>>>
>>> our
>>>
>>> GitHub to match our stated policy, is currently the default.
>>>
>>> However, it will save a lot of time and frustration for
>>>
>>> anyone
>>>
>>> needing
>>>
>>> to
>>>
>>> bisect failures, revert, or cherry-pick changes, which has
>>>
>>> merit
>>>
>>> even if
>>>
>>> you personally never do any of those three things.
>>>
>>> Please start a separate thread if you would like to revisit
>>>
>>> the
>>>
>>> community
>>>
>>> decision to require passing PR checks.
>>>
>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
>>>
>>> bschuchardt@pivotal.io>
>>>
>>> wrote:
>>>
>>> I agree with Jake. I would go further by saying that I see
>>>
>>> very
>>>
>>> little
>>>
>>> merit in this proposal. I think we're getting more and more
>>>
>>> bureaucratic
>>>
>>> in our process and that it stifles productivity. I was
>>>
>>> recently
>>>
>>> forced
>>>
>>> to
>>>
>>> spend three days fixing tests in which I had changed an
>>>
>>> import
>>>
>>> statement
>>>
>>> before they would pass stress testing. I'm glad the tests
>>>
>>> now
>>>
>>> pass
>>>
>>> reliably but I was very frustrated by the process.
>>>
>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>
>>> I’m in agreement with Dan. Changes to the infrastructure
>>>
>>> to
>>>
>>> flat
>>>
>>> out
>>>
>>> prevent things that should be self policing is annoying.
>>>
>>> This
>>>
>>> PR
>>>
>>> review
>>>
>>> lock we have had already cost us valuable time waiting for
>>>
>>> PR
>>>
>>> pipelines
>>>
>>> to
>>>
>>> pass that have no relevance to the commit, like CI work: I’d
>>>
>>> hat
>>>
>>> to
>>>
>>> see
>>>
>>> yet
>>>
>>> another process enforced that Kees us from getting work done
>>>
>>> when
>>>
>>> necessary.
>>>
>>> -Jake
>>>
>>>
>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <
>>>
>>> dsmith@pivotal.io
>>>
>>>
>>> wrote:
>>>
>>>
>>> -1 to (1) and (2).
>>>
>>> I think merge commits are appropriate in certain
>>>
>>> circumstances,
>>>
>>> so I
>>>
>>> don't
>>>
>>> think we should make a blanket restriction. In fact I
>>>
>>> think
>>>
>>> our
>>>
>>> release
>>>
>>> process involves some merges.
>>>
>>> I think setting standards on what is reasonable to be an
>>>
>>> individual
>>>
>>> commit
>>>
>>> will do a lot more to clean up our history than blocking
>>>
>>> merges.
>>>
>>> We'd
>>>
>>> rather not see commits like "Spotless Apply" in the
>>>
>>> history,
>>>
>>> but
>>>
>>> if
>>>
>>> reasonably separate and well written commits come in as
>>>
>>> part
>>>
>>> of
>>>
>>> a
>>>
>>> merge, I
>>>
>>> think that's fine.
>>>
>>> -Dan
>>>
>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
>>>
>>> jiliao@pivotal.io
>>>
>>>
>>> wrote:
>>>
>>> +1
>>>
>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
>>>
>>> onichols@pivotal.io
>>>
>>>
>>> wrote:
>>>
>>> I’d like to advance this topic from an informal
>>>
>>> request/discussion
>>>
>>> to a
>>>
>>> discussion of a concrete proposal.
>>>
>>> To recap, it sounds like there is general agreement
>>>
>>> that
>>>
>>> commit
>>>
>>> history
>>>
>>> on
>>>
>>> develop should be linear (no merge commits), and that
>>>
>>> the
>>>
>>> biggest
>>>
>>> obstacle
>>>
>>> to this is that the PR merge button in GitHub creates a
>>>
>>> merge
>>>
>>> commit
>>>
>>> by
>>>
>>> default.
>>>
>>> I propose the following changes:
>>> 1) Change GitHub settings to remove the ability to
>>>
>>> create
>>>
>>> a
>>>
>>> merge
>>>
>>> commit.
>>>
>>> This will make Squash & Merge the default.
>>>
>>> 2) Change GitHub settings to require linear history on
>>>
>>> develop.
>>>
>>> This
>>>
>>> prevents merge commits via command-line (not
>>>
>>> recommended,
>>>
>>> but
>>>
>>> wiki
>>>
>>> still
>>>
>>> has instructions for merging PRs this way).
>>>
>>> 3) Update the PR template to change the text "Is your
>>>
>>> initial
>>>
>>> contribution
>>>
>>> a single, squashed commit” to “Is your initial
>>>
>>> contribution
>>>
>>> squashed
>>>
>>> for
>>>
>>> ease of review (e.g. a single commit, or a
>>>
>>> ‘refactoring’
>>>
>>> commit
>>>
>>> plus
>>>
>>> a
>>>
>>> ‘fix’ commit)"
>>>
>>> For clarity, I am proposing no-change in the following
>>>
>>> areas:
>>>
>>> i) Leave Rebase & Merge as an option for PRs that have
>>>
>>> been
>>>
>>> structured to
>>>
>>> benefit from it (this can make it easier in a bisect to
>>>
>>> see
>>>
>>> whether
>>>
>>> the
>>>
>>> refactoring or the “fix” broke something).
>>> ii) Leave existing wording in the wiki as-is [stating
>>>
>>> that
>>>
>>> squashing
>>>
>>> is
>>>
>>> preferred].
>>>
>>>
>>> Please comment via this email thread.
>>> -Owen
>>>
>>>
>>>
>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
>>>
>>> klund@apache.org>
>>>
>>> wrote:
>>>
>>>
>>> I think it's already resolved Udo ;)
>>>
>>> Here's the problem, if I fixup a dunit test by
>>>
>>> removing
>>>
>>> all
>>>
>>> uses
>>>
>>> of
>>>
>>> "this."
>>>
>>> and I rename the dunit test, then git doesn't remember
>>>
>>> that
>>>
>>> the
>>>
>>> file
>>>
>>> is a
>>>
>>> rename -- it forever afterwards interprets it as a new
>>>
>>> file
>>>
>>> that I
>>>
>>> created
>>>
>>> if I touch more than 50% of the lines (which "this."
>>>
>>> can
>>>
>>> easily
>>>
>>> do). If
>>>
>>> we
>>>
>>> squash two commits: the rename and the cleanup of that
>>>
>>> dunit
>>>
>>> test
>>>
>>> --
>>>
>>> then
>>>
>>> we effectively lose the history of that file and it
>>>
>>> shows
>>>
>>> that
>>>
>>> I
>>>
>>> created
>>>
>>> a
>>>
>>> new file.
>>>
>>> Also for the record, I've been working on Geode since
>>>
>>> the
>>>
>>> beginning
>>>
>>> and I
>>>
>>> was never made aware of this change in our process. I
>>>
>>> never
>>>
>>> voted
>>>
>>> on
>>>
>>> it.
>>>
>>> I'm not a big fan of changing various details in our
>>>
>>> process
>>>
>>> every
>>>
>>> single
>>>
>>> week. It's very easy to miss these discussions unless
>>>
>>> someone
>>>
>>> points it
>>>
>>> out
>>>
>>> to me.
>>>
>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>>>
>>> ukohlmeyer@pivotal.io>
>>>
>>> wrote:
>>>
>>> I'm not sure what this discussion is about... WE, as
>>>
>>> a
>>>
>>> community,
>>>
>>> have
>>>
>>> agreed in common practices, in two place no less...
>>>
>>> 1) Quoting our PR template
>>>
>>>
>>> For all changes:
>>>
>>> *
>>>
>>> Is there a JIRA ticket associated with this PR? Is it
>>>
>>> referenced
>>>
>>> in
>>>
>>> the commit message?
>>>
>>> *
>>>
>>> Has your PR been rebased against the latest commit
>>>
>>> within
>>>
>>> the
>>>
>>> target
>>>
>>> branch (typically|develop|)?
>>>
>>> *
>>>
>>> ***Is your initial contribution a single, squashed
>>>
>>> commit?*
>>>
>>>
>>> *
>>>
>>> Does|gradlew build|run cleanly?
>>>
>>> *
>>>
>>> Have you written or updated unit tests to verify your
>>>
>>> changes?
>>>
>>>
>>> *
>>>
>>> If adding new dependencies to the code, are these
>>>
>>> dependencies
>>>
>>> licensed in a way that is compatible for inclusion
>>>
>>> underASF
>>>
>>> 2.0
>>>
>>> <
>>>
>>> http://www.apache.org/legal/resolved.html#category-a
>>>
>>> ?
>>>
>>>
>>> On our PR template we call out that the initial PR
>>>
>>> commit
>>>
>>> should
>>>
>>> be
>>>
>>> squashed.
>>>
>>> 2)
>>>
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>
>>> <
>>>
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>
>>> -- See "Accepting a PR Using the Command Line" -
>>>
>>> Point
>>>
>>> #3.
>>>
>>>
>>>
>>> @Kirk, if each of your commits "stands alone", I
>>>
>>> commend
>>>
>>> you
>>>
>>> on
>>>
>>> the
>>>
>>> diligence, but in reality, they should either then be
>>>
>>> stand
>>>
>>> alone
>>>
>>> PR's
>>>
>>> or just extra work created for yourself.
>>>
>>> If we want to change the way we have agreed upon we
>>>
>>> submit/commit/merge
>>>
>>> changes back into develop... Then this is another
>>>
>>> discussion
>>>
>>> thread,
>>>
>>> until then, I think we should all remind ourselves on
>>>
>>> our
>>>
>>> agreed
>>>
>>> contributions code of conduct.
>>>
>>> --Udo
>>>
>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>
>>> Kirk, I believe that creating a Pull Request with
>>>
>>> multiple
>>>
>>> commits is
>>>
>>> ok.
>>>
>>> It's just in the end that when it's being pushed to
>>>
>>> develop
>>>
>>> branch,
>>>
>>> it
>>>
>>> needs to be squash merged. I believe that is what
>>>
>>> you
>>>
>>> have
>>>
>>> mentioned
>>>
>>> in
>>>
>>> the
>>>
>>> first paragraph, and I am more than happy with that.
>>> If you can see in the first screenshot comparison
>>>
>>> that
>>>
>>> I
>>>
>>> had
>>>
>>> attached
>>>
>>> in
>>>
>>> the first email in this thread is what I want to
>>>
>>> avoid.
>>>
>>>
>>> Thank you for your feedback.
>>>
>>> Regards
>>> Naba
>>>
>>>
>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
>>>
>>> klund@apache.org>
>>>
>>> wrote:
>>>
>>> Whenever I submit a PR with multiple commits that I
>>>
>>> intend
>>>
>>> to
>>>
>>> rebase
>>>
>>> to
>>>
>>> develop, I always try to ensure that each commit
>>>
>>> stands
>>>
>>> alone
>>>
>>> as
>>>
>>> is
>>>
>>> (compiles and passes tests). Separating file
>>>
>>> renames
>>>
>>> and
>>>
>>> refactoring
>>>
>>> from
>>>
>>> behavior changes into different commits seems very
>>>
>>> valuable
>>>
>>> to
>>>
>>> me,
>>>
>>> and
>>>
>>> I've
>>>
>>> had trouble getting people to review PRs without
>>>
>>> this
>>>
>>> separation
>>>
>>> (but
>>>
>>> it
>>>
>>> could be squashed as it's merged to develop).
>>>
>>> It sounds to me like the real problem is (a) some
>>>
>>> PRs
>>>
>>> have
>>>
>>> multiple
>>>
>>> commits
>>>
>>> that don't compile or don't pass tests, and (b)
>>>
>>> some
>>>
>>> PRs
>>>
>>> that
>>>
>>> should
>>>
>>> be
>>>
>>> merged with squash are not (by accident most
>>>
>>> likely).
>>>
>>>
>>> I can submit multiple PRs instead of one PR with
>>>
>>> multiple
>>>
>>> commits.
>>>
>>> So
>>>
>>> I'll
>>>
>>> change my response to -0 if that helps prevent
>>>
>>> commits
>>>
>>> to
>>>
>>> develop
>>>
>>> that
>>>
>>> don't compile or pass tests. Without preventing
>>>
>>> rebase
>>>
>>> or
>>>
>>> merge
>>>
>>> commits
>>>
>>> from github, I'm not sure how we can really enforce
>>>
>>> this
>>>
>>> or
>>>
>>> prevent
>>>
>>> (b)
>>>
>>> above.
>>>
>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>
>>> amurmann@pivotal.io>
>>>
>>> wrote:
>>>
>>> I wonder if Kirk's and Naba's statements are
>>>
>>> necessarily
>>>
>>> at
>>>
>>> odds.
>>>
>>> Make the change easy (warning: this may be hard),
>>>
>>> then
>>>
>>> make
>>>
>>> the
>>>
>>> easy
>>>
>>> change."
>>>
>>> -Kent Beck
>>>
>>> Following Kent Beck's advise might reasonably
>>>
>>> split
>>>
>>> into
>>>
>>> two
>>>
>>> commits.
>>>
>>> One
>>>
>>> refactor commit and a separate commit that
>>>
>>> introduces
>>>
>>> the
>>>
>>> actual
>>>
>>> change.
>>>
>>> They should be individually revertible and might
>>>
>>> be
>>>
>>> easier
>>>
>>> understood
>>>
>>> if
>>>
>>> split out. I vividly remember a change on our code
>>>
>>> base
>>>
>>> where
>>>
>>> someone
>>>
>>> did a
>>>
>>> huge amount of refactoring that resulted than in
>>>
>>> one
>>>
>>> parameter
>>>
>>> changing
>>>
>>> in
>>>
>>> order to get the desired functionality change. If
>>>
>>> that
>>>
>>> was
>>>
>>> in
>>>
>>> one
>>>
>>> commit,
>>>
>>> it would be hard to see the actual change. If
>>>
>>> split
>>>
>>> out,
>>>
>>> it's
>>>
>>> beautiful
>>>
>>> and
>>>
>>> crystal clear.
>>>
>>> I am unsure how that would be reflected in terms
>>>
>>> of
>>>
>>> JIRA
>>>
>>> ticket
>>>
>>> references.
>>>
>>> Usually we assume that if there is a commit with
>>>
>>> the
>>>
>>> ticket
>>>
>>> number,
>>>
>>> the
>>>
>>> issue is resolved. Maybe the key here is to create
>>>
>>> a
>>>
>>> separate
>>>
>>> refactoring
>>>
>>> ticket.
>>>
>>> Would that allow us to have our cake and eat it
>>>
>>> too?
>>>
>>>
>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
>>>
>>> nnag@pivotal.io>
>>>
>>> wrote:
>>>
>>> It is to help with bisect operations when things
>>>
>>> start
>>>
>>> failing
>>>
>>> ...
>>>
>>> helps
>>>
>>> us
>>>
>>> it revert and build faster.
>>> also with cherry picking features / fixes to
>>>
>>> previous
>>>
>>> versions
>>>
>>> .
>>>
>>> And keeping the git history clean with no
>>>
>>> unnecessary
>>>
>>> “merge
>>>
>>> commits”.
>>>
>>> Regards
>>> Naba
>>>
>>>
>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
>>>
>>> klund@apache.org>
>>>
>>> wrote:
>>>
>>> -1 I really like to sometimes have more than 1
>>>
>>> commit
>>>
>>> in
>>>
>>> a
>>>
>>> PR
>>>
>>> and
>>>
>>> keep
>>>
>>> them
>>>
>>> separate when they merge to develop
>>>
>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>>>
>>> nnag@pivotal.io>
>>>
>>> wrote:
>>>
>>> Hi Geode Committers,
>>>
>>> A kind request for using squash commit instead
>>>
>>> of
>>>
>>> using
>>>
>>> merge.
>>>
>>> This will really help us in our bisect
>>>
>>> operations
>>>
>>> when a
>>>
>>> regression/flakiness in the product is
>>>
>>> introduced.
>>>
>>> We
>>>
>>> can
>>>
>>> automate
>>>
>>> and
>>>
>>> go
>>>
>>> through fewer commits faster, avoiding commits
>>>
>>> like
>>>
>>> "spotless
>>>
>>> fix"
>>>
>>> and
>>>
>>> "re-trigger precheck-in" or other minor commits
>>>
>>> in
>>>
>>> the
>>>
>>> merged
>>>
>>> branch.
>>>
>>> Also, please use the commit format : (helps us
>>>
>>> to
>>>
>>> know
>>>
>>> who
>>>
>>> worked
>>>
>>> on
>>>
>>> it,
>>>
>>> what is the history)
>>>
>>>
>>>
>>> * GEODE-xxxx: <brief intro >
>>> * explanation line 1
>>>
>>> *
>>>
>>> explanation
>>>
>>> line
>>>
>>> 2*
>>>
>>> This is not a rule or anything, but a request
>>>
>>> to
>>>
>>> help
>>>
>>> out
>>>
>>> your
>>>
>>> fellow
>>>
>>> committers in quickly detecting a problem.
>>>
>>> For inspiration, we can look into Apache Kafka
>>>
>>> /
>>>
>>> Spark
>>>
>>> where
>>>
>>> they
>>>
>>> have
>>>
>>> a
>>>
>>> complete linear graph for their main branch
>>>
>>> HEAD
>>>
>>> [see
>>>
>>> attachment]
>>>
>>> Regards
>>> Naba.
>>>
>>>
>>>
>>> --
>>>
>>> Ju@N
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Cheers
>>>
>>> Jinmei
>>
>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
Can you elaborate on why you would have to deal with conflicts if the
refactoring work was kept as a separate PR from the fix?
As with many git workflows, there’s an easy way and a hard way to manage
interdependent PRs (tl;dr only merge, never rebase!). I wonder if this
points out an opportunity for a “tips and tricks” page on the Geode wiki.
On Tue, Dec 31, 2019 at 5:22 PM Aaron Lindsey <aa...@apache.org>
wrote:
> -0.9
>
> I’m not in favor of the revised proposal that disallows rebase-and-merge.
> Say I am working on a PR and I have a refactor commit and another commit
> which implements a new feature. I don’t want those commits to get squashed
> because that makes it hard to understand the diff. However, if I make those
> commits as two separate PRs then I am going to have to deal with conflicts.
>
> I’m not sure when we made it a rule that every commit in develop had to
> compile and pass tests. I know we implemented a rule that all PRs had to
> pass certain checks, but I never thought that rule implied all commits had
> to pass those checks.
>
> In general I just don’t see the problem with rebase-and-merge and this
> feels like an unnecessary restriction, but I will go with it if that’s what
> everyone wants to do.
>
> Aaron
>
> > On Dec 31, 2019, at 3:09 PM, Owen Nichols <on...@pivotal.io> wrote:
> >
> > To recap, this proposal is now revised to remove 2 of the 3 merge options
> > from GitHub, leaving only Squash and Merge. PR #4513
> > <https://github.com/apache/geode/pull/4513> serves as an exhibit of
> what is
> > proposed (it is not to be merged unless discussion leads to consensus
> and a
> > successful vote). Please use the dev list (not the PR) for all
> discussion
> > (and voting, if we get that far).
> >
> > Squash and merge is already used almost exclusively by the Geode
> community,
> > with any exceptions tending to be accidental more often than intentional.
> > However, some have raised the concern that implementing this restriction
> > could result in harm or wasted time. Can someone give an example of a
> such
> > a scenario?
> >
> > It seems there is a divide here between junior and senior community
> > members. Newer committers appreciate additional guardrails to protect
> them
> > from accidentally doing the wrong thing, while those with more experience
> > want to be able to work unencumbered by restrictions of any kind.
> >
> > Our welcome email to new committers states “We like to work on trust
> rather
> > than unnecessary constraints...Being a committer enables you to more
> easily
> > make changes without needing to go through the patch submission process”.
> > I can see this as an argument against this proposal (perhaps even an
> > argument against any form of branch protection).
> >
> > In the scheme of things, this proposal makes very little difference.
> There
> > are still other ways to get non-compiling commits onto develop (e.g.
> > waiting a long time between running PR checks and merging to develop).
> > What’s more important is working well together as a community. So,
> perhaps
> > what’s best for the community is to encourage working on trust rather
> than
> > unnecessary constraints.
> >
> > -Owen
> >
> > On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org> wrote:
> >
> > I'm happy to file multiple PRs when I need to merge multiple commits to
> > develop.
> >
> > On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <mh...@pivotal.io> wrote:
> >
> > This change to disable all but squash-merge would be really easy to
> > revert. How about we try it for a while and see? If people decide it is
> > really limiting them, we can change it back. Let’s do it for 1 month and
> > see how it goes. Does that sound reasonable?
> >
> > Thanks,
> > Mark
> >
> > On Dec 30, 2019, at 5:25 PM, Owen Nichols <on...@pivotal.io> wrote:
> >
> > Given that we adopted <
> >
> >
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
> >>
> > and still wish to continue <
> >
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
> >>
> > having branch protection rules to ensure every commit landing in develop
> > has passed the required PR checks, it seems like that decision alone
> > mandates that we disable all merge mechanisms other than
> squash-and-merge.
> >
> >
> > Allowing merge commits or rebase merges bypasses branch protection for
> >
> > all commits other than the final one in the merge or rebase set. Given
> > that we decided <
> >
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
> >>
> > that bypassing PR checks should never be allowed, keeping this loophole
> > open seems untenable.
> >
> >
> > This is not just hypothetical — this loophole is causing real problems.
> >
> > We now have commits on develop that don’t compile. For example:
> >
> > git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> > ./gradlew devBuild
> > ...spotlessJava FAILED
> > We implemented branch protections to make this impossible, right?
> >
> > We can very easily close this loophole by disabling all but the
> >
> > Squash&Merge button for PRs. This will not make more work for any
> > developer. If you want to get multiple commits onto develop, simply
> submit
> > each as a separate PR — that is the only way to assure that required PR
> > checks have passed for each.
> >
> >
> > On the other hand, if we as a Geode community feel strongly that
> >
> > bypassing branch protection via merge commits and rebase commits is
> > important to allow, why not also allow arbitrary overrides (or get rid of
> > branch protection entirely)?
> >
> >
> > -Owen
> >
> > On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io> wrote:
> >
> > Just FWIW, the situation described of having multiple commits in a
> >
> > single
> >
> > PR with separate associated JIRA tickets is still kind of problematic.
> >
> > It
> >
> > could well be the case that the commits are interdependent, thus when
> > bisecting etc it's still not possible to revert the fix for a single
> > bug/feature/whatever atomically. It's all good, though, I'm satisfied
> >
> > no
> >
> > one's forcing me to adopt practice I'm opposed to. Apologies for
> >
> > getting
> >
> > my feathers a little ruffled, or if I ruffled anyone else's in return.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >
> > Hi Dan,
> >
> > When we do squash merge all the commit messages are preserved and also
> >
> > the
> >
> > co-authored tag works when we do squash merge.
> > So the authorship and history are preserved.
> >
> > In my own personal experience and reverts and pinpointing regression
> > failures are tough when the commits are spread out. Also, reverts are
> > easier when it is just one commit while we are bisecting failures.
> >
> >
> > Regards
> > Naba
> >
> > On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io> wrote:
> >
> > I'll change to -0.
> >
> > I think merge commits are a nice way to record history in some cases,
> >
> > and
> >
> > can also be a way to avoid messy conflicts that come with rebase.
> >
> > Merge
> >
> > commits also preserve authorship of commits (compared to
> >
> > squash-merge),
> >
> > which I think is valuable as an open source community that is trying
> >
> > to
> >
> > keep track of outside contributions.
> >
> > That said, if the rest of y'all feel it will help to disable the
> >
> > button,
> >
> > I
> >
> > won't stand in the way.
> >
> > -Dan
> >
> > On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
> >
> > wrote:
> >
> >
> > Whether we are talking about the geode/ repository or the
> >
> > geode-native/
> >
> > repository we are all one GEODE community.
> >
> > The idea of a native client team may matter in some contexts but in
> >
> > this
> >
> > space we are all GEODE contributors.
> >
> > Adopting a common approach across our repos will make it easier for
> >
> > new
> >
> > contributors to engage, learn our norms, and join our efforts.
> >
> > $0.02,
> > Anthony
> >
> >
> > On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
> >
> > wrote:
> >
> >
> > Is this a policy the native client team must abide by, as well? It
> >
> > varies
> >
> > slightly with what we've been doing, and all other things being
> >
> > equal I
> >
> > see
> >
> > no reason for us to change that. If I am to have any measure of
> >
> > control
> >
> > over the nc repository, I will definitely enforce a 1:1
> >
> > correspondence
> >
> > between commits to develop and JIRA tickets. IMO, if your
> >
> > refactoring
> >
> > in a
> >
> > PR is sufficiently large or complex that it's difficult to tease it
> >
> > out
> >
> > from the bug you're fixing or feature you're implementing, it merits
> >
> > its
> >
> > own JIRA ticket and a separate PR. If your "actual" fix then
> >
> > becomes
> >
> > dependent on the refactored code, that's a price I'm willing to pay
> >
> > to
> >
> > keep
> >
> > history clean.
> >
> > On the other hand, I see no real value in squashing to a single
> >
> > commit
> >
> > prior to submitting a PR, since your view of the changes on GitHub
> >
> > is
> >
> > essentially the same either way. We haven't enforced this on the nc
> >
> > repo,
> >
> > and I'd prefer to keep it that way.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
> >
> > wrote:
> >
> >
> > Merge commit is the new contributor's default setting. When we are
> >
> > merging
> >
> > new contributor's PR, since we are so used to THINKING
> >
> > "squash-and-merge"
> >
> > is the default, we forgot to check what the button really says when
> >
> > we
> >
> > are
> >
> > merging other people's PR.
> >
> > On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> >
> > eburghardt@pivotal.io>
> >
> > wrote:
> >
> > I'm a proponent of using squash-and-merge, and once a person has
> >
> > chosen
> >
> > this option once it comes up by default afterwards...
> >
> > Owen, I don't think you have consensus to put forth this PR,
> >
> > there
> >
> > are
> >
> > -1s
> >
> > above... (early voting)
> >
> > maybe we'll be better off socializing the norm of squash-and-merge
> >
> > and
> >
> > gaining a natural consensus that way...
> >
> > On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
> >
> > onichols@pivotal.io
> >
> >
> > wrote:
> >
> >
> > The proposed action manifests as a commit to the Geode git
> >
> > repository,
> >
> > so
> >
> > a PR is an acceptable vehicle for voting in this case.
> >
> > On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> >
> > bschuchardt@pivotal.io>
> >
> > wrote:
> >
> >
> > I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> >
> > thread
> >
> > and a request to "vote" using a PR. This all seems out of order
> >
> > to
> >
> > me.
> >
> > Our votes are supposed to be on the email list, aren't they? and
> >
> > I
> >
> > haven't
> >
> > seen a VOTE request.
> >
> >
> > On 12/20/19 9:33 AM, Nabarun Nag wrote:
> >
> > +1
> >
> > On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
> >
> > onichols@pivotal.io
> >
> >
> > wrote:
> >
> >
> > Based on the feedback so far, I will amend the proposal to
> >
> > drop
> >
> > item
> >
> > 2).
> >
> > Therefore, the current ability to create merge commits using
> >
> > command-line
> >
> > git will remain available.
> >
> > The proposal as amended is now:
> >
> > Change GitHub settings to make "Squash and merge" the default
> > (by removing “Create a merge commit” option).
> >
> > Update the PR template to change the text "Is your initial
> >
> > contribution
> >
> > a single, squashed commit” to “Is your initial contribution
> >
> > squashed
> >
> > for
> >
> > ease of review (e.g. a single commit, or a ‘refactoring’
> >
> > commit
> >
> > plus a
> >
> > ‘fix’ commit)"
> >
> >
> > As Naba suggested, we can try it, and if we don’t like it,
> >
> > it’s
> >
> > simple
> >
> > to
> >
> > revert.
> >
> > I’ve create a PR for the proposed change here:
> > https://github.com/apache/geode/pull/4513
> >
> > Please use the PR to vote for against this proposal. It will
> >
> > not
> >
> > be
> >
> > merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
> >
> > that
> >
> > time)
> >
> >
> > On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
> >
> > wrote:
> >
> >
> > +1
> >
> > On Fri 20 Dec 2019 at 16:18, Owen Nichols <
> >
> > onichols@pivotal.io>
> >
> > wrote:
> >
> >
> > Hi Bruce, this proposal will not waste a single second of
> >
> > your
> >
> > time. It
> >
> > just prevents people from accidentally pressing a button
> >
> > that
> >
> > we
> >
> > have
> >
> > already agreed should never be pressed, but because we never
> >
> > configured
> >
> > our
> >
> > GitHub to match our stated policy, is currently the default.
> >
> > However, it will save a lot of time and frustration for
> >
> > anyone
> >
> > needing
> >
> > to
> >
> > bisect failures, revert, or cherry-pick changes, which has
> >
> > merit
> >
> > even if
> >
> > you personally never do any of those three things.
> >
> > Please start a separate thread if you would like to revisit
> >
> > the
> >
> > community
> >
> > decision to require passing PR checks.
> >
> > On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> >
> > bschuchardt@pivotal.io>
> >
> > wrote:
> >
> > I agree with Jake. I would go further by saying that I see
> >
> > very
> >
> > little
> >
> > merit in this proposal. I think we're getting more and more
> >
> > bureaucratic
> >
> > in our process and that it stifles productivity. I was
> >
> > recently
> >
> > forced
> >
> > to
> >
> > spend three days fixing tests in which I had changed an
> >
> > import
> >
> > statement
> >
> > before they would pass stress testing. I'm glad the tests
> >
> > now
> >
> > pass
> >
> > reliably but I was very frustrated by the process.
> >
> > On 12/19/19 4:49 PM, Jacob Barrett wrote:
> >
> > I’m in agreement with Dan. Changes to the infrastructure
> >
> > to
> >
> > flat
> >
> > out
> >
> > prevent things that should be self policing is annoying.
> >
> > This
> >
> > PR
> >
> > review
> >
> > lock we have had already cost us valuable time waiting for
> >
> > PR
> >
> > pipelines
> >
> > to
> >
> > pass that have no relevance to the commit, like CI work: I’d
> >
> > hat
> >
> > to
> >
> > see
> >
> > yet
> >
> > another process enforced that Kees us from getting work done
> >
> > when
> >
> > necessary.
> >
> > -Jake
> >
> >
> > On Dec 19, 2019, at 4:43 PM, Dan Smith <
> >
> > dsmith@pivotal.io
> >
> >
> > wrote:
> >
> >
> > -1 to (1) and (2).
> >
> > I think merge commits are appropriate in certain
> >
> > circumstances,
> >
> > so I
> >
> > don't
> >
> > think we should make a blanket restriction. In fact I
> >
> > think
> >
> > our
> >
> > release
> >
> > process involves some merges.
> >
> > I think setting standards on what is reasonable to be an
> >
> > individual
> >
> > commit
> >
> > will do a lot more to clean up our history than blocking
> >
> > merges.
> >
> > We'd
> >
> > rather not see commits like "Spotless Apply" in the
> >
> > history,
> >
> > but
> >
> > if
> >
> > reasonably separate and well written commits come in as
> >
> > part
> >
> > of
> >
> > a
> >
> > merge, I
> >
> > think that's fine.
> >
> > -Dan
> >
> > On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> >
> > jiliao@pivotal.io
> >
> >
> > wrote:
> >
> > +1
> >
> > On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> >
> > onichols@pivotal.io
> >
> >
> > wrote:
> >
> > I’d like to advance this topic from an informal
> >
> > request/discussion
> >
> > to a
> >
> > discussion of a concrete proposal.
> >
> > To recap, it sounds like there is general agreement
> >
> > that
> >
> > commit
> >
> > history
> >
> > on
> >
> > develop should be linear (no merge commits), and that
> >
> > the
> >
> > biggest
> >
> > obstacle
> >
> > to this is that the PR merge button in GitHub creates a
> >
> > merge
> >
> > commit
> >
> > by
> >
> > default.
> >
> > I propose the following changes:
> > 1) Change GitHub settings to remove the ability to
> >
> > create
> >
> > a
> >
> > merge
> >
> > commit.
> >
> > This will make Squash & Merge the default.
> >
> > 2) Change GitHub settings to require linear history on
> >
> > develop.
> >
> > This
> >
> > prevents merge commits via command-line (not
> >
> > recommended,
> >
> > but
> >
> > wiki
> >
> > still
> >
> > has instructions for merging PRs this way).
> >
> > 3) Update the PR template to change the text "Is your
> >
> > initial
> >
> > contribution
> >
> > a single, squashed commit” to “Is your initial
> >
> > contribution
> >
> > squashed
> >
> > for
> >
> > ease of review (e.g. a single commit, or a
> >
> > ‘refactoring’
> >
> > commit
> >
> > plus
> >
> > a
> >
> > ‘fix’ commit)"
> >
> > For clarity, I am proposing no-change in the following
> >
> > areas:
> >
> > i) Leave Rebase & Merge as an option for PRs that have
> >
> > been
> >
> > structured to
> >
> > benefit from it (this can make it easier in a bisect to
> >
> > see
> >
> > whether
> >
> > the
> >
> > refactoring or the “fix” broke something).
> > ii) Leave existing wording in the wiki as-is [stating
> >
> > that
> >
> > squashing
> >
> > is
> >
> > preferred].
> >
> >
> > Please comment via this email thread.
> > -Owen
> >
> >
> >
> > On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> >
> > klund@apache.org>
> >
> > wrote:
> >
> >
> > I think it's already resolved Udo ;)
> >
> > Here's the problem, if I fixup a dunit test by
> >
> > removing
> >
> > all
> >
> > uses
> >
> > of
> >
> > "this."
> >
> > and I rename the dunit test, then git doesn't remember
> >
> > that
> >
> > the
> >
> > file
> >
> > is a
> >
> > rename -- it forever afterwards interprets it as a new
> >
> > file
> >
> > that I
> >
> > created
> >
> > if I touch more than 50% of the lines (which "this."
> >
> > can
> >
> > easily
> >
> > do). If
> >
> > we
> >
> > squash two commits: the rename and the cleanup of that
> >
> > dunit
> >
> > test
> >
> > --
> >
> > then
> >
> > we effectively lose the history of that file and it
> >
> > shows
> >
> > that
> >
> > I
> >
> > created
> >
> > a
> >
> > new file.
> >
> > Also for the record, I've been working on Geode since
> >
> > the
> >
> > beginning
> >
> > and I
> >
> > was never made aware of this change in our process. I
> >
> > never
> >
> > voted
> >
> > on
> >
> > it.
> >
> > I'm not a big fan of changing various details in our
> >
> > process
> >
> > every
> >
> > single
> >
> > week. It's very easy to miss these discussions unless
> >
> > someone
> >
> > points it
> >
> > out
> >
> > to me.
> >
> > On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> >
> > ukohlmeyer@pivotal.io>
> >
> > wrote:
> >
> > I'm not sure what this discussion is about... WE, as
> >
> > a
> >
> > community,
> >
> > have
> >
> > agreed in common practices, in two place no less...
> >
> > 1) Quoting our PR template
> >
> >
> > For all changes:
> >
> > *
> >
> > Is there a JIRA ticket associated with this PR? Is it
> >
> > referenced
> >
> > in
> >
> > the commit message?
> >
> > *
> >
> > Has your PR been rebased against the latest commit
> >
> > within
> >
> > the
> >
> > target
> >
> > branch (typically|develop|)?
> >
> > *
> >
> > ***Is your initial contribution a single, squashed
> >
> > commit?*
> >
> >
> > *
> >
> > Does|gradlew build|run cleanly?
> >
> > *
> >
> > Have you written or updated unit tests to verify your
> >
> > changes?
> >
> >
> > *
> >
> > If adding new dependencies to the code, are these
> >
> > dependencies
> >
> > licensed in a way that is compatible for inclusion
> >
> > underASF
> >
> > 2.0
> >
> > <
> >
> > http://www.apache.org/legal/resolved.html#category-a
> >
> > ?
> >
> >
> > On our PR template we call out that the initial PR
> >
> > commit
> >
> > should
> >
> > be
> >
> > squashed.
> >
> > 2)
> >
> >
> >
> > https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >
> > <
> >
> >
> >
> > https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >
> > -- See "Accepting a PR Using the Command Line" -
> >
> > Point
> >
> > #3.
> >
> >
> >
> > @Kirk, if each of your commits "stands alone", I
> >
> > commend
> >
> > you
> >
> > on
> >
> > the
> >
> > diligence, but in reality, they should either then be
> >
> > stand
> >
> > alone
> >
> > PR's
> >
> > or just extra work created for yourself.
> >
> > If we want to change the way we have agreed upon we
> >
> > submit/commit/merge
> >
> > changes back into develop... Then this is another
> >
> > discussion
> >
> > thread,
> >
> > until then, I think we should all remind ourselves on
> >
> > our
> >
> > agreed
> >
> > contributions code of conduct.
> >
> > --Udo
> >
> > On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >
> > Kirk, I believe that creating a Pull Request with
> >
> > multiple
> >
> > commits is
> >
> > ok.
> >
> > It's just in the end that when it's being pushed to
> >
> > develop
> >
> > branch,
> >
> > it
> >
> > needs to be squash merged. I believe that is what
> >
> > you
> >
> > have
> >
> > mentioned
> >
> > in
> >
> > the
> >
> > first paragraph, and I am more than happy with that.
> > If you can see in the first screenshot comparison
> >
> > that
> >
> > I
> >
> > had
> >
> > attached
> >
> > in
> >
> > the first email in this thread is what I want to
> >
> > avoid.
> >
> >
> > Thank you for your feedback.
> >
> > Regards
> > Naba
> >
> >
> > On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> >
> > klund@apache.org>
> >
> > wrote:
> >
> > Whenever I submit a PR with multiple commits that I
> >
> > intend
> >
> > to
> >
> > rebase
> >
> > to
> >
> > develop, I always try to ensure that each commit
> >
> > stands
> >
> > alone
> >
> > as
> >
> > is
> >
> > (compiles and passes tests). Separating file
> >
> > renames
> >
> > and
> >
> > refactoring
> >
> > from
> >
> > behavior changes into different commits seems very
> >
> > valuable
> >
> > to
> >
> > me,
> >
> > and
> >
> > I've
> >
> > had trouble getting people to review PRs without
> >
> > this
> >
> > separation
> >
> > (but
> >
> > it
> >
> > could be squashed as it's merged to develop).
> >
> > It sounds to me like the real problem is (a) some
> >
> > PRs
> >
> > have
> >
> > multiple
> >
> > commits
> >
> > that don't compile or don't pass tests, and (b)
> >
> > some
> >
> > PRs
> >
> > that
> >
> > should
> >
> > be
> >
> > merged with squash are not (by accident most
> >
> > likely).
> >
> >
> > I can submit multiple PRs instead of one PR with
> >
> > multiple
> >
> > commits.
> >
> > So
> >
> > I'll
> >
> > change my response to -0 if that helps prevent
> >
> > commits
> >
> > to
> >
> > develop
> >
> > that
> >
> > don't compile or pass tests. Without preventing
> >
> > rebase
> >
> > or
> >
> > merge
> >
> > commits
> >
> > from github, I'm not sure how we can really enforce
> >
> > this
> >
> > or
> >
> > prevent
> >
> > (b)
> >
> > above.
> >
> > On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >
> > amurmann@pivotal.io>
> >
> > wrote:
> >
> > I wonder if Kirk's and Naba's statements are
> >
> > necessarily
> >
> > at
> >
> > odds.
> >
> > Make the change easy (warning: this may be hard),
> >
> > then
> >
> > make
> >
> > the
> >
> > easy
> >
> > change."
> >
> > -Kent Beck
> >
> > Following Kent Beck's advise might reasonably
> >
> > split
> >
> > into
> >
> > two
> >
> > commits.
> >
> > One
> >
> > refactor commit and a separate commit that
> >
> > introduces
> >
> > the
> >
> > actual
> >
> > change.
> >
> > They should be individually revertible and might
> >
> > be
> >
> > easier
> >
> > understood
> >
> > if
> >
> > split out. I vividly remember a change on our code
> >
> > base
> >
> > where
> >
> > someone
> >
> > did a
> >
> > huge amount of refactoring that resulted than in
> >
> > one
> >
> > parameter
> >
> > changing
> >
> > in
> >
> > order to get the desired functionality change. If
> >
> > that
> >
> > was
> >
> > in
> >
> > one
> >
> > commit,
> >
> > it would be hard to see the actual change. If
> >
> > split
> >
> > out,
> >
> > it's
> >
> > beautiful
> >
> > and
> >
> > crystal clear.
> >
> > I am unsure how that would be reflected in terms
> >
> > of
> >
> > JIRA
> >
> > ticket
> >
> > references.
> >
> > Usually we assume that if there is a commit with
> >
> > the
> >
> > ticket
> >
> > number,
> >
> > the
> >
> > issue is resolved. Maybe the key here is to create
> >
> > a
> >
> > separate
> >
> > refactoring
> >
> > ticket.
> >
> > Would that allow us to have our cake and eat it
> >
> > too?
> >
> >
> > On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> >
> > nnag@pivotal.io>
> >
> > wrote:
> >
> > It is to help with bisect operations when things
> >
> > start
> >
> > failing
> >
> > ...
> >
> > helps
> >
> > us
> >
> > it revert and build faster.
> > also with cherry picking features / fixes to
> >
> > previous
> >
> > versions
> >
> > .
> >
> > And keeping the git history clean with no
> >
> > unnecessary
> >
> > “merge
> >
> > commits”.
> >
> > Regards
> > Naba
> >
> >
> > On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> >
> > klund@apache.org>
> >
> > wrote:
> >
> > -1 I really like to sometimes have more than 1
> >
> > commit
> >
> > in
> >
> > a
> >
> > PR
> >
> > and
> >
> > keep
> >
> > them
> >
> > separate when they merge to develop
> >
> > On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> >
> > nnag@pivotal.io>
> >
> > wrote:
> >
> > Hi Geode Committers,
> >
> > A kind request for using squash commit instead
> >
> > of
> >
> > using
> >
> > merge.
> >
> > This will really help us in our bisect
> >
> > operations
> >
> > when a
> >
> > regression/flakiness in the product is
> >
> > introduced.
> >
> > We
> >
> > can
> >
> > automate
> >
> > and
> >
> > go
> >
> > through fewer commits faster, avoiding commits
> >
> > like
> >
> > "spotless
> >
> > fix"
> >
> > and
> >
> > "re-trigger precheck-in" or other minor commits
> >
> > in
> >
> > the
> >
> > merged
> >
> > branch.
> >
> > Also, please use the commit format : (helps us
> >
> > to
> >
> > know
> >
> > who
> >
> > worked
> >
> > on
> >
> > it,
> >
> > what is the history)
> >
> >
> >
> > * GEODE-xxxx: <brief intro >
> > * explanation line 1
> >
> > *
> >
> > explanation
> >
> > line
> >
> > 2*
> >
> > This is not a rule or anything, but a request
> >
> > to
> >
> > help
> >
> > out
> >
> > your
> >
> > fellow
> >
> > committers in quickly detecting a problem.
> >
> > For inspiration, we can look into Apache Kafka
> >
> > /
> >
> > Spark
> >
> > where
> >
> > they
> >
> > have
> >
> > a
> >
> > complete linear graph for their main branch
> >
> > HEAD
> >
> > [see
> >
> > attachment]
> >
> > Regards
> > Naba.
> >
> >
> >
> > --
> >
> > Ju@N
> >
> >
> >
> >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Aaron Lindsey <aa...@apache.org>.
-0.9
I’m not in favor of the revised proposal that disallows rebase-and-merge. Say I am working on a PR and I have a refactor commit and another commit which implements a new feature. I don’t want those commits to get squashed because that makes it hard to understand the diff. However, if I make those commits as two separate PRs then I am going to have to deal with conflicts.
I’m not sure when we made it a rule that every commit in develop had to compile and pass tests. I know we implemented a rule that all PRs had to pass certain checks, but I never thought that rule implied all commits had to pass those checks.
In general I just don’t see the problem with rebase-and-merge and this feels like an unnecessary restriction, but I will go with it if that’s what everyone wants to do.
Aaron
> On Dec 31, 2019, at 3:09 PM, Owen Nichols <on...@pivotal.io> wrote:
>
> To recap, this proposal is now revised to remove 2 of the 3 merge options
> from GitHub, leaving only Squash and Merge. PR #4513
> <https://github.com/apache/geode/pull/4513> serves as an exhibit of what is
> proposed (it is not to be merged unless discussion leads to consensus and a
> successful vote). Please use the dev list (not the PR) for all discussion
> (and voting, if we get that far).
>
> Squash and merge is already used almost exclusively by the Geode community,
> with any exceptions tending to be accidental more often than intentional.
> However, some have raised the concern that implementing this restriction
> could result in harm or wasted time. Can someone give an example of a such
> a scenario?
>
> It seems there is a divide here between junior and senior community
> members. Newer committers appreciate additional guardrails to protect them
> from accidentally doing the wrong thing, while those with more experience
> want to be able to work unencumbered by restrictions of any kind.
>
> Our welcome email to new committers states “We like to work on trust rather
> than unnecessary constraints...Being a committer enables you to more easily
> make changes without needing to go through the patch submission process”.
> I can see this as an argument against this proposal (perhaps even an
> argument against any form of branch protection).
>
> In the scheme of things, this proposal makes very little difference. There
> are still other ways to get non-compiling commits onto develop (e.g.
> waiting a long time between running PR checks and merging to develop).
> What’s more important is working well together as a community. So, perhaps
> what’s best for the community is to encourage working on trust rather than
> unnecessary constraints.
>
> -Owen
>
> On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org> wrote:
>
> I'm happy to file multiple PRs when I need to merge multiple commits to
> develop.
>
> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <mh...@pivotal.io> wrote:
>
> This change to disable all but squash-merge would be really easy to
> revert. How about we try it for a while and see? If people decide it is
> really limiting them, we can change it back. Let’s do it for 1 month and
> see how it goes. Does that sound reasonable?
>
> Thanks,
> Mark
>
> On Dec 30, 2019, at 5:25 PM, Owen Nichols <on...@pivotal.io> wrote:
>
> Given that we adopted <
>
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
>>
> and still wish to continue <
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
>>
> having branch protection rules to ensure every commit landing in develop
> has passed the required PR checks, it seems like that decision alone
> mandates that we disable all merge mechanisms other than squash-and-merge.
>
>
> Allowing merge commits or rebase merges bypasses branch protection for
>
> all commits other than the final one in the merge or rebase set. Given
> that we decided <
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
>>
> that bypassing PR checks should never be allowed, keeping this loophole
> open seems untenable.
>
>
> This is not just hypothetical — this loophole is causing real problems.
>
> We now have commits on develop that don’t compile. For example:
>
> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> ./gradlew devBuild
> ...spotlessJava FAILED
> We implemented branch protections to make this impossible, right?
>
> We can very easily close this loophole by disabling all but the
>
> Squash&Merge button for PRs. This will not make more work for any
> developer. If you want to get multiple commits onto develop, simply submit
> each as a separate PR — that is the only way to assure that required PR
> checks have passed for each.
>
>
> On the other hand, if we as a Geode community feel strongly that
>
> bypassing branch protection via merge commits and rebase commits is
> important to allow, why not also allow arbitrary overrides (or get rid of
> branch protection entirely)?
>
>
> -Owen
>
> On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io> wrote:
>
> Just FWIW, the situation described of having multiple commits in a
>
> single
>
> PR with separate associated JIRA tickets is still kind of problematic.
>
> It
>
> could well be the case that the commits are interdependent, thus when
> bisecting etc it's still not possible to revert the fix for a single
> bug/feature/whatever atomically. It's all good, though, I'm satisfied
>
> no
>
> one's forcing me to adopt practice I'm opposed to. Apologies for
>
> getting
>
> my feathers a little ruffled, or if I ruffled anyone else's in return.
>
> Thanks,
>
> Blake
>
>
> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Dan,
>
> When we do squash merge all the commit messages are preserved and also
>
> the
>
> co-authored tag works when we do squash merge.
> So the authorship and history are preserved.
>
> In my own personal experience and reverts and pinpointing regression
> failures are tough when the commits are spread out. Also, reverts are
> easier when it is just one commit while we are bisecting failures.
>
>
> Regards
> Naba
>
> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io> wrote:
>
> I'll change to -0.
>
> I think merge commits are a nice way to record history in some cases,
>
> and
>
> can also be a way to avoid messy conflicts that come with rebase.
>
> Merge
>
> commits also preserve authorship of commits (compared to
>
> squash-merge),
>
> which I think is valuable as an open source community that is trying
>
> to
>
> keep track of outside contributions.
>
> That said, if the rest of y'all feel it will help to disable the
>
> button,
>
> I
>
> won't stand in the way.
>
> -Dan
>
> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
>
> wrote:
>
>
> Whether we are talking about the geode/ repository or the
>
> geode-native/
>
> repository we are all one GEODE community.
>
> The idea of a native client team may matter in some contexts but in
>
> this
>
> space we are all GEODE contributors.
>
> Adopting a common approach across our repos will make it easier for
>
> new
>
> contributors to engage, learn our norms, and join our efforts.
>
> $0.02,
> Anthony
>
>
> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
>
> wrote:
>
>
> Is this a policy the native client team must abide by, as well? It
>
> varies
>
> slightly with what we've been doing, and all other things being
>
> equal I
>
> see
>
> no reason for us to change that. If I am to have any measure of
>
> control
>
> over the nc repository, I will definitely enforce a 1:1
>
> correspondence
>
> between commits to develop and JIRA tickets. IMO, if your
>
> refactoring
>
> in a
>
> PR is sufficiently large or complex that it's difficult to tease it
>
> out
>
> from the bug you're fixing or feature you're implementing, it merits
>
> its
>
> own JIRA ticket and a separate PR. If your "actual" fix then
>
> becomes
>
> dependent on the refactored code, that's a price I'm willing to pay
>
> to
>
> keep
>
> history clean.
>
> On the other hand, I see no real value in squashing to a single
>
> commit
>
> prior to submitting a PR, since your view of the changes on GitHub
>
> is
>
> essentially the same either way. We haven't enforced this on the nc
>
> repo,
>
> and I'd prefer to keep it that way.
>
> Thanks,
>
> Blake
>
>
> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
>
> wrote:
>
>
> Merge commit is the new contributor's default setting. When we are
>
> merging
>
> new contributor's PR, since we are so used to THINKING
>
> "squash-and-merge"
>
> is the default, we forgot to check what the button really says when
>
> we
>
> are
>
> merging other people's PR.
>
> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
>
> eburghardt@pivotal.io>
>
> wrote:
>
> I'm a proponent of using squash-and-merge, and once a person has
>
> chosen
>
> this option once it comes up by default afterwards...
>
> Owen, I don't think you have consensus to put forth this PR,
>
> there
>
> are
>
> -1s
>
> above... (early voting)
>
> maybe we'll be better off socializing the norm of squash-and-merge
>
> and
>
> gaining a natural consensus that way...
>
> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
>
> onichols@pivotal.io
>
>
> wrote:
>
>
> The proposed action manifests as a commit to the Geode git
>
> repository,
>
> so
>
> a PR is an acceptable vehicle for voting in this case.
>
> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
>
> bschuchardt@pivotal.io>
>
> wrote:
>
>
> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
>
> thread
>
> and a request to "vote" using a PR. This all seems out of order
>
> to
>
> me.
>
> Our votes are supposed to be on the email list, aren't they? and
>
> I
>
> haven't
>
> seen a VOTE request.
>
>
> On 12/20/19 9:33 AM, Nabarun Nag wrote:
>
> +1
>
> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
>
> onichols@pivotal.io
>
>
> wrote:
>
>
> Based on the feedback so far, I will amend the proposal to
>
> drop
>
> item
>
> 2).
>
> Therefore, the current ability to create merge commits using
>
> command-line
>
> git will remain available.
>
> The proposal as amended is now:
>
> Change GitHub settings to make "Squash and merge" the default
> (by removing “Create a merge commit” option).
>
> Update the PR template to change the text "Is your initial
>
> contribution
>
> a single, squashed commit” to “Is your initial contribution
>
> squashed
>
> for
>
> ease of review (e.g. a single commit, or a ‘refactoring’
>
> commit
>
> plus a
>
> ‘fix’ commit)"
>
>
> As Naba suggested, we can try it, and if we don’t like it,
>
> it’s
>
> simple
>
> to
>
> revert.
>
> I’ve create a PR for the proposed change here:
> https://github.com/apache/geode/pull/4513
>
> Please use the PR to vote for against this proposal. It will
>
> not
>
> be
>
> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
>
> that
>
> time)
>
>
> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
>
> wrote:
>
>
> +1
>
> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
>
> onichols@pivotal.io>
>
> wrote:
>
>
> Hi Bruce, this proposal will not waste a single second of
>
> your
>
> time. It
>
> just prevents people from accidentally pressing a button
>
> that
>
> we
>
> have
>
> already agreed should never be pressed, but because we never
>
> configured
>
> our
>
> GitHub to match our stated policy, is currently the default.
>
> However, it will save a lot of time and frustration for
>
> anyone
>
> needing
>
> to
>
> bisect failures, revert, or cherry-pick changes, which has
>
> merit
>
> even if
>
> you personally never do any of those three things.
>
> Please start a separate thread if you would like to revisit
>
> the
>
> community
>
> decision to require passing PR checks.
>
> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
>
> bschuchardt@pivotal.io>
>
> wrote:
>
> I agree with Jake. I would go further by saying that I see
>
> very
>
> little
>
> merit in this proposal. I think we're getting more and more
>
> bureaucratic
>
> in our process and that it stifles productivity. I was
>
> recently
>
> forced
>
> to
>
> spend three days fixing tests in which I had changed an
>
> import
>
> statement
>
> before they would pass stress testing. I'm glad the tests
>
> now
>
> pass
>
> reliably but I was very frustrated by the process.
>
> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>
> I’m in agreement with Dan. Changes to the infrastructure
>
> to
>
> flat
>
> out
>
> prevent things that should be self policing is annoying.
>
> This
>
> PR
>
> review
>
> lock we have had already cost us valuable time waiting for
>
> PR
>
> pipelines
>
> to
>
> pass that have no relevance to the commit, like CI work: I’d
>
> hat
>
> to
>
> see
>
> yet
>
> another process enforced that Kees us from getting work done
>
> when
>
> necessary.
>
> -Jake
>
>
> On Dec 19, 2019, at 4:43 PM, Dan Smith <
>
> dsmith@pivotal.io
>
>
> wrote:
>
>
> -1 to (1) and (2).
>
> I think merge commits are appropriate in certain
>
> circumstances,
>
> so I
>
> don't
>
> think we should make a blanket restriction. In fact I
>
> think
>
> our
>
> release
>
> process involves some merges.
>
> I think setting standards on what is reasonable to be an
>
> individual
>
> commit
>
> will do a lot more to clean up our history than blocking
>
> merges.
>
> We'd
>
> rather not see commits like "Spotless Apply" in the
>
> history,
>
> but
>
> if
>
> reasonably separate and well written commits come in as
>
> part
>
> of
>
> a
>
> merge, I
>
> think that's fine.
>
> -Dan
>
> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
>
> jiliao@pivotal.io
>
>
> wrote:
>
> +1
>
> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
>
> onichols@pivotal.io
>
>
> wrote:
>
> I’d like to advance this topic from an informal
>
> request/discussion
>
> to a
>
> discussion of a concrete proposal.
>
> To recap, it sounds like there is general agreement
>
> that
>
> commit
>
> history
>
> on
>
> develop should be linear (no merge commits), and that
>
> the
>
> biggest
>
> obstacle
>
> to this is that the PR merge button in GitHub creates a
>
> merge
>
> commit
>
> by
>
> default.
>
> I propose the following changes:
> 1) Change GitHub settings to remove the ability to
>
> create
>
> a
>
> merge
>
> commit.
>
> This will make Squash & Merge the default.
>
> 2) Change GitHub settings to require linear history on
>
> develop.
>
> This
>
> prevents merge commits via command-line (not
>
> recommended,
>
> but
>
> wiki
>
> still
>
> has instructions for merging PRs this way).
>
> 3) Update the PR template to change the text "Is your
>
> initial
>
> contribution
>
> a single, squashed commit” to “Is your initial
>
> contribution
>
> squashed
>
> for
>
> ease of review (e.g. a single commit, or a
>
> ‘refactoring’
>
> commit
>
> plus
>
> a
>
> ‘fix’ commit)"
>
> For clarity, I am proposing no-change in the following
>
> areas:
>
> i) Leave Rebase & Merge as an option for PRs that have
>
> been
>
> structured to
>
> benefit from it (this can make it easier in a bisect to
>
> see
>
> whether
>
> the
>
> refactoring or the “fix” broke something).
> ii) Leave existing wording in the wiki as-is [stating
>
> that
>
> squashing
>
> is
>
> preferred].
>
>
> Please comment via this email thread.
> -Owen
>
>
>
> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
>
> klund@apache.org>
>
> wrote:
>
>
> I think it's already resolved Udo ;)
>
> Here's the problem, if I fixup a dunit test by
>
> removing
>
> all
>
> uses
>
> of
>
> "this."
>
> and I rename the dunit test, then git doesn't remember
>
> that
>
> the
>
> file
>
> is a
>
> rename -- it forever afterwards interprets it as a new
>
> file
>
> that I
>
> created
>
> if I touch more than 50% of the lines (which "this."
>
> can
>
> easily
>
> do). If
>
> we
>
> squash two commits: the rename and the cleanup of that
>
> dunit
>
> test
>
> --
>
> then
>
> we effectively lose the history of that file and it
>
> shows
>
> that
>
> I
>
> created
>
> a
>
> new file.
>
> Also for the record, I've been working on Geode since
>
> the
>
> beginning
>
> and I
>
> was never made aware of this change in our process. I
>
> never
>
> voted
>
> on
>
> it.
>
> I'm not a big fan of changing various details in our
>
> process
>
> every
>
> single
>
> week. It's very easy to miss these discussions unless
>
> someone
>
> points it
>
> out
>
> to me.
>
> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>
> ukohlmeyer@pivotal.io>
>
> wrote:
>
> I'm not sure what this discussion is about... WE, as
>
> a
>
> community,
>
> have
>
> agreed in common practices, in two place no less...
>
> 1) Quoting our PR template
>
>
> For all changes:
>
> *
>
> Is there a JIRA ticket associated with this PR? Is it
>
> referenced
>
> in
>
> the commit message?
>
> *
>
> Has your PR been rebased against the latest commit
>
> within
>
> the
>
> target
>
> branch (typically|develop|)?
>
> *
>
> ***Is your initial contribution a single, squashed
>
> commit?*
>
>
> *
>
> Does|gradlew build|run cleanly?
>
> *
>
> Have you written or updated unit tests to verify your
>
> changes?
>
>
> *
>
> If adding new dependencies to the code, are these
>
> dependencies
>
> licensed in a way that is compatible for inclusion
>
> underASF
>
> 2.0
>
> <
>
> http://www.apache.org/legal/resolved.html#category-a
>
> ?
>
>
> On our PR template we call out that the initial PR
>
> commit
>
> should
>
> be
>
> squashed.
>
> 2)
>
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>
> <
>
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>
> -- See "Accepting a PR Using the Command Line" -
>
> Point
>
> #3.
>
>
>
> @Kirk, if each of your commits "stands alone", I
>
> commend
>
> you
>
> on
>
> the
>
> diligence, but in reality, they should either then be
>
> stand
>
> alone
>
> PR's
>
> or just extra work created for yourself.
>
> If we want to change the way we have agreed upon we
>
> submit/commit/merge
>
> changes back into develop... Then this is another
>
> discussion
>
> thread,
>
> until then, I think we should all remind ourselves on
>
> our
>
> agreed
>
> contributions code of conduct.
>
> --Udo
>
> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>
> Kirk, I believe that creating a Pull Request with
>
> multiple
>
> commits is
>
> ok.
>
> It's just in the end that when it's being pushed to
>
> develop
>
> branch,
>
> it
>
> needs to be squash merged. I believe that is what
>
> you
>
> have
>
> mentioned
>
> in
>
> the
>
> first paragraph, and I am more than happy with that.
> If you can see in the first screenshot comparison
>
> that
>
> I
>
> had
>
> attached
>
> in
>
> the first email in this thread is what I want to
>
> avoid.
>
>
> Thank you for your feedback.
>
> Regards
> Naba
>
>
> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
>
> klund@apache.org>
>
> wrote:
>
> Whenever I submit a PR with multiple commits that I
>
> intend
>
> to
>
> rebase
>
> to
>
> develop, I always try to ensure that each commit
>
> stands
>
> alone
>
> as
>
> is
>
> (compiles and passes tests). Separating file
>
> renames
>
> and
>
> refactoring
>
> from
>
> behavior changes into different commits seems very
>
> valuable
>
> to
>
> me,
>
> and
>
> I've
>
> had trouble getting people to review PRs without
>
> this
>
> separation
>
> (but
>
> it
>
> could be squashed as it's merged to develop).
>
> It sounds to me like the real problem is (a) some
>
> PRs
>
> have
>
> multiple
>
> commits
>
> that don't compile or don't pass tests, and (b)
>
> some
>
> PRs
>
> that
>
> should
>
> be
>
> merged with squash are not (by accident most
>
> likely).
>
>
> I can submit multiple PRs instead of one PR with
>
> multiple
>
> commits.
>
> So
>
> I'll
>
> change my response to -0 if that helps prevent
>
> commits
>
> to
>
> develop
>
> that
>
> don't compile or pass tests. Without preventing
>
> rebase
>
> or
>
> merge
>
> commits
>
> from github, I'm not sure how we can really enforce
>
> this
>
> or
>
> prevent
>
> (b)
>
> above.
>
> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>
> amurmann@pivotal.io>
>
> wrote:
>
> I wonder if Kirk's and Naba's statements are
>
> necessarily
>
> at
>
> odds.
>
> Make the change easy (warning: this may be hard),
>
> then
>
> make
>
> the
>
> easy
>
> change."
>
> -Kent Beck
>
> Following Kent Beck's advise might reasonably
>
> split
>
> into
>
> two
>
> commits.
>
> One
>
> refactor commit and a separate commit that
>
> introduces
>
> the
>
> actual
>
> change.
>
> They should be individually revertible and might
>
> be
>
> easier
>
> understood
>
> if
>
> split out. I vividly remember a change on our code
>
> base
>
> where
>
> someone
>
> did a
>
> huge amount of refactoring that resulted than in
>
> one
>
> parameter
>
> changing
>
> in
>
> order to get the desired functionality change. If
>
> that
>
> was
>
> in
>
> one
>
> commit,
>
> it would be hard to see the actual change. If
>
> split
>
> out,
>
> it's
>
> beautiful
>
> and
>
> crystal clear.
>
> I am unsure how that would be reflected in terms
>
> of
>
> JIRA
>
> ticket
>
> references.
>
> Usually we assume that if there is a commit with
>
> the
>
> ticket
>
> number,
>
> the
>
> issue is resolved. Maybe the key here is to create
>
> a
>
> separate
>
> refactoring
>
> ticket.
>
> Would that allow us to have our cake and eat it
>
> too?
>
>
> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
>
> nnag@pivotal.io>
>
> wrote:
>
> It is to help with bisect operations when things
>
> start
>
> failing
>
> ...
>
> helps
>
> us
>
> it revert and build faster.
> also with cherry picking features / fixes to
>
> previous
>
> versions
>
> .
>
> And keeping the git history clean with no
>
> unnecessary
>
> “merge
>
> commits”.
>
> Regards
> Naba
>
>
> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
>
> klund@apache.org>
>
> wrote:
>
> -1 I really like to sometimes have more than 1
>
> commit
>
> in
>
> a
>
> PR
>
> and
>
> keep
>
> them
>
> separate when they merge to develop
>
> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>
> nnag@pivotal.io>
>
> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead
>
> of
>
> using
>
> merge.
>
> This will really help us in our bisect
>
> operations
>
> when a
>
> regression/flakiness in the product is
>
> introduced.
>
> We
>
> can
>
> automate
>
> and
>
> go
>
> through fewer commits faster, avoiding commits
>
> like
>
> "spotless
>
> fix"
>
> and
>
> "re-trigger precheck-in" or other minor commits
>
> in
>
> the
>
> merged
>
> branch.
>
> Also, please use the commit format : (helps us
>
> to
>
> know
>
> who
>
> worked
>
> on
>
> it,
>
> what is the history)
>
>
>
> * GEODE-xxxx: <brief intro >
> * explanation line 1
>
> *
>
> explanation
>
> line
>
> 2*
>
> This is not a rule or anything, but a request
>
> to
>
> help
>
> out
>
> your
>
> fellow
>
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka
>
> /
>
> Spark
>
> where
>
> they
>
> have
>
> a
>
> complete linear graph for their main branch
>
> HEAD
>
> [see
>
> attachment]
>
> Regards
> Naba.
>
>
>
> --
>
> Ju@N
>
>
>
>
>
>
>
> --
> Cheers
>
> Jinmei
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
To recap, this proposal is now revised to remove 2 of the 3 merge options
from GitHub, leaving only Squash and Merge. PR #4513
<https://github.com/apache/geode/pull/4513> serves as an exhibit of what is
proposed (it is not to be merged unless discussion leads to consensus and a
successful vote). Please use the dev list (not the PR) for all discussion
(and voting, if we get that far).
Squash and merge is already used almost exclusively by the Geode community,
with any exceptions tending to be accidental more often than intentional.
However, some have raised the concern that implementing this restriction
could result in harm or wasted time. Can someone give an example of a such
a scenario?
It seems there is a divide here between junior and senior community
members. Newer committers appreciate additional guardrails to protect them
from accidentally doing the wrong thing, while those with more experience
want to be able to work unencumbered by restrictions of any kind.
Our welcome email to new committers states “We like to work on trust rather
than unnecessary constraints...Being a committer enables you to more easily
make changes without needing to go through the patch submission process”.
I can see this as an argument against this proposal (perhaps even an
argument against any form of branch protection).
In the scheme of things, this proposal makes very little difference. There
are still other ways to get non-compiling commits onto develop (e.g.
waiting a long time between running PR checks and merging to develop).
What’s more important is working well together as a community. So, perhaps
what’s best for the community is to encourage working on trust rather than
unnecessary constraints.
-Owen
On Dec 31, 2019, at 10:56 AM, Kirk Lund <kl...@apache.org> wrote:
I'm happy to file multiple PRs when I need to merge multiple commits to
develop.
On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <mh...@pivotal.io> wrote:
This change to disable all but squash-merge would be really easy to
revert. How about we try it for a while and see? If people decide it is
really limiting them, we can change it back. Let’s do it for 1 month and
see how it goes. Does that sound reasonable?
Thanks,
Mark
On Dec 30, 2019, at 5:25 PM, Owen Nichols <on...@pivotal.io> wrote:
Given that we adopted <
https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
>
and still wish to continue <
https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
>
having branch protection rules to ensure every commit landing in develop
has passed the required PR checks, it seems like that decision alone
mandates that we disable all merge mechanisms other than squash-and-merge.
Allowing merge commits or rebase merges bypasses branch protection for
all commits other than the final one in the merge or rebase set. Given
that we decided <
https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
>
that bypassing PR checks should never be allowed, keeping this loophole
open seems untenable.
This is not just hypothetical — this loophole is causing real problems.
We now have commits on develop that don’t compile. For example:
git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
./gradlew devBuild
...spotlessJava FAILED
We implemented branch protections to make this impossible, right?
We can very easily close this loophole by disabling all but the
Squash&Merge button for PRs. This will not make more work for any
developer. If you want to get multiple commits onto develop, simply submit
each as a separate PR — that is the only way to assure that required PR
checks have passed for each.
On the other hand, if we as a Geode community feel strongly that
bypassing branch protection via merge commits and rebase commits is
important to allow, why not also allow arbitrary overrides (or get rid of
branch protection entirely)?
-Owen
On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io> wrote:
Just FWIW, the situation described of having multiple commits in a
single
PR with separate associated JIRA tickets is still kind of problematic.
It
could well be the case that the commits are interdependent, thus when
bisecting etc it's still not possible to revert the fix for a single
bug/feature/whatever atomically. It's all good, though, I'm satisfied
no
one's forcing me to adopt practice I'm opposed to. Apologies for
getting
my feathers a little ruffled, or if I ruffled anyone else's in return.
Thanks,
Blake
On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
Hi Dan,
When we do squash merge all the commit messages are preserved and also
the
co-authored tag works when we do squash merge.
So the authorship and history are preserved.
In my own personal experience and reverts and pinpointing regression
failures are tough when the commits are spread out. Also, reverts are
easier when it is just one commit while we are bisecting failures.
Regards
Naba
On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io> wrote:
I'll change to -0.
I think merge commits are a nice way to record history in some cases,
and
can also be a way to avoid messy conflicts that come with rebase.
Merge
commits also preserve authorship of commits (compared to
squash-merge),
which I think is valuable as an open source community that is trying
to
keep track of outside contributions.
That said, if the rest of y'all feel it will help to disable the
button,
I
won't stand in the way.
-Dan
On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
wrote:
Whether we are talking about the geode/ repository or the
geode-native/
repository we are all one GEODE community.
The idea of a native client team may matter in some contexts but in
this
space we are all GEODE contributors.
Adopting a common approach across our repos will make it easier for
new
contributors to engage, learn our norms, and join our efforts.
$0.02,
Anthony
On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
wrote:
Is this a policy the native client team must abide by, as well? It
varies
slightly with what we've been doing, and all other things being
equal I
see
no reason for us to change that. If I am to have any measure of
control
over the nc repository, I will definitely enforce a 1:1
correspondence
between commits to develop and JIRA tickets. IMO, if your
refactoring
in a
PR is sufficiently large or complex that it's difficult to tease it
out
from the bug you're fixing or feature you're implementing, it merits
its
own JIRA ticket and a separate PR. If your "actual" fix then
becomes
dependent on the refactored code, that's a price I'm willing to pay
to
keep
history clean.
On the other hand, I see no real value in squashing to a single
commit
prior to submitting a PR, since your view of the changes on GitHub
is
essentially the same either way. We haven't enforced this on the nc
repo,
and I'd prefer to keep it that way.
Thanks,
Blake
On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
wrote:
Merge commit is the new contributor's default setting. When we are
merging
new contributor's PR, since we are so used to THINKING
"squash-and-merge"
is the default, we forgot to check what the button really says when
we
are
merging other people's PR.
On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
eburghardt@pivotal.io>
wrote:
I'm a proponent of using squash-and-merge, and once a person has
chosen
this option once it comes up by default afterwards...
Owen, I don't think you have consensus to put forth this PR,
there
are
-1s
above... (early voting)
maybe we'll be better off socializing the norm of squash-and-merge
and
gaining a natural consensus that way...
On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
onichols@pivotal.io
wrote:
The proposed action manifests as a commit to the Geode git
repository,
so
a PR is an acceptable vehicle for voting in this case.
On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
bschuchardt@pivotal.io>
wrote:
I see a lot of plus-ones and a "voting deadline" on this DISCUSS
thread
and a request to "vote" using a PR. This all seems out of order
to
me.
Our votes are supposed to be on the email list, aren't they? and
I
haven't
seen a VOTE request.
On 12/20/19 9:33 AM, Nabarun Nag wrote:
+1
On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
onichols@pivotal.io
wrote:
Based on the feedback so far, I will amend the proposal to
drop
item
2).
Therefore, the current ability to create merge commits using
command-line
git will remain available.
The proposal as amended is now:
Change GitHub settings to make "Squash and merge" the default
(by removing “Create a merge commit” option).
Update the PR template to change the text "Is your initial
contribution
a single, squashed commit” to “Is your initial contribution
squashed
for
ease of review (e.g. a single commit, or a ‘refactoring’
commit
plus a
‘fix’ commit)"
As Naba suggested, we can try it, and if we don’t like it,
it’s
simple
to
revert.
I’ve create a PR for the proposed change here:
https://github.com/apache/geode/pull/4513
Please use the PR to vote for against this proposal. It will
not
be
merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
that
time)
On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
wrote:
+1
On Fri 20 Dec 2019 at 16:18, Owen Nichols <
onichols@pivotal.io>
wrote:
Hi Bruce, this proposal will not waste a single second of
your
time. It
just prevents people from accidentally pressing a button
that
we
have
already agreed should never be pressed, but because we never
configured
our
GitHub to match our stated policy, is currently the default.
However, it will save a lot of time and frustration for
anyone
needing
to
bisect failures, revert, or cherry-pick changes, which has
merit
even if
you personally never do any of those three things.
Please start a separate thread if you would like to revisit
the
community
decision to require passing PR checks.
On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
bschuchardt@pivotal.io>
wrote:
I agree with Jake. I would go further by saying that I see
very
little
merit in this proposal. I think we're getting more and more
bureaucratic
in our process and that it stifles productivity. I was
recently
forced
to
spend three days fixing tests in which I had changed an
import
statement
before they would pass stress testing. I'm glad the tests
now
pass
reliably but I was very frustrated by the process.
On 12/19/19 4:49 PM, Jacob Barrett wrote:
I’m in agreement with Dan. Changes to the infrastructure
to
flat
out
prevent things that should be self policing is annoying.
This
PR
review
lock we have had already cost us valuable time waiting for
PR
pipelines
to
pass that have no relevance to the commit, like CI work: I’d
hat
to
see
yet
another process enforced that Kees us from getting work done
when
necessary.
-Jake
On Dec 19, 2019, at 4:43 PM, Dan Smith <
dsmith@pivotal.io
wrote:
-1 to (1) and (2).
I think merge commits are appropriate in certain
circumstances,
so I
don't
think we should make a blanket restriction. In fact I
think
our
release
process involves some merges.
I think setting standards on what is reasonable to be an
individual
commit
will do a lot more to clean up our history than blocking
merges.
We'd
rather not see commits like "Spotless Apply" in the
history,
but
if
reasonably separate and well written commits come in as
part
of
a
merge, I
think that's fine.
-Dan
On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
jiliao@pivotal.io
wrote:
+1
On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
onichols@pivotal.io
wrote:
I’d like to advance this topic from an informal
request/discussion
to a
discussion of a concrete proposal.
To recap, it sounds like there is general agreement
that
commit
history
on
develop should be linear (no merge commits), and that
the
biggest
obstacle
to this is that the PR merge button in GitHub creates a
merge
commit
by
default.
I propose the following changes:
1) Change GitHub settings to remove the ability to
create
a
merge
commit.
This will make Squash & Merge the default.
2) Change GitHub settings to require linear history on
develop.
This
prevents merge commits via command-line (not
recommended,
but
wiki
still
has instructions for merging PRs this way).
3) Update the PR template to change the text "Is your
initial
contribution
a single, squashed commit” to “Is your initial
contribution
squashed
for
ease of review (e.g. a single commit, or a
‘refactoring’
commit
plus
a
‘fix’ commit)"
For clarity, I am proposing no-change in the following
areas:
i) Leave Rebase & Merge as an option for PRs that have
been
structured to
benefit from it (this can make it easier in a bisect to
see
whether
the
refactoring or the “fix” broke something).
ii) Leave existing wording in the wiki as-is [stating
that
squashing
is
preferred].
Please comment via this email thread.
-Owen
On Dec 16, 2019, at 10:49 AM, Kirk Lund <
klund@apache.org>
wrote:
I think it's already resolved Udo ;)
Here's the problem, if I fixup a dunit test by
removing
all
uses
of
"this."
and I rename the dunit test, then git doesn't remember
that
the
file
is a
rename -- it forever afterwards interprets it as a new
file
that I
created
if I touch more than 50% of the lines (which "this."
can
easily
do). If
we
squash two commits: the rename and the cleanup of that
dunit
test
--
then
we effectively lose the history of that file and it
shows
that
I
created
a
new file.
Also for the record, I've been working on Geode since
the
beginning
and I
was never made aware of this change in our process. I
never
voted
on
it.
I'm not a big fan of changing various details in our
process
every
single
week. It's very easy to miss these discussions unless
someone
points it
out
to me.
On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
ukohlmeyer@pivotal.io>
wrote:
I'm not sure what this discussion is about... WE, as
a
community,
have
agreed in common practices, in two place no less...
1) Quoting our PR template
For all changes:
*
Is there a JIRA ticket associated with this PR? Is it
referenced
in
the commit message?
*
Has your PR been rebased against the latest commit
within
the
target
branch (typically|develop|)?
*
***Is your initial contribution a single, squashed
commit?*
*
Does|gradlew build|run cleanly?
*
Have you written or updated unit tests to verify your
changes?
*
If adding new dependencies to the code, are these
dependencies
licensed in a way that is compatible for inclusion
underASF
2.0
<
http://www.apache.org/legal/resolved.html#category-a
?
On our PR template we call out that the initial PR
commit
should
be
squashed.
2)
https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
<
https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
-- See "Accepting a PR Using the Command Line" -
Point
#3.
@Kirk, if each of your commits "stands alone", I
commend
you
on
the
diligence, but in reality, they should either then be
stand
alone
PR's
or just extra work created for yourself.
If we want to change the way we have agreed upon we
submit/commit/merge
changes back into develop... Then this is another
discussion
thread,
until then, I think we should all remind ourselves on
our
agreed
contributions code of conduct.
--Udo
On 12/16/19 9:59 AM, Nabarun Nag wrote:
Kirk, I believe that creating a Pull Request with
multiple
commits is
ok.
It's just in the end that when it's being pushed to
develop
branch,
it
needs to be squash merged. I believe that is what
you
have
mentioned
in
the
first paragraph, and I am more than happy with that.
If you can see in the first screenshot comparison
that
I
had
attached
in
the first email in this thread is what I want to
avoid.
Thank you for your feedback.
Regards
Naba
On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
klund@apache.org>
wrote:
Whenever I submit a PR with multiple commits that I
intend
to
rebase
to
develop, I always try to ensure that each commit
stands
alone
as
is
(compiles and passes tests). Separating file
renames
and
refactoring
from
behavior changes into different commits seems very
valuable
to
me,
and
I've
had trouble getting people to review PRs without
this
separation
(but
it
could be squashed as it's merged to develop).
It sounds to me like the real problem is (a) some
PRs
have
multiple
commits
that don't compile or don't pass tests, and (b)
some
PRs
that
should
be
merged with squash are not (by accident most
likely).
I can submit multiple PRs instead of one PR with
multiple
commits.
So
I'll
change my response to -0 if that helps prevent
commits
to
develop
that
don't compile or pass tests. Without preventing
rebase
or
merge
commits
from github, I'm not sure how we can really enforce
this
or
prevent
(b)
above.
On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
amurmann@pivotal.io>
wrote:
I wonder if Kirk's and Naba's statements are
necessarily
at
odds.
Make the change easy (warning: this may be hard),
then
make
the
easy
change."
-Kent Beck
Following Kent Beck's advise might reasonably
split
into
two
commits.
One
refactor commit and a separate commit that
introduces
the
actual
change.
They should be individually revertible and might
be
easier
understood
if
split out. I vividly remember a change on our code
base
where
someone
did a
huge amount of refactoring that resulted than in
one
parameter
changing
in
order to get the desired functionality change. If
that
was
in
one
commit,
it would be hard to see the actual change. If
split
out,
it's
beautiful
and
crystal clear.
I am unsure how that would be reflected in terms
of
JIRA
ticket
references.
Usually we assume that if there is a commit with
the
ticket
number,
the
issue is resolved. Maybe the key here is to create
a
separate
refactoring
ticket.
Would that allow us to have our cake and eat it
too?
On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
nnag@pivotal.io>
wrote:
It is to help with bisect operations when things
start
failing
...
helps
us
it revert and build faster.
also with cherry picking features / fixes to
previous
versions
.
And keeping the git history clean with no
unnecessary
“merge
commits”.
Regards
Naba
On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
klund@apache.org>
wrote:
-1 I really like to sometimes have more than 1
commit
in
a
PR
and
keep
them
separate when they merge to develop
On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
nnag@pivotal.io>
wrote:
Hi Geode Committers,
A kind request for using squash commit instead
of
using
merge.
This will really help us in our bisect
operations
when a
regression/flakiness in the product is
introduced.
We
can
automate
and
go
through fewer commits faster, avoiding commits
like
"spotless
fix"
and
"re-trigger precheck-in" or other minor commits
in
the
merged
branch.
Also, please use the commit format : (helps us
to
know
who
worked
on
it,
what is the history)
* GEODE-xxxx: <brief intro >
* explanation line 1
*
explanation
line
2*
This is not a rule or anything, but a request
to
help
out
your
fellow
committers in quickly detecting a problem.
For inspiration, we can look into Apache Kafka
/
Spark
where
they
have
a
complete linear graph for their main branch
HEAD
[see
attachment]
Regards
Naba.
--
Ju@N
--
Cheers
Jinmei
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Kirk Lund <kl...@apache.org>.
I'm happy to file multiple PRs when I need to merge multiple commits to
develop.
On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <mh...@pivotal.io> wrote:
> This change to disable all but squash-merge would be really easy to
> revert. How about we try it for a while and see? If people decide it is
> really limiting them, we can change it back. Let’s do it for 1 month and
> see how it goes. Does that sound reasonable?
>
> Thanks,
> Mark
>
> > On Dec 30, 2019, at 5:25 PM, Owen Nichols <on...@pivotal.io> wrote:
> >
> > Given that we adopted <
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E>
> and still wish to continue <
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E>
> having branch protection rules to ensure every commit landing in develop
> has passed the required PR checks, it seems like that decision alone
> mandates that we disable all merge mechanisms other than squash-and-merge.
> >
> > Allowing merge commits or rebase merges bypasses branch protection for
> all commits other than the final one in the merge or rebase set. Given
> that we decided <
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E>
> that bypassing PR checks should never be allowed, keeping this loophole
> open seems untenable.
> >
> > This is not just hypothetical — this loophole is causing real problems.
> We now have commits on develop that don’t compile. For example:
> > git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> > ./gradlew devBuild
> > ...spotlessJava FAILED
> > We implemented branch protections to make this impossible, right?
> >
> > We can very easily close this loophole by disabling all but the
> Squash&Merge button for PRs. This will not make more work for any
> developer. If you want to get multiple commits onto develop, simply submit
> each as a separate PR — that is the only way to assure that required PR
> checks have passed for each.
> >
> > On the other hand, if we as a Geode community feel strongly that
> bypassing branch protection via merge commits and rebase commits is
> important to allow, why not also allow arbitrary overrides (or get rid of
> branch protection entirely)?
> >
> > -Owen
> >
> >> On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io> wrote:
> >>
> >> Just FWIW, the situation described of having multiple commits in a
> single
> >> PR with separate associated JIRA tickets is still kind of problematic.
> It
> >> could well be the case that the commits are interdependent, thus when
> >> bisecting etc it's still not possible to revert the fix for a single
> >> bug/feature/whatever atomically. It's all good, though, I'm satisfied
> no
> >> one's forcing me to adopt practice I'm opposed to. Apologies for
> getting
> >> my feathers a little ruffled, or if I ruffled anyone else's in return.
> >>
> >> Thanks,
> >>
> >> Blake
> >>
> >>
> >> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >>
> >>> Hi Dan,
> >>>
> >>> When we do squash merge all the commit messages are preserved and also
> the
> >>> co-authored tag works when we do squash merge.
> >>> So the authorship and history are preserved.
> >>>
> >>> In my own personal experience and reverts and pinpointing regression
> >>> failures are tough when the commits are spread out. Also, reverts are
> >>> easier when it is just one commit while we are bisecting failures.
> >>>
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io> wrote:
> >>>
> >>>> I'll change to -0.
> >>>>
> >>>> I think merge commits are a nice way to record history in some cases,
> and
> >>>> can also be a way to avoid messy conflicts that come with rebase.
> Merge
> >>>> commits also preserve authorship of commits (compared to
> squash-merge),
> >>>> which I think is valuable as an open source community that is trying
> to
> >>>> keep track of outside contributions.
> >>>>
> >>>> That said, if the rest of y'all feel it will help to disable the
> button,
> >>> I
> >>>> won't stand in the way.
> >>>>
> >>>> -Dan
> >>>>
> >>>> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
> >>> wrote:
> >>>>
> >>>>> Whether we are talking about the geode/ repository or the
> geode-native/
> >>>>> repository we are all one GEODE community.
> >>>>>
> >>>>> The idea of a native client team may matter in some contexts but in
> >>> this
> >>>>> space we are all GEODE contributors.
> >>>>>
> >>>>> Adopting a common approach across our repos will make it easier for
> new
> >>>>> contributors to engage, learn our norms, and join our efforts.
> >>>>>
> >>>>> $0.02,
> >>>>> Anthony
> >>>>>
> >>>>>
> >>>>>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
> >>> wrote:
> >>>>>>
> >>>>>> Is this a policy the native client team must abide by, as well? It
> >>>>> varies
> >>>>>> slightly with what we've been doing, and all other things being
> >>> equal I
> >>>>> see
> >>>>>> no reason for us to change that. If I am to have any measure of
> >>>> control
> >>>>>> over the nc repository, I will definitely enforce a 1:1
> >>> correspondence
> >>>>>> between commits to develop and JIRA tickets. IMO, if your
> >>> refactoring
> >>>>> in a
> >>>>>> PR is sufficiently large or complex that it's difficult to tease it
> >>> out
> >>>>>> from the bug you're fixing or feature you're implementing, it merits
> >>>> its
> >>>>>> own JIRA ticket and a separate PR. If your "actual" fix then
> becomes
> >>>>>> dependent on the refactored code, that's a price I'm willing to pay
> >>> to
> >>>>> keep
> >>>>>> history clean.
> >>>>>>
> >>>>>> On the other hand, I see no real value in squashing to a single
> >>> commit
> >>>>>> prior to submitting a PR, since your view of the changes on GitHub
> is
> >>>>>> essentially the same either way. We haven't enforced this on the nc
> >>>>> repo,
> >>>>>> and I'd prefer to keep it that way.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Blake
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
> >>>> wrote:
> >>>>>>
> >>>>>>> Merge commit is the new contributor's default setting. When we are
> >>>>> merging
> >>>>>>> new contributor's PR, since we are so used to THINKING
> >>>>> "squash-and-merge"
> >>>>>>> is the default, we forgot to check what the button really says when
> >>> we
> >>>>> are
> >>>>>>> merging other people's PR.
> >>>>>>>
> >>>>>>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> >>>>> eburghardt@pivotal.io>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> I'm a proponent of using squash-and-merge, and once a person has
> >>>> chosen
> >>>>>>>> this option once it comes up by default afterwards...
> >>>>>>>>
> >>>>>>>> Owen, I don't think you have consensus to put forth this PR,
> there
> >>>> are
> >>>>>>> -1s
> >>>>>>>> above... (early voting)
> >>>>>>>>
> >>>>>>>> maybe we'll be better off socializing the norm of squash-and-merge
> >>>> and
> >>>>>>>> gaining a natural consensus that way...
> >>>>>>>>
> >>>>>>>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <
> onichols@pivotal.io
> >>>>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> The proposed action manifests as a commit to the Geode git
> >>>> repository,
> >>>>>>> so
> >>>>>>>>> a PR is an acceptable vehicle for voting in this case.
> >>>>>>>>>
> >>>>>>>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> >>>>>>> bschuchardt@pivotal.io>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> >>>>>>> thread
> >>>>>>>>> and a request to "vote" using a PR. This all seems out of order
> >>> to
> >>>>> me.
> >>>>>>>>> Our votes are supposed to be on the email list, aren't they? and
> I
> >>>>>>>> haven't
> >>>>>>>>> seen a VOTE request.
> >>>>>>>>>>
> >>>>>>>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> >>>>>>>>>>> +1
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
> >>> onichols@pivotal.io
> >>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Based on the feedback so far, I will amend the proposal to
> drop
> >>>>>>> item
> >>>>>>>>> 2).
> >>>>>>>>>>>> Therefore, the current ability to create merge commits using
> >>>>>>>>> command-line
> >>>>>>>>>>>> git will remain available.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The proposal as amended is now:
> >>>>>>>>>>>>> Change GitHub settings to make "Squash and merge" the default
> >>>>>>>>>>>>> (by removing “Create a merge commit” option).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Update the PR template to change the text "Is your initial
> >>>>>>>>> contribution
> >>>>>>>>>>>>> a single, squashed commit” to “Is your initial contribution
> >>>>>>> squashed
> >>>>>>>>> for
> >>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> >>> commit
> >>>>>>>> plus a
> >>>>>>>>>>>>> ‘fix’ commit)"
> >>>>>>>>>>>>
> >>>>>>>>>>>> As Naba suggested, we can try it, and if we don’t like it,
> it’s
> >>>>>>>> simple
> >>>>>>>>> to
> >>>>>>>>>>>> revert.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I’ve create a PR for the proposed change here:
> >>>>>>>>>>>> https://github.com/apache/geode/pull/4513
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please use the PR to vote for against this proposal. It will
> >>> not
> >>>>>>> be
> >>>>>>>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at
> that
> >>>>>>> time)
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
> >>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> +1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
> >>> onichols@pivotal.io>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Bruce, this proposal will not waste a single second of
> >>> your
> >>>>>>>>> time. It
> >>>>>>>>>>>>>> just prevents people from accidentally pressing a button
> that
> >>>> we
> >>>>>>>> have
> >>>>>>>>>>>>>> already agreed should never be pressed, but because we never
> >>>>>>>>> configured
> >>>>>>>>>>>> our
> >>>>>>>>>>>>>> GitHub to match our stated policy, is currently the default.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> However, it will save a lot of time and frustration for
> >>> anyone
> >>>>>>>>> needing
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>> bisect failures, revert, or cherry-pick changes, which has
> >>>> merit
> >>>>>>>>> even if
> >>>>>>>>>>>>>> you personally never do any of those three things.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please start a separate thread if you would like to revisit
> >>> the
> >>>>>>>>>>>> community
> >>>>>>>>>>>>>> decision to require passing PR checks.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> >>>>>>>>> bschuchardt@pivotal.io>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>> I agree with Jake. I would go further by saying that I see
> >>>> very
> >>>>>>>>> little
> >>>>>>>>>>>>>> merit in this proposal. I think we're getting more and more
> >>>>>>>>>>>> bureaucratic
> >>>>>>>>>>>>>> in our process and that it stifles productivity. I was
> >>>> recently
> >>>>>>>>> forced
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>> spend three days fixing tests in which I had changed an
> >>> import
> >>>>>>>>> statement
> >>>>>>>>>>>>>> before they would pass stress testing. I'm glad the tests
> >>> now
> >>>>>>> pass
> >>>>>>>>>>>>>> reliably but I was very frustrated by the process.
> >>>>>>>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> >>>>>>>>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure
> to
> >>>>>>> flat
> >>>>>>>>> out
> >>>>>>>>>>>>>> prevent things that should be self policing is annoying.
> This
> >>>> PR
> >>>>>>>>> review
> >>>>>>>>>>>>>> lock we have had already cost us valuable time waiting for
> PR
> >>>>>>>>> pipelines
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>> pass that have no relevance to the commit, like CI work: I’d
> >>>> hat
> >>>>>>> to
> >>>>>>>>> see
> >>>>>>>>>>>> yet
> >>>>>>>>>>>>>> another process enforced that Kees us from getting work done
> >>>> when
> >>>>>>>>>>>> necessary.
> >>>>>>>>>>>>>>>> -Jake
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <
> dsmith@pivotal.io
> >>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -1 to (1) and (2).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think merge commits are appropriate in certain
> >>>>>>> circumstances,
> >>>>>>>>> so I
> >>>>>>>>>>>>>> don't
> >>>>>>>>>>>>>>>>> think we should make a blanket restriction. In fact I
> >>> think
> >>>>>>> our
> >>>>>>>>>>>> release
> >>>>>>>>>>>>>>>>> process involves some merges.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think setting standards on what is reasonable to be an
> >>>>>>>>> individual
> >>>>>>>>>>>>>> commit
> >>>>>>>>>>>>>>>>> will do a lot more to clean up our history than blocking
> >>>>>>> merges.
> >>>>>>>>> We'd
> >>>>>>>>>>>>>>>>> rather not see commits like "Spotless Apply" in the
> >>> history,
> >>>>>>> but
> >>>>>>>>> if
> >>>>>>>>>>>>>>>>> reasonably separate and well written commits come in as
> >>> part
> >>>>>>> of
> >>>>>>>> a
> >>>>>>>>>>>>>> merge, I
> >>>>>>>>>>>>>>>>> think that's fine.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -Dan
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> >>>>>>> jiliao@pivotal.io
> >>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> >>>>>>>> onichols@pivotal.io
> >>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>> I’d like to advance this topic from an informal
> >>>>>>>>> request/discussion
> >>>>>>>>>>>>>> to a
> >>>>>>>>>>>>>>>>>>> discussion of a concrete proposal.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> To recap, it sounds like there is general agreement
> that
> >>>>>>>> commit
> >>>>>>>>>>>>>> history
> >>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>> develop should be linear (no merge commits), and that
> >>> the
> >>>>>>>>> biggest
> >>>>>>>>>>>>>>>>>> obstacle
> >>>>>>>>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a
> >>>>>>> merge
> >>>>>>>>>>>> commit
> >>>>>>>>>>>>>> by
> >>>>>>>>>>>>>>>>>>> default.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I propose the following changes:
> >>>>>>>>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to
> >>> create
> >>>> a
> >>>>>>>>> merge
> >>>>>>>>>>>>>> commit.
> >>>>>>>>>>>>>>>>>>> This will make Squash & Merge the default.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 2) Change GitHub settings to require linear history on
> >>>>>>>> develop.
> >>>>>>>>>>>> This
> >>>>>>>>>>>>>>>>>>> prevents merge commits via command-line (not
> >>> recommended,
> >>>>>>> but
> >>>>>>>>> wiki
> >>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>>>> has instructions for merging PRs this way).
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 3) Update the PR template to change the text "Is your
> >>>>>>> initial
> >>>>>>>>>>>>>>>>>> contribution
> >>>>>>>>>>>>>>>>>>> a single, squashed commit” to “Is your initial
> >>>> contribution
> >>>>>>>>>>>> squashed
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>> ease of review (e.g. a single commit, or a
> ‘refactoring’
> >>>>>>>> commit
> >>>>>>>>>>>> plus
> >>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>> ‘fix’ commit)"
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> For clarity, I am proposing no-change in the following
> >>>>>>> areas:
> >>>>>>>>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have
> >>>> been
> >>>>>>>>>>>>>> structured to
> >>>>>>>>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to
> >>>> see
> >>>>>>>>> whether
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> refactoring or the “fix” broke something).
> >>>>>>>>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating
> >>> that
> >>>>>>>>>>>> squashing
> >>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>> preferred].
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Please comment via this email thread.
> >>>>>>>>>>>>>>>>>>> -Owen
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> >>>> klund@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I think it's already resolved Udo ;)
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by
> removing
> >>>> all
> >>>>>>>>> uses
> >>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> "this."
> >>>>>>>>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember
> >>>> that
> >>>>>>>> the
> >>>>>>>>>>>> file
> >>>>>>>>>>>>>>>>>> is a
> >>>>>>>>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new
> >>>> file
> >>>>>>>>> that I
> >>>>>>>>>>>>>>>>>>> created
> >>>>>>>>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this."
> >>> can
> >>>>>>>> easily
> >>>>>>>>>>>>>> do). If
> >>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that
> >>>>>>> dunit
> >>>>>>>>> test
> >>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>>> we effectively lose the history of that file and it
> >>> shows
> >>>>>>>> that
> >>>>>>>>> I
> >>>>>>>>>>>>>>>>>> created
> >>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>> new file.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Also for the record, I've been working on Geode since
> >>> the
> >>>>>>>>>>>> beginning
> >>>>>>>>>>>>>>>>>> and I
> >>>>>>>>>>>>>>>>>>>> was never made aware of this change in our process. I
> >>>> never
> >>>>>>>>> voted
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>> it.
> >>>>>>>>>>>>>>>>>>>> I'm not a big fan of changing various details in our
> >>>>>>> process
> >>>>>>>>> every
> >>>>>>>>>>>>>>>>>> single
> >>>>>>>>>>>>>>>>>>>> week. It's very easy to miss these discussions unless
> >>>>>>> someone
> >>>>>>>>>>>>>> points it
> >>>>>>>>>>>>>>>>>>> out
> >>>>>>>>>>>>>>>>>>>> to me.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> >>>>>>>>>>>>>> ukohlmeyer@pivotal.io>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as
> a
> >>>>>>>>> community,
> >>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>>> agreed in common practices, in two place no less...
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 1) Quoting our PR template
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> For all changes:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> >>>>>>>>> referenced
> >>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>> the commit message?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Has your PR been rebased against the latest commit
> >>>> within
> >>>>>>>> the
> >>>>>>>>>>>>>>>>>> target
> >>>>>>>>>>>>>>>>>>>>> branch (typically|develop|)?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed
> >>>>>>> commit?*
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
> >>>>>>>>> changes?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> If adding new dependencies to the code, are these
> >>>>>>>>> dependencies
> >>>>>>>>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion
> >>>>>>> underASF
> >>>>>>>>> 2.0
> >>>>>>>>>>>>>>>>>>>>> <
> http://www.apache.org/legal/resolved.html#category-a
> >>>> ?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On our PR template we call out that the initial PR
> >>>> commit
> >>>>>>>>> should
> >>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>> squashed.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 2)
> >>>>>>>>>>>>
> >>>>>>>
> >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>
> >>>>>>>>
> >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" -
> Point
> >>>> #3.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I
> >>> commend
> >>>>>>> you
> >>>>>>>>> on
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> diligence, but in reality, they should either then be
> >>>>>>> stand
> >>>>>>>>> alone
> >>>>>>>>>>>>>> PR's
> >>>>>>>>>>>>>>>>>>>>> or just extra work created for yourself.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
> >>>>>>>>>>>>>>>>>> submit/commit/merge
> >>>>>>>>>>>>>>>>>>>>> changes back into develop... Then this is another
> >>>>>>> discussion
> >>>>>>>>>>>>>> thread,
> >>>>>>>>>>>>>>>>>>>>> until then, I think we should all remind ourselves on
> >>>> our
> >>>>>>>>> agreed
> >>>>>>>>>>>>>>>>>>>>> contributions code of conduct.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> --Udo
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >>>>>>>>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
> >>>>>>> multiple
> >>>>>>>>>>>>>> commits is
> >>>>>>>>>>>>>>>>>>> ok.
> >>>>>>>>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to
> >>>>>>> develop
> >>>>>>>>>>>>>> branch,
> >>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what
> you
> >>>>>>> have
> >>>>>>>>>>>>>> mentioned
> >>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
> >>>>>>>>>>>>>>>>>>>>>> If you can see in the first screenshot comparison
> >>> that
> >>>> I
> >>>>>>>> had
> >>>>>>>>>>>>>> attached
> >>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>> the first email in this thread is what I want to
> >>> avoid.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Thank you for your feedback.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>>>>>> Naba
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> >>>>>>>> klund@apache.org>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
> >>>>>>> intend
> >>>>>>>>> to
> >>>>>>>>>>>>>> rebase
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit
> >>>> stands
> >>>>>>>>> alone
> >>>>>>>>>>>> as
> >>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file
> renames
> >>>> and
> >>>>>>>>>>>>>> refactoring
> >>>>>>>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>>>>>>>> behavior changes into different commits seems very
> >>>>>>>> valuable
> >>>>>>>>> to
> >>>>>>>>>>>>>> me,
> >>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>> I've
> >>>>>>>>>>>>>>>>>>>>>>> had trouble getting people to review PRs without
> >>> this
> >>>>>>>>>>>> separation
> >>>>>>>>>>>>>>>>>> (but
> >>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some
> >>> PRs
> >>>>>>> have
> >>>>>>>>>>>>>> multiple
> >>>>>>>>>>>>>>>>>>>>> commits
> >>>>>>>>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b)
> some
> >>>> PRs
> >>>>>>>>> that
> >>>>>>>>>>>>>> should
> >>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>> merged with squash are not (by accident most
> >>> likely).
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
> >>>>>>> multiple
> >>>>>>>>>>>>>> commits.
> >>>>>>>>>>>>>>>>>> So
> >>>>>>>>>>>>>>>>>>>>> I'll
> >>>>>>>>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent
> >>> commits
> >>>>>>> to
> >>>>>>>>>>>> develop
> >>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing
> >>> rebase
> >>>>>>> or
> >>>>>>>>> merge
> >>>>>>>>>>>>>>>>>>> commits
> >>>>>>>>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce
> >>>> this
> >>>>>>>> or
> >>>>>>>>>>>>>> prevent
> >>>>>>>>>>>>>>>>>>> (b)
> >>>>>>>>>>>>>>>>>>>>>>> above.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >>>>>>>>>>>>>>>>>>> amurmann@pivotal.io>
> >>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
> >>>>>>> necessarily
> >>>>>>>> at
> >>>>>>>>>>>>>> odds.
> >>>>>>>>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard),
> >>>> then
> >>>>>>>> make
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> easy
> >>>>>>>>>>>>>>>>>>>>>>>>> change."
> >>>>>>>>>>>>>>>>>>>>>>>> -Kent Beck
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably
> split
> >>>>>>> into
> >>>>>>>>> two
> >>>>>>>>>>>>>>>>>> commits.
> >>>>>>>>>>>>>>>>>>>>> One
> >>>>>>>>>>>>>>>>>>>>>>>> refactor commit and a separate commit that
> >>> introduces
> >>>>>>> the
> >>>>>>>>>>>> actual
> >>>>>>>>>>>>>>>>>>>>> change.
> >>>>>>>>>>>>>>>>>>>>>>>> They should be individually revertible and might
> be
> >>>>>>>> easier
> >>>>>>>>>>>>>>>>>> understood
> >>>>>>>>>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code
> >>>> base
> >>>>>>>>> where
> >>>>>>>>>>>>>>>>>> someone
> >>>>>>>>>>>>>>>>>>>>>>> did a
> >>>>>>>>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in
> >>> one
> >>>>>>>>> parameter
> >>>>>>>>>>>>>>>>>>> changing
> >>>>>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>>> order to get the desired functionality change. If
> >>>> that
> >>>>>>>> was
> >>>>>>>>> in
> >>>>>>>>>>>>>> one
> >>>>>>>>>>>>>>>>>>>>> commit,
> >>>>>>>>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If
> split
> >>>>>>> out,
> >>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>> beautiful
> >>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>> crystal clear.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms
> of
> >>>>>>> JIRA
> >>>>>>>>>>>> ticket
> >>>>>>>>>>>>>>>>>>>>>>> references.
> >>>>>>>>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with
> >>> the
> >>>>>>>> ticket
> >>>>>>>>>>>>>> number,
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create
> >>> a
> >>>>>>>>> separate
> >>>>>>>>>>>>>>>>>>>>> refactoring
> >>>>>>>>>>>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it
> >>> too?
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> >>>>>>>>> nnag@pivotal.io>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things
> >>>> start
> >>>>>>>>>>>> failing
> >>>>>>>>>>>>>> ...
> >>>>>>>>>>>>>>>>>>>>>>> helps
> >>>>>>>>>>>>>>>>>>>>>>>> us
> >>>>>>>>>>>>>>>>>>>>>>>>> it revert and build faster.
> >>>>>>>>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to
> >>>> previous
> >>>>>>>>>>>> versions
> >>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>>>>>>>>>>> And keeping the git history clean with no
> >>>> unnecessary
> >>>>>>>>> “merge
> >>>>>>>>>>>>>>>>>>> commits”.
> >>>>>>>>>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>>>>>>>>> Naba
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> >>>>>>>>> klund@apache.org>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1
> >>>> commit
> >>>>>>>> in
> >>>>>>>>> a
> >>>>>>>>>>>> PR
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>> keep
> >>>>>>>>>>>>>>>>>>>>>>>>> them
> >>>>>>>>>>>>>>>>>>>>>>>>>> separate when they merge to develop
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> >>>>>>>>>>>> nnag@pivotal.io>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead
> >>> of
> >>>>>>>> using
> >>>>>>>>>>>>>> merge.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect
> >>> operations
> >>>>>>>> when a
> >>>>>>>>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is
> >>> introduced.
> >>>>>>> We
> >>>>>>>>> can
> >>>>>>>>>>>>>>>>>> automate
> >>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>> go
> >>>>>>>>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits
> >>>> like
> >>>>>>>>>>>> "spotless
> >>>>>>>>>>>>>>>>>> fix"
> >>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits
> >>> in
> >>>>>>> the
> >>>>>>>>>>>> merged
> >>>>>>>>>>>>>>>>>>>>>>> branch.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us
> >>> to
> >>>>>>> know
> >>>>>>>>> who
> >>>>>>>>>>>>>>>>>> worked
> >>>>>>>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>>> it,
> >>>>>>>>>>>>>>>>>>>>>>>>>>> what is the history)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * explanation line 1
> >>>>>>> *
> >>>>>>>>>>>>>>>>>> explanation
> >>>>>>>>>>>>>>>>>>>>>>>> line
> >>>>>>>>>>>>>>>>>>>>>>>>> 2*
> >>>>>>>>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request
> to
> >>>>>>> help
> >>>>>>>>> out
> >>>>>>>>>>>>>> your
> >>>>>>>>>>>>>>>>>>>>>>> fellow
> >>>>>>>>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka
> /
> >>>>>>> Spark
> >>>>>>>>>>>> where
> >>>>>>>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch
> HEAD
> >>>>>>> [see
> >>>>>>>>>>>>>>>>>> attachment]
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Naba.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>> Ju@N
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Cheers
> >>>>>>>
> >>>>>>> Jinmei
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >
>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Mark Hanson <mh...@pivotal.io>.
This change to disable all but squash-merge would be really easy to revert. How about we try it for a while and see? If people decide it is really limiting them, we can change it back. Let’s do it for 1 month and see how it goes. Does that sound reasonable?
Thanks,
Mark
> On Dec 30, 2019, at 5:25 PM, Owen Nichols <on...@pivotal.io> wrote:
>
> Given that we adopted <https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E> and still wish to continue <https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E> having branch protection rules to ensure every commit landing in develop has passed the required PR checks, it seems like that decision alone mandates that we disable all merge mechanisms other than squash-and-merge.
>
> Allowing merge commits or rebase merges bypasses branch protection for all commits other than the final one in the merge or rebase set. Given that we decided <https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E> that bypassing PR checks should never be allowed, keeping this loophole open seems untenable.
>
> This is not just hypothetical — this loophole is causing real problems. We now have commits on develop that don’t compile. For example:
> git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
> ./gradlew devBuild
> ...spotlessJava FAILED
> We implemented branch protections to make this impossible, right?
>
> We can very easily close this loophole by disabling all but the Squash&Merge button for PRs. This will not make more work for any developer. If you want to get multiple commits onto develop, simply submit each as a separate PR — that is the only way to assure that required PR checks have passed for each.
>
> On the other hand, if we as a Geode community feel strongly that bypassing branch protection via merge commits and rebase commits is important to allow, why not also allow arbitrary overrides (or get rid of branch protection entirely)?
>
> -Owen
>
>> On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io> wrote:
>>
>> Just FWIW, the situation described of having multiple commits in a single
>> PR with separate associated JIRA tickets is still kind of problematic. It
>> could well be the case that the commits are interdependent, thus when
>> bisecting etc it's still not possible to revert the fix for a single
>> bug/feature/whatever atomically. It's all good, though, I'm satisfied no
>> one's forcing me to adopt practice I'm opposed to. Apologies for getting
>> my feathers a little ruffled, or if I ruffled anyone else's in return.
>>
>> Thanks,
>>
>> Blake
>>
>>
>> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>
>>> Hi Dan,
>>>
>>> When we do squash merge all the commit messages are preserved and also the
>>> co-authored tag works when we do squash merge.
>>> So the authorship and history are preserved.
>>>
>>> In my own personal experience and reverts and pinpointing regression
>>> failures are tough when the commits are spread out. Also, reverts are
>>> easier when it is just one commit while we are bisecting failures.
>>>
>>>
>>> Regards
>>> Naba
>>>
>>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io> wrote:
>>>
>>>> I'll change to -0.
>>>>
>>>> I think merge commits are a nice way to record history in some cases, and
>>>> can also be a way to avoid messy conflicts that come with rebase. Merge
>>>> commits also preserve authorship of commits (compared to squash-merge),
>>>> which I think is valuable as an open source community that is trying to
>>>> keep track of outside contributions.
>>>>
>>>> That said, if the rest of y'all feel it will help to disable the button,
>>> I
>>>> won't stand in the way.
>>>>
>>>> -Dan
>>>>
>>>> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
>>> wrote:
>>>>
>>>>> Whether we are talking about the geode/ repository or the geode-native/
>>>>> repository we are all one GEODE community.
>>>>>
>>>>> The idea of a native client team may matter in some contexts but in
>>> this
>>>>> space we are all GEODE contributors.
>>>>>
>>>>> Adopting a common approach across our repos will make it easier for new
>>>>> contributors to engage, learn our norms, and join our efforts.
>>>>>
>>>>> $0.02,
>>>>> Anthony
>>>>>
>>>>>
>>>>>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
>>> wrote:
>>>>>>
>>>>>> Is this a policy the native client team must abide by, as well? It
>>>>> varies
>>>>>> slightly with what we've been doing, and all other things being
>>> equal I
>>>>> see
>>>>>> no reason for us to change that. If I am to have any measure of
>>>> control
>>>>>> over the nc repository, I will definitely enforce a 1:1
>>> correspondence
>>>>>> between commits to develop and JIRA tickets. IMO, if your
>>> refactoring
>>>>> in a
>>>>>> PR is sufficiently large or complex that it's difficult to tease it
>>> out
>>>>>> from the bug you're fixing or feature you're implementing, it merits
>>>> its
>>>>>> own JIRA ticket and a separate PR. If your "actual" fix then becomes
>>>>>> dependent on the refactored code, that's a price I'm willing to pay
>>> to
>>>>> keep
>>>>>> history clean.
>>>>>>
>>>>>> On the other hand, I see no real value in squashing to a single
>>> commit
>>>>>> prior to submitting a PR, since your view of the changes on GitHub is
>>>>>> essentially the same either way. We haven't enforced this on the nc
>>>>> repo,
>>>>>> and I'd prefer to keep it that way.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Blake
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
>>>> wrote:
>>>>>>
>>>>>>> Merge commit is the new contributor's default setting. When we are
>>>>> merging
>>>>>>> new contributor's PR, since we are so used to THINKING
>>>>> "squash-and-merge"
>>>>>>> is the default, we forgot to check what the button really says when
>>> we
>>>>> are
>>>>>>> merging other people's PR.
>>>>>>>
>>>>>>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
>>>>> eburghardt@pivotal.io>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'm a proponent of using squash-and-merge, and once a person has
>>>> chosen
>>>>>>>> this option once it comes up by default afterwards...
>>>>>>>>
>>>>>>>> Owen, I don't think you have consensus to put forth this PR, there
>>>> are
>>>>>>> -1s
>>>>>>>> above... (early voting)
>>>>>>>>
>>>>>>>> maybe we'll be better off socializing the norm of squash-and-merge
>>>> and
>>>>>>>> gaining a natural consensus that way...
>>>>>>>>
>>>>>>>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <onichols@pivotal.io
>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> The proposed action manifests as a commit to the Geode git
>>>> repository,
>>>>>>> so
>>>>>>>>> a PR is an acceptable vehicle for voting in this case.
>>>>>>>>>
>>>>>>>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
>>>>>>> bschuchardt@pivotal.io>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
>>>>>>> thread
>>>>>>>>> and a request to "vote" using a PR. This all seems out of order
>>> to
>>>>> me.
>>>>>>>>> Our votes are supposed to be on the email list, aren't they? and I
>>>>>>>> haven't
>>>>>>>>> seen a VOTE request.
>>>>>>>>>>
>>>>>>>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
>>> onichols@pivotal.io
>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Based on the feedback so far, I will amend the proposal to drop
>>>>>>> item
>>>>>>>>> 2).
>>>>>>>>>>>> Therefore, the current ability to create merge commits using
>>>>>>>>> command-line
>>>>>>>>>>>> git will remain available.
>>>>>>>>>>>>
>>>>>>>>>>>> The proposal as amended is now:
>>>>>>>>>>>>> Change GitHub settings to make "Squash and merge" the default
>>>>>>>>>>>>> (by removing “Create a merge commit” option).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Update the PR template to change the text "Is your initial
>>>>>>>>> contribution
>>>>>>>>>>>>> a single, squashed commit” to “Is your initial contribution
>>>>>>> squashed
>>>>>>>>> for
>>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
>>> commit
>>>>>>>> plus a
>>>>>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>>>>
>>>>>>>>>>>> As Naba suggested, we can try it, and if we don’t like it, it’s
>>>>>>>> simple
>>>>>>>>> to
>>>>>>>>>>>> revert.
>>>>>>>>>>>>
>>>>>>>>>>>> I’ve create a PR for the proposed change here:
>>>>>>>>>>>> https://github.com/apache/geode/pull/4513
>>>>>>>>>>>>
>>>>>>>>>>>> Please use the PR to vote for against this proposal. It will
>>> not
>>>>>>> be
>>>>>>>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
>>>>>>> time)
>>>>>>>>>>>>
>>>>>>>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
>>> onichols@pivotal.io>
>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Bruce, this proposal will not waste a single second of
>>> your
>>>>>>>>> time. It
>>>>>>>>>>>>>> just prevents people from accidentally pressing a button that
>>>> we
>>>>>>>> have
>>>>>>>>>>>>>> already agreed should never be pressed, but because we never
>>>>>>>>> configured
>>>>>>>>>>>> our
>>>>>>>>>>>>>> GitHub to match our stated policy, is currently the default.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, it will save a lot of time and frustration for
>>> anyone
>>>>>>>>> needing
>>>>>>>>>>>> to
>>>>>>>>>>>>>> bisect failures, revert, or cherry-pick changes, which has
>>>> merit
>>>>>>>>> even if
>>>>>>>>>>>>>> you personally never do any of those three things.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please start a separate thread if you would like to revisit
>>> the
>>>>>>>>>>>> community
>>>>>>>>>>>>>> decision to require passing PR checks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
>>>>>>>>> bschuchardt@pivotal.io>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> I agree with Jake. I would go further by saying that I see
>>>> very
>>>>>>>>> little
>>>>>>>>>>>>>> merit in this proposal. I think we're getting more and more
>>>>>>>>>>>> bureaucratic
>>>>>>>>>>>>>> in our process and that it stifles productivity. I was
>>>> recently
>>>>>>>>> forced
>>>>>>>>>>>> to
>>>>>>>>>>>>>> spend three days fixing tests in which I had changed an
>>> import
>>>>>>>>> statement
>>>>>>>>>>>>>> before they would pass stress testing. I'm glad the tests
>>> now
>>>>>>> pass
>>>>>>>>>>>>>> reliably but I was very frustrated by the process.
>>>>>>>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>>>>>>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to
>>>>>>> flat
>>>>>>>>> out
>>>>>>>>>>>>>> prevent things that should be self policing is annoying. This
>>>> PR
>>>>>>>>> review
>>>>>>>>>>>>>> lock we have had already cost us valuable time waiting for PR
>>>>>>>>> pipelines
>>>>>>>>>>>> to
>>>>>>>>>>>>>> pass that have no relevance to the commit, like CI work: I’d
>>>> hat
>>>>>>> to
>>>>>>>>> see
>>>>>>>>>>>> yet
>>>>>>>>>>>>>> another process enforced that Kees us from getting work done
>>>> when
>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>> -Jake
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <dsmith@pivotal.io
>>>>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -1 to (1) and (2).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think merge commits are appropriate in certain
>>>>>>> circumstances,
>>>>>>>>> so I
>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>> think we should make a blanket restriction. In fact I
>>> think
>>>>>>> our
>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>> process involves some merges.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think setting standards on what is reasonable to be an
>>>>>>>>> individual
>>>>>>>>>>>>>> commit
>>>>>>>>>>>>>>>>> will do a lot more to clean up our history than blocking
>>>>>>> merges.
>>>>>>>>> We'd
>>>>>>>>>>>>>>>>> rather not see commits like "Spotless Apply" in the
>>> history,
>>>>>>> but
>>>>>>>>> if
>>>>>>>>>>>>>>>>> reasonably separate and well written commits come in as
>>> part
>>>>>>> of
>>>>>>>> a
>>>>>>>>>>>>>> merge, I
>>>>>>>>>>>>>>>>> think that's fine.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Dan
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
>>>>>>> jiliao@pivotal.io
>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
>>>>>>>> onichols@pivotal.io
>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> I’d like to advance this topic from an informal
>>>>>>>>> request/discussion
>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>>>>>>> discussion of a concrete proposal.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> To recap, it sounds like there is general agreement that
>>>>>>>> commit
>>>>>>>>>>>>>> history
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> develop should be linear (no merge commits), and that
>>> the
>>>>>>>>> biggest
>>>>>>>>>>>>>>>>>> obstacle
>>>>>>>>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a
>>>>>>> merge
>>>>>>>>>>>> commit
>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I propose the following changes:
>>>>>>>>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to
>>> create
>>>> a
>>>>>>>>> merge
>>>>>>>>>>>>>> commit.
>>>>>>>>>>>>>>>>>>> This will make Squash & Merge the default.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2) Change GitHub settings to require linear history on
>>>>>>>> develop.
>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>> prevents merge commits via command-line (not
>>> recommended,
>>>>>>> but
>>>>>>>>> wiki
>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>>> has instructions for merging PRs this way).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 3) Update the PR template to change the text "Is your
>>>>>>> initial
>>>>>>>>>>>>>>>>>> contribution
>>>>>>>>>>>>>>>>>>> a single, squashed commit” to “Is your initial
>>>> contribution
>>>>>>>>>>>> squashed
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
>>>>>>>> commit
>>>>>>>>>>>> plus
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> For clarity, I am proposing no-change in the following
>>>>>>> areas:
>>>>>>>>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have
>>>> been
>>>>>>>>>>>>>> structured to
>>>>>>>>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to
>>>> see
>>>>>>>>> whether
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> refactoring or the “fix” broke something).
>>>>>>>>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating
>>> that
>>>>>>>>>>>> squashing
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> preferred].
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please comment via this email thread.
>>>>>>>>>>>>>>>>>>> -Owen
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
>>>> klund@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think it's already resolved Udo ;)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing
>>>> all
>>>>>>>>> uses
>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> "this."
>>>>>>>>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember
>>>> that
>>>>>>>> the
>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new
>>>> file
>>>>>>>>> that I
>>>>>>>>>>>>>>>>>>> created
>>>>>>>>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this."
>>> can
>>>>>>>> easily
>>>>>>>>>>>>>> do). If
>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that
>>>>>>> dunit
>>>>>>>>> test
>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>> we effectively lose the history of that file and it
>>> shows
>>>>>>>> that
>>>>>>>>> I
>>>>>>>>>>>>>>>>>> created
>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> new file.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Also for the record, I've been working on Geode since
>>> the
>>>>>>>>>>>> beginning
>>>>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>>>>>>> was never made aware of this change in our process. I
>>>> never
>>>>>>>>> voted
>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>> I'm not a big fan of changing various details in our
>>>>>>> process
>>>>>>>>> every
>>>>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>>>>>>> week. It's very easy to miss these discussions unless
>>>>>>> someone
>>>>>>>>>>>>>> points it
>>>>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>>>>>> to me.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>>>>>>>>>>>>>> ukohlmeyer@pivotal.io>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
>>>>>>>>> community,
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>> agreed in common practices, in two place no less...
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 1) Quoting our PR template
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> For all changes:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
>>>>>>>>> referenced
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> the commit message?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Has your PR been rebased against the latest commit
>>>> within
>>>>>>>> the
>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>>>>> branch (typically|develop|)?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed
>>>>>>> commit?*
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
>>>>>>>>> changes?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If adding new dependencies to the code, are these
>>>>>>>>> dependencies
>>>>>>>>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion
>>>>>>> underASF
>>>>>>>>> 2.0
>>>>>>>>>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a
>>>> ?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On our PR template we call out that the initial PR
>>>> commit
>>>>>>>>> should
>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>> squashed.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2)
>>>>>>>>>>>>
>>>>>>>
>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>
>>>>>>>>
>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point
>>>> #3.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I
>>> commend
>>>>>>> you
>>>>>>>>> on
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> diligence, but in reality, they should either then be
>>>>>>> stand
>>>>>>>>> alone
>>>>>>>>>>>>>> PR's
>>>>>>>>>>>>>>>>>>>>> or just extra work created for yourself.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
>>>>>>>>>>>>>>>>>> submit/commit/merge
>>>>>>>>>>>>>>>>>>>>> changes back into develop... Then this is another
>>>>>>> discussion
>>>>>>>>>>>>>> thread,
>>>>>>>>>>>>>>>>>>>>> until then, I think we should all remind ourselves on
>>>> our
>>>>>>>>> agreed
>>>>>>>>>>>>>>>>>>>>> contributions code of conduct.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --Udo
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
>>>>>>> multiple
>>>>>>>>>>>>>> commits is
>>>>>>>>>>>>>>>>>>> ok.
>>>>>>>>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to
>>>>>>> develop
>>>>>>>>>>>>>> branch,
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you
>>>>>>> have
>>>>>>>>>>>>>> mentioned
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>>>>>>>>>>>>>>>> If you can see in the first screenshot comparison
>>> that
>>>> I
>>>>>>>> had
>>>>>>>>>>>>>> attached
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>> the first email in this thread is what I want to
>>> avoid.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thank you for your feedback.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
>>>>>>>> klund@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
>>>>>>> intend
>>>>>>>>> to
>>>>>>>>>>>>>> rebase
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit
>>>> stands
>>>>>>>>> alone
>>>>>>>>>>>> as
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames
>>>> and
>>>>>>>>>>>>>> refactoring
>>>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>>>>> behavior changes into different commits seems very
>>>>>>>> valuable
>>>>>>>>> to
>>>>>>>>>>>>>> me,
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>>>>> had trouble getting people to review PRs without
>>> this
>>>>>>>>>>>> separation
>>>>>>>>>>>>>>>>>> (but
>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some
>>> PRs
>>>>>>> have
>>>>>>>>>>>>>> multiple
>>>>>>>>>>>>>>>>>>>>> commits
>>>>>>>>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some
>>>> PRs
>>>>>>>>> that
>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>> merged with squash are not (by accident most
>>> likely).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
>>>>>>> multiple
>>>>>>>>>>>>>> commits.
>>>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent
>>> commits
>>>>>>> to
>>>>>>>>>>>> develop
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing
>>> rebase
>>>>>>> or
>>>>>>>>> merge
>>>>>>>>>>>>>>>>>>> commits
>>>>>>>>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce
>>>> this
>>>>>>>> or
>>>>>>>>>>>>>> prevent
>>>>>>>>>>>>>>>>>>> (b)
>>>>>>>>>>>>>>>>>>>>>>> above.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>>>>>>>>>>>>>>>> amurmann@pivotal.io>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
>>>>>>> necessarily
>>>>>>>> at
>>>>>>>>>>>>>> odds.
>>>>>>>>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard),
>>>> then
>>>>>>>> make
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> easy
>>>>>>>>>>>>>>>>>>>>>>>>> change."
>>>>>>>>>>>>>>>>>>>>>>>> -Kent Beck
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split
>>>>>>> into
>>>>>>>>> two
>>>>>>>>>>>>>>>>>> commits.
>>>>>>>>>>>>>>>>>>>>> One
>>>>>>>>>>>>>>>>>>>>>>>> refactor commit and a separate commit that
>>> introduces
>>>>>>> the
>>>>>>>>>>>> actual
>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>>> They should be individually revertible and might be
>>>>>>>> easier
>>>>>>>>>>>>>>>>>> understood
>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code
>>>> base
>>>>>>>>> where
>>>>>>>>>>>>>>>>>> someone
>>>>>>>>>>>>>>>>>>>>>>> did a
>>>>>>>>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in
>>> one
>>>>>>>>> parameter
>>>>>>>>>>>>>>>>>>> changing
>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>> order to get the desired functionality change. If
>>>> that
>>>>>>>> was
>>>>>>>>> in
>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>>>>>>> commit,
>>>>>>>>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split
>>>>>>> out,
>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>> beautiful
>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>> crystal clear.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of
>>>>>>> JIRA
>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>>>>>> references.
>>>>>>>>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with
>>> the
>>>>>>>> ticket
>>>>>>>>>>>>>> number,
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create
>>> a
>>>>>>>>> separate
>>>>>>>>>>>>>>>>>>>>> refactoring
>>>>>>>>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it
>>> too?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
>>>>>>>>> nnag@pivotal.io>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things
>>>> start
>>>>>>>>>>>> failing
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>>> helps
>>>>>>>>>>>>>>>>>>>>>>>> us
>>>>>>>>>>>>>>>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to
>>>> previous
>>>>>>>>>>>> versions
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>>>>>>> And keeping the git history clean with no
>>>> unnecessary
>>>>>>>>> “merge
>>>>>>>>>>>>>>>>>>> commits”.
>>>>>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
>>>>>>>>> klund@apache.org>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1
>>>> commit
>>>>>>>> in
>>>>>>>>> a
>>>>>>>>>>>> PR
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>> keep
>>>>>>>>>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>>>>>>>>>>>> nnag@pivotal.io>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead
>>> of
>>>>>>>> using
>>>>>>>>>>>>>> merge.
>>>>>>>>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect
>>> operations
>>>>>>>> when a
>>>>>>>>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is
>>> introduced.
>>>>>>> We
>>>>>>>>> can
>>>>>>>>>>>>>>>>>> automate
>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits
>>>> like
>>>>>>>>>>>> "spotless
>>>>>>>>>>>>>>>>>> fix"
>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits
>>> in
>>>>>>> the
>>>>>>>>>>>> merged
>>>>>>>>>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us
>>> to
>>>>>>> know
>>>>>>>>> who
>>>>>>>>>>>>>>>>>> worked
>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>> it,
>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>>>>>>>>>>>>>>>> * explanation line 1
>>>>>>> *
>>>>>>>>>>>>>>>>>> explanation
>>>>>>>>>>>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>>>>>>>>>>>> 2*
>>>>>>>>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to
>>>>>>> help
>>>>>>>>> out
>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>>>>>> fellow
>>>>>>>>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka /
>>>>>>> Spark
>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD
>>>>>>> [see
>>>>>>>>>>>>>>>>>> attachment]
>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>> Ju@N
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers
>>>>>>>
>>>>>>> Jinmei
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
Given that we adopted <https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E> and still wish to continue <https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E> having branch protection rules to ensure every commit landing in develop has passed the required PR checks, it seems like that decision alone mandates that we disable all merge mechanisms other than squash-and-merge.
Allowing merge commits or rebase merges bypasses branch protection for all commits other than the final one in the merge or rebase set. Given that we decided <https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E> that bypassing PR checks should never be allowed, keeping this loophole open seems untenable.
This is not just hypothetical — this loophole is causing real problems. We now have commits on develop that don’t compile. For example:
git checkout 19eee7821322a1301f16bdcd31fd3b8c872a41b6
./gradlew devBuild
...spotlessJava FAILED
We implemented branch protections to make this impossible, right?
We can very easily close this loophole by disabling all but the Squash&Merge button for PRs. This will not make more work for any developer. If you want to get multiple commits onto develop, simply submit each as a separate PR — that is the only way to assure that required PR checks have passed for each.
On the other hand, if we as a Geode community feel strongly that bypassing branch protection via merge commits and rebase commits is important to allow, why not also allow arbitrary overrides (or get rid of branch protection entirely)?
-Owen
> On Dec 20, 2019, at 12:31 PM, Blake Bender <bb...@pivotal.io> wrote:
>
> Just FWIW, the situation described of having multiple commits in a single
> PR with separate associated JIRA tickets is still kind of problematic. It
> could well be the case that the commits are interdependent, thus when
> bisecting etc it's still not possible to revert the fix for a single
> bug/feature/whatever atomically. It's all good, though, I'm satisfied no
> one's forcing me to adopt practice I'm opposed to. Apologies for getting
> my feathers a little ruffled, or if I ruffled anyone else's in return.
>
> Thanks,
>
> Blake
>
>
> On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
>
>> Hi Dan,
>>
>> When we do squash merge all the commit messages are preserved and also the
>> co-authored tag works when we do squash merge.
>> So the authorship and history are preserved.
>>
>> In my own personal experience and reverts and pinpointing regression
>> failures are tough when the commits are spread out. Also, reverts are
>> easier when it is just one commit while we are bisecting failures.
>>
>>
>> Regards
>> Naba
>>
>> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io> wrote:
>>
>>> I'll change to -0.
>>>
>>> I think merge commits are a nice way to record history in some cases, and
>>> can also be a way to avoid messy conflicts that come with rebase. Merge
>>> commits also preserve authorship of commits (compared to squash-merge),
>>> which I think is valuable as an open source community that is trying to
>>> keep track of outside contributions.
>>>
>>> That said, if the rest of y'all feel it will help to disable the button,
>> I
>>> won't stand in the way.
>>>
>>> -Dan
>>>
>>> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
>> wrote:
>>>
>>>> Whether we are talking about the geode/ repository or the geode-native/
>>>> repository we are all one GEODE community.
>>>>
>>>> The idea of a native client team may matter in some contexts but in
>> this
>>>> space we are all GEODE contributors.
>>>>
>>>> Adopting a common approach across our repos will make it easier for new
>>>> contributors to engage, learn our norms, and join our efforts.
>>>>
>>>> $0.02,
>>>> Anthony
>>>>
>>>>
>>>>> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
>> wrote:
>>>>>
>>>>> Is this a policy the native client team must abide by, as well? It
>>>> varies
>>>>> slightly with what we've been doing, and all other things being
>> equal I
>>>> see
>>>>> no reason for us to change that. If I am to have any measure of
>>> control
>>>>> over the nc repository, I will definitely enforce a 1:1
>> correspondence
>>>>> between commits to develop and JIRA tickets. IMO, if your
>> refactoring
>>>> in a
>>>>> PR is sufficiently large or complex that it's difficult to tease it
>> out
>>>>> from the bug you're fixing or feature you're implementing, it merits
>>> its
>>>>> own JIRA ticket and a separate PR. If your "actual" fix then becomes
>>>>> dependent on the refactored code, that's a price I'm willing to pay
>> to
>>>> keep
>>>>> history clean.
>>>>>
>>>>> On the other hand, I see no real value in squashing to a single
>> commit
>>>>> prior to submitting a PR, since your view of the changes on GitHub is
>>>>> essentially the same either way. We haven't enforced this on the nc
>>>> repo,
>>>>> and I'd prefer to keep it that way.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Blake
>>>>>
>>>>>
>>>>> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
>>> wrote:
>>>>>
>>>>>> Merge commit is the new contributor's default setting. When we are
>>>> merging
>>>>>> new contributor's PR, since we are so used to THINKING
>>>> "squash-and-merge"
>>>>>> is the default, we forgot to check what the button really says when
>> we
>>>> are
>>>>>> merging other people's PR.
>>>>>>
>>>>>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
>>>> eburghardt@pivotal.io>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm a proponent of using squash-and-merge, and once a person has
>>> chosen
>>>>>>> this option once it comes up by default afterwards...
>>>>>>>
>>>>>>> Owen, I don't think you have consensus to put forth this PR, there
>>> are
>>>>>> -1s
>>>>>>> above... (early voting)
>>>>>>>
>>>>>>> maybe we'll be better off socializing the norm of squash-and-merge
>>> and
>>>>>>> gaining a natural consensus that way...
>>>>>>>
>>>>>>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <onichols@pivotal.io
>>>
>>>>>> wrote:
>>>>>>>
>>>>>>>> The proposed action manifests as a commit to the Geode git
>>> repository,
>>>>>> so
>>>>>>>> a PR is an acceptable vehicle for voting in this case.
>>>>>>>>
>>>>>>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
>>>>>> bschuchardt@pivotal.io>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
>>>>>> thread
>>>>>>>> and a request to "vote" using a PR. This all seems out of order
>> to
>>>> me.
>>>>>>>> Our votes are supposed to be on the email list, aren't they? and I
>>>>>>> haven't
>>>>>>>> seen a VOTE request.
>>>>>>>>>
>>>>>>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
>> onichols@pivotal.io
>>>>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Based on the feedback so far, I will amend the proposal to drop
>>>>>> item
>>>>>>>> 2).
>>>>>>>>>>> Therefore, the current ability to create merge commits using
>>>>>>>> command-line
>>>>>>>>>>> git will remain available.
>>>>>>>>>>>
>>>>>>>>>>> The proposal as amended is now:
>>>>>>>>>>>> Change GitHub settings to make "Squash and merge" the default
>>>>>>>>>>>> (by removing “Create a merge commit” option).
>>>>>>>>>>>>
>>>>>>>>>>>> Update the PR template to change the text "Is your initial
>>>>>>>> contribution
>>>>>>>>>>>> a single, squashed commit” to “Is your initial contribution
>>>>>> squashed
>>>>>>>> for
>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
>> commit
>>>>>>> plus a
>>>>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>>>
>>>>>>>>>>> As Naba suggested, we can try it, and if we don’t like it, it’s
>>>>>>> simple
>>>>>>>> to
>>>>>>>>>>> revert.
>>>>>>>>>>>
>>>>>>>>>>> I’ve create a PR for the proposed change here:
>>>>>>>>>>> https://github.com/apache/geode/pull/4513
>>>>>>>>>>>
>>>>>>>>>>> Please use the PR to vote for against this proposal. It will
>> not
>>>>>> be
>>>>>>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
>>>>>> time)
>>>>>>>>>>>
>>>>>>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> +1
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
>> onichols@pivotal.io>
>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Bruce, this proposal will not waste a single second of
>> your
>>>>>>>> time. It
>>>>>>>>>>>>> just prevents people from accidentally pressing a button that
>>> we
>>>>>>> have
>>>>>>>>>>>>> already agreed should never be pressed, but because we never
>>>>>>>> configured
>>>>>>>>>>> our
>>>>>>>>>>>>> GitHub to match our stated policy, is currently the default.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, it will save a lot of time and frustration for
>> anyone
>>>>>>>> needing
>>>>>>>>>>> to
>>>>>>>>>>>>> bisect failures, revert, or cherry-pick changes, which has
>>> merit
>>>>>>>> even if
>>>>>>>>>>>>> you personally never do any of those three things.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please start a separate thread if you would like to revisit
>> the
>>>>>>>>>>> community
>>>>>>>>>>>>> decision to require passing PR checks.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
>>>>>>>> bschuchardt@pivotal.io>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> I agree with Jake. I would go further by saying that I see
>>> very
>>>>>>>> little
>>>>>>>>>>>>> merit in this proposal. I think we're getting more and more
>>>>>>>>>>> bureaucratic
>>>>>>>>>>>>> in our process and that it stifles productivity. I was
>>> recently
>>>>>>>> forced
>>>>>>>>>>> to
>>>>>>>>>>>>> spend three days fixing tests in which I had changed an
>> import
>>>>>>>> statement
>>>>>>>>>>>>> before they would pass stress testing. I'm glad the tests
>> now
>>>>>> pass
>>>>>>>>>>>>> reliably but I was very frustrated by the process.
>>>>>>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>>>>>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to
>>>>>> flat
>>>>>>>> out
>>>>>>>>>>>>> prevent things that should be self policing is annoying. This
>>> PR
>>>>>>>> review
>>>>>>>>>>>>> lock we have had already cost us valuable time waiting for PR
>>>>>>>> pipelines
>>>>>>>>>>> to
>>>>>>>>>>>>> pass that have no relevance to the commit, like CI work: I’d
>>> hat
>>>>>> to
>>>>>>>> see
>>>>>>>>>>> yet
>>>>>>>>>>>>> another process enforced that Kees us from getting work done
>>> when
>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>> -Jake
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <dsmith@pivotal.io
>>>
>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -1 to (1) and (2).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think merge commits are appropriate in certain
>>>>>> circumstances,
>>>>>>>> so I
>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>> think we should make a blanket restriction. In fact I
>> think
>>>>>> our
>>>>>>>>>>> release
>>>>>>>>>>>>>>>> process involves some merges.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think setting standards on what is reasonable to be an
>>>>>>>> individual
>>>>>>>>>>>>> commit
>>>>>>>>>>>>>>>> will do a lot more to clean up our history than blocking
>>>>>> merges.
>>>>>>>> We'd
>>>>>>>>>>>>>>>> rather not see commits like "Spotless Apply" in the
>> history,
>>>>>> but
>>>>>>>> if
>>>>>>>>>>>>>>>> reasonably separate and well written commits come in as
>> part
>>>>>> of
>>>>>>> a
>>>>>>>>>>>>> merge, I
>>>>>>>>>>>>>>>> think that's fine.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Dan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
>>>>>> jiliao@pivotal.io
>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
>>>>>>> onichols@pivotal.io
>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> I’d like to advance this topic from an informal
>>>>>>>> request/discussion
>>>>>>>>>>>>> to a
>>>>>>>>>>>>>>>>>> discussion of a concrete proposal.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> To recap, it sounds like there is general agreement that
>>>>>>> commit
>>>>>>>>>>>>> history
>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> develop should be linear (no merge commits), and that
>> the
>>>>>>>> biggest
>>>>>>>>>>>>>>>>> obstacle
>>>>>>>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a
>>>>>> merge
>>>>>>>>>>> commit
>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I propose the following changes:
>>>>>>>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to
>> create
>>> a
>>>>>>>> merge
>>>>>>>>>>>>> commit.
>>>>>>>>>>>>>>>>>> This will make Squash & Merge the default.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2) Change GitHub settings to require linear history on
>>>>>>> develop.
>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>> prevents merge commits via command-line (not
>> recommended,
>>>>>> but
>>>>>>>> wiki
>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>> has instructions for merging PRs this way).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 3) Update the PR template to change the text "Is your
>>>>>> initial
>>>>>>>>>>>>>>>>> contribution
>>>>>>>>>>>>>>>>>> a single, squashed commit” to “Is your initial
>>> contribution
>>>>>>>>>>> squashed
>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
>>>>>>> commit
>>>>>>>>>>> plus
>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For clarity, I am proposing no-change in the following
>>>>>> areas:
>>>>>>>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have
>>> been
>>>>>>>>>>>>> structured to
>>>>>>>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to
>>> see
>>>>>>>> whether
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> refactoring or the “fix” broke something).
>>>>>>>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating
>> that
>>>>>>>>>>> squashing
>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> preferred].
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please comment via this email thread.
>>>>>>>>>>>>>>>>>> -Owen
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
>>> klund@apache.org>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I think it's already resolved Udo ;)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing
>>> all
>>>>>>>> uses
>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> "this."
>>>>>>>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember
>>> that
>>>>>>> the
>>>>>>>>>>> file
>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new
>>> file
>>>>>>>> that I
>>>>>>>>>>>>>>>>>> created
>>>>>>>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this."
>> can
>>>>>>> easily
>>>>>>>>>>>>> do). If
>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that
>>>>>> dunit
>>>>>>>> test
>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>> we effectively lose the history of that file and it
>> shows
>>>>>>> that
>>>>>>>> I
>>>>>>>>>>>>>>>>> created
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>> new file.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Also for the record, I've been working on Geode since
>> the
>>>>>>>>>>> beginning
>>>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>>>>>> was never made aware of this change in our process. I
>>> never
>>>>>>>> voted
>>>>>>>>>>> on
>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>> I'm not a big fan of changing various details in our
>>>>>> process
>>>>>>>> every
>>>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>>>>>> week. It's very easy to miss these discussions unless
>>>>>> someone
>>>>>>>>>>>>> points it
>>>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>>>>> to me.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>>>>>>>>>>>>> ukohlmeyer@pivotal.io>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
>>>>>>>> community,
>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>> agreed in common practices, in two place no less...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1) Quoting our PR template
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For all changes:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
>>>>>>>> referenced
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> the commit message?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Has your PR been rebased against the latest commit
>>> within
>>>>>>> the
>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>>>> branch (typically|develop|)?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed
>>>>>> commit?*
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
>>>>>>>> changes?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If adding new dependencies to the code, are these
>>>>>>>> dependencies
>>>>>>>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion
>>>>>> underASF
>>>>>>>> 2.0
>>>>>>>>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a
>>> ?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On our PR template we call out that the initial PR
>>> commit
>>>>>>>> should
>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> squashed.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2)
>>>>>>>>>>>
>>>>>>
>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>
>>>>>>>
>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point
>>> #3.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I
>> commend
>>>>>> you
>>>>>>>> on
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> diligence, but in reality, they should either then be
>>>>>> stand
>>>>>>>> alone
>>>>>>>>>>>>> PR's
>>>>>>>>>>>>>>>>>>>> or just extra work created for yourself.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
>>>>>>>>>>>>>>>>> submit/commit/merge
>>>>>>>>>>>>>>>>>>>> changes back into develop... Then this is another
>>>>>> discussion
>>>>>>>>>>>>> thread,
>>>>>>>>>>>>>>>>>>>> until then, I think we should all remind ourselves on
>>> our
>>>>>>>> agreed
>>>>>>>>>>>>>>>>>>>> contributions code of conduct.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --Udo
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
>>>>>> multiple
>>>>>>>>>>>>> commits is
>>>>>>>>>>>>>>>>>> ok.
>>>>>>>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to
>>>>>> develop
>>>>>>>>>>>>> branch,
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you
>>>>>> have
>>>>>>>>>>>>> mentioned
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>>>>>>>>>>>>>>> If you can see in the first screenshot comparison
>> that
>>> I
>>>>>>> had
>>>>>>>>>>>>> attached
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> the first email in this thread is what I want to
>> avoid.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thank you for your feedback.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
>>>>>>> klund@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
>>>>>> intend
>>>>>>>> to
>>>>>>>>>>>>> rebase
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit
>>> stands
>>>>>>>> alone
>>>>>>>>>>> as
>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames
>>> and
>>>>>>>>>>>>> refactoring
>>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>>>> behavior changes into different commits seems very
>>>>>>> valuable
>>>>>>>> to
>>>>>>>>>>>>> me,
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>>>> had trouble getting people to review PRs without
>> this
>>>>>>>>>>> separation
>>>>>>>>>>>>>>>>> (but
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some
>> PRs
>>>>>> have
>>>>>>>>>>>>> multiple
>>>>>>>>>>>>>>>>>>>> commits
>>>>>>>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some
>>> PRs
>>>>>>>> that
>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> merged with squash are not (by accident most
>> likely).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
>>>>>> multiple
>>>>>>>>>>>>> commits.
>>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent
>> commits
>>>>>> to
>>>>>>>>>>> develop
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing
>> rebase
>>>>>> or
>>>>>>>> merge
>>>>>>>>>>>>>>>>>> commits
>>>>>>>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce
>>> this
>>>>>>> or
>>>>>>>>>>>>> prevent
>>>>>>>>>>>>>>>>>> (b)
>>>>>>>>>>>>>>>>>>>>>> above.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>>>>>>>>>>>>>>> amurmann@pivotal.io>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
>>>>>> necessarily
>>>>>>> at
>>>>>>>>>>>>> odds.
>>>>>>>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard),
>>> then
>>>>>>> make
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> easy
>>>>>>>>>>>>>>>>>>>>>>>> change."
>>>>>>>>>>>>>>>>>>>>>>> -Kent Beck
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split
>>>>>> into
>>>>>>>> two
>>>>>>>>>>>>>>>>> commits.
>>>>>>>>>>>>>>>>>>>> One
>>>>>>>>>>>>>>>>>>>>>>> refactor commit and a separate commit that
>> introduces
>>>>>> the
>>>>>>>>>>> actual
>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>> They should be individually revertible and might be
>>>>>>> easier
>>>>>>>>>>>>>>>>> understood
>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code
>>> base
>>>>>>>> where
>>>>>>>>>>>>>>>>> someone
>>>>>>>>>>>>>>>>>>>>>> did a
>>>>>>>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in
>> one
>>>>>>>> parameter
>>>>>>>>>>>>>>>>>> changing
>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>> order to get the desired functionality change. If
>>> that
>>>>>>> was
>>>>>>>> in
>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>>>>>> commit,
>>>>>>>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split
>>>>>> out,
>>>>>>>> it's
>>>>>>>>>>>>>>>>>> beautiful
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>> crystal clear.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of
>>>>>> JIRA
>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>>>>> references.
>>>>>>>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with
>> the
>>>>>>> ticket
>>>>>>>>>>>>> number,
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create
>> a
>>>>>>>> separate
>>>>>>>>>>>>>>>>>>>> refactoring
>>>>>>>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it
>> too?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
>>>>>>>> nnag@pivotal.io>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things
>>> start
>>>>>>>>>>> failing
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>> helps
>>>>>>>>>>>>>>>>>>>>>>> us
>>>>>>>>>>>>>>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to
>>> previous
>>>>>>>>>>> versions
>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>>>>>> And keeping the git history clean with no
>>> unnecessary
>>>>>>>> “merge
>>>>>>>>>>>>>>>>>> commits”.
>>>>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
>>>>>>>> klund@apache.org>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1
>>> commit
>>>>>>> in
>>>>>>>> a
>>>>>>>>>>> PR
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> keep
>>>>>>>>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>>>>>>>>>>> nnag@pivotal.io>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead
>> of
>>>>>>> using
>>>>>>>>>>>>> merge.
>>>>>>>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect
>> operations
>>>>>>> when a
>>>>>>>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is
>> introduced.
>>>>>> We
>>>>>>>> can
>>>>>>>>>>>>>>>>> automate
>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits
>>> like
>>>>>>>>>>> "spotless
>>>>>>>>>>>>>>>>> fix"
>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits
>> in
>>>>>> the
>>>>>>>>>>> merged
>>>>>>>>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us
>> to
>>>>>> know
>>>>>>>> who
>>>>>>>>>>>>>>>>> worked
>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>> it,
>>>>>>>>>>>>>>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>>>>>>>>>>>>>>> * explanation line 1
>>>>>> *
>>>>>>>>>>>>>>>>> explanation
>>>>>>>>>>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>>>>>>>>>>> 2*
>>>>>>>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to
>>>>>> help
>>>>>>>> out
>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>>>>> fellow
>>>>>>>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka /
>>>>>> Spark
>>>>>>>>>>> where
>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD
>>>>>> [see
>>>>>>>>>>>>>>>>> attachment]
>>>>>>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>> Ju@N
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers
>>>>>>
>>>>>> Jinmei
>>>>>>
>>>>
>>>>
>>>
>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Blake Bender <bb...@pivotal.io>.
Just FWIW, the situation described of having multiple commits in a single
PR with separate associated JIRA tickets is still kind of problematic. It
could well be the case that the commits are interdependent, thus when
bisecting etc it's still not possible to revert the fix for a single
bug/feature/whatever atomically. It's all good, though, I'm satisfied no
one's forcing me to adopt practice I'm opposed to. Apologies for getting
my feathers a little ruffled, or if I ruffled anyone else's in return.
Thanks,
Blake
On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag <nn...@pivotal.io> wrote:
> Hi Dan,
>
> When we do squash merge all the commit messages are preserved and also the
> co-authored tag works when we do squash merge.
> So the authorship and history are preserved.
>
> In my own personal experience and reverts and pinpointing regression
> failures are tough when the commits are spread out. Also, reverts are
> easier when it is just one commit while we are bisecting failures.
>
>
> Regards
> Naba
>
> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io> wrote:
>
> > I'll change to -0.
> >
> > I think merge commits are a nice way to record history in some cases, and
> > can also be a way to avoid messy conflicts that come with rebase. Merge
> > commits also preserve authorship of commits (compared to squash-merge),
> > which I think is valuable as an open source community that is trying to
> > keep track of outside contributions.
> >
> > That said, if the rest of y'all feel it will help to disable the button,
> I
> > won't stand in the way.
> >
> > -Dan
> >
> > On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io>
> wrote:
> >
> > > Whether we are talking about the geode/ repository or the geode-native/
> > > repository we are all one GEODE community.
> > >
> > > The idea of a native client team may matter in some contexts but in
> this
> > > space we are all GEODE contributors.
> > >
> > > Adopting a common approach across our repos will make it easier for new
> > > contributors to engage, learn our norms, and join our efforts.
> > >
> > > $0.02,
> > > Anthony
> > >
> > >
> > > > On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io>
> wrote:
> > > >
> > > > Is this a policy the native client team must abide by, as well? It
> > > varies
> > > > slightly with what we've been doing, and all other things being
> equal I
> > > see
> > > > no reason for us to change that. If I am to have any measure of
> > control
> > > > over the nc repository, I will definitely enforce a 1:1
> correspondence
> > > > between commits to develop and JIRA tickets. IMO, if your
> refactoring
> > > in a
> > > > PR is sufficiently large or complex that it's difficult to tease it
> out
> > > > from the bug you're fixing or feature you're implementing, it merits
> > its
> > > > own JIRA ticket and a separate PR. If your "actual" fix then becomes
> > > > dependent on the refactored code, that's a price I'm willing to pay
> to
> > > keep
> > > > history clean.
> > > >
> > > > On the other hand, I see no real value in squashing to a single
> commit
> > > > prior to submitting a PR, since your view of the changes on GitHub is
> > > > essentially the same either way. We haven't enforced this on the nc
> > > repo,
> > > > and I'd prefer to keep it that way.
> > > >
> > > > Thanks,
> > > >
> > > > Blake
> > > >
> > > >
> > > > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
> > wrote:
> > > >
> > > >> Merge commit is the new contributor's default setting. When we are
> > > merging
> > > >> new contributor's PR, since we are so used to THINKING
> > > "squash-and-merge"
> > > >> is the default, we forgot to check what the button really says when
> we
> > > are
> > > >> merging other people's PR.
> > > >>
> > > >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > > eburghardt@pivotal.io>
> > > >> wrote:
> > > >>
> > > >>> I'm a proponent of using squash-and-merge, and once a person has
> > chosen
> > > >>> this option once it comes up by default afterwards...
> > > >>>
> > > >>> Owen, I don't think you have consensus to put forth this PR, there
> > are
> > > >> -1s
> > > >>> above... (early voting)
> > > >>>
> > > >>> maybe we'll be better off socializing the norm of squash-and-merge
> > and
> > > >>> gaining a natural consensus that way...
> > > >>>
> > > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <onichols@pivotal.io
> >
> > > >> wrote:
> > > >>>
> > > >>>> The proposed action manifests as a commit to the Geode git
> > repository,
> > > >> so
> > > >>>> a PR is an acceptable vehicle for voting in this case.
> > > >>>>
> > > >>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > > >> bschuchardt@pivotal.io>
> > > >>>> wrote:
> > > >>>>>
> > > >>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> > > >> thread
> > > >>>> and a request to "vote" using a PR. This all seems out of order
> to
> > > me.
> > > >>>> Our votes are supposed to be on the email list, aren't they? and I
> > > >>> haven't
> > > >>>> seen a VOTE request.
> > > >>>>>
> > > >>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > > >>>>>> +1
> > > >>>>>>
> > > >>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <
> onichols@pivotal.io
> > >
> > > >>>> wrote:
> > > >>>>>>
> > > >>>>>>> Based on the feedback so far, I will amend the proposal to drop
> > > >> item
> > > >>>> 2).
> > > >>>>>>> Therefore, the current ability to create merge commits using
> > > >>>> command-line
> > > >>>>>>> git will remain available.
> > > >>>>>>>
> > > >>>>>>> The proposal as amended is now:
> > > >>>>>>>> Change GitHub settings to make "Squash and merge" the default
> > > >>>>>>>> (by removing “Create a merge commit” option).
> > > >>>>>>>>
> > > >>>>>>>> Update the PR template to change the text "Is your initial
> > > >>>> contribution
> > > >>>>>>>> a single, squashed commit” to “Is your initial contribution
> > > >> squashed
> > > >>>> for
> > > >>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> commit
> > > >>> plus a
> > > >>>>>>>> ‘fix’ commit)"
> > > >>>>>>>
> > > >>>>>>> As Naba suggested, we can try it, and if we don’t like it, it’s
> > > >>> simple
> > > >>>> to
> > > >>>>>>> revert.
> > > >>>>>>>
> > > >>>>>>> I’ve create a PR for the proposed change here:
> > > >>>>>>> https://github.com/apache/geode/pull/4513
> > > >>>>>>>
> > > >>>>>>> Please use the PR to vote for against this proposal. It will
> not
> > > >> be
> > > >>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
> > > >> time)
> > > >>>>>>>
> > > >>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com>
> wrote:
> > > >>>>>>>>
> > > >>>>>>>> +1
> > > >>>>>>>>
> > > >>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <
> onichols@pivotal.io>
> > > >>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Hi Bruce, this proposal will not waste a single second of
> your
> > > >>>> time. It
> > > >>>>>>>>> just prevents people from accidentally pressing a button that
> > we
> > > >>> have
> > > >>>>>>>>> already agreed should never be pressed, but because we never
> > > >>>> configured
> > > >>>>>>> our
> > > >>>>>>>>> GitHub to match our stated policy, is currently the default.
> > > >>>>>>>>>
> > > >>>>>>>>> However, it will save a lot of time and frustration for
> anyone
> > > >>>> needing
> > > >>>>>>> to
> > > >>>>>>>>> bisect failures, revert, or cherry-pick changes, which has
> > merit
> > > >>>> even if
> > > >>>>>>>>> you personally never do any of those three things.
> > > >>>>>>>>>
> > > >>>>>>>>> Please start a separate thread if you would like to revisit
> the
> > > >>>>>>> community
> > > >>>>>>>>> decision to require passing PR checks.
> > > >>>>>>>>>
> > > >>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > > >>>> bschuchardt@pivotal.io>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>> I agree with Jake. I would go further by saying that I see
> > very
> > > >>>> little
> > > >>>>>>>>> merit in this proposal. I think we're getting more and more
> > > >>>>>>> bureaucratic
> > > >>>>>>>>> in our process and that it stifles productivity. I was
> > recently
> > > >>>> forced
> > > >>>>>>> to
> > > >>>>>>>>> spend three days fixing tests in which I had changed an
> import
> > > >>>> statement
> > > >>>>>>>>> before they would pass stress testing. I'm glad the tests
> now
> > > >> pass
> > > >>>>>>>>> reliably but I was very frustrated by the process.
> > > >>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > > >>>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to
> > > >> flat
> > > >>>> out
> > > >>>>>>>>> prevent things that should be self policing is annoying. This
> > PR
> > > >>>> review
> > > >>>>>>>>> lock we have had already cost us valuable time waiting for PR
> > > >>>> pipelines
> > > >>>>>>> to
> > > >>>>>>>>> pass that have no relevance to the commit, like CI work: I’d
> > hat
> > > >> to
> > > >>>> see
> > > >>>>>>> yet
> > > >>>>>>>>> another process enforced that Kees us from getting work done
> > when
> > > >>>>>>> necessary.
> > > >>>>>>>>>>> -Jake
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <dsmith@pivotal.io
> >
> > > >>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> -1 to (1) and (2).
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I think merge commits are appropriate in certain
> > > >> circumstances,
> > > >>>> so I
> > > >>>>>>>>> don't
> > > >>>>>>>>>>>> think we should make a blanket restriction. In fact I
> think
> > > >> our
> > > >>>>>>> release
> > > >>>>>>>>>>>> process involves some merges.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I think setting standards on what is reasonable to be an
> > > >>>> individual
> > > >>>>>>>>> commit
> > > >>>>>>>>>>>> will do a lot more to clean up our history than blocking
> > > >> merges.
> > > >>>> We'd
> > > >>>>>>>>>>>> rather not see commits like "Spotless Apply" in the
> history,
> > > >> but
> > > >>>> if
> > > >>>>>>>>>>>> reasonably separate and well written commits come in as
> part
> > > >> of
> > > >>> a
> > > >>>>>>>>> merge, I
> > > >>>>>>>>>>>> think that's fine.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> -Dan
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> > > >> jiliao@pivotal.io
> > > >>>>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>> +1
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> > > >>> onichols@pivotal.io
> > > >>>>>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>>> I’d like to advance this topic from an informal
> > > >>>> request/discussion
> > > >>>>>>>>> to a
> > > >>>>>>>>>>>>>> discussion of a concrete proposal.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> To recap, it sounds like there is general agreement that
> > > >>> commit
> > > >>>>>>>>> history
> > > >>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>> develop should be linear (no merge commits), and that
> the
> > > >>>> biggest
> > > >>>>>>>>>>>>> obstacle
> > > >>>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a
> > > >> merge
> > > >>>>>>> commit
> > > >>>>>>>>> by
> > > >>>>>>>>>>>>>> default.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I propose the following changes:
> > > >>>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to
> create
> > a
> > > >>>> merge
> > > >>>>>>>>> commit.
> > > >>>>>>>>>>>>>> This will make Squash & Merge the default.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 2) Change GitHub settings to require linear history on
> > > >>> develop.
> > > >>>>>>> This
> > > >>>>>>>>>>>>>> prevents merge commits via command-line (not
> recommended,
> > > >> but
> > > >>>> wiki
> > > >>>>>>>>> still
> > > >>>>>>>>>>>>>> has instructions for merging PRs this way).
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 3) Update the PR template to change the text "Is your
> > > >> initial
> > > >>>>>>>>>>>>> contribution
> > > >>>>>>>>>>>>>> a single, squashed commit” to “Is your initial
> > contribution
> > > >>>>>>> squashed
> > > >>>>>>>>> for
> > > >>>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> > > >>> commit
> > > >>>>>>> plus
> > > >>>>>>>>> a
> > > >>>>>>>>>>>>>> ‘fix’ commit)"
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> For clarity, I am proposing no-change in the following
> > > >> areas:
> > > >>>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have
> > been
> > > >>>>>>>>> structured to
> > > >>>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to
> > see
> > > >>>> whether
> > > >>>>>>>>> the
> > > >>>>>>>>>>>>>> refactoring or the “fix” broke something).
> > > >>>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating
> that
> > > >>>>>>> squashing
> > > >>>>>>>>> is
> > > >>>>>>>>>>>>>> preferred].
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Please comment via this email thread.
> > > >>>>>>>>>>>>>> -Owen
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> > klund@apache.org>
> > > >>>> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> I think it's already resolved Udo ;)
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing
> > all
> > > >>>> uses
> > > >>>>>>> of
> > > >>>>>>>>>>>>>> "this."
> > > >>>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember
> > that
> > > >>> the
> > > >>>>>>> file
> > > >>>>>>>>>>>>> is a
> > > >>>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new
> > file
> > > >>>> that I
> > > >>>>>>>>>>>>>> created
> > > >>>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this."
> can
> > > >>> easily
> > > >>>>>>>>> do). If
> > > >>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that
> > > >> dunit
> > > >>>> test
> > > >>>>>>> --
> > > >>>>>>>>>>>>> then
> > > >>>>>>>>>>>>>>> we effectively lose the history of that file and it
> shows
> > > >>> that
> > > >>>> I
> > > >>>>>>>>>>>>> created
> > > >>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>> new file.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Also for the record, I've been working on Geode since
> the
> > > >>>>>>> beginning
> > > >>>>>>>>>>>>> and I
> > > >>>>>>>>>>>>>>> was never made aware of this change in our process. I
> > never
> > > >>>> voted
> > > >>>>>>> on
> > > >>>>>>>>>>>>> it.
> > > >>>>>>>>>>>>>>> I'm not a big fan of changing various details in our
> > > >> process
> > > >>>> every
> > > >>>>>>>>>>>>> single
> > > >>>>>>>>>>>>>>> week. It's very easy to miss these discussions unless
> > > >> someone
> > > >>>>>>>>> points it
> > > >>>>>>>>>>>>>> out
> > > >>>>>>>>>>>>>>> to me.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > > >>>>>>>>> ukohlmeyer@pivotal.io>
> > > >>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
> > > >>>> community,
> > > >>>>>>>>> have
> > > >>>>>>>>>>>>>>>> agreed in common practices, in two place no less...
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 1) Quoting our PR template
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> For all changes:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> > > >>>> referenced
> > > >>>>>>>>> in
> > > >>>>>>>>>>>>>>>> the commit message?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Has your PR been rebased against the latest commit
> > within
> > > >>> the
> > > >>>>>>>>>>>>> target
> > > >>>>>>>>>>>>>>>> branch (typically|develop|)?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed
> > > >> commit?*
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
> > > >>>> changes?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> If adding new dependencies to the code, are these
> > > >>>> dependencies
> > > >>>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion
> > > >> underASF
> > > >>>> 2.0
> > > >>>>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a
> >?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On our PR template we call out that the initial PR
> > commit
> > > >>>> should
> > > >>>>>>> be
> > > >>>>>>>>>>>>>>>> squashed.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 2)
> > > >>>>>>>
> > > >>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > >>>>>>>>>>>>>>>> <
> > > >>>>>>>>>
> > > >>>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > >>>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point
> > #3.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I
> commend
> > > >> you
> > > >>>> on
> > > >>>>>>> the
> > > >>>>>>>>>>>>>>>> diligence, but in reality, they should either then be
> > > >> stand
> > > >>>> alone
> > > >>>>>>>>> PR's
> > > >>>>>>>>>>>>>>>> or just extra work created for yourself.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
> > > >>>>>>>>>>>>> submit/commit/merge
> > > >>>>>>>>>>>>>>>> changes back into develop... Then this is another
> > > >> discussion
> > > >>>>>>>>> thread,
> > > >>>>>>>>>>>>>>>> until then, I think we should all remind ourselves on
> > our
> > > >>>> agreed
> > > >>>>>>>>>>>>>>>> contributions code of conduct.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> --Udo
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > > >>>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
> > > >> multiple
> > > >>>>>>>>> commits is
> > > >>>>>>>>>>>>>> ok.
> > > >>>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to
> > > >> develop
> > > >>>>>>>>> branch,
> > > >>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you
> > > >> have
> > > >>>>>>>>> mentioned
> > > >>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
> > > >>>>>>>>>>>>>>>>> If you can see in the first screenshot comparison
> that
> > I
> > > >>> had
> > > >>>>>>>>> attached
> > > >>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>> the first email in this thread is what I want to
> avoid.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Thank you for your feedback.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Regards
> > > >>>>>>>>>>>>>>>>> Naba
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> > > >>> klund@apache.org>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
> > > >> intend
> > > >>>> to
> > > >>>>>>>>> rebase
> > > >>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit
> > stands
> > > >>>> alone
> > > >>>>>>> as
> > > >>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames
> > and
> > > >>>>>>>>> refactoring
> > > >>>>>>>>>>>>>>>> from
> > > >>>>>>>>>>>>>>>>>> behavior changes into different commits seems very
> > > >>> valuable
> > > >>>> to
> > > >>>>>>>>> me,
> > > >>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>> I've
> > > >>>>>>>>>>>>>>>>>> had trouble getting people to review PRs without
> this
> > > >>>>>>> separation
> > > >>>>>>>>>>>>> (but
> > > >>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some
> PRs
> > > >> have
> > > >>>>>>>>> multiple
> > > >>>>>>>>>>>>>>>> commits
> > > >>>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some
> > PRs
> > > >>>> that
> > > >>>>>>>>> should
> > > >>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>> merged with squash are not (by accident most
> likely).
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
> > > >> multiple
> > > >>>>>>>>> commits.
> > > >>>>>>>>>>>>> So
> > > >>>>>>>>>>>>>>>> I'll
> > > >>>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent
> commits
> > > >> to
> > > >>>>>>> develop
> > > >>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing
> rebase
> > > >> or
> > > >>>> merge
> > > >>>>>>>>>>>>>> commits
> > > >>>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce
> > this
> > > >>> or
> > > >>>>>>>>> prevent
> > > >>>>>>>>>>>>>> (b)
> > > >>>>>>>>>>>>>>>>>> above.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > > >>>>>>>>>>>>>> amurmann@pivotal.io>
> > > >>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
> > > >> necessarily
> > > >>> at
> > > >>>>>>>>> odds.
> > > >>>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard),
> > then
> > > >>> make
> > > >>>>>>> the
> > > >>>>>>>>>>>>> easy
> > > >>>>>>>>>>>>>>>>>>>> change."
> > > >>>>>>>>>>>>>>>>>>> -Kent Beck
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split
> > > >> into
> > > >>>> two
> > > >>>>>>>>>>>>> commits.
> > > >>>>>>>>>>>>>>>> One
> > > >>>>>>>>>>>>>>>>>>> refactor commit and a separate commit that
> introduces
> > > >> the
> > > >>>>>>> actual
> > > >>>>>>>>>>>>>>>> change.
> > > >>>>>>>>>>>>>>>>>>> They should be individually revertible and might be
> > > >>> easier
> > > >>>>>>>>>>>>> understood
> > > >>>>>>>>>>>>>>>> if
> > > >>>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code
> > base
> > > >>>> where
> > > >>>>>>>>>>>>> someone
> > > >>>>>>>>>>>>>>>>>> did a
> > > >>>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in
> one
> > > >>>> parameter
> > > >>>>>>>>>>>>>> changing
> > > >>>>>>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>>>> order to get the desired functionality change. If
> > that
> > > >>> was
> > > >>>> in
> > > >>>>>>>>> one
> > > >>>>>>>>>>>>>>>> commit,
> > > >>>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split
> > > >> out,
> > > >>>> it's
> > > >>>>>>>>>>>>>> beautiful
> > > >>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>> crystal clear.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of
> > > >> JIRA
> > > >>>>>>> ticket
> > > >>>>>>>>>>>>>>>>>> references.
> > > >>>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with
> the
> > > >>> ticket
> > > >>>>>>>>> number,
> > > >>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create
> a
> > > >>>> separate
> > > >>>>>>>>>>>>>>>> refactoring
> > > >>>>>>>>>>>>>>>>>>> ticket.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it
> too?
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> > > >>>> nnag@pivotal.io>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things
> > start
> > > >>>>>>> failing
> > > >>>>>>>>> ...
> > > >>>>>>>>>>>>>>>>>> helps
> > > >>>>>>>>>>>>>>>>>>> us
> > > >>>>>>>>>>>>>>>>>>>> it revert and build faster.
> > > >>>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to
> > previous
> > > >>>>>>> versions
> > > >>>>>>>>> .
> > > >>>>>>>>>>>>>>>>>>>> And keeping the git history clean with no
> > unnecessary
> > > >>>> “merge
> > > >>>>>>>>>>>>>> commits”.
> > > >>>>>>>>>>>>>>>>>>>> Regards
> > > >>>>>>>>>>>>>>>>>>>> Naba
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> > > >>>> klund@apache.org>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1
> > commit
> > > >>> in
> > > >>>> a
> > > >>>>>>> PR
> > > >>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>> keep
> > > >>>>>>>>>>>>>>>>>>>> them
> > > >>>>>>>>>>>>>>>>>>>>> separate when they merge to develop
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> > > >>>>>>> nnag@pivotal.io>
> > > >>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead
> of
> > > >>> using
> > > >>>>>>>>> merge.
> > > >>>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect
> operations
> > > >>> when a
> > > >>>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is
> introduced.
> > > >> We
> > > >>>> can
> > > >>>>>>>>>>>>> automate
> > > >>>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>> go
> > > >>>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits
> > like
> > > >>>>>>> "spotless
> > > >>>>>>>>>>>>> fix"
> > > >>>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits
> in
> > > >> the
> > > >>>>>>> merged
> > > >>>>>>>>>>>>>>>>>> branch.
> > > >>>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us
> to
> > > >> know
> > > >>>> who
> > > >>>>>>>>>>>>> worked
> > > >>>>>>>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>>>>>>>> it,
> > > >>>>>>>>>>>>>>>>>>>>>> what is the history)
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> > > >>>>>>>>>>>>>>>>>>>>>> * explanation line 1
> > > >> *
> > > >>>>>>>>>>>>> explanation
> > > >>>>>>>>>>>>>>>>>>> line
> > > >>>>>>>>>>>>>>>>>>>> 2*
> > > >>>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to
> > > >> help
> > > >>>> out
> > > >>>>>>>>> your
> > > >>>>>>>>>>>>>>>>>> fellow
> > > >>>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka /
> > > >> Spark
> > > >>>>>>> where
> > > >>>>>>>>>>>>> they
> > > >>>>>>>>>>>>>>>>>>> have
> > > >>>>>>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD
> > > >> [see
> > > >>>>>>>>>>>>> attachment]
> > > >>>>>>>>>>>>>>>>>>>>>> Regards
> > > >>>>>>>>>>>>>>>>>>>>>> Naba.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>> Ju@N
> > > >>>>>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Cheers
> > > >>
> > > >> Jinmei
> > > >>
> > >
> > >
> >
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Nabarun Nag <nn...@pivotal.io>.
Hi Dan,
When we do squash merge all the commit messages are preserved and also the
co-authored tag works when we do squash merge.
So the authorship and history are preserved.
In my own personal experience and reverts and pinpointing regression
failures are tough when the commits are spread out. Also, reverts are
easier when it is just one commit while we are bisecting failures.
Regards
Naba
On Fri, Dec 20, 2019 at 12:07 PM Dan Smith <ds...@pivotal.io> wrote:
> I'll change to -0.
>
> I think merge commits are a nice way to record history in some cases, and
> can also be a way to avoid messy conflicts that come with rebase. Merge
> commits also preserve authorship of commits (compared to squash-merge),
> which I think is valuable as an open source community that is trying to
> keep track of outside contributions.
>
> That said, if the rest of y'all feel it will help to disable the button, I
> won't stand in the way.
>
> -Dan
>
> On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io> wrote:
>
> > Whether we are talking about the geode/ repository or the geode-native/
> > repository we are all one GEODE community.
> >
> > The idea of a native client team may matter in some contexts but in this
> > space we are all GEODE contributors.
> >
> > Adopting a common approach across our repos will make it easier for new
> > contributors to engage, learn our norms, and join our efforts.
> >
> > $0.02,
> > Anthony
> >
> >
> > > On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io> wrote:
> > >
> > > Is this a policy the native client team must abide by, as well? It
> > varies
> > > slightly with what we've been doing, and all other things being equal I
> > see
> > > no reason for us to change that. If I am to have any measure of
> control
> > > over the nc repository, I will definitely enforce a 1:1 correspondence
> > > between commits to develop and JIRA tickets. IMO, if your refactoring
> > in a
> > > PR is sufficiently large or complex that it's difficult to tease it out
> > > from the bug you're fixing or feature you're implementing, it merits
> its
> > > own JIRA ticket and a separate PR. If your "actual" fix then becomes
> > > dependent on the refactored code, that's a price I'm willing to pay to
> > keep
> > > history clean.
> > >
> > > On the other hand, I see no real value in squashing to a single commit
> > > prior to submitting a PR, since your view of the changes on GitHub is
> > > essentially the same either way. We haven't enforced this on the nc
> > repo,
> > > and I'd prefer to keep it that way.
> > >
> > > Thanks,
> > >
> > > Blake
> > >
> > >
> > > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io>
> wrote:
> > >
> > >> Merge commit is the new contributor's default setting. When we are
> > merging
> > >> new contributor's PR, since we are so used to THINKING
> > "squash-and-merge"
> > >> is the default, we forgot to check what the button really says when we
> > are
> > >> merging other people's PR.
> > >>
> > >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > eburghardt@pivotal.io>
> > >> wrote:
> > >>
> > >>> I'm a proponent of using squash-and-merge, and once a person has
> chosen
> > >>> this option once it comes up by default afterwards...
> > >>>
> > >>> Owen, I don't think you have consensus to put forth this PR, there
> are
> > >> -1s
> > >>> above... (early voting)
> > >>>
> > >>> maybe we'll be better off socializing the norm of squash-and-merge
> and
> > >>> gaining a natural consensus that way...
> > >>>
> > >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <on...@pivotal.io>
> > >> wrote:
> > >>>
> > >>>> The proposed action manifests as a commit to the Geode git
> repository,
> > >> so
> > >>>> a PR is an acceptable vehicle for voting in this case.
> > >>>>
> > >>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> > >> bschuchardt@pivotal.io>
> > >>>> wrote:
> > >>>>>
> > >>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> > >> thread
> > >>>> and a request to "vote" using a PR. This all seems out of order to
> > me.
> > >>>> Our votes are supposed to be on the email list, aren't they? and I
> > >>> haven't
> > >>>> seen a VOTE request.
> > >>>>>
> > >>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > >>>>>> +1
> > >>>>>>
> > >>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <onichols@pivotal.io
> >
> > >>>> wrote:
> > >>>>>>
> > >>>>>>> Based on the feedback so far, I will amend the proposal to drop
> > >> item
> > >>>> 2).
> > >>>>>>> Therefore, the current ability to create merge commits using
> > >>>> command-line
> > >>>>>>> git will remain available.
> > >>>>>>>
> > >>>>>>> The proposal as amended is now:
> > >>>>>>>> Change GitHub settings to make "Squash and merge" the default
> > >>>>>>>> (by removing “Create a merge commit” option).
> > >>>>>>>>
> > >>>>>>>> Update the PR template to change the text "Is your initial
> > >>>> contribution
> > >>>>>>>> a single, squashed commit” to “Is your initial contribution
> > >> squashed
> > >>>> for
> > >>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> > >>> plus a
> > >>>>>>>> ‘fix’ commit)"
> > >>>>>>>
> > >>>>>>> As Naba suggested, we can try it, and if we don’t like it, it’s
> > >>> simple
> > >>>> to
> > >>>>>>> revert.
> > >>>>>>>
> > >>>>>>> I’ve create a PR for the proposed change here:
> > >>>>>>> https://github.com/apache/geode/pull/4513
> > >>>>>>>
> > >>>>>>> Please use the PR to vote for against this proposal. It will not
> > >> be
> > >>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
> > >> time)
> > >>>>>>>
> > >>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
> > >>>>>>>>
> > >>>>>>>> +1
> > >>>>>>>>
> > >>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io>
> > >>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Hi Bruce, this proposal will not waste a single second of your
> > >>>> time. It
> > >>>>>>>>> just prevents people from accidentally pressing a button that
> we
> > >>> have
> > >>>>>>>>> already agreed should never be pressed, but because we never
> > >>>> configured
> > >>>>>>> our
> > >>>>>>>>> GitHub to match our stated policy, is currently the default.
> > >>>>>>>>>
> > >>>>>>>>> However, it will save a lot of time and frustration for anyone
> > >>>> needing
> > >>>>>>> to
> > >>>>>>>>> bisect failures, revert, or cherry-pick changes, which has
> merit
> > >>>> even if
> > >>>>>>>>> you personally never do any of those three things.
> > >>>>>>>>>
> > >>>>>>>>> Please start a separate thread if you would like to revisit the
> > >>>>>>> community
> > >>>>>>>>> decision to require passing PR checks.
> > >>>>>>>>>
> > >>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > >>>> bschuchardt@pivotal.io>
> > >>>>>>>>> wrote:
> > >>>>>>>>>> I agree with Jake. I would go further by saying that I see
> very
> > >>>> little
> > >>>>>>>>> merit in this proposal. I think we're getting more and more
> > >>>>>>> bureaucratic
> > >>>>>>>>> in our process and that it stifles productivity. I was
> recently
> > >>>> forced
> > >>>>>>> to
> > >>>>>>>>> spend three days fixing tests in which I had changed an import
> > >>>> statement
> > >>>>>>>>> before they would pass stress testing. I'm glad the tests now
> > >> pass
> > >>>>>>>>> reliably but I was very frustrated by the process.
> > >>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > >>>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to
> > >> flat
> > >>>> out
> > >>>>>>>>> prevent things that should be self policing is annoying. This
> PR
> > >>>> review
> > >>>>>>>>> lock we have had already cost us valuable time waiting for PR
> > >>>> pipelines
> > >>>>>>> to
> > >>>>>>>>> pass that have no relevance to the commit, like CI work: I’d
> hat
> > >> to
> > >>>> see
> > >>>>>>> yet
> > >>>>>>>>> another process enforced that Kees us from getting work done
> when
> > >>>>>>> necessary.
> > >>>>>>>>>>> -Jake
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io>
> > >>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> -1 to (1) and (2).
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I think merge commits are appropriate in certain
> > >> circumstances,
> > >>>> so I
> > >>>>>>>>> don't
> > >>>>>>>>>>>> think we should make a blanket restriction. In fact I think
> > >> our
> > >>>>>>> release
> > >>>>>>>>>>>> process involves some merges.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I think setting standards on what is reasonable to be an
> > >>>> individual
> > >>>>>>>>> commit
> > >>>>>>>>>>>> will do a lot more to clean up our history than blocking
> > >> merges.
> > >>>> We'd
> > >>>>>>>>>>>> rather not see commits like "Spotless Apply" in the history,
> > >> but
> > >>>> if
> > >>>>>>>>>>>> reasonably separate and well written commits come in as part
> > >> of
> > >>> a
> > >>>>>>>>> merge, I
> > >>>>>>>>>>>> think that's fine.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> -Dan
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> > >> jiliao@pivotal.io
> > >>>>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>> +1
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> > >>> onichols@pivotal.io
> > >>>>>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>>> I’d like to advance this topic from an informal
> > >>>> request/discussion
> > >>>>>>>>> to a
> > >>>>>>>>>>>>>> discussion of a concrete proposal.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> To recap, it sounds like there is general agreement that
> > >>> commit
> > >>>>>>>>> history
> > >>>>>>>>>>>>> on
> > >>>>>>>>>>>>>> develop should be linear (no merge commits), and that the
> > >>>> biggest
> > >>>>>>>>>>>>> obstacle
> > >>>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a
> > >> merge
> > >>>>>>> commit
> > >>>>>>>>> by
> > >>>>>>>>>>>>>> default.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I propose the following changes:
> > >>>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to create
> a
> > >>>> merge
> > >>>>>>>>> commit.
> > >>>>>>>>>>>>>> This will make Squash & Merge the default.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 2) Change GitHub settings to require linear history on
> > >>> develop.
> > >>>>>>> This
> > >>>>>>>>>>>>>> prevents merge commits via command-line (not recommended,
> > >> but
> > >>>> wiki
> > >>>>>>>>> still
> > >>>>>>>>>>>>>> has instructions for merging PRs this way).
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 3) Update the PR template to change the text "Is your
> > >> initial
> > >>>>>>>>>>>>> contribution
> > >>>>>>>>>>>>>> a single, squashed commit” to “Is your initial
> contribution
> > >>>>>>> squashed
> > >>>>>>>>> for
> > >>>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> > >>> commit
> > >>>>>>> plus
> > >>>>>>>>> a
> > >>>>>>>>>>>>>> ‘fix’ commit)"
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> For clarity, I am proposing no-change in the following
> > >> areas:
> > >>>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have
> been
> > >>>>>>>>> structured to
> > >>>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to
> see
> > >>>> whether
> > >>>>>>>>> the
> > >>>>>>>>>>>>>> refactoring or the “fix” broke something).
> > >>>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
> > >>>>>>> squashing
> > >>>>>>>>> is
> > >>>>>>>>>>>>>> preferred].
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Please comment via this email thread.
> > >>>>>>>>>>>>>> -Owen
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <
> klund@apache.org>
> > >>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I think it's already resolved Udo ;)
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing
> all
> > >>>> uses
> > >>>>>>> of
> > >>>>>>>>>>>>>> "this."
> > >>>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember
> that
> > >>> the
> > >>>>>>> file
> > >>>>>>>>>>>>> is a
> > >>>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new
> file
> > >>>> that I
> > >>>>>>>>>>>>>> created
> > >>>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this." can
> > >>> easily
> > >>>>>>>>> do). If
> > >>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that
> > >> dunit
> > >>>> test
> > >>>>>>> --
> > >>>>>>>>>>>>> then
> > >>>>>>>>>>>>>>> we effectively lose the history of that file and it shows
> > >>> that
> > >>>> I
> > >>>>>>>>>>>>> created
> > >>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>> new file.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Also for the record, I've been working on Geode since the
> > >>>>>>> beginning
> > >>>>>>>>>>>>> and I
> > >>>>>>>>>>>>>>> was never made aware of this change in our process. I
> never
> > >>>> voted
> > >>>>>>> on
> > >>>>>>>>>>>>> it.
> > >>>>>>>>>>>>>>> I'm not a big fan of changing various details in our
> > >> process
> > >>>> every
> > >>>>>>>>>>>>> single
> > >>>>>>>>>>>>>>> week. It's very easy to miss these discussions unless
> > >> someone
> > >>>>>>>>> points it
> > >>>>>>>>>>>>>> out
> > >>>>>>>>>>>>>>> to me.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > >>>>>>>>> ukohlmeyer@pivotal.io>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
> > >>>> community,
> > >>>>>>>>> have
> > >>>>>>>>>>>>>>>> agreed in common practices, in two place no less...
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 1) Quoting our PR template
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> For all changes:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> > >>>> referenced
> > >>>>>>>>> in
> > >>>>>>>>>>>>>>>> the commit message?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Has your PR been rebased against the latest commit
> within
> > >>> the
> > >>>>>>>>>>>>> target
> > >>>>>>>>>>>>>>>> branch (typically|develop|)?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed
> > >> commit?*
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
> > >>>> changes?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> If adding new dependencies to the code, are these
> > >>>> dependencies
> > >>>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion
> > >> underASF
> > >>>> 2.0
> > >>>>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On our PR template we call out that the initial PR
> commit
> > >>>> should
> > >>>>>>> be
> > >>>>>>>>>>>>>>>> squashed.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 2)
> > >>>>>>>
> > >> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>>>>>>>>>>>>>> <
> > >>>>>>>>>
> > >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point
> #3.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend
> > >> you
> > >>>> on
> > >>>>>>> the
> > >>>>>>>>>>>>>>>> diligence, but in reality, they should either then be
> > >> stand
> > >>>> alone
> > >>>>>>>>> PR's
> > >>>>>>>>>>>>>>>> or just extra work created for yourself.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
> > >>>>>>>>>>>>> submit/commit/merge
> > >>>>>>>>>>>>>>>> changes back into develop... Then this is another
> > >> discussion
> > >>>>>>>>> thread,
> > >>>>>>>>>>>>>>>> until then, I think we should all remind ourselves on
> our
> > >>>> agreed
> > >>>>>>>>>>>>>>>> contributions code of conduct.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> --Udo
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > >>>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
> > >> multiple
> > >>>>>>>>> commits is
> > >>>>>>>>>>>>>> ok.
> > >>>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to
> > >> develop
> > >>>>>>>>> branch,
> > >>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you
> > >> have
> > >>>>>>>>> mentioned
> > >>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
> > >>>>>>>>>>>>>>>>> If you can see in the first screenshot comparison that
> I
> > >>> had
> > >>>>>>>>> attached
> > >>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>> the first email in this thread is what I want to avoid.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Thank you for your feedback.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>>>> Naba
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> > >>> klund@apache.org>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
> > >> intend
> > >>>> to
> > >>>>>>>>> rebase
> > >>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit
> stands
> > >>>> alone
> > >>>>>>> as
> > >>>>>>>>> is
> > >>>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames
> and
> > >>>>>>>>> refactoring
> > >>>>>>>>>>>>>>>> from
> > >>>>>>>>>>>>>>>>>> behavior changes into different commits seems very
> > >>> valuable
> > >>>> to
> > >>>>>>>>> me,
> > >>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>> I've
> > >>>>>>>>>>>>>>>>>> had trouble getting people to review PRs without this
> > >>>>>>> separation
> > >>>>>>>>>>>>> (but
> > >>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs
> > >> have
> > >>>>>>>>> multiple
> > >>>>>>>>>>>>>>>> commits
> > >>>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some
> PRs
> > >>>> that
> > >>>>>>>>> should
> > >>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>> merged with squash are not (by accident most likely).
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
> > >> multiple
> > >>>>>>>>> commits.
> > >>>>>>>>>>>>> So
> > >>>>>>>>>>>>>>>> I'll
> > >>>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent commits
> > >> to
> > >>>>>>> develop
> > >>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase
> > >> or
> > >>>> merge
> > >>>>>>>>>>>>>> commits
> > >>>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce
> this
> > >>> or
> > >>>>>>>>> prevent
> > >>>>>>>>>>>>>> (b)
> > >>>>>>>>>>>>>>>>>> above.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > >>>>>>>>>>>>>> amurmann@pivotal.io>
> > >>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
> > >> necessarily
> > >>> at
> > >>>>>>>>> odds.
> > >>>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard),
> then
> > >>> make
> > >>>>>>> the
> > >>>>>>>>>>>>> easy
> > >>>>>>>>>>>>>>>>>>>> change."
> > >>>>>>>>>>>>>>>>>>> -Kent Beck
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split
> > >> into
> > >>>> two
> > >>>>>>>>>>>>> commits.
> > >>>>>>>>>>>>>>>> One
> > >>>>>>>>>>>>>>>>>>> refactor commit and a separate commit that introduces
> > >> the
> > >>>>>>> actual
> > >>>>>>>>>>>>>>>> change.
> > >>>>>>>>>>>>>>>>>>> They should be individually revertible and might be
> > >>> easier
> > >>>>>>>>>>>>> understood
> > >>>>>>>>>>>>>>>> if
> > >>>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code
> base
> > >>>> where
> > >>>>>>>>>>>>> someone
> > >>>>>>>>>>>>>>>>>> did a
> > >>>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one
> > >>>> parameter
> > >>>>>>>>>>>>>> changing
> > >>>>>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>>> order to get the desired functionality change. If
> that
> > >>> was
> > >>>> in
> > >>>>>>>>> one
> > >>>>>>>>>>>>>>>> commit,
> > >>>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split
> > >> out,
> > >>>> it's
> > >>>>>>>>>>>>>> beautiful
> > >>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>> crystal clear.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of
> > >> JIRA
> > >>>>>>> ticket
> > >>>>>>>>>>>>>>>>>> references.
> > >>>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with the
> > >>> ticket
> > >>>>>>>>> number,
> > >>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a
> > >>>> separate
> > >>>>>>>>>>>>>>>> refactoring
> > >>>>>>>>>>>>>>>>>>> ticket.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> > >>>> nnag@pivotal.io>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things
> start
> > >>>>>>> failing
> > >>>>>>>>> ...
> > >>>>>>>>>>>>>>>>>> helps
> > >>>>>>>>>>>>>>>>>>> us
> > >>>>>>>>>>>>>>>>>>>> it revert and build faster.
> > >>>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to
> previous
> > >>>>>>> versions
> > >>>>>>>>> .
> > >>>>>>>>>>>>>>>>>>>> And keeping the git history clean with no
> unnecessary
> > >>>> “merge
> > >>>>>>>>>>>>>> commits”.
> > >>>>>>>>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>>>>>>> Naba
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> > >>>> klund@apache.org>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1
> commit
> > >>> in
> > >>>> a
> > >>>>>>> PR
> > >>>>>>>>> and
> > >>>>>>>>>>>>>>>>>> keep
> > >>>>>>>>>>>>>>>>>>>> them
> > >>>>>>>>>>>>>>>>>>>>> separate when they merge to develop
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> > >>>>>>> nnag@pivotal.io>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of
> > >>> using
> > >>>>>>>>> merge.
> > >>>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect operations
> > >>> when a
> > >>>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced.
> > >> We
> > >>>> can
> > >>>>>>>>>>>>> automate
> > >>>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>> go
> > >>>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits
> like
> > >>>>>>> "spotless
> > >>>>>>>>>>>>> fix"
> > >>>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in
> > >> the
> > >>>>>>> merged
> > >>>>>>>>>>>>>>>>>> branch.
> > >>>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to
> > >> know
> > >>>> who
> > >>>>>>>>>>>>> worked
> > >>>>>>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>>>>>> it,
> > >>>>>>>>>>>>>>>>>>>>>> what is the history)
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> > >>>>>>>>>>>>>>>>>>>>>> * explanation line 1
> > >> *
> > >>>>>>>>>>>>> explanation
> > >>>>>>>>>>>>>>>>>>> line
> > >>>>>>>>>>>>>>>>>>>> 2*
> > >>>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to
> > >> help
> > >>>> out
> > >>>>>>>>> your
> > >>>>>>>>>>>>>>>>>> fellow
> > >>>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka /
> > >> Spark
> > >>>>>>> where
> > >>>>>>>>>>>>> they
> > >>>>>>>>>>>>>>>>>>> have
> > >>>>>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD
> > >> [see
> > >>>>>>>>>>>>> attachment]
> > >>>>>>>>>>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>>>>>>>>> Naba.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>> Ju@N
> > >>>>>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Cheers
> > >>
> > >> Jinmei
> > >>
> >
> >
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Dan Smith <ds...@pivotal.io>.
I'll change to -0.
I think merge commits are a nice way to record history in some cases, and
can also be a way to avoid messy conflicts that come with rebase. Merge
commits also preserve authorship of commits (compared to squash-merge),
which I think is valuable as an open source community that is trying to
keep track of outside contributions.
That said, if the rest of y'all feel it will help to disable the button, I
won't stand in the way.
-Dan
On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker <ab...@pivotal.io> wrote:
> Whether we are talking about the geode/ repository or the geode-native/
> repository we are all one GEODE community.
>
> The idea of a native client team may matter in some contexts but in this
> space we are all GEODE contributors.
>
> Adopting a common approach across our repos will make it easier for new
> contributors to engage, learn our norms, and join our efforts.
>
> $0.02,
> Anthony
>
>
> > On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io> wrote:
> >
> > Is this a policy the native client team must abide by, as well? It
> varies
> > slightly with what we've been doing, and all other things being equal I
> see
> > no reason for us to change that. If I am to have any measure of control
> > over the nc repository, I will definitely enforce a 1:1 correspondence
> > between commits to develop and JIRA tickets. IMO, if your refactoring
> in a
> > PR is sufficiently large or complex that it's difficult to tease it out
> > from the bug you're fixing or feature you're implementing, it merits its
> > own JIRA ticket and a separate PR. If your "actual" fix then becomes
> > dependent on the refactored code, that's a price I'm willing to pay to
> keep
> > history clean.
> >
> > On the other hand, I see no real value in squashing to a single commit
> > prior to submitting a PR, since your view of the changes on GitHub is
> > essentially the same either way. We haven't enforced this on the nc
> repo,
> > and I'd prefer to keep it that way.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io> wrote:
> >
> >> Merge commit is the new contributor's default setting. When we are
> merging
> >> new contributor's PR, since we are so used to THINKING
> "squash-and-merge"
> >> is the default, we forgot to check what the button really says when we
> are
> >> merging other people's PR.
> >>
> >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> eburghardt@pivotal.io>
> >> wrote:
> >>
> >>> I'm a proponent of using squash-and-merge, and once a person has chosen
> >>> this option once it comes up by default afterwards...
> >>>
> >>> Owen, I don't think you have consensus to put forth this PR, there are
> >> -1s
> >>> above... (early voting)
> >>>
> >>> maybe we'll be better off socializing the norm of squash-and-merge and
> >>> gaining a natural consensus that way...
> >>>
> >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <on...@pivotal.io>
> >> wrote:
> >>>
> >>>> The proposed action manifests as a commit to the Geode git repository,
> >> so
> >>>> a PR is an acceptable vehicle for voting in this case.
> >>>>
> >>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> >> bschuchardt@pivotal.io>
> >>>> wrote:
> >>>>>
> >>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> >> thread
> >>>> and a request to "vote" using a PR. This all seems out of order to
> me.
> >>>> Our votes are supposed to be on the email list, aren't they? and I
> >>> haven't
> >>>> seen a VOTE request.
> >>>>>
> >>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> >>>>>> +1
> >>>>>>
> >>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io>
> >>>> wrote:
> >>>>>>
> >>>>>>> Based on the feedback so far, I will amend the proposal to drop
> >> item
> >>>> 2).
> >>>>>>> Therefore, the current ability to create merge commits using
> >>>> command-line
> >>>>>>> git will remain available.
> >>>>>>>
> >>>>>>> The proposal as amended is now:
> >>>>>>>> Change GitHub settings to make "Squash and merge" the default
> >>>>>>>> (by removing “Create a merge commit” option).
> >>>>>>>>
> >>>>>>>> Update the PR template to change the text "Is your initial
> >>>> contribution
> >>>>>>>> a single, squashed commit” to “Is your initial contribution
> >> squashed
> >>>> for
> >>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> >>> plus a
> >>>>>>>> ‘fix’ commit)"
> >>>>>>>
> >>>>>>> As Naba suggested, we can try it, and if we don’t like it, it’s
> >>> simple
> >>>> to
> >>>>>>> revert.
> >>>>>>>
> >>>>>>> I’ve create a PR for the proposed change here:
> >>>>>>> https://github.com/apache/geode/pull/4513
> >>>>>>>
> >>>>>>> Please use the PR to vote for against this proposal. It will not
> >> be
> >>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
> >> time)
> >>>>>>>
> >>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> +1
> >>>>>>>>
> >>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io>
> >>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Bruce, this proposal will not waste a single second of your
> >>>> time. It
> >>>>>>>>> just prevents people from accidentally pressing a button that we
> >>> have
> >>>>>>>>> already agreed should never be pressed, but because we never
> >>>> configured
> >>>>>>> our
> >>>>>>>>> GitHub to match our stated policy, is currently the default.
> >>>>>>>>>
> >>>>>>>>> However, it will save a lot of time and frustration for anyone
> >>>> needing
> >>>>>>> to
> >>>>>>>>> bisect failures, revert, or cherry-pick changes, which has merit
> >>>> even if
> >>>>>>>>> you personally never do any of those three things.
> >>>>>>>>>
> >>>>>>>>> Please start a separate thread if you would like to revisit the
> >>>>>>> community
> >>>>>>>>> decision to require passing PR checks.
> >>>>>>>>>
> >>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> >>>> bschuchardt@pivotal.io>
> >>>>>>>>> wrote:
> >>>>>>>>>> I agree with Jake. I would go further by saying that I see very
> >>>> little
> >>>>>>>>> merit in this proposal. I think we're getting more and more
> >>>>>>> bureaucratic
> >>>>>>>>> in our process and that it stifles productivity. I was recently
> >>>> forced
> >>>>>>> to
> >>>>>>>>> spend three days fixing tests in which I had changed an import
> >>>> statement
> >>>>>>>>> before they would pass stress testing. I'm glad the tests now
> >> pass
> >>>>>>>>> reliably but I was very frustrated by the process.
> >>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> >>>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to
> >> flat
> >>>> out
> >>>>>>>>> prevent things that should be self policing is annoying. This PR
> >>>> review
> >>>>>>>>> lock we have had already cost us valuable time waiting for PR
> >>>> pipelines
> >>>>>>> to
> >>>>>>>>> pass that have no relevance to the commit, like CI work: I’d hat
> >> to
> >>>> see
> >>>>>>> yet
> >>>>>>>>> another process enforced that Kees us from getting work done when
> >>>>>>> necessary.
> >>>>>>>>>>> -Jake
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io>
> >>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> -1 to (1) and (2).
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think merge commits are appropriate in certain
> >> circumstances,
> >>>> so I
> >>>>>>>>> don't
> >>>>>>>>>>>> think we should make a blanket restriction. In fact I think
> >> our
> >>>>>>> release
> >>>>>>>>>>>> process involves some merges.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think setting standards on what is reasonable to be an
> >>>> individual
> >>>>>>>>> commit
> >>>>>>>>>>>> will do a lot more to clean up our history than blocking
> >> merges.
> >>>> We'd
> >>>>>>>>>>>> rather not see commits like "Spotless Apply" in the history,
> >> but
> >>>> if
> >>>>>>>>>>>> reasonably separate and well written commits come in as part
> >> of
> >>> a
> >>>>>>>>> merge, I
> >>>>>>>>>>>> think that's fine.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -Dan
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> >> jiliao@pivotal.io
> >>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>> +1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> >>> onichols@pivotal.io
> >>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>> I’d like to advance this topic from an informal
> >>>> request/discussion
> >>>>>>>>> to a
> >>>>>>>>>>>>>> discussion of a concrete proposal.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> To recap, it sounds like there is general agreement that
> >>> commit
> >>>>>>>>> history
> >>>>>>>>>>>>> on
> >>>>>>>>>>>>>> develop should be linear (no merge commits), and that the
> >>>> biggest
> >>>>>>>>>>>>> obstacle
> >>>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a
> >> merge
> >>>>>>> commit
> >>>>>>>>> by
> >>>>>>>>>>>>>> default.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I propose the following changes:
> >>>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to create a
> >>>> merge
> >>>>>>>>> commit.
> >>>>>>>>>>>>>> This will make Squash & Merge the default.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2) Change GitHub settings to require linear history on
> >>> develop.
> >>>>>>> This
> >>>>>>>>>>>>>> prevents merge commits via command-line (not recommended,
> >> but
> >>>> wiki
> >>>>>>>>> still
> >>>>>>>>>>>>>> has instructions for merging PRs this way).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 3) Update the PR template to change the text "Is your
> >> initial
> >>>>>>>>>>>>> contribution
> >>>>>>>>>>>>>> a single, squashed commit” to “Is your initial contribution
> >>>>>>> squashed
> >>>>>>>>> for
> >>>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> >>> commit
> >>>>>>> plus
> >>>>>>>>> a
> >>>>>>>>>>>>>> ‘fix’ commit)"
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> For clarity, I am proposing no-change in the following
> >> areas:
> >>>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
> >>>>>>>>> structured to
> >>>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to see
> >>>> whether
> >>>>>>>>> the
> >>>>>>>>>>>>>> refactoring or the “fix” broke something).
> >>>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
> >>>>>>> squashing
> >>>>>>>>> is
> >>>>>>>>>>>>>> preferred].
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please comment via this email thread.
> >>>>>>>>>>>>>> -Owen
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org>
> >>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think it's already resolved Udo ;)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all
> >>>> uses
> >>>>>>> of
> >>>>>>>>>>>>>> "this."
> >>>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember that
> >>> the
> >>>>>>> file
> >>>>>>>>>>>>> is a
> >>>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new file
> >>>> that I
> >>>>>>>>>>>>>> created
> >>>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this." can
> >>> easily
> >>>>>>>>> do). If
> >>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that
> >> dunit
> >>>> test
> >>>>>>> --
> >>>>>>>>>>>>> then
> >>>>>>>>>>>>>>> we effectively lose the history of that file and it shows
> >>> that
> >>>> I
> >>>>>>>>>>>>> created
> >>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>> new file.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Also for the record, I've been working on Geode since the
> >>>>>>> beginning
> >>>>>>>>>>>>> and I
> >>>>>>>>>>>>>>> was never made aware of this change in our process. I never
> >>>> voted
> >>>>>>> on
> >>>>>>>>>>>>> it.
> >>>>>>>>>>>>>>> I'm not a big fan of changing various details in our
> >> process
> >>>> every
> >>>>>>>>>>>>> single
> >>>>>>>>>>>>>>> week. It's very easy to miss these discussions unless
> >> someone
> >>>>>>>>> points it
> >>>>>>>>>>>>>> out
> >>>>>>>>>>>>>>> to me.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> >>>>>>>>> ukohlmeyer@pivotal.io>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
> >>>> community,
> >>>>>>>>> have
> >>>>>>>>>>>>>>>> agreed in common practices, in two place no less...
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1) Quoting our PR template
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> For all changes:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> >>>> referenced
> >>>>>>>>> in
> >>>>>>>>>>>>>>>> the commit message?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Has your PR been rebased against the latest commit within
> >>> the
> >>>>>>>>>>>>> target
> >>>>>>>>>>>>>>>> branch (typically|develop|)?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed
> >> commit?*
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
> >>>> changes?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If adding new dependencies to the code, are these
> >>>> dependencies
> >>>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion
> >> underASF
> >>>> 2.0
> >>>>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On our PR template we call out that the initial PR commit
> >>>> should
> >>>>>>> be
> >>>>>>>>>>>>>>>> squashed.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2)
> >>>>>>>
> >> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>>>>>>>>> <
> >>>>>>>>>
> >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend
> >> you
> >>>> on
> >>>>>>> the
> >>>>>>>>>>>>>>>> diligence, but in reality, they should either then be
> >> stand
> >>>> alone
> >>>>>>>>> PR's
> >>>>>>>>>>>>>>>> or just extra work created for yourself.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
> >>>>>>>>>>>>> submit/commit/merge
> >>>>>>>>>>>>>>>> changes back into develop... Then this is another
> >> discussion
> >>>>>>>>> thread,
> >>>>>>>>>>>>>>>> until then, I think we should all remind ourselves on our
> >>>> agreed
> >>>>>>>>>>>>>>>> contributions code of conduct.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --Udo
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >>>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
> >> multiple
> >>>>>>>>> commits is
> >>>>>>>>>>>>>> ok.
> >>>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to
> >> develop
> >>>>>>>>> branch,
> >>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you
> >> have
> >>>>>>>>> mentioned
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
> >>>>>>>>>>>>>>>>> If you can see in the first screenshot comparison that I
> >>> had
> >>>>>>>>> attached
> >>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>> the first email in this thread is what I want to avoid.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thank you for your feedback.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>> Naba
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> >>> klund@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
> >> intend
> >>>> to
> >>>>>>>>> rebase
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit stands
> >>>> alone
> >>>>>>> as
> >>>>>>>>> is
> >>>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
> >>>>>>>>> refactoring
> >>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>>> behavior changes into different commits seems very
> >>> valuable
> >>>> to
> >>>>>>>>> me,
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> I've
> >>>>>>>>>>>>>>>>>> had trouble getting people to review PRs without this
> >>>>>>> separation
> >>>>>>>>>>>>> (but
> >>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs
> >> have
> >>>>>>>>> multiple
> >>>>>>>>>>>>>>>> commits
> >>>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs
> >>>> that
> >>>>>>>>> should
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>> merged with squash are not (by accident most likely).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
> >> multiple
> >>>>>>>>> commits.
> >>>>>>>>>>>>> So
> >>>>>>>>>>>>>>>> I'll
> >>>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent commits
> >> to
> >>>>>>> develop
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase
> >> or
> >>>> merge
> >>>>>>>>>>>>>> commits
> >>>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this
> >>> or
> >>>>>>>>> prevent
> >>>>>>>>>>>>>> (b)
> >>>>>>>>>>>>>>>>>> above.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >>>>>>>>>>>>>> amurmann@pivotal.io>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
> >> necessarily
> >>> at
> >>>>>>>>> odds.
> >>>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then
> >>> make
> >>>>>>> the
> >>>>>>>>>>>>> easy
> >>>>>>>>>>>>>>>>>>>> change."
> >>>>>>>>>>>>>>>>>>> -Kent Beck
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split
> >> into
> >>>> two
> >>>>>>>>>>>>> commits.
> >>>>>>>>>>>>>>>> One
> >>>>>>>>>>>>>>>>>>> refactor commit and a separate commit that introduces
> >> the
> >>>>>>> actual
> >>>>>>>>>>>>>>>> change.
> >>>>>>>>>>>>>>>>>>> They should be individually revertible and might be
> >>> easier
> >>>>>>>>>>>>> understood
> >>>>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code base
> >>>> where
> >>>>>>>>>>>>> someone
> >>>>>>>>>>>>>>>>>> did a
> >>>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one
> >>>> parameter
> >>>>>>>>>>>>>> changing
> >>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>> order to get the desired functionality change. If that
> >>> was
> >>>> in
> >>>>>>>>> one
> >>>>>>>>>>>>>>>> commit,
> >>>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split
> >> out,
> >>>> it's
> >>>>>>>>>>>>>> beautiful
> >>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> crystal clear.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of
> >> JIRA
> >>>>>>> ticket
> >>>>>>>>>>>>>>>>>> references.
> >>>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with the
> >>> ticket
> >>>>>>>>> number,
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a
> >>>> separate
> >>>>>>>>>>>>>>>> refactoring
> >>>>>>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> >>>> nnag@pivotal.io>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things start
> >>>>>>> failing
> >>>>>>>>> ...
> >>>>>>>>>>>>>>>>>> helps
> >>>>>>>>>>>>>>>>>>> us
> >>>>>>>>>>>>>>>>>>>> it revert and build faster.
> >>>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
> >>>>>>> versions
> >>>>>>>>> .
> >>>>>>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary
> >>>> “merge
> >>>>>>>>>>>>>> commits”.
> >>>>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>>>> Naba
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> >>>> klund@apache.org>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit
> >>> in
> >>>> a
> >>>>>>> PR
> >>>>>>>>> and
> >>>>>>>>>>>>>>>>>> keep
> >>>>>>>>>>>>>>>>>>>> them
> >>>>>>>>>>>>>>>>>>>>> separate when they merge to develop
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> >>>>>>> nnag@pivotal.io>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of
> >>> using
> >>>>>>>>> merge.
> >>>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect operations
> >>> when a
> >>>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced.
> >> We
> >>>> can
> >>>>>>>>>>>>> automate
> >>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> go
> >>>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
> >>>>>>> "spotless
> >>>>>>>>>>>>> fix"
> >>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in
> >> the
> >>>>>>> merged
> >>>>>>>>>>>>>>>>>> branch.
> >>>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to
> >> know
> >>>> who
> >>>>>>>>>>>>> worked
> >>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>> it,
> >>>>>>>>>>>>>>>>>>>>>> what is the history)
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> >>>>>>>>>>>>>>>>>>>>>> * explanation line 1
> >> *
> >>>>>>>>>>>>> explanation
> >>>>>>>>>>>>>>>>>>> line
> >>>>>>>>>>>>>>>>>>>> 2*
> >>>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to
> >> help
> >>>> out
> >>>>>>>>> your
> >>>>>>>>>>>>>>>>>> fellow
> >>>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka /
> >> Spark
> >>>>>>> where
> >>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD
> >> [see
> >>>>>>>>>>>>> attachment]
> >>>>>>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>>>>>> Naba.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>> Ju@N
> >>>>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Anthony Baker <ab...@pivotal.io>.
Whether we are talking about the geode/ repository or the geode-native/ repository we are all one GEODE community.
The idea of a native client team may matter in some contexts but in this space we are all GEODE contributors.
Adopting a common approach across our repos will make it easier for new contributors to engage, learn our norms, and join our efforts.
$0.02,
Anthony
> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io> wrote:
>
> Is this a policy the native client team must abide by, as well? It varies
> slightly with what we've been doing, and all other things being equal I see
> no reason for us to change that. If I am to have any measure of control
> over the nc repository, I will definitely enforce a 1:1 correspondence
> between commits to develop and JIRA tickets. IMO, if your refactoring in a
> PR is sufficiently large or complex that it's difficult to tease it out
> from the bug you're fixing or feature you're implementing, it merits its
> own JIRA ticket and a separate PR. If your "actual" fix then becomes
> dependent on the refactored code, that's a price I'm willing to pay to keep
> history clean.
>
> On the other hand, I see no real value in squashing to a single commit
> prior to submitting a PR, since your view of the changes on GitHub is
> essentially the same either way. We haven't enforced this on the nc repo,
> and I'd prefer to keep it that way.
>
> Thanks,
>
> Blake
>
>
> On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io> wrote:
>
>> Merge commit is the new contributor's default setting. When we are merging
>> new contributor's PR, since we are so used to THINKING "squash-and-merge"
>> is the default, we forgot to check what the button really says when we are
>> merging other people's PR.
>>
>> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <eb...@pivotal.io>
>> wrote:
>>
>>> I'm a proponent of using squash-and-merge, and once a person has chosen
>>> this option once it comes up by default afterwards...
>>>
>>> Owen, I don't think you have consensus to put forth this PR, there are
>> -1s
>>> above... (early voting)
>>>
>>> maybe we'll be better off socializing the norm of squash-and-merge and
>>> gaining a natural consensus that way...
>>>
>>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <on...@pivotal.io>
>> wrote:
>>>
>>>> The proposed action manifests as a commit to the Geode git repository,
>> so
>>>> a PR is an acceptable vehicle for voting in this case.
>>>>
>>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
>> bschuchardt@pivotal.io>
>>>> wrote:
>>>>>
>>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
>> thread
>>>> and a request to "vote" using a PR. This all seems out of order to me.
>>>> Our votes are supposed to be on the email list, aren't they? and I
>>> haven't
>>>> seen a VOTE request.
>>>>>
>>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
>>>>>> +1
>>>>>>
>>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io>
>>>> wrote:
>>>>>>
>>>>>>> Based on the feedback so far, I will amend the proposal to drop
>> item
>>>> 2).
>>>>>>> Therefore, the current ability to create merge commits using
>>>> command-line
>>>>>>> git will remain available.
>>>>>>>
>>>>>>> The proposal as amended is now:
>>>>>>>> Change GitHub settings to make "Squash and merge" the default
>>>>>>>> (by removing “Create a merge commit” option).
>>>>>>>>
>>>>>>>> Update the PR template to change the text "Is your initial
>>>> contribution
>>>>>>>> a single, squashed commit” to “Is your initial contribution
>> squashed
>>>> for
>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
>>> plus a
>>>>>>>> ‘fix’ commit)"
>>>>>>>
>>>>>>> As Naba suggested, we can try it, and if we don’t like it, it’s
>>> simple
>>>> to
>>>>>>> revert.
>>>>>>>
>>>>>>> I’ve create a PR for the proposed change here:
>>>>>>> https://github.com/apache/geode/pull/4513
>>>>>>>
>>>>>>> Please use the PR to vote for against this proposal. It will not
>> be
>>>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
>> time)
>>>>>>>
>>>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io>
>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Bruce, this proposal will not waste a single second of your
>>>> time. It
>>>>>>>>> just prevents people from accidentally pressing a button that we
>>> have
>>>>>>>>> already agreed should never be pressed, but because we never
>>>> configured
>>>>>>> our
>>>>>>>>> GitHub to match our stated policy, is currently the default.
>>>>>>>>>
>>>>>>>>> However, it will save a lot of time and frustration for anyone
>>>> needing
>>>>>>> to
>>>>>>>>> bisect failures, revert, or cherry-pick changes, which has merit
>>>> even if
>>>>>>>>> you personally never do any of those three things.
>>>>>>>>>
>>>>>>>>> Please start a separate thread if you would like to revisit the
>>>>>>> community
>>>>>>>>> decision to require passing PR checks.
>>>>>>>>>
>>>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
>>>> bschuchardt@pivotal.io>
>>>>>>>>> wrote:
>>>>>>>>>> I agree with Jake. I would go further by saying that I see very
>>>> little
>>>>>>>>> merit in this proposal. I think we're getting more and more
>>>>>>> bureaucratic
>>>>>>>>> in our process and that it stifles productivity. I was recently
>>>> forced
>>>>>>> to
>>>>>>>>> spend three days fixing tests in which I had changed an import
>>>> statement
>>>>>>>>> before they would pass stress testing. I'm glad the tests now
>> pass
>>>>>>>>> reliably but I was very frustrated by the process.
>>>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to
>> flat
>>>> out
>>>>>>>>> prevent things that should be self policing is annoying. This PR
>>>> review
>>>>>>>>> lock we have had already cost us valuable time waiting for PR
>>>> pipelines
>>>>>>> to
>>>>>>>>> pass that have no relevance to the commit, like CI work: I’d hat
>> to
>>>> see
>>>>>>> yet
>>>>>>>>> another process enforced that Kees us from getting work done when
>>>>>>> necessary.
>>>>>>>>>>> -Jake
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io>
>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> -1 to (1) and (2).
>>>>>>>>>>>>
>>>>>>>>>>>> I think merge commits are appropriate in certain
>> circumstances,
>>>> so I
>>>>>>>>> don't
>>>>>>>>>>>> think we should make a blanket restriction. In fact I think
>> our
>>>>>>> release
>>>>>>>>>>>> process involves some merges.
>>>>>>>>>>>>
>>>>>>>>>>>> I think setting standards on what is reasonable to be an
>>>> individual
>>>>>>>>> commit
>>>>>>>>>>>> will do a lot more to clean up our history than blocking
>> merges.
>>>> We'd
>>>>>>>>>>>> rather not see commits like "Spotless Apply" in the history,
>> but
>>>> if
>>>>>>>>>>>> reasonably separate and well written commits come in as part
>> of
>>> a
>>>>>>>>> merge, I
>>>>>>>>>>>> think that's fine.
>>>>>>>>>>>>
>>>>>>>>>>>> -Dan
>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
>> jiliao@pivotal.io
>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
>>> onichols@pivotal.io
>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>>>> I’d like to advance this topic from an informal
>>>> request/discussion
>>>>>>>>> to a
>>>>>>>>>>>>>> discussion of a concrete proposal.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To recap, it sounds like there is general agreement that
>>> commit
>>>>>>>>> history
>>>>>>>>>>>>> on
>>>>>>>>>>>>>> develop should be linear (no merge commits), and that the
>>>> biggest
>>>>>>>>>>>>> obstacle
>>>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a
>> merge
>>>>>>> commit
>>>>>>>>> by
>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I propose the following changes:
>>>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to create a
>>>> merge
>>>>>>>>> commit.
>>>>>>>>>>>>>> This will make Squash & Merge the default.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2) Change GitHub settings to require linear history on
>>> develop.
>>>>>>> This
>>>>>>>>>>>>>> prevents merge commits via command-line (not recommended,
>> but
>>>> wiki
>>>>>>>>> still
>>>>>>>>>>>>>> has instructions for merging PRs this way).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3) Update the PR template to change the text "Is your
>> initial
>>>>>>>>>>>>> contribution
>>>>>>>>>>>>>> a single, squashed commit” to “Is your initial contribution
>>>>>>> squashed
>>>>>>>>> for
>>>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
>>> commit
>>>>>>> plus
>>>>>>>>> a
>>>>>>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For clarity, I am proposing no-change in the following
>> areas:
>>>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
>>>>>>>>> structured to
>>>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to see
>>>> whether
>>>>>>>>> the
>>>>>>>>>>>>>> refactoring or the “fix” broke something).
>>>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
>>>>>>> squashing
>>>>>>>>> is
>>>>>>>>>>>>>> preferred].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please comment via this email thread.
>>>>>>>>>>>>>> -Owen
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org>
>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think it's already resolved Udo ;)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all
>>>> uses
>>>>>>> of
>>>>>>>>>>>>>> "this."
>>>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember that
>>> the
>>>>>>> file
>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new file
>>>> that I
>>>>>>>>>>>>>> created
>>>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this." can
>>> easily
>>>>>>>>> do). If
>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that
>> dunit
>>>> test
>>>>>>> --
>>>>>>>>>>>>> then
>>>>>>>>>>>>>>> we effectively lose the history of that file and it shows
>>> that
>>>> I
>>>>>>>>>>>>> created
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>> new file.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Also for the record, I've been working on Geode since the
>>>>>>> beginning
>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>> was never made aware of this change in our process. I never
>>>> voted
>>>>>>> on
>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>> I'm not a big fan of changing various details in our
>> process
>>>> every
>>>>>>>>>>>>> single
>>>>>>>>>>>>>>> week. It's very easy to miss these discussions unless
>> someone
>>>>>>>>> points it
>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>> to me.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>>>>>>>>> ukohlmeyer@pivotal.io>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
>>>> community,
>>>>>>>>> have
>>>>>>>>>>>>>>>> agreed in common practices, in two place no less...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1) Quoting our PR template
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For all changes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
>>>> referenced
>>>>>>>>> in
>>>>>>>>>>>>>>>> the commit message?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Has your PR been rebased against the latest commit within
>>> the
>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>> branch (typically|develop|)?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed
>> commit?*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
>>>> changes?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If adding new dependencies to the code, are these
>>>> dependencies
>>>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion
>> underASF
>>>> 2.0
>>>>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On our PR template we call out that the initial PR commit
>>>> should
>>>>>>> be
>>>>>>>>>>>>>>>> squashed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2)
>>>>>>>
>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>>>>> <
>>>>>>>>>
>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend
>> you
>>>> on
>>>>>>> the
>>>>>>>>>>>>>>>> diligence, but in reality, they should either then be
>> stand
>>>> alone
>>>>>>>>> PR's
>>>>>>>>>>>>>>>> or just extra work created for yourself.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
>>>>>>>>>>>>> submit/commit/merge
>>>>>>>>>>>>>>>> changes back into develop... Then this is another
>> discussion
>>>>>>>>> thread,
>>>>>>>>>>>>>>>> until then, I think we should all remind ourselves on our
>>>> agreed
>>>>>>>>>>>>>>>> contributions code of conduct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --Udo
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
>> multiple
>>>>>>>>> commits is
>>>>>>>>>>>>>> ok.
>>>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to
>> develop
>>>>>>>>> branch,
>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you
>> have
>>>>>>>>> mentioned
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>>>>>>>>>>> If you can see in the first screenshot comparison that I
>>> had
>>>>>>>>> attached
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank you for your feedback.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
>>> klund@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
>> intend
>>>> to
>>>>>>>>> rebase
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit stands
>>>> alone
>>>>>>> as
>>>>>>>>> is
>>>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
>>>>>>>>> refactoring
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>> behavior changes into different commits seems very
>>> valuable
>>>> to
>>>>>>>>> me,
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>> had trouble getting people to review PRs without this
>>>>>>> separation
>>>>>>>>>>>>> (but
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs
>> have
>>>>>>>>> multiple
>>>>>>>>>>>>>>>> commits
>>>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs
>>>> that
>>>>>>>>> should
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
>> multiple
>>>>>>>>> commits.
>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent commits
>> to
>>>>>>> develop
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase
>> or
>>>> merge
>>>>>>>>>>>>>> commits
>>>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this
>>> or
>>>>>>>>> prevent
>>>>>>>>>>>>>> (b)
>>>>>>>>>>>>>>>>>> above.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>>>>>>>>>>> amurmann@pivotal.io>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
>> necessarily
>>> at
>>>>>>>>> odds.
>>>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then
>>> make
>>>>>>> the
>>>>>>>>>>>>> easy
>>>>>>>>>>>>>>>>>>>> change."
>>>>>>>>>>>>>>>>>>> -Kent Beck
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split
>> into
>>>> two
>>>>>>>>>>>>> commits.
>>>>>>>>>>>>>>>> One
>>>>>>>>>>>>>>>>>>> refactor commit and a separate commit that introduces
>> the
>>>>>>> actual
>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>> They should be individually revertible and might be
>>> easier
>>>>>>>>>>>>> understood
>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code base
>>>> where
>>>>>>>>>>>>> someone
>>>>>>>>>>>>>>>>>> did a
>>>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one
>>>> parameter
>>>>>>>>>>>>>> changing
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> order to get the desired functionality change. If that
>>> was
>>>> in
>>>>>>>>> one
>>>>>>>>>>>>>>>> commit,
>>>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split
>> out,
>>>> it's
>>>>>>>>>>>>>> beautiful
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> crystal clear.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of
>> JIRA
>>>>>>> ticket
>>>>>>>>>>>>>>>>>> references.
>>>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with the
>>> ticket
>>>>>>>>> number,
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a
>>>> separate
>>>>>>>>>>>>>>>> refactoring
>>>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
>>>> nnag@pivotal.io>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things start
>>>>>>> failing
>>>>>>>>> ...
>>>>>>>>>>>>>>>>>> helps
>>>>>>>>>>>>>>>>>>> us
>>>>>>>>>>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
>>>>>>> versions
>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary
>>>> “merge
>>>>>>>>>>>>>> commits”.
>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
>>>> klund@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit
>>> in
>>>> a
>>>>>>> PR
>>>>>>>>> and
>>>>>>>>>>>>>>>>>> keep
>>>>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>>>>>>> nnag@pivotal.io>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of
>>> using
>>>>>>>>> merge.
>>>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect operations
>>> when a
>>>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced.
>> We
>>>> can
>>>>>>>>>>>>> automate
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
>>>>>>> "spotless
>>>>>>>>>>>>> fix"
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in
>> the
>>>>>>> merged
>>>>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to
>> know
>>>> who
>>>>>>>>>>>>> worked
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>> it,
>>>>>>>>>>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>>>>>>>>>>> * explanation line 1
>> *
>>>>>>>>>>>>> explanation
>>>>>>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>>>>>>> 2*
>>>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to
>> help
>>>> out
>>>>>>>>> your
>>>>>>>>>>>>>>>>>> fellow
>>>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka /
>> Spark
>>>>>>> where
>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD
>> [see
>>>>>>>>>>>>> attachment]
>>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>> Ju@N
>>>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Cheers
>>
>> Jinmei
>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Aaron Lindsey <aa...@apache.org>.
Just to be clear, this proposal wouldn't require anyone to squash their commits before merging a PR. All it’s saying is that if you do have multiple commits in your PR, you would have to rebase those commits onto develop before merging to ensure a linear commit history.
- Aaron
> On Dec 20, 2019, at 11:32 AM, Blake Bender <bb...@pivotal.io> wrote:
>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Blake Bender <bb...@pivotal.io>.
Is this a policy the native client team must abide by, as well? It varies
slightly with what we've been doing, and all other things being equal I see
no reason for us to change that. If I am to have any measure of control
over the nc repository, I will definitely enforce a 1:1 correspondence
between commits to develop and JIRA tickets. IMO, if your refactoring in a
PR is sufficiently large or complex that it's difficult to tease it out
from the bug you're fixing or feature you're implementing, it merits its
own JIRA ticket and a separate PR. If your "actual" fix then becomes
dependent on the refactored code, that's a price I'm willing to pay to keep
history clean.
On the other hand, I see no real value in squashing to a single commit
prior to submitting a PR, since your view of the changes on GitHub is
essentially the same either way. We haven't enforced this on the nc repo,
and I'd prefer to keep it that way.
Thanks,
Blake
On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao <ji...@pivotal.io> wrote:
> Merge commit is the new contributor's default setting. When we are merging
> new contributor's PR, since we are so used to THINKING "squash-and-merge"
> is the default, we forgot to check what the button really says when we are
> merging other people's PR.
>
> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <eb...@pivotal.io>
> wrote:
>
> > I'm a proponent of using squash-and-merge, and once a person has chosen
> > this option once it comes up by default afterwards...
> >
> > Owen, I don't think you have consensus to put forth this PR, there are
> -1s
> > above... (early voting)
> >
> > maybe we'll be better off socializing the norm of squash-and-merge and
> > gaining a natural consensus that way...
> >
> > On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <on...@pivotal.io>
> wrote:
> >
> > > The proposed action manifests as a commit to the Geode git repository,
> so
> > > a PR is an acceptable vehicle for voting in this case.
> > >
> > > > On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> bschuchardt@pivotal.io>
> > > wrote:
> > > >
> > > > I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> thread
> > > and a request to "vote" using a PR. This all seems out of order to me.
> > > Our votes are supposed to be on the email list, aren't they? and I
> > haven't
> > > seen a VOTE request.
> > > >
> > > > On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > > >> +1
> > > >>
> > > >> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io>
> > > wrote:
> > > >>
> > > >>> Based on the feedback so far, I will amend the proposal to drop
> item
> > > 2).
> > > >>> Therefore, the current ability to create merge commits using
> > > command-line
> > > >>> git will remain available.
> > > >>>
> > > >>> The proposal as amended is now:
> > > >>>> Change GitHub settings to make "Squash and merge" the default
> > > >>>> (by removing “Create a merge commit” option).
> > > >>>>
> > > >>>> Update the PR template to change the text "Is your initial
> > > contribution
> > > >>>> a single, squashed commit” to “Is your initial contribution
> squashed
> > > for
> > > >>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> > plus a
> > > >>>> ‘fix’ commit)"
> > > >>>
> > > >>> As Naba suggested, we can try it, and if we don’t like it, it’s
> > simple
> > > to
> > > >>> revert.
> > > >>>
> > > >>> I’ve create a PR for the proposed change here:
> > > >>> https://github.com/apache/geode/pull/4513
> > > >>>
> > > >>> Please use the PR to vote for against this proposal. It will not
> be
> > > >>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
> time)
> > > >>>
> > > >>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
> > > >>>>
> > > >>>> +1
> > > >>>>
> > > >>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io>
> > > wrote:
> > > >>>>
> > > >>>>> Hi Bruce, this proposal will not waste a single second of your
> > > time. It
> > > >>>>> just prevents people from accidentally pressing a button that we
> > have
> > > >>>>> already agreed should never be pressed, but because we never
> > > configured
> > > >>> our
> > > >>>>> GitHub to match our stated policy, is currently the default.
> > > >>>>>
> > > >>>>> However, it will save a lot of time and frustration for anyone
> > > needing
> > > >>> to
> > > >>>>> bisect failures, revert, or cherry-pick changes, which has merit
> > > even if
> > > >>>>> you personally never do any of those three things.
> > > >>>>>
> > > >>>>> Please start a separate thread if you would like to revisit the
> > > >>> community
> > > >>>>> decision to require passing PR checks.
> > > >>>>>
> > > >>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > > bschuchardt@pivotal.io>
> > > >>>>> wrote:
> > > >>>>>> I agree with Jake. I would go further by saying that I see very
> > > little
> > > >>>>> merit in this proposal. I think we're getting more and more
> > > >>> bureaucratic
> > > >>>>> in our process and that it stifles productivity. I was recently
> > > forced
> > > >>> to
> > > >>>>> spend three days fixing tests in which I had changed an import
> > > statement
> > > >>>>> before they would pass stress testing. I'm glad the tests now
> pass
> > > >>>>> reliably but I was very frustrated by the process.
> > > >>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > > >>>>>>> I’m in agreement with Dan. Changes to the infrastructure to
> flat
> > > out
> > > >>>>> prevent things that should be self policing is annoying. This PR
> > > review
> > > >>>>> lock we have had already cost us valuable time waiting for PR
> > > pipelines
> > > >>> to
> > > >>>>> pass that have no relevance to the commit, like CI work: I’d hat
> to
> > > see
> > > >>> yet
> > > >>>>> another process enforced that Kees us from getting work done when
> > > >>> necessary.
> > > >>>>>>> -Jake
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io>
> > wrote:
> > > >>>>>>>>
> > > >>>>>>>> -1 to (1) and (2).
> > > >>>>>>>>
> > > >>>>>>>> I think merge commits are appropriate in certain
> circumstances,
> > > so I
> > > >>>>> don't
> > > >>>>>>>> think we should make a blanket restriction. In fact I think
> our
> > > >>> release
> > > >>>>>>>> process involves some merges.
> > > >>>>>>>>
> > > >>>>>>>> I think setting standards on what is reasonable to be an
> > > individual
> > > >>>>> commit
> > > >>>>>>>> will do a lot more to clean up our history than blocking
> merges.
> > > We'd
> > > >>>>>>>> rather not see commits like "Spotless Apply" in the history,
> but
> > > if
> > > >>>>>>>> reasonably separate and well written commits come in as part
> of
> > a
> > > >>>>> merge, I
> > > >>>>>>>> think that's fine.
> > > >>>>>>>>
> > > >>>>>>>> -Dan
> > > >>>>>>>>
> > > >>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <
> jiliao@pivotal.io
> > >
> > > >>>>> wrote:
> > > >>>>>>>>> +1
> > > >>>>>>>>>
> > > >>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> > onichols@pivotal.io
> > > >
> > > >>>>> wrote:
> > > >>>>>>>>>> I’d like to advance this topic from an informal
> > > request/discussion
> > > >>>>> to a
> > > >>>>>>>>>> discussion of a concrete proposal.
> > > >>>>>>>>>>
> > > >>>>>>>>>> To recap, it sounds like there is general agreement that
> > commit
> > > >>>>> history
> > > >>>>>>>>> on
> > > >>>>>>>>>> develop should be linear (no merge commits), and that the
> > > biggest
> > > >>>>>>>>> obstacle
> > > >>>>>>>>>> to this is that the PR merge button in GitHub creates a
> merge
> > > >>> commit
> > > >>>>> by
> > > >>>>>>>>>> default.
> > > >>>>>>>>>>
> > > >>>>>>>>>> I propose the following changes:
> > > >>>>>>>>>> 1) Change GitHub settings to remove the ability to create a
> > > merge
> > > >>>>> commit.
> > > >>>>>>>>>> This will make Squash & Merge the default.
> > > >>>>>>>>>>
> > > >>>>>>>>>> 2) Change GitHub settings to require linear history on
> > develop.
> > > >>> This
> > > >>>>>>>>>> prevents merge commits via command-line (not recommended,
> but
> > > wiki
> > > >>>>> still
> > > >>>>>>>>>> has instructions for merging PRs this way).
> > > >>>>>>>>>>
> > > >>>>>>>>>> 3) Update the PR template to change the text "Is your
> initial
> > > >>>>>>>>> contribution
> > > >>>>>>>>>> a single, squashed commit” to “Is your initial contribution
> > > >>> squashed
> > > >>>>> for
> > > >>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> > commit
> > > >>> plus
> > > >>>>> a
> > > >>>>>>>>>> ‘fix’ commit)"
> > > >>>>>>>>>>
> > > >>>>>>>>>> For clarity, I am proposing no-change in the following
> areas:
> > > >>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
> > > >>>>> structured to
> > > >>>>>>>>>> benefit from it (this can make it easier in a bisect to see
> > > whether
> > > >>>>> the
> > > >>>>>>>>>> refactoring or the “fix” broke something).
> > > >>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
> > > >>> squashing
> > > >>>>> is
> > > >>>>>>>>>> preferred].
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> Please comment via this email thread.
> > > >>>>>>>>>> -Owen
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org>
> > > wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I think it's already resolved Udo ;)
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all
> > > uses
> > > >>> of
> > > >>>>>>>>>> "this."
> > > >>>>>>>>>>> and I rename the dunit test, then git doesn't remember that
> > the
> > > >>> file
> > > >>>>>>>>> is a
> > > >>>>>>>>>>> rename -- it forever afterwards interprets it as a new file
> > > that I
> > > >>>>>>>>>> created
> > > >>>>>>>>>>> if I touch more than 50% of the lines (which "this." can
> > easily
> > > >>>>> do). If
> > > >>>>>>>>>> we
> > > >>>>>>>>>>> squash two commits: the rename and the cleanup of that
> dunit
> > > test
> > > >>> --
> > > >>>>>>>>> then
> > > >>>>>>>>>>> we effectively lose the history of that file and it shows
> > that
> > > I
> > > >>>>>>>>> created
> > > >>>>>>>>>> a
> > > >>>>>>>>>>> new file.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Also for the record, I've been working on Geode since the
> > > >>> beginning
> > > >>>>>>>>> and I
> > > >>>>>>>>>>> was never made aware of this change in our process. I never
> > > voted
> > > >>> on
> > > >>>>>>>>> it.
> > > >>>>>>>>>>> I'm not a big fan of changing various details in our
> process
> > > every
> > > >>>>>>>>> single
> > > >>>>>>>>>>> week. It's very easy to miss these discussions unless
> someone
> > > >>>>> points it
> > > >>>>>>>>>> out
> > > >>>>>>>>>>> to me.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > > >>>>> ukohlmeyer@pivotal.io>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
> > > community,
> > > >>>>> have
> > > >>>>>>>>>>>> agreed in common practices, in two place no less...
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 1) Quoting our PR template
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> For all changes:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> *
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> > > referenced
> > > >>>>> in
> > > >>>>>>>>>>>> the commit message?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> *
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Has your PR been rebased against the latest commit within
> > the
> > > >>>>>>>>> target
> > > >>>>>>>>>>>> branch (typically|develop|)?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> *
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> ***Is your initial contribution a single, squashed
> commit?*
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> *
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Does|gradlew build|run cleanly?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> *
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Have you written or updated unit tests to verify your
> > > changes?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> *
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> If adding new dependencies to the code, are these
> > > dependencies
> > > >>>>>>>>>>>> licensed in a way that is compatible for inclusion
> underASF
> > > 2.0
> > > >>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On our PR template we call out that the initial PR commit
> > > should
> > > >>> be
> > > >>>>>>>>>>>> squashed.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 2)
> > > >>>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > >>>>>>>>>>>> <
> > > >>>>>
> > https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > > >>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend
> you
> > > on
> > > >>> the
> > > >>>>>>>>>>>> diligence, but in reality, they should either then be
> stand
> > > alone
> > > >>>>> PR's
> > > >>>>>>>>>>>> or just extra work created for yourself.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> If we want to change the way we have agreed upon we
> > > >>>>>>>>> submit/commit/merge
> > > >>>>>>>>>>>> changes back into develop... Then this is another
> discussion
> > > >>>>> thread,
> > > >>>>>>>>>>>> until then, I think we should all remind ourselves on our
> > > agreed
> > > >>>>>>>>>>>> contributions code of conduct.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> --Udo
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > > >>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with
> multiple
> > > >>>>> commits is
> > > >>>>>>>>>> ok.
> > > >>>>>>>>>>>>> It's just in the end that when it's being pushed to
> develop
> > > >>>>> branch,
> > > >>>>>>>>> it
> > > >>>>>>>>>>>>> needs to be squash merged. I believe that is what you
> have
> > > >>>>> mentioned
> > > >>>>>>>>> in
> > > >>>>>>>>>>>> the
> > > >>>>>>>>>>>>> first paragraph, and I am more than happy with that.
> > > >>>>>>>>>>>>> If you can see in the first screenshot comparison that I
> > had
> > > >>>>> attached
> > > >>>>>>>>>> in
> > > >>>>>>>>>>>>> the first email in this thread is what I want to avoid.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thank you for your feedback.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Regards
> > > >>>>>>>>>>>>> Naba
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> > klund@apache.org>
> > > >>>>> wrote:
> > > >>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I
> intend
> > > to
> > > >>>>> rebase
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>>>> develop, I always try to ensure that each commit stands
> > > alone
> > > >>> as
> > > >>>>> is
> > > >>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
> > > >>>>> refactoring
> > > >>>>>>>>>>>> from
> > > >>>>>>>>>>>>>> behavior changes into different commits seems very
> > valuable
> > > to
> > > >>>>> me,
> > > >>>>>>>>> and
> > > >>>>>>>>>>>> I've
> > > >>>>>>>>>>>>>> had trouble getting people to review PRs without this
> > > >>> separation
> > > >>>>>>>>> (but
> > > >>>>>>>>>> it
> > > >>>>>>>>>>>>>> could be squashed as it's merged to develop).
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs
> have
> > > >>>>> multiple
> > > >>>>>>>>>>>> commits
> > > >>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs
> > > that
> > > >>>>> should
> > > >>>>>>>>>> be
> > > >>>>>>>>>>>>>> merged with squash are not (by accident most likely).
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with
> multiple
> > > >>>>> commits.
> > > >>>>>>>>> So
> > > >>>>>>>>>>>> I'll
> > > >>>>>>>>>>>>>> change my response to -0 if that helps prevent commits
> to
> > > >>> develop
> > > >>>>>>>>> that
> > > >>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase
> or
> > > merge
> > > >>>>>>>>>> commits
> > > >>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this
> > or
> > > >>>>> prevent
> > > >>>>>>>>>> (b)
> > > >>>>>>>>>>>>>> above.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > > >>>>>>>>>> amurmann@pivotal.io>
> > > >>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are
> necessarily
> > at
> > > >>>>> odds.
> > > >>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then
> > make
> > > >>> the
> > > >>>>>>>>> easy
> > > >>>>>>>>>>>>>>>> change."
> > > >>>>>>>>>>>>>>> -Kent Beck
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split
> into
> > > two
> > > >>>>>>>>> commits.
> > > >>>>>>>>>>>> One
> > > >>>>>>>>>>>>>>> refactor commit and a separate commit that introduces
> the
> > > >>> actual
> > > >>>>>>>>>>>> change.
> > > >>>>>>>>>>>>>>> They should be individually revertible and might be
> > easier
> > > >>>>>>>>> understood
> > > >>>>>>>>>>>> if
> > > >>>>>>>>>>>>>>> split out. I vividly remember a change on our code base
> > > where
> > > >>>>>>>>> someone
> > > >>>>>>>>>>>>>> did a
> > > >>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one
> > > parameter
> > > >>>>>>>>>> changing
> > > >>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>> order to get the desired functionality change. If that
> > was
> > > in
> > > >>>>> one
> > > >>>>>>>>>>>> commit,
> > > >>>>>>>>>>>>>>> it would be hard to see the actual change. If split
> out,
> > > it's
> > > >>>>>>>>>> beautiful
> > > >>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>> crystal clear.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of
> JIRA
> > > >>> ticket
> > > >>>>>>>>>>>>>> references.
> > > >>>>>>>>>>>>>>> Usually we assume that if there is a commit with the
> > ticket
> > > >>>>> number,
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a
> > > separate
> > > >>>>>>>>>>>> refactoring
> > > >>>>>>>>>>>>>>> ticket.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> > > nnag@pivotal.io>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>> It is to help with bisect operations when things start
> > > >>> failing
> > > >>>>> ...
> > > >>>>>>>>>>>>>> helps
> > > >>>>>>>>>>>>>>> us
> > > >>>>>>>>>>>>>>>> it revert and build faster.
> > > >>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
> > > >>> versions
> > > >>>>> .
> > > >>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary
> > > “merge
> > > >>>>>>>>>> commits”.
> > > >>>>>>>>>>>>>>>> Regards
> > > >>>>>>>>>>>>>>>> Naba
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> > > klund@apache.org>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit
> > in
> > > a
> > > >>> PR
> > > >>>>> and
> > > >>>>>>>>>>>>>> keep
> > > >>>>>>>>>>>>>>>> them
> > > >>>>>>>>>>>>>>>>> separate when they merge to develop
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> > > >>> nnag@pivotal.io>
> > > >>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>> Hi Geode Committers,
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of
> > using
> > > >>>>> merge.
> > > >>>>>>>>>>>>>>>>>> This will really help us in our bisect operations
> > when a
> > > >>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced.
> We
> > > can
> > > >>>>>>>>> automate
> > > >>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>> go
> > > >>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
> > > >>> "spotless
> > > >>>>>>>>> fix"
> > > >>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in
> the
> > > >>> merged
> > > >>>>>>>>>>>>>> branch.
> > > >>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to
> know
> > > who
> > > >>>>>>>>> worked
> > > >>>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>>>> it,
> > > >>>>>>>>>>>>>>>>>> what is the history)
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> > > >>>>>>>>>>>>>>>>>> * explanation line 1
> *
> > > >>>>>>>>> explanation
> > > >>>>>>>>>>>>>>> line
> > > >>>>>>>>>>>>>>>> 2*
> > > >>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to
> help
> > > out
> > > >>>>> your
> > > >>>>>>>>>>>>>> fellow
> > > >>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka /
> Spark
> > > >>> where
> > > >>>>>>>>> they
> > > >>>>>>>>>>>>>>> have
> > > >>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD
> [see
> > > >>>>>>>>> attachment]
> > > >>>>>>>>>>>>>>>>>> Regards
> > > >>>>>>>>>>>>>>>>>> Naba.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>> --
> > > >>>> Ju@N
> > > >>>
> > >
> > >
> >
>
>
> --
> Cheers
>
> Jinmei
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Jinmei Liao <ji...@pivotal.io>.
Merge commit is the new contributor's default setting. When we are merging
new contributor's PR, since we are so used to THINKING "squash-and-merge"
is the default, we forgot to check what the button really says when we are
merging other people's PR.
On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <eb...@pivotal.io>
wrote:
> I'm a proponent of using squash-and-merge, and once a person has chosen
> this option once it comes up by default afterwards...
>
> Owen, I don't think you have consensus to put forth this PR, there are -1s
> above... (early voting)
>
> maybe we'll be better off socializing the norm of squash-and-merge and
> gaining a natural consensus that way...
>
> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <on...@pivotal.io> wrote:
>
> > The proposed action manifests as a commit to the Geode git repository, so
> > a PR is an acceptable vehicle for voting in this case.
> >
> > > On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <bs...@pivotal.io>
> > wrote:
> > >
> > > I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread
> > and a request to "vote" using a PR. This all seems out of order to me.
> > Our votes are supposed to be on the email list, aren't they? and I
> haven't
> > seen a VOTE request.
> > >
> > > On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > >> +1
> > >>
> > >> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io>
> > wrote:
> > >>
> > >>> Based on the feedback so far, I will amend the proposal to drop item
> > 2).
> > >>> Therefore, the current ability to create merge commits using
> > command-line
> > >>> git will remain available.
> > >>>
> > >>> The proposal as amended is now:
> > >>>> Change GitHub settings to make "Squash and merge" the default
> > >>>> (by removing “Create a merge commit” option).
> > >>>>
> > >>>> Update the PR template to change the text "Is your initial
> > contribution
> > >>>> a single, squashed commit” to “Is your initial contribution squashed
> > for
> > >>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> plus a
> > >>>> ‘fix’ commit)"
> > >>>
> > >>> As Naba suggested, we can try it, and if we don’t like it, it’s
> simple
> > to
> > >>> revert.
> > >>>
> > >>> I’ve create a PR for the proposed change here:
> > >>> https://github.com/apache/geode/pull/4513
> > >>>
> > >>> Please use the PR to vote for against this proposal. It will not be
> > >>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that time)
> > >>>
> > >>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
> > >>>>
> > >>>> +1
> > >>>>
> > >>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io>
> > wrote:
> > >>>>
> > >>>>> Hi Bruce, this proposal will not waste a single second of your
> > time. It
> > >>>>> just prevents people from accidentally pressing a button that we
> have
> > >>>>> already agreed should never be pressed, but because we never
> > configured
> > >>> our
> > >>>>> GitHub to match our stated policy, is currently the default.
> > >>>>>
> > >>>>> However, it will save a lot of time and frustration for anyone
> > needing
> > >>> to
> > >>>>> bisect failures, revert, or cherry-pick changes, which has merit
> > even if
> > >>>>> you personally never do any of those three things.
> > >>>>>
> > >>>>> Please start a separate thread if you would like to revisit the
> > >>> community
> > >>>>> decision to require passing PR checks.
> > >>>>>
> > >>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > bschuchardt@pivotal.io>
> > >>>>> wrote:
> > >>>>>> I agree with Jake. I would go further by saying that I see very
> > little
> > >>>>> merit in this proposal. I think we're getting more and more
> > >>> bureaucratic
> > >>>>> in our process and that it stifles productivity. I was recently
> > forced
> > >>> to
> > >>>>> spend three days fixing tests in which I had changed an import
> > statement
> > >>>>> before they would pass stress testing. I'm glad the tests now pass
> > >>>>> reliably but I was very frustrated by the process.
> > >>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > >>>>>>> I’m in agreement with Dan. Changes to the infrastructure to flat
> > out
> > >>>>> prevent things that should be self policing is annoying. This PR
> > review
> > >>>>> lock we have had already cost us valuable time waiting for PR
> > pipelines
> > >>> to
> > >>>>> pass that have no relevance to the commit, like CI work: I’d hat to
> > see
> > >>> yet
> > >>>>> another process enforced that Kees us from getting work done when
> > >>> necessary.
> > >>>>>>> -Jake
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io>
> wrote:
> > >>>>>>>>
> > >>>>>>>> -1 to (1) and (2).
> > >>>>>>>>
> > >>>>>>>> I think merge commits are appropriate in certain circumstances,
> > so I
> > >>>>> don't
> > >>>>>>>> think we should make a blanket restriction. In fact I think our
> > >>> release
> > >>>>>>>> process involves some merges.
> > >>>>>>>>
> > >>>>>>>> I think setting standards on what is reasonable to be an
> > individual
> > >>>>> commit
> > >>>>>>>> will do a lot more to clean up our history than blocking merges.
> > We'd
> > >>>>>>>> rather not see commits like "Spotless Apply" in the history, but
> > if
> > >>>>>>>> reasonably separate and well written commits come in as part of
> a
> > >>>>> merge, I
> > >>>>>>>> think that's fine.
> > >>>>>>>>
> > >>>>>>>> -Dan
> > >>>>>>>>
> > >>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <jiliao@pivotal.io
> >
> > >>>>> wrote:
> > >>>>>>>>> +1
> > >>>>>>>>>
> > >>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <
> onichols@pivotal.io
> > >
> > >>>>> wrote:
> > >>>>>>>>>> I’d like to advance this topic from an informal
> > request/discussion
> > >>>>> to a
> > >>>>>>>>>> discussion of a concrete proposal.
> > >>>>>>>>>>
> > >>>>>>>>>> To recap, it sounds like there is general agreement that
> commit
> > >>>>> history
> > >>>>>>>>> on
> > >>>>>>>>>> develop should be linear (no merge commits), and that the
> > biggest
> > >>>>>>>>> obstacle
> > >>>>>>>>>> to this is that the PR merge button in GitHub creates a merge
> > >>> commit
> > >>>>> by
> > >>>>>>>>>> default.
> > >>>>>>>>>>
> > >>>>>>>>>> I propose the following changes:
> > >>>>>>>>>> 1) Change GitHub settings to remove the ability to create a
> > merge
> > >>>>> commit.
> > >>>>>>>>>> This will make Squash & Merge the default.
> > >>>>>>>>>>
> > >>>>>>>>>> 2) Change GitHub settings to require linear history on
> develop.
> > >>> This
> > >>>>>>>>>> prevents merge commits via command-line (not recommended, but
> > wiki
> > >>>>> still
> > >>>>>>>>>> has instructions for merging PRs this way).
> > >>>>>>>>>>
> > >>>>>>>>>> 3) Update the PR template to change the text "Is your initial
> > >>>>>>>>> contribution
> > >>>>>>>>>> a single, squashed commit” to “Is your initial contribution
> > >>> squashed
> > >>>>> for
> > >>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’
> commit
> > >>> plus
> > >>>>> a
> > >>>>>>>>>> ‘fix’ commit)"
> > >>>>>>>>>>
> > >>>>>>>>>> For clarity, I am proposing no-change in the following areas:
> > >>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
> > >>>>> structured to
> > >>>>>>>>>> benefit from it (this can make it easier in a bisect to see
> > whether
> > >>>>> the
> > >>>>>>>>>> refactoring or the “fix” broke something).
> > >>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
> > >>> squashing
> > >>>>> is
> > >>>>>>>>>> preferred].
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Please comment via this email thread.
> > >>>>>>>>>> -Owen
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org>
> > wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> I think it's already resolved Udo ;)
> > >>>>>>>>>>>
> > >>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all
> > uses
> > >>> of
> > >>>>>>>>>> "this."
> > >>>>>>>>>>> and I rename the dunit test, then git doesn't remember that
> the
> > >>> file
> > >>>>>>>>> is a
> > >>>>>>>>>>> rename -- it forever afterwards interprets it as a new file
> > that I
> > >>>>>>>>>> created
> > >>>>>>>>>>> if I touch more than 50% of the lines (which "this." can
> easily
> > >>>>> do). If
> > >>>>>>>>>> we
> > >>>>>>>>>>> squash two commits: the rename and the cleanup of that dunit
> > test
> > >>> --
> > >>>>>>>>> then
> > >>>>>>>>>>> we effectively lose the history of that file and it shows
> that
> > I
> > >>>>>>>>> created
> > >>>>>>>>>> a
> > >>>>>>>>>>> new file.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Also for the record, I've been working on Geode since the
> > >>> beginning
> > >>>>>>>>> and I
> > >>>>>>>>>>> was never made aware of this change in our process. I never
> > voted
> > >>> on
> > >>>>>>>>> it.
> > >>>>>>>>>>> I'm not a big fan of changing various details in our process
> > every
> > >>>>>>>>> single
> > >>>>>>>>>>> week. It's very easy to miss these discussions unless someone
> > >>>>> points it
> > >>>>>>>>>> out
> > >>>>>>>>>>> to me.
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> > >>>>> ukohlmeyer@pivotal.io>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
> > community,
> > >>>>> have
> > >>>>>>>>>>>> agreed in common practices, in two place no less...
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 1) Quoting our PR template
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> For all changes:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> > referenced
> > >>>>> in
> > >>>>>>>>>>>> the commit message?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Has your PR been rebased against the latest commit within
> the
> > >>>>>>>>> target
> > >>>>>>>>>>>> branch (typically|develop|)?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> ***Is your initial contribution a single, squashed commit?*
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Does|gradlew build|run cleanly?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Have you written or updated unit tests to verify your
> > changes?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> *
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> If adding new dependencies to the code, are these
> > dependencies
> > >>>>>>>>>>>> licensed in a way that is compatible for inclusion underASF
> > 2.0
> > >>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On our PR template we call out that the initial PR commit
> > should
> > >>> be
> > >>>>>>>>>>>> squashed.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 2)
> > >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>>>>>>>>>> <
> > >>>>>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend you
> > on
> > >>> the
> > >>>>>>>>>>>> diligence, but in reality, they should either then be stand
> > alone
> > >>>>> PR's
> > >>>>>>>>>>>> or just extra work created for yourself.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> If we want to change the way we have agreed upon we
> > >>>>>>>>> submit/commit/merge
> > >>>>>>>>>>>> changes back into develop... Then this is another discussion
> > >>>>> thread,
> > >>>>>>>>>>>> until then, I think we should all remind ourselves on our
> > agreed
> > >>>>>>>>>>>> contributions code of conduct.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --Udo
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > >>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with multiple
> > >>>>> commits is
> > >>>>>>>>>> ok.
> > >>>>>>>>>>>>> It's just in the end that when it's being pushed to develop
> > >>>>> branch,
> > >>>>>>>>> it
> > >>>>>>>>>>>>> needs to be squash merged. I believe that is what you have
> > >>>>> mentioned
> > >>>>>>>>> in
> > >>>>>>>>>>>> the
> > >>>>>>>>>>>>> first paragraph, and I am more than happy with that.
> > >>>>>>>>>>>>> If you can see in the first screenshot comparison that I
> had
> > >>>>> attached
> > >>>>>>>>>> in
> > >>>>>>>>>>>>> the first email in this thread is what I want to avoid.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thank you for your feedback.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>> Naba
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <
> klund@apache.org>
> > >>>>> wrote:
> > >>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I intend
> > to
> > >>>>> rebase
> > >>>>>>>>>> to
> > >>>>>>>>>>>>>> develop, I always try to ensure that each commit stands
> > alone
> > >>> as
> > >>>>> is
> > >>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
> > >>>>> refactoring
> > >>>>>>>>>>>> from
> > >>>>>>>>>>>>>> behavior changes into different commits seems very
> valuable
> > to
> > >>>>> me,
> > >>>>>>>>> and
> > >>>>>>>>>>>> I've
> > >>>>>>>>>>>>>> had trouble getting people to review PRs without this
> > >>> separation
> > >>>>>>>>> (but
> > >>>>>>>>>> it
> > >>>>>>>>>>>>>> could be squashed as it's merged to develop).
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs have
> > >>>>> multiple
> > >>>>>>>>>>>> commits
> > >>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs
> > that
> > >>>>> should
> > >>>>>>>>>> be
> > >>>>>>>>>>>>>> merged with squash are not (by accident most likely).
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with multiple
> > >>>>> commits.
> > >>>>>>>>> So
> > >>>>>>>>>>>> I'll
> > >>>>>>>>>>>>>> change my response to -0 if that helps prevent commits to
> > >>> develop
> > >>>>>>>>> that
> > >>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase or
> > merge
> > >>>>>>>>>> commits
> > >>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this
> or
> > >>>>> prevent
> > >>>>>>>>>> (b)
> > >>>>>>>>>>>>>> above.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > >>>>>>>>>> amurmann@pivotal.io>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily
> at
> > >>>>> odds.
> > >>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then
> make
> > >>> the
> > >>>>>>>>> easy
> > >>>>>>>>>>>>>>>> change."
> > >>>>>>>>>>>>>>> -Kent Beck
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split into
> > two
> > >>>>>>>>> commits.
> > >>>>>>>>>>>> One
> > >>>>>>>>>>>>>>> refactor commit and a separate commit that introduces the
> > >>> actual
> > >>>>>>>>>>>> change.
> > >>>>>>>>>>>>>>> They should be individually revertible and might be
> easier
> > >>>>>>>>> understood
> > >>>>>>>>>>>> if
> > >>>>>>>>>>>>>>> split out. I vividly remember a change on our code base
> > where
> > >>>>>>>>> someone
> > >>>>>>>>>>>>>> did a
> > >>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one
> > parameter
> > >>>>>>>>>> changing
> > >>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>> order to get the desired functionality change. If that
> was
> > in
> > >>>>> one
> > >>>>>>>>>>>> commit,
> > >>>>>>>>>>>>>>> it would be hard to see the actual change. If split out,
> > it's
> > >>>>>>>>>> beautiful
> > >>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>> crystal clear.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA
> > >>> ticket
> > >>>>>>>>>>>>>> references.
> > >>>>>>>>>>>>>>> Usually we assume that if there is a commit with the
> ticket
> > >>>>> number,
> > >>>>>>>>>> the
> > >>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a
> > separate
> > >>>>>>>>>>>> refactoring
> > >>>>>>>>>>>>>>> ticket.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> > nnag@pivotal.io>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>> It is to help with bisect operations when things start
> > >>> failing
> > >>>>> ...
> > >>>>>>>>>>>>>> helps
> > >>>>>>>>>>>>>>> us
> > >>>>>>>>>>>>>>>> it revert and build faster.
> > >>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
> > >>> versions
> > >>>>> .
> > >>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary
> > “merge
> > >>>>>>>>>> commits”.
> > >>>>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>>> Naba
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> > klund@apache.org>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit
> in
> > a
> > >>> PR
> > >>>>> and
> > >>>>>>>>>>>>>> keep
> > >>>>>>>>>>>>>>>> them
> > >>>>>>>>>>>>>>>>> separate when they merge to develop
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> > >>> nnag@pivotal.io>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>> Hi Geode Committers,
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of
> using
> > >>>>> merge.
> > >>>>>>>>>>>>>>>>>> This will really help us in our bisect operations
> when a
> > >>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced. We
> > can
> > >>>>>>>>> automate
> > >>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>> go
> > >>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
> > >>> "spotless
> > >>>>>>>>> fix"
> > >>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the
> > >>> merged
> > >>>>>>>>>>>>>> branch.
> > >>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to know
> > who
> > >>>>>>>>> worked
> > >>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>> it,
> > >>>>>>>>>>>>>>>>>> what is the history)
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> > >>>>>>>>>>>>>>>>>> * explanation line 1 *
> > >>>>>>>>> explanation
> > >>>>>>>>>>>>>>> line
> > >>>>>>>>>>>>>>>> 2*
> > >>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to help
> > out
> > >>>>> your
> > >>>>>>>>>>>>>> fellow
> > >>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark
> > >>> where
> > >>>>>>>>> they
> > >>>>>>>>>>>>>>> have
> > >>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
> > >>>>>>>>> attachment]
> > >>>>>>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>>>>> Naba.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>> --
> > >>>> Ju@N
> > >>>
> >
> >
>
--
Cheers
Jinmei
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
The objections in the discuss thread all seemed to hinge on item 2) of the original proposal. With this item removed, perhaps many or all of those people would no longer vote -1.
Please feel free to “request changes” on the PR if you still want something different -or- to indicate you believe we should not make this change at all. The PR will not be merged unless there is unanimous approval by DEC 31.
> On Dec 20, 2019, at 10:18 AM, Ernest Burghardt <eb...@pivotal.io> wrote:
>
> I'm a proponent of using squash-and-merge, and once a person has chosen
> this option once it comes up by default afterwards...
>
> Owen, I don't think you have consensus to put forth this PR, there are -1s
> above... (early voting)
>
> maybe we'll be better off socializing the norm of squash-and-merge and
> gaining a natural consensus that way...
>
> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <on...@pivotal.io> wrote:
>
>> The proposed action manifests as a commit to the Geode git repository, so
>> a PR is an acceptable vehicle for voting in this case.
>>
>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <bs...@pivotal.io>
>> wrote:
>>>
>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread
>> and a request to "vote" using a PR. This all seems out of order to me.
>> Our votes are supposed to be on the email list, aren't they? and I haven't
>> seen a VOTE request.
>>>
>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
>>>> +1
>>>>
>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io>
>> wrote:
>>>>
>>>>> Based on the feedback so far, I will amend the proposal to drop item
>> 2).
>>>>> Therefore, the current ability to create merge commits using
>> command-line
>>>>> git will remain available.
>>>>>
>>>>> The proposal as amended is now:
>>>>>> Change GitHub settings to make "Squash and merge" the default
>>>>>> (by removing “Create a merge commit” option).
>>>>>>
>>>>>> Update the PR template to change the text "Is your initial
>> contribution
>>>>>> a single, squashed commit” to “Is your initial contribution squashed
>> for
>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
>>>>>> ‘fix’ commit)"
>>>>>
>>>>> As Naba suggested, we can try it, and if we don’t like it, it’s simple
>> to
>>>>> revert.
>>>>>
>>>>> I’ve create a PR for the proposed change here:
>>>>> https://github.com/apache/geode/pull/4513
>>>>>
>>>>> Please use the PR to vote for against this proposal. It will not be
>>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that time)
>>>>>
>>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io>
>> wrote:
>>>>>>
>>>>>>> Hi Bruce, this proposal will not waste a single second of your
>> time. It
>>>>>>> just prevents people from accidentally pressing a button that we have
>>>>>>> already agreed should never be pressed, but because we never
>> configured
>>>>> our
>>>>>>> GitHub to match our stated policy, is currently the default.
>>>>>>>
>>>>>>> However, it will save a lot of time and frustration for anyone
>> needing
>>>>> to
>>>>>>> bisect failures, revert, or cherry-pick changes, which has merit
>> even if
>>>>>>> you personally never do any of those three things.
>>>>>>>
>>>>>>> Please start a separate thread if you would like to revisit the
>>>>> community
>>>>>>> decision to require passing PR checks.
>>>>>>>
>>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
>> bschuchardt@pivotal.io>
>>>>>>> wrote:
>>>>>>>> I agree with Jake. I would go further by saying that I see very
>> little
>>>>>>> merit in this proposal. I think we're getting more and more
>>>>> bureaucratic
>>>>>>> in our process and that it stifles productivity. I was recently
>> forced
>>>>> to
>>>>>>> spend three days fixing tests in which I had changed an import
>> statement
>>>>>>> before they would pass stress testing. I'm glad the tests now pass
>>>>>>> reliably but I was very frustrated by the process.
>>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to flat
>> out
>>>>>>> prevent things that should be self policing is annoying. This PR
>> review
>>>>>>> lock we have had already cost us valuable time waiting for PR
>> pipelines
>>>>> to
>>>>>>> pass that have no relevance to the commit, like CI work: I’d hat to
>> see
>>>>> yet
>>>>>>> another process enforced that Kees us from getting work done when
>>>>> necessary.
>>>>>>>>> -Jake
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>>>>>>>>>>
>>>>>>>>>> -1 to (1) and (2).
>>>>>>>>>>
>>>>>>>>>> I think merge commits are appropriate in certain circumstances,
>> so I
>>>>>>> don't
>>>>>>>>>> think we should make a blanket restriction. In fact I think our
>>>>> release
>>>>>>>>>> process involves some merges.
>>>>>>>>>>
>>>>>>>>>> I think setting standards on what is reasonable to be an
>> individual
>>>>>>> commit
>>>>>>>>>> will do a lot more to clean up our history than blocking merges.
>> We'd
>>>>>>>>>> rather not see commits like "Spotless Apply" in the history, but
>> if
>>>>>>>>>> reasonably separate and well written commits come in as part of a
>>>>>>> merge, I
>>>>>>>>>> think that's fine.
>>>>>>>>>>
>>>>>>>>>> -Dan
>>>>>>>>>>
>>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io>
>>>>>>> wrote:
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <onichols@pivotal.io
>>>
>>>>>>> wrote:
>>>>>>>>>>>> I’d like to advance this topic from an informal
>> request/discussion
>>>>>>> to a
>>>>>>>>>>>> discussion of a concrete proposal.
>>>>>>>>>>>>
>>>>>>>>>>>> To recap, it sounds like there is general agreement that commit
>>>>>>> history
>>>>>>>>>>> on
>>>>>>>>>>>> develop should be linear (no merge commits), and that the
>> biggest
>>>>>>>>>>> obstacle
>>>>>>>>>>>> to this is that the PR merge button in GitHub creates a merge
>>>>> commit
>>>>>>> by
>>>>>>>>>>>> default.
>>>>>>>>>>>>
>>>>>>>>>>>> I propose the following changes:
>>>>>>>>>>>> 1) Change GitHub settings to remove the ability to create a
>> merge
>>>>>>> commit.
>>>>>>>>>>>> This will make Squash & Merge the default.
>>>>>>>>>>>>
>>>>>>>>>>>> 2) Change GitHub settings to require linear history on develop.
>>>>> This
>>>>>>>>>>>> prevents merge commits via command-line (not recommended, but
>> wiki
>>>>>>> still
>>>>>>>>>>>> has instructions for merging PRs this way).
>>>>>>>>>>>>
>>>>>>>>>>>> 3) Update the PR template to change the text "Is your initial
>>>>>>>>>>> contribution
>>>>>>>>>>>> a single, squashed commit” to “Is your initial contribution
>>>>> squashed
>>>>>>> for
>>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
>>>>> plus
>>>>>>> a
>>>>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>>>>
>>>>>>>>>>>> For clarity, I am proposing no-change in the following areas:
>>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
>>>>>>> structured to
>>>>>>>>>>>> benefit from it (this can make it easier in a bisect to see
>> whether
>>>>>>> the
>>>>>>>>>>>> refactoring or the “fix” broke something).
>>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
>>>>> squashing
>>>>>>> is
>>>>>>>>>>>> preferred].
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Please comment via this email thread.
>>>>>>>>>>>> -Owen
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org>
>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think it's already resolved Udo ;)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all
>> uses
>>>>> of
>>>>>>>>>>>> "this."
>>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember that the
>>>>> file
>>>>>>>>>>> is a
>>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new file
>> that I
>>>>>>>>>>>> created
>>>>>>>>>>>>> if I touch more than 50% of the lines (which "this." can easily
>>>>>>> do). If
>>>>>>>>>>>> we
>>>>>>>>>>>>> squash two commits: the rename and the cleanup of that dunit
>> test
>>>>> --
>>>>>>>>>>> then
>>>>>>>>>>>>> we effectively lose the history of that file and it shows that
>> I
>>>>>>>>>>> created
>>>>>>>>>>>> a
>>>>>>>>>>>>> new file.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also for the record, I've been working on Geode since the
>>>>> beginning
>>>>>>>>>>> and I
>>>>>>>>>>>>> was never made aware of this change in our process. I never
>> voted
>>>>> on
>>>>>>>>>>> it.
>>>>>>>>>>>>> I'm not a big fan of changing various details in our process
>> every
>>>>>>>>>>> single
>>>>>>>>>>>>> week. It's very easy to miss these discussions unless someone
>>>>>>> points it
>>>>>>>>>>>> out
>>>>>>>>>>>>> to me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>>>>>>> ukohlmeyer@pivotal.io>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
>> community,
>>>>>>> have
>>>>>>>>>>>>>> agreed in common practices, in two place no less...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1) Quoting our PR template
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For all changes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
>> referenced
>>>>>>> in
>>>>>>>>>>>>>> the commit message?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Has your PR been rebased against the latest commit within the
>>>>>>>>>>> target
>>>>>>>>>>>>>> branch (typically|develop|)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Have you written or updated unit tests to verify your
>> changes?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If adding new dependencies to the code, are these
>> dependencies
>>>>>>>>>>>>>> licensed in a way that is compatible for inclusion underASF
>> 2.0
>>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On our PR template we call out that the initial PR commit
>> should
>>>>> be
>>>>>>>>>>>>>> squashed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2)
>>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>>> <
>>>>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend you
>> on
>>>>> the
>>>>>>>>>>>>>> diligence, but in reality, they should either then be stand
>> alone
>>>>>>> PR's
>>>>>>>>>>>>>> or just extra work created for yourself.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If we want to change the way we have agreed upon we
>>>>>>>>>>> submit/commit/merge
>>>>>>>>>>>>>> changes back into develop... Then this is another discussion
>>>>>>> thread,
>>>>>>>>>>>>>> until then, I think we should all remind ourselves on our
>> agreed
>>>>>>>>>>>>>> contributions code of conduct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --Udo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with multiple
>>>>>>> commits is
>>>>>>>>>>>> ok.
>>>>>>>>>>>>>>> It's just in the end that when it's being pushed to develop
>>>>>>> branch,
>>>>>>>>>>> it
>>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you have
>>>>>>> mentioned
>>>>>>>>>>> in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>>>>>>>>> If you can see in the first screenshot comparison that I had
>>>>>>> attached
>>>>>>>>>>>> in
>>>>>>>>>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you for your feedback.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org>
>>>>>>> wrote:
>>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I intend
>> to
>>>>>>> rebase
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> develop, I always try to ensure that each commit stands
>> alone
>>>>> as
>>>>>>> is
>>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
>>>>>>> refactoring
>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>> behavior changes into different commits seems very valuable
>> to
>>>>>>> me,
>>>>>>>>>>> and
>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>> had trouble getting people to review PRs without this
>>>>> separation
>>>>>>>>>>> (but
>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs have
>>>>>>> multiple
>>>>>>>>>>>>>> commits
>>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs
>> that
>>>>>>> should
>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with multiple
>>>>>>> commits.
>>>>>>>>>>> So
>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>>> change my response to -0 if that helps prevent commits to
>>>>> develop
>>>>>>>>>>> that
>>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase or
>> merge
>>>>>>>>>>>> commits
>>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this or
>>>>>>> prevent
>>>>>>>>>>>> (b)
>>>>>>>>>>>>>>>> above.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>>>>>>>>> amurmann@pivotal.io>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at
>>>>>>> odds.
>>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then make
>>>>> the
>>>>>>>>>>> easy
>>>>>>>>>>>>>>>>>> change."
>>>>>>>>>>>>>>>>> -Kent Beck
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split into
>> two
>>>>>>>>>>> commits.
>>>>>>>>>>>>>> One
>>>>>>>>>>>>>>>>> refactor commit and a separate commit that introduces the
>>>>> actual
>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>> They should be individually revertible and might be easier
>>>>>>>>>>> understood
>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code base
>> where
>>>>>>>>>>> someone
>>>>>>>>>>>>>>>> did a
>>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one
>> parameter
>>>>>>>>>>>> changing
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> order to get the desired functionality change. If that was
>> in
>>>>>>> one
>>>>>>>>>>>>>> commit,
>>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split out,
>> it's
>>>>>>>>>>>> beautiful
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> crystal clear.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA
>>>>> ticket
>>>>>>>>>>>>>>>> references.
>>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with the ticket
>>>>>>> number,
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a
>> separate
>>>>>>>>>>>>>> refactoring
>>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
>> nnag@pivotal.io>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> It is to help with bisect operations when things start
>>>>> failing
>>>>>>> ...
>>>>>>>>>>>>>>>> helps
>>>>>>>>>>>>>>>>> us
>>>>>>>>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
>>>>> versions
>>>>>>> .
>>>>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary
>> “merge
>>>>>>>>>>>> commits”.
>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
>> klund@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in
>> a
>>>>> PR
>>>>>>> and
>>>>>>>>>>>>>>>> keep
>>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>>>>> nnag@pivotal.io>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of using
>>>>>>> merge.
>>>>>>>>>>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced. We
>> can
>>>>>>>>>>> automate
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
>>>>> "spotless
>>>>>>>>>>> fix"
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the
>>>>> merged
>>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to know
>> who
>>>>>>>>>>> worked
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> it,
>>>>>>>>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>>>>>>>>> * explanation line 1 *
>>>>>>>>>>> explanation
>>>>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>>>>> 2*
>>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to help
>> out
>>>>>>> your
>>>>>>>>>>>>>>>> fellow
>>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark
>>>>> where
>>>>>>>>>>> they
>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>>>>>>>>>>> attachment]
>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>> --
>>>>>> Ju@N
>>>>>
>>
>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Ernest Burghardt <eb...@pivotal.io>.
I'm a proponent of using squash-and-merge, and once a person has chosen
this option once it comes up by default afterwards...
Owen, I don't think you have consensus to put forth this PR, there are -1s
above... (early voting)
maybe we'll be better off socializing the norm of squash-and-merge and
gaining a natural consensus that way...
On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols <on...@pivotal.io> wrote:
> The proposed action manifests as a commit to the Geode git repository, so
> a PR is an acceptable vehicle for voting in this case.
>
> > On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <bs...@pivotal.io>
> wrote:
> >
> > I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread
> and a request to "vote" using a PR. This all seems out of order to me.
> Our votes are supposed to be on the email list, aren't they? and I haven't
> seen a VOTE request.
> >
> > On 12/20/19 9:33 AM, Nabarun Nag wrote:
> >> +1
> >>
> >> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io>
> wrote:
> >>
> >>> Based on the feedback so far, I will amend the proposal to drop item
> 2).
> >>> Therefore, the current ability to create merge commits using
> command-line
> >>> git will remain available.
> >>>
> >>> The proposal as amended is now:
> >>>> Change GitHub settings to make "Squash and merge" the default
> >>>> (by removing “Create a merge commit” option).
> >>>>
> >>>> Update the PR template to change the text "Is your initial
> contribution
> >>>> a single, squashed commit” to “Is your initial contribution squashed
> for
> >>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
> >>>> ‘fix’ commit)"
> >>>
> >>> As Naba suggested, we can try it, and if we don’t like it, it’s simple
> to
> >>> revert.
> >>>
> >>> I’ve create a PR for the proposed change here:
> >>> https://github.com/apache/geode/pull/4513
> >>>
> >>> Please use the PR to vote for against this proposal. It will not be
> >>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that time)
> >>>
> >>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
> >>>>
> >>>> +1
> >>>>
> >>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io>
> wrote:
> >>>>
> >>>>> Hi Bruce, this proposal will not waste a single second of your
> time. It
> >>>>> just prevents people from accidentally pressing a button that we have
> >>>>> already agreed should never be pressed, but because we never
> configured
> >>> our
> >>>>> GitHub to match our stated policy, is currently the default.
> >>>>>
> >>>>> However, it will save a lot of time and frustration for anyone
> needing
> >>> to
> >>>>> bisect failures, revert, or cherry-pick changes, which has merit
> even if
> >>>>> you personally never do any of those three things.
> >>>>>
> >>>>> Please start a separate thread if you would like to revisit the
> >>> community
> >>>>> decision to require passing PR checks.
> >>>>>
> >>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> bschuchardt@pivotal.io>
> >>>>> wrote:
> >>>>>> I agree with Jake. I would go further by saying that I see very
> little
> >>>>> merit in this proposal. I think we're getting more and more
> >>> bureaucratic
> >>>>> in our process and that it stifles productivity. I was recently
> forced
> >>> to
> >>>>> spend three days fixing tests in which I had changed an import
> statement
> >>>>> before they would pass stress testing. I'm glad the tests now pass
> >>>>> reliably but I was very frustrated by the process.
> >>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> >>>>>>> I’m in agreement with Dan. Changes to the infrastructure to flat
> out
> >>>>> prevent things that should be self policing is annoying. This PR
> review
> >>>>> lock we have had already cost us valuable time waiting for PR
> pipelines
> >>> to
> >>>>> pass that have no relevance to the commit, like CI work: I’d hat to
> see
> >>> yet
> >>>>> another process enforced that Kees us from getting work done when
> >>> necessary.
> >>>>>>> -Jake
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
> >>>>>>>>
> >>>>>>>> -1 to (1) and (2).
> >>>>>>>>
> >>>>>>>> I think merge commits are appropriate in certain circumstances,
> so I
> >>>>> don't
> >>>>>>>> think we should make a blanket restriction. In fact I think our
> >>> release
> >>>>>>>> process involves some merges.
> >>>>>>>>
> >>>>>>>> I think setting standards on what is reasonable to be an
> individual
> >>>>> commit
> >>>>>>>> will do a lot more to clean up our history than blocking merges.
> We'd
> >>>>>>>> rather not see commits like "Spotless Apply" in the history, but
> if
> >>>>>>>> reasonably separate and well written commits come in as part of a
> >>>>> merge, I
> >>>>>>>> think that's fine.
> >>>>>>>>
> >>>>>>>> -Dan
> >>>>>>>>
> >>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io>
> >>>>> wrote:
> >>>>>>>>> +1
> >>>>>>>>>
> >>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <onichols@pivotal.io
> >
> >>>>> wrote:
> >>>>>>>>>> I’d like to advance this topic from an informal
> request/discussion
> >>>>> to a
> >>>>>>>>>> discussion of a concrete proposal.
> >>>>>>>>>>
> >>>>>>>>>> To recap, it sounds like there is general agreement that commit
> >>>>> history
> >>>>>>>>> on
> >>>>>>>>>> develop should be linear (no merge commits), and that the
> biggest
> >>>>>>>>> obstacle
> >>>>>>>>>> to this is that the PR merge button in GitHub creates a merge
> >>> commit
> >>>>> by
> >>>>>>>>>> default.
> >>>>>>>>>>
> >>>>>>>>>> I propose the following changes:
> >>>>>>>>>> 1) Change GitHub settings to remove the ability to create a
> merge
> >>>>> commit.
> >>>>>>>>>> This will make Squash & Merge the default.
> >>>>>>>>>>
> >>>>>>>>>> 2) Change GitHub settings to require linear history on develop.
> >>> This
> >>>>>>>>>> prevents merge commits via command-line (not recommended, but
> wiki
> >>>>> still
> >>>>>>>>>> has instructions for merging PRs this way).
> >>>>>>>>>>
> >>>>>>>>>> 3) Update the PR template to change the text "Is your initial
> >>>>>>>>> contribution
> >>>>>>>>>> a single, squashed commit” to “Is your initial contribution
> >>> squashed
> >>>>> for
> >>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> >>> plus
> >>>>> a
> >>>>>>>>>> ‘fix’ commit)"
> >>>>>>>>>>
> >>>>>>>>>> For clarity, I am proposing no-change in the following areas:
> >>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
> >>>>> structured to
> >>>>>>>>>> benefit from it (this can make it easier in a bisect to see
> whether
> >>>>> the
> >>>>>>>>>> refactoring or the “fix” broke something).
> >>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
> >>> squashing
> >>>>> is
> >>>>>>>>>> preferred].
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Please comment via this email thread.
> >>>>>>>>>> -Owen
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org>
> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> I think it's already resolved Udo ;)
> >>>>>>>>>>>
> >>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all
> uses
> >>> of
> >>>>>>>>>> "this."
> >>>>>>>>>>> and I rename the dunit test, then git doesn't remember that the
> >>> file
> >>>>>>>>> is a
> >>>>>>>>>>> rename -- it forever afterwards interprets it as a new file
> that I
> >>>>>>>>>> created
> >>>>>>>>>>> if I touch more than 50% of the lines (which "this." can easily
> >>>>> do). If
> >>>>>>>>>> we
> >>>>>>>>>>> squash two commits: the rename and the cleanup of that dunit
> test
> >>> --
> >>>>>>>>> then
> >>>>>>>>>>> we effectively lose the history of that file and it shows that
> I
> >>>>>>>>> created
> >>>>>>>>>> a
> >>>>>>>>>>> new file.
> >>>>>>>>>>>
> >>>>>>>>>>> Also for the record, I've been working on Geode since the
> >>> beginning
> >>>>>>>>> and I
> >>>>>>>>>>> was never made aware of this change in our process. I never
> voted
> >>> on
> >>>>>>>>> it.
> >>>>>>>>>>> I'm not a big fan of changing various details in our process
> every
> >>>>>>>>> single
> >>>>>>>>>>> week. It's very easy to miss these discussions unless someone
> >>>>> points it
> >>>>>>>>>> out
> >>>>>>>>>>> to me.
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> >>>>> ukohlmeyer@pivotal.io>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a
> community,
> >>>>> have
> >>>>>>>>>>>> agreed in common practices, in two place no less...
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1) Quoting our PR template
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> For all changes:
> >>>>>>>>>>>>
> >>>>>>>>>>>> *
> >>>>>>>>>>>>
> >>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it
> referenced
> >>>>> in
> >>>>>>>>>>>> the commit message?
> >>>>>>>>>>>>
> >>>>>>>>>>>> *
> >>>>>>>>>>>>
> >>>>>>>>>>>> Has your PR been rebased against the latest commit within the
> >>>>>>>>> target
> >>>>>>>>>>>> branch (typically|develop|)?
> >>>>>>>>>>>>
> >>>>>>>>>>>> *
> >>>>>>>>>>>>
> >>>>>>>>>>>> ***Is your initial contribution a single, squashed commit?*
> >>>>>>>>>>>>
> >>>>>>>>>>>> *
> >>>>>>>>>>>>
> >>>>>>>>>>>> Does|gradlew build|run cleanly?
> >>>>>>>>>>>>
> >>>>>>>>>>>> *
> >>>>>>>>>>>>
> >>>>>>>>>>>> Have you written or updated unit tests to verify your
> changes?
> >>>>>>>>>>>>
> >>>>>>>>>>>> *
> >>>>>>>>>>>>
> >>>>>>>>>>>> If adding new dependencies to the code, are these
> dependencies
> >>>>>>>>>>>> licensed in a way that is compatible for inclusion underASF
> 2.0
> >>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> >>>>>>>>>>>>
> >>>>>>>>>>>> On our PR template we call out that the initial PR commit
> should
> >>> be
> >>>>>>>>>>>> squashed.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2)
> >>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>>>>> <
> >>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend you
> on
> >>> the
> >>>>>>>>>>>> diligence, but in reality, they should either then be stand
> alone
> >>>>> PR's
> >>>>>>>>>>>> or just extra work created for yourself.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If we want to change the way we have agreed upon we
> >>>>>>>>> submit/commit/merge
> >>>>>>>>>>>> changes back into develop... Then this is another discussion
> >>>>> thread,
> >>>>>>>>>>>> until then, I think we should all remind ourselves on our
> agreed
> >>>>>>>>>>>> contributions code of conduct.
> >>>>>>>>>>>>
> >>>>>>>>>>>> --Udo
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with multiple
> >>>>> commits is
> >>>>>>>>>> ok.
> >>>>>>>>>>>>> It's just in the end that when it's being pushed to develop
> >>>>> branch,
> >>>>>>>>> it
> >>>>>>>>>>>>> needs to be squash merged. I believe that is what you have
> >>>>> mentioned
> >>>>>>>>> in
> >>>>>>>>>>>> the
> >>>>>>>>>>>>> first paragraph, and I am more than happy with that.
> >>>>>>>>>>>>> If you can see in the first screenshot comparison that I had
> >>>>> attached
> >>>>>>>>>> in
> >>>>>>>>>>>>> the first email in this thread is what I want to avoid.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thank you for your feedback.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Regards
> >>>>>>>>>>>>> Naba
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org>
> >>>>> wrote:
> >>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I intend
> to
> >>>>> rebase
> >>>>>>>>>> to
> >>>>>>>>>>>>>> develop, I always try to ensure that each commit stands
> alone
> >>> as
> >>>>> is
> >>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
> >>>>> refactoring
> >>>>>>>>>>>> from
> >>>>>>>>>>>>>> behavior changes into different commits seems very valuable
> to
> >>>>> me,
> >>>>>>>>> and
> >>>>>>>>>>>> I've
> >>>>>>>>>>>>>> had trouble getting people to review PRs without this
> >>> separation
> >>>>>>>>> (but
> >>>>>>>>>> it
> >>>>>>>>>>>>>> could be squashed as it's merged to develop).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs have
> >>>>> multiple
> >>>>>>>>>>>> commits
> >>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs
> that
> >>>>> should
> >>>>>>>>>> be
> >>>>>>>>>>>>>> merged with squash are not (by accident most likely).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with multiple
> >>>>> commits.
> >>>>>>>>> So
> >>>>>>>>>>>> I'll
> >>>>>>>>>>>>>> change my response to -0 if that helps prevent commits to
> >>> develop
> >>>>>>>>> that
> >>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase or
> merge
> >>>>>>>>>> commits
> >>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this or
> >>>>> prevent
> >>>>>>>>>> (b)
> >>>>>>>>>>>>>> above.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >>>>>>>>>> amurmann@pivotal.io>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at
> >>>>> odds.
> >>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then make
> >>> the
> >>>>>>>>> easy
> >>>>>>>>>>>>>>>> change."
> >>>>>>>>>>>>>>> -Kent Beck
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split into
> two
> >>>>>>>>> commits.
> >>>>>>>>>>>> One
> >>>>>>>>>>>>>>> refactor commit and a separate commit that introduces the
> >>> actual
> >>>>>>>>>>>> change.
> >>>>>>>>>>>>>>> They should be individually revertible and might be easier
> >>>>>>>>> understood
> >>>>>>>>>>>> if
> >>>>>>>>>>>>>>> split out. I vividly remember a change on our code base
> where
> >>>>>>>>> someone
> >>>>>>>>>>>>>> did a
> >>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one
> parameter
> >>>>>>>>>> changing
> >>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>> order to get the desired functionality change. If that was
> in
> >>>>> one
> >>>>>>>>>>>> commit,
> >>>>>>>>>>>>>>> it would be hard to see the actual change. If split out,
> it's
> >>>>>>>>>> beautiful
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>> crystal clear.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA
> >>> ticket
> >>>>>>>>>>>>>> references.
> >>>>>>>>>>>>>>> Usually we assume that if there is a commit with the ticket
> >>>>> number,
> >>>>>>>>>> the
> >>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a
> separate
> >>>>>>>>>>>> refactoring
> >>>>>>>>>>>>>>> ticket.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <
> nnag@pivotal.io>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>> It is to help with bisect operations when things start
> >>> failing
> >>>>> ...
> >>>>>>>>>>>>>> helps
> >>>>>>>>>>>>>>> us
> >>>>>>>>>>>>>>>> it revert and build faster.
> >>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
> >>> versions
> >>>>> .
> >>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary
> “merge
> >>>>>>>>>> commits”.
> >>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>> Naba
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <
> klund@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in
> a
> >>> PR
> >>>>> and
> >>>>>>>>>>>>>> keep
> >>>>>>>>>>>>>>>> them
> >>>>>>>>>>>>>>>>> separate when they merge to develop
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> >>> nnag@pivotal.io>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>> Hi Geode Committers,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of using
> >>>>> merge.
> >>>>>>>>>>>>>>>>>> This will really help us in our bisect operations when a
> >>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced. We
> can
> >>>>>>>>> automate
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> go
> >>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
> >>> "spotless
> >>>>>>>>> fix"
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the
> >>> merged
> >>>>>>>>>>>>>> branch.
> >>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to know
> who
> >>>>>>>>> worked
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>> it,
> >>>>>>>>>>>>>>>>>> what is the history)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> >>>>>>>>>>>>>>>>>> * explanation line 1 *
> >>>>>>>>> explanation
> >>>>>>>>>>>>>>> line
> >>>>>>>>>>>>>>>> 2*
> >>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to help
> out
> >>>>> your
> >>>>>>>>>>>>>> fellow
> >>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark
> >>> where
> >>>>>>>>> they
> >>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
> >>>>>>>>> attachment]
> >>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>> Naba.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>> --
> >>>> Ju@N
> >>>
>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Bruce Schuchardt <bs...@pivotal.io>.
well, I always use squash-and-merge so I'm not against the primary
motivation for this thread.
On 12/20/19 10:07 AM, Owen Nichols wrote:
> The proposed action manifests as a commit to the Geode git repository, so a PR is an acceptable vehicle for voting in this case.
>
>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <bs...@pivotal.io> wrote:
>>
>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread and a request to "vote" using a PR. This all seems out of order to me. Our votes are supposed to be on the email list, aren't they? and I haven't seen a VOTE request.
>>
>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
>>> +1
>>>
>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io> wrote:
>>>
>>>> Based on the feedback so far, I will amend the proposal to drop item 2).
>>>> Therefore, the current ability to create merge commits using command-line
>>>> git will remain available.
>>>>
>>>> The proposal as amended is now:
>>>>> Change GitHub settings to make "Squash and merge" the default
>>>>> (by removing “Create a merge commit” option).
>>>>>
>>>>> Update the PR template to change the text "Is your initial contribution
>>>>> a single, squashed commit” to “Is your initial contribution squashed for
>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
>>>>> ‘fix’ commit)"
>>>> As Naba suggested, we can try it, and if we don’t like it, it’s simple to
>>>> revert.
>>>>
>>>> I’ve create a PR for the proposed change here:
>>>> https://github.com/apache/geode/pull/4513
>>>>
>>>> Please use the PR to vote for against this proposal. It will not be
>>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that time)
>>>>
>>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
>>>>>
>>>>> +1
>>>>>
>>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io> wrote:
>>>>>
>>>>>> Hi Bruce, this proposal will not waste a single second of your time. It
>>>>>> just prevents people from accidentally pressing a button that we have
>>>>>> already agreed should never be pressed, but because we never configured
>>>> our
>>>>>> GitHub to match our stated policy, is currently the default.
>>>>>>
>>>>>> However, it will save a lot of time and frustration for anyone needing
>>>> to
>>>>>> bisect failures, revert, or cherry-pick changes, which has merit even if
>>>>>> you personally never do any of those three things.
>>>>>>
>>>>>> Please start a separate thread if you would like to revisit the
>>>> community
>>>>>> decision to require passing PR checks.
>>>>>>
>>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <bs...@pivotal.io>
>>>>>> wrote:
>>>>>>> I agree with Jake. I would go further by saying that I see very little
>>>>>> merit in this proposal. I think we're getting more and more
>>>> bureaucratic
>>>>>> in our process and that it stifles productivity. I was recently forced
>>>> to
>>>>>> spend three days fixing tests in which I had changed an import statement
>>>>>> before they would pass stress testing. I'm glad the tests now pass
>>>>>> reliably but I was very frustrated by the process.
>>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to flat out
>>>>>> prevent things that should be self policing is annoying. This PR review
>>>>>> lock we have had already cost us valuable time waiting for PR pipelines
>>>> to
>>>>>> pass that have no relevance to the commit, like CI work: I’d hat to see
>>>> yet
>>>>>> another process enforced that Kees us from getting work done when
>>>> necessary.
>>>>>>>> -Jake
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>>>>>>>>>
>>>>>>>>> -1 to (1) and (2).
>>>>>>>>>
>>>>>>>>> I think merge commits are appropriate in certain circumstances, so I
>>>>>> don't
>>>>>>>>> think we should make a blanket restriction. In fact I think our
>>>> release
>>>>>>>>> process involves some merges.
>>>>>>>>>
>>>>>>>>> I think setting standards on what is reasonable to be an individual
>>>>>> commit
>>>>>>>>> will do a lot more to clean up our history than blocking merges. We'd
>>>>>>>>> rather not see commits like "Spotless Apply" in the history, but if
>>>>>>>>> reasonably separate and well written commits come in as part of a
>>>>>> merge, I
>>>>>>>>> think that's fine.
>>>>>>>>>
>>>>>>>>> -Dan
>>>>>>>>>
>>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io>
>>>>>> wrote:
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io>
>>>>>> wrote:
>>>>>>>>>>> I’d like to advance this topic from an informal request/discussion
>>>>>> to a
>>>>>>>>>>> discussion of a concrete proposal.
>>>>>>>>>>>
>>>>>>>>>>> To recap, it sounds like there is general agreement that commit
>>>>>> history
>>>>>>>>>> on
>>>>>>>>>>> develop should be linear (no merge commits), and that the biggest
>>>>>>>>>> obstacle
>>>>>>>>>>> to this is that the PR merge button in GitHub creates a merge
>>>> commit
>>>>>> by
>>>>>>>>>>> default.
>>>>>>>>>>>
>>>>>>>>>>> I propose the following changes:
>>>>>>>>>>> 1) Change GitHub settings to remove the ability to create a merge
>>>>>> commit.
>>>>>>>>>>> This will make Squash & Merge the default.
>>>>>>>>>>>
>>>>>>>>>>> 2) Change GitHub settings to require linear history on develop.
>>>> This
>>>>>>>>>>> prevents merge commits via command-line (not recommended, but wiki
>>>>>> still
>>>>>>>>>>> has instructions for merging PRs this way).
>>>>>>>>>>>
>>>>>>>>>>> 3) Update the PR template to change the text "Is your initial
>>>>>>>>>> contribution
>>>>>>>>>>> a single, squashed commit” to “Is your initial contribution
>>>> squashed
>>>>>> for
>>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
>>>> plus
>>>>>> a
>>>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>>>
>>>>>>>>>>> For clarity, I am proposing no-change in the following areas:
>>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
>>>>>> structured to
>>>>>>>>>>> benefit from it (this can make it easier in a bisect to see whether
>>>>>> the
>>>>>>>>>>> refactoring or the “fix” broke something).
>>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
>>>> squashing
>>>>>> is
>>>>>>>>>>> preferred].
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Please comment via this email thread.
>>>>>>>>>>> -Owen
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I think it's already resolved Udo ;)
>>>>>>>>>>>>
>>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all uses
>>>> of
>>>>>>>>>>> "this."
>>>>>>>>>>>> and I rename the dunit test, then git doesn't remember that the
>>>> file
>>>>>>>>>> is a
>>>>>>>>>>>> rename -- it forever afterwards interprets it as a new file that I
>>>>>>>>>>> created
>>>>>>>>>>>> if I touch more than 50% of the lines (which "this." can easily
>>>>>> do). If
>>>>>>>>>>> we
>>>>>>>>>>>> squash two commits: the rename and the cleanup of that dunit test
>>>> --
>>>>>>>>>> then
>>>>>>>>>>>> we effectively lose the history of that file and it shows that I
>>>>>>>>>> created
>>>>>>>>>>> a
>>>>>>>>>>>> new file.
>>>>>>>>>>>>
>>>>>>>>>>>> Also for the record, I've been working on Geode since the
>>>> beginning
>>>>>>>>>> and I
>>>>>>>>>>>> was never made aware of this change in our process. I never voted
>>>> on
>>>>>>>>>> it.
>>>>>>>>>>>> I'm not a big fan of changing various details in our process every
>>>>>>>>>> single
>>>>>>>>>>>> week. It's very easy to miss these discussions unless someone
>>>>>> points it
>>>>>>>>>>> out
>>>>>>>>>>>> to me.
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>>>>>> ukohlmeyer@pivotal.io>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a community,
>>>>>> have
>>>>>>>>>>>>> agreed in common practices, in two place no less...
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) Quoting our PR template
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> For all changes:
>>>>>>>>>>>>>
>>>>>>>>>>>>> *
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it referenced
>>>>>> in
>>>>>>>>>>>>> the commit message?
>>>>>>>>>>>>>
>>>>>>>>>>>>> *
>>>>>>>>>>>>>
>>>>>>>>>>>>> Has your PR been rebased against the latest commit within the
>>>>>>>>>> target
>>>>>>>>>>>>> branch (typically|develop|)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> *
>>>>>>>>>>>>>
>>>>>>>>>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>>>>>>>>>
>>>>>>>>>>>>> *
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>>>>>>>
>>>>>>>>>>>>> *
>>>>>>>>>>>>>
>>>>>>>>>>>>> Have you written or updated unit tests to verify your changes?
>>>>>>>>>>>>>
>>>>>>>>>>>>> *
>>>>>>>>>>>>>
>>>>>>>>>>>>> If adding new dependencies to the code, are these dependencies
>>>>>>>>>>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On our PR template we call out that the initial PR commit should
>>>> be
>>>>>>>>>>>>> squashed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2)
>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>> <
>>>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend you on
>>>> the
>>>>>>>>>>>>> diligence, but in reality, they should either then be stand alone
>>>>>> PR's
>>>>>>>>>>>>> or just extra work created for yourself.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we want to change the way we have agreed upon we
>>>>>>>>>> submit/commit/merge
>>>>>>>>>>>>> changes back into develop... Then this is another discussion
>>>>>> thread,
>>>>>>>>>>>>> until then, I think we should all remind ourselves on our agreed
>>>>>>>>>>>>> contributions code of conduct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Udo
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with multiple
>>>>>> commits is
>>>>>>>>>>> ok.
>>>>>>>>>>>>>> It's just in the end that when it's being pushed to develop
>>>>>> branch,
>>>>>>>>>> it
>>>>>>>>>>>>>> needs to be squash merged. I believe that is what you have
>>>>>> mentioned
>>>>>>>>>> in
>>>>>>>>>>>>> the
>>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>>>>>>>> If you can see in the first screenshot comparison that I had
>>>>>> attached
>>>>>>>>>>> in
>>>>>>>>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you for your feedback.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org>
>>>>>> wrote:
>>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I intend to
>>>>>> rebase
>>>>>>>>>>> to
>>>>>>>>>>>>>>> develop, I always try to ensure that each commit stands alone
>>>> as
>>>>>> is
>>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
>>>>>> refactoring
>>>>>>>>>>>>> from
>>>>>>>>>>>>>>> behavior changes into different commits seems very valuable to
>>>>>> me,
>>>>>>>>>> and
>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>> had trouble getting people to review PRs without this
>>>> separation
>>>>>>>>>> (but
>>>>>>>>>>> it
>>>>>>>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs have
>>>>>> multiple
>>>>>>>>>>>>> commits
>>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that
>>>>>> should
>>>>>>>>>>> be
>>>>>>>>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with multiple
>>>>>> commits.
>>>>>>>>>> So
>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>> change my response to -0 if that helps prevent commits to
>>>> develop
>>>>>>>>>> that
>>>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
>>>>>>>>>>> commits
>>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this or
>>>>>> prevent
>>>>>>>>>>> (b)
>>>>>>>>>>>>>>> above.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>>>>>>>> amurmann@pivotal.io>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at
>>>>>> odds.
>>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then make
>>>> the
>>>>>>>>>> easy
>>>>>>>>>>>>>>>>> change."
>>>>>>>>>>>>>>>> -Kent Beck
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split into two
>>>>>>>>>> commits.
>>>>>>>>>>>>> One
>>>>>>>>>>>>>>>> refactor commit and a separate commit that introduces the
>>>> actual
>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>> They should be individually revertible and might be easier
>>>>>>>>>> understood
>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>> split out. I vividly remember a change on our code base where
>>>>>>>>>> someone
>>>>>>>>>>>>>>> did a
>>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one parameter
>>>>>>>>>>> changing
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> order to get the desired functionality change. If that was in
>>>>>> one
>>>>>>>>>>>>> commit,
>>>>>>>>>>>>>>>> it would be hard to see the actual change. If split out, it's
>>>>>>>>>>> beautiful
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> crystal clear.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA
>>>> ticket
>>>>>>>>>>>>>>> references.
>>>>>>>>>>>>>>>> Usually we assume that if there is a commit with the ticket
>>>>>> number,
>>>>>>>>>>> the
>>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>>>>>>>>>>> refactoring
>>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> It is to help with bisect operations when things start
>>>> failing
>>>>>> ...
>>>>>>>>>>>>>>> helps
>>>>>>>>>>>>>>>> us
>>>>>>>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
>>>> versions
>>>>>> .
>>>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
>>>>>>>>>>> commits”.
>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a
>>>> PR
>>>>>> and
>>>>>>>>>>>>>>> keep
>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>>>> nnag@pivotal.io>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of using
>>>>>> merge.
>>>>>>>>>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced. We can
>>>>>>>>>> automate
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
>>>> "spotless
>>>>>>>>>> fix"
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the
>>>> merged
>>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to know who
>>>>>>>>>> worked
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>> it,
>>>>>>>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>>>>>>>> * explanation line 1 *
>>>>>>>>>> explanation
>>>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>>>> 2*
>>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to help out
>>>>>> your
>>>>>>>>>>>>>>> fellow
>>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark
>>>> where
>>>>>>>>>> they
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>>>>>>>>>> attachment]
>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>> --
>>>>> Ju@N
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
The proposed action manifests as a commit to the Geode git repository, so a PR is an acceptable vehicle for voting in this case.
> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <bs...@pivotal.io> wrote:
>
> I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread and a request to "vote" using a PR. This all seems out of order to me. Our votes are supposed to be on the email list, aren't they? and I haven't seen a VOTE request.
>
> On 12/20/19 9:33 AM, Nabarun Nag wrote:
>> +1
>>
>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io> wrote:
>>
>>> Based on the feedback so far, I will amend the proposal to drop item 2).
>>> Therefore, the current ability to create merge commits using command-line
>>> git will remain available.
>>>
>>> The proposal as amended is now:
>>>> Change GitHub settings to make "Squash and merge" the default
>>>> (by removing “Create a merge commit” option).
>>>>
>>>> Update the PR template to change the text "Is your initial contribution
>>>> a single, squashed commit” to “Is your initial contribution squashed for
>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
>>>> ‘fix’ commit)"
>>>
>>> As Naba suggested, we can try it, and if we don’t like it, it’s simple to
>>> revert.
>>>
>>> I’ve create a PR for the proposed change here:
>>> https://github.com/apache/geode/pull/4513
>>>
>>> Please use the PR to vote for against this proposal. It will not be
>>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that time)
>>>
>>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
>>>>
>>>> +1
>>>>
>>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io> wrote:
>>>>
>>>>> Hi Bruce, this proposal will not waste a single second of your time. It
>>>>> just prevents people from accidentally pressing a button that we have
>>>>> already agreed should never be pressed, but because we never configured
>>> our
>>>>> GitHub to match our stated policy, is currently the default.
>>>>>
>>>>> However, it will save a lot of time and frustration for anyone needing
>>> to
>>>>> bisect failures, revert, or cherry-pick changes, which has merit even if
>>>>> you personally never do any of those three things.
>>>>>
>>>>> Please start a separate thread if you would like to revisit the
>>> community
>>>>> decision to require passing PR checks.
>>>>>
>>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <bs...@pivotal.io>
>>>>> wrote:
>>>>>> I agree with Jake. I would go further by saying that I see very little
>>>>> merit in this proposal. I think we're getting more and more
>>> bureaucratic
>>>>> in our process and that it stifles productivity. I was recently forced
>>> to
>>>>> spend three days fixing tests in which I had changed an import statement
>>>>> before they would pass stress testing. I'm glad the tests now pass
>>>>> reliably but I was very frustrated by the process.
>>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>>>>> I’m in agreement with Dan. Changes to the infrastructure to flat out
>>>>> prevent things that should be self policing is annoying. This PR review
>>>>> lock we have had already cost us valuable time waiting for PR pipelines
>>> to
>>>>> pass that have no relevance to the commit, like CI work: I’d hat to see
>>> yet
>>>>> another process enforced that Kees us from getting work done when
>>> necessary.
>>>>>>> -Jake
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>>>>>>>>
>>>>>>>> -1 to (1) and (2).
>>>>>>>>
>>>>>>>> I think merge commits are appropriate in certain circumstances, so I
>>>>> don't
>>>>>>>> think we should make a blanket restriction. In fact I think our
>>> release
>>>>>>>> process involves some merges.
>>>>>>>>
>>>>>>>> I think setting standards on what is reasonable to be an individual
>>>>> commit
>>>>>>>> will do a lot more to clean up our history than blocking merges. We'd
>>>>>>>> rather not see commits like "Spotless Apply" in the history, but if
>>>>>>>> reasonably separate and well written commits come in as part of a
>>>>> merge, I
>>>>>>>> think that's fine.
>>>>>>>>
>>>>>>>> -Dan
>>>>>>>>
>>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io>
>>>>> wrote:
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io>
>>>>> wrote:
>>>>>>>>>> I’d like to advance this topic from an informal request/discussion
>>>>> to a
>>>>>>>>>> discussion of a concrete proposal.
>>>>>>>>>>
>>>>>>>>>> To recap, it sounds like there is general agreement that commit
>>>>> history
>>>>>>>>> on
>>>>>>>>>> develop should be linear (no merge commits), and that the biggest
>>>>>>>>> obstacle
>>>>>>>>>> to this is that the PR merge button in GitHub creates a merge
>>> commit
>>>>> by
>>>>>>>>>> default.
>>>>>>>>>>
>>>>>>>>>> I propose the following changes:
>>>>>>>>>> 1) Change GitHub settings to remove the ability to create a merge
>>>>> commit.
>>>>>>>>>> This will make Squash & Merge the default.
>>>>>>>>>>
>>>>>>>>>> 2) Change GitHub settings to require linear history on develop.
>>> This
>>>>>>>>>> prevents merge commits via command-line (not recommended, but wiki
>>>>> still
>>>>>>>>>> has instructions for merging PRs this way).
>>>>>>>>>>
>>>>>>>>>> 3) Update the PR template to change the text "Is your initial
>>>>>>>>> contribution
>>>>>>>>>> a single, squashed commit” to “Is your initial contribution
>>> squashed
>>>>> for
>>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
>>> plus
>>>>> a
>>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>>
>>>>>>>>>> For clarity, I am proposing no-change in the following areas:
>>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
>>>>> structured to
>>>>>>>>>> benefit from it (this can make it easier in a bisect to see whether
>>>>> the
>>>>>>>>>> refactoring or the “fix” broke something).
>>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
>>> squashing
>>>>> is
>>>>>>>>>> preferred].
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Please comment via this email thread.
>>>>>>>>>> -Owen
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think it's already resolved Udo ;)
>>>>>>>>>>>
>>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all uses
>>> of
>>>>>>>>>> "this."
>>>>>>>>>>> and I rename the dunit test, then git doesn't remember that the
>>> file
>>>>>>>>> is a
>>>>>>>>>>> rename -- it forever afterwards interprets it as a new file that I
>>>>>>>>>> created
>>>>>>>>>>> if I touch more than 50% of the lines (which "this." can easily
>>>>> do). If
>>>>>>>>>> we
>>>>>>>>>>> squash two commits: the rename and the cleanup of that dunit test
>>> --
>>>>>>>>> then
>>>>>>>>>>> we effectively lose the history of that file and it shows that I
>>>>>>>>> created
>>>>>>>>>> a
>>>>>>>>>>> new file.
>>>>>>>>>>>
>>>>>>>>>>> Also for the record, I've been working on Geode since the
>>> beginning
>>>>>>>>> and I
>>>>>>>>>>> was never made aware of this change in our process. I never voted
>>> on
>>>>>>>>> it.
>>>>>>>>>>> I'm not a big fan of changing various details in our process every
>>>>>>>>> single
>>>>>>>>>>> week. It's very easy to miss these discussions unless someone
>>>>> points it
>>>>>>>>>> out
>>>>>>>>>>> to me.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>>>>> ukohlmeyer@pivotal.io>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a community,
>>>>> have
>>>>>>>>>>>> agreed in common practices, in two place no less...
>>>>>>>>>>>>
>>>>>>>>>>>> 1) Quoting our PR template
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> For all changes:
>>>>>>>>>>>>
>>>>>>>>>>>> *
>>>>>>>>>>>>
>>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it referenced
>>>>> in
>>>>>>>>>>>> the commit message?
>>>>>>>>>>>>
>>>>>>>>>>>> *
>>>>>>>>>>>>
>>>>>>>>>>>> Has your PR been rebased against the latest commit within the
>>>>>>>>> target
>>>>>>>>>>>> branch (typically|develop|)?
>>>>>>>>>>>>
>>>>>>>>>>>> *
>>>>>>>>>>>>
>>>>>>>>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>>>>>>>>
>>>>>>>>>>>> *
>>>>>>>>>>>>
>>>>>>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>>>>>>
>>>>>>>>>>>> *
>>>>>>>>>>>>
>>>>>>>>>>>> Have you written or updated unit tests to verify your changes?
>>>>>>>>>>>>
>>>>>>>>>>>> *
>>>>>>>>>>>>
>>>>>>>>>>>> If adding new dependencies to the code, are these dependencies
>>>>>>>>>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>>>>>>>
>>>>>>>>>>>> On our PR template we call out that the initial PR commit should
>>> be
>>>>>>>>>>>> squashed.
>>>>>>>>>>>>
>>>>>>>>>>>> 2)
>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>> <
>>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend you on
>>> the
>>>>>>>>>>>> diligence, but in reality, they should either then be stand alone
>>>>> PR's
>>>>>>>>>>>> or just extra work created for yourself.
>>>>>>>>>>>>
>>>>>>>>>>>> If we want to change the way we have agreed upon we
>>>>>>>>> submit/commit/merge
>>>>>>>>>>>> changes back into develop... Then this is another discussion
>>>>> thread,
>>>>>>>>>>>> until then, I think we should all remind ourselves on our agreed
>>>>>>>>>>>> contributions code of conduct.
>>>>>>>>>>>>
>>>>>>>>>>>> --Udo
>>>>>>>>>>>>
>>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with multiple
>>>>> commits is
>>>>>>>>>> ok.
>>>>>>>>>>>>> It's just in the end that when it's being pushed to develop
>>>>> branch,
>>>>>>>>> it
>>>>>>>>>>>>> needs to be squash merged. I believe that is what you have
>>>>> mentioned
>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>>>>>>> If you can see in the first screenshot comparison that I had
>>>>> attached
>>>>>>>>>> in
>>>>>>>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you for your feedback.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org>
>>>>> wrote:
>>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I intend to
>>>>> rebase
>>>>>>>>>> to
>>>>>>>>>>>>>> develop, I always try to ensure that each commit stands alone
>>> as
>>>>> is
>>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
>>>>> refactoring
>>>>>>>>>>>> from
>>>>>>>>>>>>>> behavior changes into different commits seems very valuable to
>>>>> me,
>>>>>>>>> and
>>>>>>>>>>>> I've
>>>>>>>>>>>>>> had trouble getting people to review PRs without this
>>> separation
>>>>>>>>> (but
>>>>>>>>>> it
>>>>>>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs have
>>>>> multiple
>>>>>>>>>>>> commits
>>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that
>>>>> should
>>>>>>>>>> be
>>>>>>>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with multiple
>>>>> commits.
>>>>>>>>> So
>>>>>>>>>>>> I'll
>>>>>>>>>>>>>> change my response to -0 if that helps prevent commits to
>>> develop
>>>>>>>>> that
>>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
>>>>>>>>>> commits
>>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this or
>>>>> prevent
>>>>>>>>>> (b)
>>>>>>>>>>>>>> above.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>>>>>>> amurmann@pivotal.io>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at
>>>>> odds.
>>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then make
>>> the
>>>>>>>>> easy
>>>>>>>>>>>>>>>> change."
>>>>>>>>>>>>>>> -Kent Beck
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split into two
>>>>>>>>> commits.
>>>>>>>>>>>> One
>>>>>>>>>>>>>>> refactor commit and a separate commit that introduces the
>>> actual
>>>>>>>>>>>> change.
>>>>>>>>>>>>>>> They should be individually revertible and might be easier
>>>>>>>>> understood
>>>>>>>>>>>> if
>>>>>>>>>>>>>>> split out. I vividly remember a change on our code base where
>>>>>>>>> someone
>>>>>>>>>>>>>> did a
>>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one parameter
>>>>>>>>>> changing
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> order to get the desired functionality change. If that was in
>>>>> one
>>>>>>>>>>>> commit,
>>>>>>>>>>>>>>> it would be hard to see the actual change. If split out, it's
>>>>>>>>>> beautiful
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> crystal clear.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA
>>> ticket
>>>>>>>>>>>>>> references.
>>>>>>>>>>>>>>> Usually we assume that if there is a commit with the ticket
>>>>> number,
>>>>>>>>>> the
>>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>>>>>>>>>> refactoring
>>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> It is to help with bisect operations when things start
>>> failing
>>>>> ...
>>>>>>>>>>>>>> helps
>>>>>>>>>>>>>>> us
>>>>>>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
>>> versions
>>>>> .
>>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
>>>>>>>>>> commits”.
>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a
>>> PR
>>>>> and
>>>>>>>>>>>>>> keep
>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>>> nnag@pivotal.io>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of using
>>>>> merge.
>>>>>>>>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced. We can
>>>>>>>>> automate
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
>>> "spotless
>>>>>>>>> fix"
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the
>>> merged
>>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to know who
>>>>>>>>> worked
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> it,
>>>>>>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>>>>>>> * explanation line 1 *
>>>>>>>>> explanation
>>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>>> 2*
>>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to help out
>>>>> your
>>>>>>>>>>>>>> fellow
>>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark
>>> where
>>>>>>>>> they
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>>>>>>>>> attachment]
>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>> --
>>>> Ju@N
>>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Bruce Schuchardt <bs...@pivotal.io>.
I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread
and a request to "vote" using a PR. This all seems out of order to me.
Our votes are supposed to be on the email list, aren't they? and I
haven't seen a VOTE request.
On 12/20/19 9:33 AM, Nabarun Nag wrote:
> +1
>
> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io> wrote:
>
>> Based on the feedback so far, I will amend the proposal to drop item 2).
>> Therefore, the current ability to create merge commits using command-line
>> git will remain available.
>>
>> The proposal as amended is now:
>>> Change GitHub settings to make "Squash and merge" the default
>>> (by removing “Create a merge commit” option).
>>>
>>> Update the PR template to change the text "Is your initial contribution
>>> a single, squashed commit” to “Is your initial contribution squashed for
>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
>>> ‘fix’ commit)"
>>
>> As Naba suggested, we can try it, and if we don’t like it, it’s simple to
>> revert.
>>
>> I’ve create a PR for the proposed change here:
>> https://github.com/apache/geode/pull/4513
>>
>> Please use the PR to vote for against this proposal. It will not be
>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that time)
>>
>>> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
>>>
>>> +1
>>>
>>> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io> wrote:
>>>
>>>> Hi Bruce, this proposal will not waste a single second of your time. It
>>>> just prevents people from accidentally pressing a button that we have
>>>> already agreed should never be pressed, but because we never configured
>> our
>>>> GitHub to match our stated policy, is currently the default.
>>>>
>>>> However, it will save a lot of time and frustration for anyone needing
>> to
>>>> bisect failures, revert, or cherry-pick changes, which has merit even if
>>>> you personally never do any of those three things.
>>>>
>>>> Please start a separate thread if you would like to revisit the
>> community
>>>> decision to require passing PR checks.
>>>>
>>>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <bs...@pivotal.io>
>>>> wrote:
>>>>> I agree with Jake. I would go further by saying that I see very little
>>>> merit in this proposal. I think we're getting more and more
>> bureaucratic
>>>> in our process and that it stifles productivity. I was recently forced
>> to
>>>> spend three days fixing tests in which I had changed an import statement
>>>> before they would pass stress testing. I'm glad the tests now pass
>>>> reliably but I was very frustrated by the process.
>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>>>> I’m in agreement with Dan. Changes to the infrastructure to flat out
>>>> prevent things that should be self policing is annoying. This PR review
>>>> lock we have had already cost us valuable time waiting for PR pipelines
>> to
>>>> pass that have no relevance to the commit, like CI work: I’d hat to see
>> yet
>>>> another process enforced that Kees us from getting work done when
>> necessary.
>>>>>> -Jake
>>>>>>
>>>>>>
>>>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>>>>>>>
>>>>>>> -1 to (1) and (2).
>>>>>>>
>>>>>>> I think merge commits are appropriate in certain circumstances, so I
>>>> don't
>>>>>>> think we should make a blanket restriction. In fact I think our
>> release
>>>>>>> process involves some merges.
>>>>>>>
>>>>>>> I think setting standards on what is reasonable to be an individual
>>>> commit
>>>>>>> will do a lot more to clean up our history than blocking merges. We'd
>>>>>>> rather not see commits like "Spotless Apply" in the history, but if
>>>>>>> reasonably separate and well written commits come in as part of a
>>>> merge, I
>>>>>>> think that's fine.
>>>>>>>
>>>>>>> -Dan
>>>>>>>
>>>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io>
>>>> wrote:
>>>>>>>> +1
>>>>>>>>
>>>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io>
>>>> wrote:
>>>>>>>>> I’d like to advance this topic from an informal request/discussion
>>>> to a
>>>>>>>>> discussion of a concrete proposal.
>>>>>>>>>
>>>>>>>>> To recap, it sounds like there is general agreement that commit
>>>> history
>>>>>>>> on
>>>>>>>>> develop should be linear (no merge commits), and that the biggest
>>>>>>>> obstacle
>>>>>>>>> to this is that the PR merge button in GitHub creates a merge
>> commit
>>>> by
>>>>>>>>> default.
>>>>>>>>>
>>>>>>>>> I propose the following changes:
>>>>>>>>> 1) Change GitHub settings to remove the ability to create a merge
>>>> commit.
>>>>>>>>> This will make Squash & Merge the default.
>>>>>>>>>
>>>>>>>>> 2) Change GitHub settings to require linear history on develop.
>> This
>>>>>>>>> prevents merge commits via command-line (not recommended, but wiki
>>>> still
>>>>>>>>> has instructions for merging PRs this way).
>>>>>>>>>
>>>>>>>>> 3) Update the PR template to change the text "Is your initial
>>>>>>>> contribution
>>>>>>>>> a single, squashed commit” to “Is your initial contribution
>> squashed
>>>> for
>>>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
>> plus
>>>> a
>>>>>>>>> ‘fix’ commit)"
>>>>>>>>>
>>>>>>>>> For clarity, I am proposing no-change in the following areas:
>>>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
>>>> structured to
>>>>>>>>> benefit from it (this can make it easier in a bisect to see whether
>>>> the
>>>>>>>>> refactoring or the “fix” broke something).
>>>>>>>>> ii) Leave existing wording in the wiki as-is [stating that
>> squashing
>>>> is
>>>>>>>>> preferred].
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please comment via this email thread.
>>>>>>>>> -Owen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>> I think it's already resolved Udo ;)
>>>>>>>>>>
>>>>>>>>>> Here's the problem, if I fixup a dunit test by removing all uses
>> of
>>>>>>>>> "this."
>>>>>>>>>> and I rename the dunit test, then git doesn't remember that the
>> file
>>>>>>>> is a
>>>>>>>>>> rename -- it forever afterwards interprets it as a new file that I
>>>>>>>>> created
>>>>>>>>>> if I touch more than 50% of the lines (which "this." can easily
>>>> do). If
>>>>>>>>> we
>>>>>>>>>> squash two commits: the rename and the cleanup of that dunit test
>> --
>>>>>>>> then
>>>>>>>>>> we effectively lose the history of that file and it shows that I
>>>>>>>> created
>>>>>>>>> a
>>>>>>>>>> new file.
>>>>>>>>>>
>>>>>>>>>> Also for the record, I've been working on Geode since the
>> beginning
>>>>>>>> and I
>>>>>>>>>> was never made aware of this change in our process. I never voted
>> on
>>>>>>>> it.
>>>>>>>>>> I'm not a big fan of changing various details in our process every
>>>>>>>> single
>>>>>>>>>> week. It's very easy to miss these discussions unless someone
>>>> points it
>>>>>>>>> out
>>>>>>>>>> to me.
>>>>>>>>>>
>>>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>>>> ukohlmeyer@pivotal.io>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I'm not sure what this discussion is about... WE, as a community,
>>>> have
>>>>>>>>>>> agreed in common practices, in two place no less...
>>>>>>>>>>>
>>>>>>>>>>> 1) Quoting our PR template
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> For all changes:
>>>>>>>>>>>
>>>>>>>>>>> *
>>>>>>>>>>>
>>>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it referenced
>>>> in
>>>>>>>>>>> the commit message?
>>>>>>>>>>>
>>>>>>>>>>> *
>>>>>>>>>>>
>>>>>>>>>>> Has your PR been rebased against the latest commit within the
>>>>>>>> target
>>>>>>>>>>> branch (typically|develop|)?
>>>>>>>>>>>
>>>>>>>>>>> *
>>>>>>>>>>>
>>>>>>>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>>>>>>>
>>>>>>>>>>> *
>>>>>>>>>>>
>>>>>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>>>>>
>>>>>>>>>>> *
>>>>>>>>>>>
>>>>>>>>>>> Have you written or updated unit tests to verify your changes?
>>>>>>>>>>>
>>>>>>>>>>> *
>>>>>>>>>>>
>>>>>>>>>>> If adding new dependencies to the code, are these dependencies
>>>>>>>>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>>>>>>
>>>>>>>>>>> On our PR template we call out that the initial PR commit should
>> be
>>>>>>>>>>> squashed.
>>>>>>>>>>>
>>>>>>>>>>> 2)
>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>> <
>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend you on
>> the
>>>>>>>>>>> diligence, but in reality, they should either then be stand alone
>>>> PR's
>>>>>>>>>>> or just extra work created for yourself.
>>>>>>>>>>>
>>>>>>>>>>> If we want to change the way we have agreed upon we
>>>>>>>> submit/commit/merge
>>>>>>>>>>> changes back into develop... Then this is another discussion
>>>> thread,
>>>>>>>>>>> until then, I think we should all remind ourselves on our agreed
>>>>>>>>>>> contributions code of conduct.
>>>>>>>>>>>
>>>>>>>>>>> --Udo
>>>>>>>>>>>
>>>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>>>>>> Kirk, I believe that creating a Pull Request with multiple
>>>> commits is
>>>>>>>>> ok.
>>>>>>>>>>>> It's just in the end that when it's being pushed to develop
>>>> branch,
>>>>>>>> it
>>>>>>>>>>>> needs to be squash merged. I believe that is what you have
>>>> mentioned
>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>>>>>> If you can see in the first screenshot comparison that I had
>>>> attached
>>>>>>>>> in
>>>>>>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you for your feedback.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Naba
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org>
>>>> wrote:
>>>>>>>>>>>>> Whenever I submit a PR with multiple commits that I intend to
>>>> rebase
>>>>>>>>> to
>>>>>>>>>>>>> develop, I always try to ensure that each commit stands alone
>> as
>>>> is
>>>>>>>>>>>>> (compiles and passes tests). Separating file renames and
>>>> refactoring
>>>>>>>>>>> from
>>>>>>>>>>>>> behavior changes into different commits seems very valuable to
>>>> me,
>>>>>>>> and
>>>>>>>>>>> I've
>>>>>>>>>>>>> had trouble getting people to review PRs without this
>> separation
>>>>>>>> (but
>>>>>>>>> it
>>>>>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>>>>>
>>>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs have
>>>> multiple
>>>>>>>>>>> commits
>>>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that
>>>> should
>>>>>>>>> be
>>>>>>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can submit multiple PRs instead of one PR with multiple
>>>> commits.
>>>>>>>> So
>>>>>>>>>>> I'll
>>>>>>>>>>>>> change my response to -0 if that helps prevent commits to
>> develop
>>>>>>>> that
>>>>>>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
>>>>>>>>> commits
>>>>>>>>>>>>> from github, I'm not sure how we can really enforce this or
>>>> prevent
>>>>>>>>> (b)
>>>>>>>>>>>>> above.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>>>>>> amurmann@pivotal.io>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at
>>>> odds.
>>>>>>>>>>>>>> Make the change easy (warning: this may be hard), then make
>> the
>>>>>>>> easy
>>>>>>>>>>>>>>> change."
>>>>>>>>>>>>>> -Kent Beck
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Following Kent Beck's advise might reasonably split into two
>>>>>>>> commits.
>>>>>>>>>>> One
>>>>>>>>>>>>>> refactor commit and a separate commit that introduces the
>> actual
>>>>>>>>>>> change.
>>>>>>>>>>>>>> They should be individually revertible and might be easier
>>>>>>>> understood
>>>>>>>>>>> if
>>>>>>>>>>>>>> split out. I vividly remember a change on our code base where
>>>>>>>> someone
>>>>>>>>>>>>> did a
>>>>>>>>>>>>>> huge amount of refactoring that resulted than in one parameter
>>>>>>>>> changing
>>>>>>>>>>>>> in
>>>>>>>>>>>>>> order to get the desired functionality change. If that was in
>>>> one
>>>>>>>>>>> commit,
>>>>>>>>>>>>>> it would be hard to see the actual change. If split out, it's
>>>>>>>>> beautiful
>>>>>>>>>>>>> and
>>>>>>>>>>>>>> crystal clear.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA
>> ticket
>>>>>>>>>>>>> references.
>>>>>>>>>>>>>> Usually we assume that if there is a commit with the ticket
>>>> number,
>>>>>>>>> the
>>>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>>>>>>>>> refactoring
>>>>>>>>>>>>>> ticket.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
>>>>>>>> wrote:
>>>>>>>>>>>>>>> It is to help with bisect operations when things start
>> failing
>>>> ...
>>>>>>>>>>>>> helps
>>>>>>>>>>>>>> us
>>>>>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>>>>>> also with cherry picking features / fixes to previous
>> versions
>>>> .
>>>>>>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
>>>>>>>>> commits”.
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a
>> PR
>>>> and
>>>>>>>>>>>>> keep
>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
>> nnag@pivotal.io>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A kind request for using squash commit instead of using
>>>> merge.
>>>>>>>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>>>>>>>> regression/flakiness in the product is introduced. We can
>>>>>>>> automate
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> go
>>>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
>> "spotless
>>>>>>>> fix"
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the
>> merged
>>>>>>>>>>>>> branch.
>>>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to know who
>>>>>>>> worked
>>>>>>>>>>>>> on
>>>>>>>>>>>>>>> it,
>>>>>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>>>>>> * explanation line 1 *
>>>>>>>> explanation
>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>> 2*
>>>>>>>>>>>>>>>>> This is not a rule or anything, but a request to help out
>>>> your
>>>>>>>>>>>>> fellow
>>>>>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark
>> where
>>>>>>>> they
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>>>>>>>> attachment]
>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>> --
>>> Ju@N
>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Nabarun Nag <nn...@pivotal.io>.
+1
On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols <on...@pivotal.io> wrote:
> Based on the feedback so far, I will amend the proposal to drop item 2).
> Therefore, the current ability to create merge commits using command-line
> git will remain available.
>
> The proposal as amended is now:
> > Change GitHub settings to make "Squash and merge" the default
> > (by removing “Create a merge commit” option).
> >
> > Update the PR template to change the text "Is your initial contribution
> > a single, squashed commit” to “Is your initial contribution squashed for
> > ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
> > ‘fix’ commit)"
>
>
> As Naba suggested, we can try it, and if we don’t like it, it’s simple to
> revert.
>
> I’ve create a PR for the proposed change here:
> https://github.com/apache/geode/pull/4513
>
> Please use the PR to vote for against this proposal. It will not be
> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that time)
>
> > On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
> >
> > +1
> >
> > On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io> wrote:
> >
> >> Hi Bruce, this proposal will not waste a single second of your time. It
> >> just prevents people from accidentally pressing a button that we have
> >> already agreed should never be pressed, but because we never configured
> our
> >> GitHub to match our stated policy, is currently the default.
> >>
> >> However, it will save a lot of time and frustration for anyone needing
> to
> >> bisect failures, revert, or cherry-pick changes, which has merit even if
> >> you personally never do any of those three things.
> >>
> >> Please start a separate thread if you would like to revisit the
> community
> >> decision to require passing PR checks.
> >>
> >>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <bs...@pivotal.io>
> >> wrote:
> >>>
> >>> I agree with Jake. I would go further by saying that I see very little
> >> merit in this proposal. I think we're getting more and more
> bureaucratic
> >> in our process and that it stifles productivity. I was recently forced
> to
> >> spend three days fixing tests in which I had changed an import statement
> >> before they would pass stress testing. I'm glad the tests now pass
> >> reliably but I was very frustrated by the process.
> >>>
> >>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> >>>> I’m in agreement with Dan. Changes to the infrastructure to flat out
> >> prevent things that should be self policing is annoying. This PR review
> >> lock we have had already cost us valuable time waiting for PR pipelines
> to
> >> pass that have no relevance to the commit, like CI work: I’d hat to see
> yet
> >> another process enforced that Kees us from getting work done when
> necessary.
> >>>>
> >>>> -Jake
> >>>>
> >>>>
> >>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
> >>>>>
> >>>>> -1 to (1) and (2).
> >>>>>
> >>>>> I think merge commits are appropriate in certain circumstances, so I
> >> don't
> >>>>> think we should make a blanket restriction. In fact I think our
> release
> >>>>> process involves some merges.
> >>>>>
> >>>>> I think setting standards on what is reasonable to be an individual
> >> commit
> >>>>> will do a lot more to clean up our history than blocking merges. We'd
> >>>>> rather not see commits like "Spotless Apply" in the history, but if
> >>>>> reasonably separate and well written commits come in as part of a
> >> merge, I
> >>>>> think that's fine.
> >>>>>
> >>>>> -Dan
> >>>>>
> >>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io>
> >> wrote:
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io>
> >> wrote:
> >>>>>>>
> >>>>>>> I’d like to advance this topic from an informal request/discussion
> >> to a
> >>>>>>> discussion of a concrete proposal.
> >>>>>>>
> >>>>>>> To recap, it sounds like there is general agreement that commit
> >> history
> >>>>>> on
> >>>>>>> develop should be linear (no merge commits), and that the biggest
> >>>>>> obstacle
> >>>>>>> to this is that the PR merge button in GitHub creates a merge
> commit
> >> by
> >>>>>>> default.
> >>>>>>>
> >>>>>>> I propose the following changes:
> >>>>>>> 1) Change GitHub settings to remove the ability to create a merge
> >> commit.
> >>>>>>> This will make Squash & Merge the default.
> >>>>>>>
> >>>>>>> 2) Change GitHub settings to require linear history on develop.
> This
> >>>>>>> prevents merge commits via command-line (not recommended, but wiki
> >> still
> >>>>>>> has instructions for merging PRs this way).
> >>>>>>>
> >>>>>>> 3) Update the PR template to change the text "Is your initial
> >>>>>> contribution
> >>>>>>> a single, squashed commit” to “Is your initial contribution
> squashed
> >> for
> >>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit
> plus
> >> a
> >>>>>>> ‘fix’ commit)"
> >>>>>>>
> >>>>>>> For clarity, I am proposing no-change in the following areas:
> >>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
> >> structured to
> >>>>>>> benefit from it (this can make it easier in a bisect to see whether
> >> the
> >>>>>>> refactoring or the “fix” broke something).
> >>>>>>> ii) Leave existing wording in the wiki as-is [stating that
> squashing
> >> is
> >>>>>>> preferred].
> >>>>>>>
> >>>>>>>
> >>>>>>> Please comment via this email thread.
> >>>>>>> -Owen
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
> >>>>>>>>
> >>>>>>>> I think it's already resolved Udo ;)
> >>>>>>>>
> >>>>>>>> Here's the problem, if I fixup a dunit test by removing all uses
> of
> >>>>>>> "this."
> >>>>>>>> and I rename the dunit test, then git doesn't remember that the
> file
> >>>>>> is a
> >>>>>>>> rename -- it forever afterwards interprets it as a new file that I
> >>>>>>> created
> >>>>>>>> if I touch more than 50% of the lines (which "this." can easily
> >> do). If
> >>>>>>> we
> >>>>>>>> squash two commits: the rename and the cleanup of that dunit test
> --
> >>>>>> then
> >>>>>>>> we effectively lose the history of that file and it shows that I
> >>>>>> created
> >>>>>>> a
> >>>>>>>> new file.
> >>>>>>>>
> >>>>>>>> Also for the record, I've been working on Geode since the
> beginning
> >>>>>> and I
> >>>>>>>> was never made aware of this change in our process. I never voted
> on
> >>>>>> it.
> >>>>>>>> I'm not a big fan of changing various details in our process every
> >>>>>> single
> >>>>>>>> week. It's very easy to miss these discussions unless someone
> >> points it
> >>>>>>> out
> >>>>>>>> to me.
> >>>>>>>>
> >>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> >> ukohlmeyer@pivotal.io>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I'm not sure what this discussion is about... WE, as a community,
> >> have
> >>>>>>>>> agreed in common practices, in two place no less...
> >>>>>>>>>
> >>>>>>>>> 1) Quoting our PR template
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> For all changes:
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> Is there a JIRA ticket associated with this PR? Is it referenced
> >> in
> >>>>>>>>> the commit message?
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> Has your PR been rebased against the latest commit within the
> >>>>>> target
> >>>>>>>>> branch (typically|develop|)?
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> ***Is your initial contribution a single, squashed commit?*
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> Does|gradlew build|run cleanly?
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> Have you written or updated unit tests to verify your changes?
> >>>>>>>>>
> >>>>>>>>> *
> >>>>>>>>>
> >>>>>>>>> If adding new dependencies to the code, are these dependencies
> >>>>>>>>> licensed in a way that is compatible for inclusion underASF 2.0
> >>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> >>>>>>>>>
> >>>>>>>>> On our PR template we call out that the initial PR commit should
> be
> >>>>>>>>> squashed.
> >>>>>>>>>
> >>>>>>>>> 2)
> >>>>>>
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>> <
> >> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> @Kirk, if each of your commits "stands alone", I commend you on
> the
> >>>>>>>>> diligence, but in reality, they should either then be stand alone
> >> PR's
> >>>>>>>>> or just extra work created for yourself.
> >>>>>>>>>
> >>>>>>>>> If we want to change the way we have agreed upon we
> >>>>>> submit/commit/merge
> >>>>>>>>> changes back into develop... Then this is another discussion
> >> thread,
> >>>>>>>>> until then, I think we should all remind ourselves on our agreed
> >>>>>>>>> contributions code of conduct.
> >>>>>>>>>
> >>>>>>>>> --Udo
> >>>>>>>>>
> >>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >>>>>>>>>> Kirk, I believe that creating a Pull Request with multiple
> >> commits is
> >>>>>>> ok.
> >>>>>>>>>> It's just in the end that when it's being pushed to develop
> >> branch,
> >>>>>> it
> >>>>>>>>>> needs to be squash merged. I believe that is what you have
> >> mentioned
> >>>>>> in
> >>>>>>>>> the
> >>>>>>>>>> first paragraph, and I am more than happy with that.
> >>>>>>>>>> If you can see in the first screenshot comparison that I had
> >> attached
> >>>>>>> in
> >>>>>>>>>> the first email in this thread is what I want to avoid.
> >>>>>>>>>>
> >>>>>>>>>> Thank you for your feedback.
> >>>>>>>>>>
> >>>>>>>>>> Regards
> >>>>>>>>>> Naba
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org>
> >> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Whenever I submit a PR with multiple commits that I intend to
> >> rebase
> >>>>>>> to
> >>>>>>>>>>> develop, I always try to ensure that each commit stands alone
> as
> >> is
> >>>>>>>>>>> (compiles and passes tests). Separating file renames and
> >> refactoring
> >>>>>>>>> from
> >>>>>>>>>>> behavior changes into different commits seems very valuable to
> >> me,
> >>>>>> and
> >>>>>>>>> I've
> >>>>>>>>>>> had trouble getting people to review PRs without this
> separation
> >>>>>> (but
> >>>>>>> it
> >>>>>>>>>>> could be squashed as it's merged to develop).
> >>>>>>>>>>>
> >>>>>>>>>>> It sounds to me like the real problem is (a) some PRs have
> >> multiple
> >>>>>>>>> commits
> >>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that
> >> should
> >>>>>>> be
> >>>>>>>>>>> merged with squash are not (by accident most likely).
> >>>>>>>>>>>
> >>>>>>>>>>> I can submit multiple PRs instead of one PR with multiple
> >> commits.
> >>>>>> So
> >>>>>>>>> I'll
> >>>>>>>>>>> change my response to -0 if that helps prevent commits to
> develop
> >>>>>> that
> >>>>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
> >>>>>>> commits
> >>>>>>>>>>> from github, I'm not sure how we can really enforce this or
> >> prevent
> >>>>>>> (b)
> >>>>>>>>>>> above.
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >>>>>>> amurmann@pivotal.io>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at
> >> odds.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Make the change easy (warning: this may be hard), then make
> the
> >>>>>> easy
> >>>>>>>>>>>>> change."
> >>>>>>>>>>>> -Kent Beck
> >>>>>>>>>>>>
> >>>>>>>>>>>> Following Kent Beck's advise might reasonably split into two
> >>>>>> commits.
> >>>>>>>>> One
> >>>>>>>>>>>> refactor commit and a separate commit that introduces the
> actual
> >>>>>>>>> change.
> >>>>>>>>>>>> They should be individually revertible and might be easier
> >>>>>> understood
> >>>>>>>>> if
> >>>>>>>>>>>> split out. I vividly remember a change on our code base where
> >>>>>> someone
> >>>>>>>>>>> did a
> >>>>>>>>>>>> huge amount of refactoring that resulted than in one parameter
> >>>>>>> changing
> >>>>>>>>>>> in
> >>>>>>>>>>>> order to get the desired functionality change. If that was in
> >> one
> >>>>>>>>> commit,
> >>>>>>>>>>>> it would be hard to see the actual change. If split out, it's
> >>>>>>> beautiful
> >>>>>>>>>>> and
> >>>>>>>>>>>> crystal clear.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA
> ticket
> >>>>>>>>>>> references.
> >>>>>>>>>>>> Usually we assume that if there is a commit with the ticket
> >> number,
> >>>>>>> the
> >>>>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
> >>>>>>>>> refactoring
> >>>>>>>>>>>> ticket.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Would that allow us to have our cake and eat it too?
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
> >>>>>> wrote:
> >>>>>>>>>>>>> It is to help with bisect operations when things start
> failing
> >> ...
> >>>>>>>>>>> helps
> >>>>>>>>>>>> us
> >>>>>>>>>>>>> it revert and build faster.
> >>>>>>>>>>>>> also with cherry picking features / fixes to previous
> versions
> >> .
> >>>>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
> >>>>>>> commits”.
> >>>>>>>>>>>>> Regards
> >>>>>>>>>>>>> Naba
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
> >>>>>> wrote:
> >>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a
> PR
> >> and
> >>>>>>>>>>> keep
> >>>>>>>>>>>>> them
> >>>>>>>>>>>>>> separate when they merge to develop
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <
> nnag@pivotal.io>
> >>>>>>> wrote:
> >>>>>>>>>>>>>>> Hi Geode Committers,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> A kind request for using squash commit instead of using
> >> merge.
> >>>>>>>>>>>>>>> This will really help us in our bisect operations when a
> >>>>>>>>>>>>>>> regression/flakiness in the product is introduced. We can
> >>>>>> automate
> >>>>>>>>>>>> and
> >>>>>>>>>>>>> go
> >>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like
> "spotless
> >>>>>> fix"
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the
> merged
> >>>>>>>>>>> branch.
> >>>>>>>>>>>>>>> Also, please use the commit format : (helps us to know who
> >>>>>> worked
> >>>>>>>>>>> on
> >>>>>>>>>>>>> it,
> >>>>>>>>>>>>>>> what is the history)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> >>>>>>>>>>>>>>> * explanation line 1 *
> >>>>>> explanation
> >>>>>>>>>>>> line
> >>>>>>>>>>>>> 2*
> >>>>>>>>>>>>>>> This is not a rule or anything, but a request to help out
> >> your
> >>>>>>>>>>> fellow
> >>>>>>>>>>>>>>> committers in quickly detecting a problem.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark
> where
> >>>>>> they
> >>>>>>>>>>>> have
> >>>>>>>>>>>>> a
> >>>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
> >>>>>> attachment]
> >>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>> Naba.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>
> >>
> >> --
> > Ju@N
>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
Based on the feedback so far, I will amend the proposal to drop item 2). Therefore, the current ability to create merge commits using command-line git will remain available.
The proposal as amended is now:
> Change GitHub settings to make "Squash and merge" the default
> (by removing “Create a merge commit” option).
>
> Update the PR template to change the text "Is your initial contribution
> a single, squashed commit” to “Is your initial contribution squashed for
> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
> ‘fix’ commit)"
As Naba suggested, we can try it, and if we don’t like it, it’s simple to revert.
I’ve create a PR for the proposed change here: https://github.com/apache/geode/pull/4513
Please use the PR to vote for against this proposal. It will not be merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that time)
> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
>
> +1
>
> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io> wrote:
>
>> Hi Bruce, this proposal will not waste a single second of your time. It
>> just prevents people from accidentally pressing a button that we have
>> already agreed should never be pressed, but because we never configured our
>> GitHub to match our stated policy, is currently the default.
>>
>> However, it will save a lot of time and frustration for anyone needing to
>> bisect failures, revert, or cherry-pick changes, which has merit even if
>> you personally never do any of those three things.
>>
>> Please start a separate thread if you would like to revisit the community
>> decision to require passing PR checks.
>>
>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <bs...@pivotal.io>
>> wrote:
>>>
>>> I agree with Jake. I would go further by saying that I see very little
>> merit in this proposal. I think we're getting more and more bureaucratic
>> in our process and that it stifles productivity. I was recently forced to
>> spend three days fixing tests in which I had changed an import statement
>> before they would pass stress testing. I'm glad the tests now pass
>> reliably but I was very frustrated by the process.
>>>
>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>> I’m in agreement with Dan. Changes to the infrastructure to flat out
>> prevent things that should be self policing is annoying. This PR review
>> lock we have had already cost us valuable time waiting for PR pipelines to
>> pass that have no relevance to the commit, like CI work: I’d hat to see yet
>> another process enforced that Kees us from getting work done when necessary.
>>>>
>>>> -Jake
>>>>
>>>>
>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>>>>>
>>>>> -1 to (1) and (2).
>>>>>
>>>>> I think merge commits are appropriate in certain circumstances, so I
>> don't
>>>>> think we should make a blanket restriction. In fact I think our release
>>>>> process involves some merges.
>>>>>
>>>>> I think setting standards on what is reasonable to be an individual
>> commit
>>>>> will do a lot more to clean up our history than blocking merges. We'd
>>>>> rather not see commits like "Spotless Apply" in the history, but if
>>>>> reasonably separate and well written commits come in as part of a
>> merge, I
>>>>> think that's fine.
>>>>>
>>>>> -Dan
>>>>>
>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io>
>> wrote:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io>
>> wrote:
>>>>>>>
>>>>>>> I’d like to advance this topic from an informal request/discussion
>> to a
>>>>>>> discussion of a concrete proposal.
>>>>>>>
>>>>>>> To recap, it sounds like there is general agreement that commit
>> history
>>>>>> on
>>>>>>> develop should be linear (no merge commits), and that the biggest
>>>>>> obstacle
>>>>>>> to this is that the PR merge button in GitHub creates a merge commit
>> by
>>>>>>> default.
>>>>>>>
>>>>>>> I propose the following changes:
>>>>>>> 1) Change GitHub settings to remove the ability to create a merge
>> commit.
>>>>>>> This will make Squash & Merge the default.
>>>>>>>
>>>>>>> 2) Change GitHub settings to require linear history on develop. This
>>>>>>> prevents merge commits via command-line (not recommended, but wiki
>> still
>>>>>>> has instructions for merging PRs this way).
>>>>>>>
>>>>>>> 3) Update the PR template to change the text "Is your initial
>>>>>> contribution
>>>>>>> a single, squashed commit” to “Is your initial contribution squashed
>> for
>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus
>> a
>>>>>>> ‘fix’ commit)"
>>>>>>>
>>>>>>> For clarity, I am proposing no-change in the following areas:
>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
>> structured to
>>>>>>> benefit from it (this can make it easier in a bisect to see whether
>> the
>>>>>>> refactoring or the “fix” broke something).
>>>>>>> ii) Leave existing wording in the wiki as-is [stating that squashing
>> is
>>>>>>> preferred].
>>>>>>>
>>>>>>>
>>>>>>> Please comment via this email thread.
>>>>>>> -Owen
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>>>>>>
>>>>>>>> I think it's already resolved Udo ;)
>>>>>>>>
>>>>>>>> Here's the problem, if I fixup a dunit test by removing all uses of
>>>>>>> "this."
>>>>>>>> and I rename the dunit test, then git doesn't remember that the file
>>>>>> is a
>>>>>>>> rename -- it forever afterwards interprets it as a new file that I
>>>>>>> created
>>>>>>>> if I touch more than 50% of the lines (which "this." can easily
>> do). If
>>>>>>> we
>>>>>>>> squash two commits: the rename and the cleanup of that dunit test --
>>>>>> then
>>>>>>>> we effectively lose the history of that file and it shows that I
>>>>>> created
>>>>>>> a
>>>>>>>> new file.
>>>>>>>>
>>>>>>>> Also for the record, I've been working on Geode since the beginning
>>>>>> and I
>>>>>>>> was never made aware of this change in our process. I never voted on
>>>>>> it.
>>>>>>>> I'm not a big fan of changing various details in our process every
>>>>>> single
>>>>>>>> week. It's very easy to miss these discussions unless someone
>> points it
>>>>>>> out
>>>>>>>> to me.
>>>>>>>>
>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>> ukohlmeyer@pivotal.io>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I'm not sure what this discussion is about... WE, as a community,
>> have
>>>>>>>>> agreed in common practices, in two place no less...
>>>>>>>>>
>>>>>>>>> 1) Quoting our PR template
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For all changes:
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it referenced
>> in
>>>>>>>>> the commit message?
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Has your PR been rebased against the latest commit within the
>>>>>> target
>>>>>>>>> branch (typically|develop|)?
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Have you written or updated unit tests to verify your changes?
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> If adding new dependencies to the code, are these dependencies
>>>>>>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>>>>
>>>>>>>>> On our PR template we call out that the initial PR commit should be
>>>>>>>>> squashed.
>>>>>>>>>
>>>>>>>>> 2)
>>>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>> <
>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend you on the
>>>>>>>>> diligence, but in reality, they should either then be stand alone
>> PR's
>>>>>>>>> or just extra work created for yourself.
>>>>>>>>>
>>>>>>>>> If we want to change the way we have agreed upon we
>>>>>> submit/commit/merge
>>>>>>>>> changes back into develop... Then this is another discussion
>> thread,
>>>>>>>>> until then, I think we should all remind ourselves on our agreed
>>>>>>>>> contributions code of conduct.
>>>>>>>>>
>>>>>>>>> --Udo
>>>>>>>>>
>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>>>> Kirk, I believe that creating a Pull Request with multiple
>> commits is
>>>>>>> ok.
>>>>>>>>>> It's just in the end that when it's being pushed to develop
>> branch,
>>>>>> it
>>>>>>>>>> needs to be squash merged. I believe that is what you have
>> mentioned
>>>>>> in
>>>>>>>>> the
>>>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>>>> If you can see in the first screenshot comparison that I had
>> attached
>>>>>>> in
>>>>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>>>>
>>>>>>>>>> Thank you for your feedback.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Naba
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org>
>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Whenever I submit a PR with multiple commits that I intend to
>> rebase
>>>>>>> to
>>>>>>>>>>> develop, I always try to ensure that each commit stands alone as
>> is
>>>>>>>>>>> (compiles and passes tests). Separating file renames and
>> refactoring
>>>>>>>>> from
>>>>>>>>>>> behavior changes into different commits seems very valuable to
>> me,
>>>>>> and
>>>>>>>>> I've
>>>>>>>>>>> had trouble getting people to review PRs without this separation
>>>>>> (but
>>>>>>> it
>>>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>>>
>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs have
>> multiple
>>>>>>>>> commits
>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that
>> should
>>>>>>> be
>>>>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>>>>
>>>>>>>>>>> I can submit multiple PRs instead of one PR with multiple
>> commits.
>>>>>> So
>>>>>>>>> I'll
>>>>>>>>>>> change my response to -0 if that helps prevent commits to develop
>>>>>> that
>>>>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
>>>>>>> commits
>>>>>>>>>>> from github, I'm not sure how we can really enforce this or
>> prevent
>>>>>>> (b)
>>>>>>>>>>> above.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>>>> amurmann@pivotal.io>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at
>> odds.
>>>>>>>>>>>>
>>>>>>>>>>>> Make the change easy (warning: this may be hard), then make the
>>>>>> easy
>>>>>>>>>>>>> change."
>>>>>>>>>>>> -Kent Beck
>>>>>>>>>>>>
>>>>>>>>>>>> Following Kent Beck's advise might reasonably split into two
>>>>>> commits.
>>>>>>>>> One
>>>>>>>>>>>> refactor commit and a separate commit that introduces the actual
>>>>>>>>> change.
>>>>>>>>>>>> They should be individually revertible and might be easier
>>>>>> understood
>>>>>>>>> if
>>>>>>>>>>>> split out. I vividly remember a change on our code base where
>>>>>> someone
>>>>>>>>>>> did a
>>>>>>>>>>>> huge amount of refactoring that resulted than in one parameter
>>>>>>> changing
>>>>>>>>>>> in
>>>>>>>>>>>> order to get the desired functionality change. If that was in
>> one
>>>>>>>>> commit,
>>>>>>>>>>>> it would be hard to see the actual change. If split out, it's
>>>>>>> beautiful
>>>>>>>>>>> and
>>>>>>>>>>>> crystal clear.
>>>>>>>>>>>>
>>>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
>>>>>>>>>>> references.
>>>>>>>>>>>> Usually we assume that if there is a commit with the ticket
>> number,
>>>>>>> the
>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>>>>>>> refactoring
>>>>>>>>>>>> ticket.
>>>>>>>>>>>>
>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
>>>>>> wrote:
>>>>>>>>>>>>> It is to help with bisect operations when things start failing
>> ...
>>>>>>>>>>> helps
>>>>>>>>>>>> us
>>>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>>>> also with cherry picking features / fixes to previous versions
>> .
>>>>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
>>>>>>> commits”.
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
>>>>>> wrote:
>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR
>> and
>>>>>>>>>>> keep
>>>>>>>>>>>>> them
>>>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
>>>>>>> wrote:
>>>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A kind request for using squash commit instead of using
>> merge.
>>>>>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>>>>>> regression/flakiness in the product is introduced. We can
>>>>>> automate
>>>>>>>>>>>> and
>>>>>>>>>>>>> go
>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless
>>>>>> fix"
>>>>>>>>>>>> and
>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>>>>>>>>>>> branch.
>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to know who
>>>>>> worked
>>>>>>>>>>> on
>>>>>>>>>>>>> it,
>>>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>>>> * explanation line 1 *
>>>>>> explanation
>>>>>>>>>>>> line
>>>>>>>>>>>>> 2*
>>>>>>>>>>>>>>> This is not a rule or anything, but a request to help out
>> your
>>>>>>>>>>> fellow
>>>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
>>>>>> they
>>>>>>>>>>>> have
>>>>>>>>>>>>> a
>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>>>>>> attachment]
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>
>>
>> --
> Ju@N
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Aaron Lindsey <aa...@apache.org>.
+1 to (1) and (3)
I’m on board with (1). I’m hesitant about agreeing to (2) because it seems harder to “accidentally” do a merge commit via the command line, and I don’t want to add unnecessary restrictions. (3) has needed to be done for some time now, so I’m happy to see a proposal to change that.
In which case would an explicit merge commit be preferred/required to a “rebase and merge”? In my experience working on Geode, I’ve never needed to create an explicit merge commit. I have, however, seen people do it by accident. As a reminder, “rebase and merge" sill allows you to keep all of the individual commits from your PR.
- Aaron
> On Dec 20, 2019, at 8:31 AM, Ju@N <ju...@gmail.com> wrote:
>
> +1
>
> On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io> wrote:
>
>> Hi Bruce, this proposal will not waste a single second of your time. It
>> just prevents people from accidentally pressing a button that we have
>> already agreed should never be pressed, but because we never configured our
>> GitHub to match our stated policy, is currently the default.
>>
>> However, it will save a lot of time and frustration for anyone needing to
>> bisect failures, revert, or cherry-pick changes, which has merit even if
>> you personally never do any of those three things.
>>
>> Please start a separate thread if you would like to revisit the community
>> decision to require passing PR checks.
>>
>>> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <bs...@pivotal.io>
>> wrote:
>>>
>>> I agree with Jake. I would go further by saying that I see very little
>> merit in this proposal. I think we're getting more and more bureaucratic
>> in our process and that it stifles productivity. I was recently forced to
>> spend three days fixing tests in which I had changed an import statement
>> before they would pass stress testing. I'm glad the tests now pass
>> reliably but I was very frustrated by the process.
>>>
>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>>>> I’m in agreement with Dan. Changes to the infrastructure to flat out
>> prevent things that should be self policing is annoying. This PR review
>> lock we have had already cost us valuable time waiting for PR pipelines to
>> pass that have no relevance to the commit, like CI work: I’d hat to see yet
>> another process enforced that Kees us from getting work done when necessary.
>>>>
>>>> -Jake
>>>>
>>>>
>>>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>>>>>
>>>>> -1 to (1) and (2).
>>>>>
>>>>> I think merge commits are appropriate in certain circumstances, so I
>> don't
>>>>> think we should make a blanket restriction. In fact I think our release
>>>>> process involves some merges.
>>>>>
>>>>> I think setting standards on what is reasonable to be an individual
>> commit
>>>>> will do a lot more to clean up our history than blocking merges. We'd
>>>>> rather not see commits like "Spotless Apply" in the history, but if
>>>>> reasonably separate and well written commits come in as part of a
>> merge, I
>>>>> think that's fine.
>>>>>
>>>>> -Dan
>>>>>
>>>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io>
>> wrote:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io>
>> wrote:
>>>>>>>
>>>>>>> I’d like to advance this topic from an informal request/discussion
>> to a
>>>>>>> discussion of a concrete proposal.
>>>>>>>
>>>>>>> To recap, it sounds like there is general agreement that commit
>> history
>>>>>> on
>>>>>>> develop should be linear (no merge commits), and that the biggest
>>>>>> obstacle
>>>>>>> to this is that the PR merge button in GitHub creates a merge commit
>> by
>>>>>>> default.
>>>>>>>
>>>>>>> I propose the following changes:
>>>>>>> 1) Change GitHub settings to remove the ability to create a merge
>> commit.
>>>>>>> This will make Squash & Merge the default.
>>>>>>>
>>>>>>> 2) Change GitHub settings to require linear history on develop. This
>>>>>>> prevents merge commits via command-line (not recommended, but wiki
>> still
>>>>>>> has instructions for merging PRs this way).
>>>>>>>
>>>>>>> 3) Update the PR template to change the text "Is your initial
>>>>>> contribution
>>>>>>> a single, squashed commit” to “Is your initial contribution squashed
>> for
>>>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus
>> a
>>>>>>> ‘fix’ commit)"
>>>>>>>
>>>>>>> For clarity, I am proposing no-change in the following areas:
>>>>>>> i) Leave Rebase & Merge as an option for PRs that have been
>> structured to
>>>>>>> benefit from it (this can make it easier in a bisect to see whether
>> the
>>>>>>> refactoring or the “fix” broke something).
>>>>>>> ii) Leave existing wording in the wiki as-is [stating that squashing
>> is
>>>>>>> preferred].
>>>>>>>
>>>>>>>
>>>>>>> Please comment via this email thread.
>>>>>>> -Owen
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>>>>>>
>>>>>>>> I think it's already resolved Udo ;)
>>>>>>>>
>>>>>>>> Here's the problem, if I fixup a dunit test by removing all uses of
>>>>>>> "this."
>>>>>>>> and I rename the dunit test, then git doesn't remember that the file
>>>>>> is a
>>>>>>>> rename -- it forever afterwards interprets it as a new file that I
>>>>>>> created
>>>>>>>> if I touch more than 50% of the lines (which "this." can easily
>> do). If
>>>>>>> we
>>>>>>>> squash two commits: the rename and the cleanup of that dunit test --
>>>>>> then
>>>>>>>> we effectively lose the history of that file and it shows that I
>>>>>> created
>>>>>>> a
>>>>>>>> new file.
>>>>>>>>
>>>>>>>> Also for the record, I've been working on Geode since the beginning
>>>>>> and I
>>>>>>>> was never made aware of this change in our process. I never voted on
>>>>>> it.
>>>>>>>> I'm not a big fan of changing various details in our process every
>>>>>> single
>>>>>>>> week. It's very easy to miss these discussions unless someone
>> points it
>>>>>>> out
>>>>>>>> to me.
>>>>>>>>
>>>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
>> ukohlmeyer@pivotal.io>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I'm not sure what this discussion is about... WE, as a community,
>> have
>>>>>>>>> agreed in common practices, in two place no less...
>>>>>>>>>
>>>>>>>>> 1) Quoting our PR template
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For all changes:
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Is there a JIRA ticket associated with this PR? Is it referenced
>> in
>>>>>>>>> the commit message?
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Has your PR been rebased against the latest commit within the
>>>>>> target
>>>>>>>>> branch (typically|develop|)?
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> Have you written or updated unit tests to verify your changes?
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> If adding new dependencies to the code, are these dependencies
>>>>>>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>>>>
>>>>>>>>> On our PR template we call out that the initial PR commit should be
>>>>>>>>> squashed.
>>>>>>>>>
>>>>>>>>> 2)
>>>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>> <
>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @Kirk, if each of your commits "stands alone", I commend you on the
>>>>>>>>> diligence, but in reality, they should either then be stand alone
>> PR's
>>>>>>>>> or just extra work created for yourself.
>>>>>>>>>
>>>>>>>>> If we want to change the way we have agreed upon we
>>>>>> submit/commit/merge
>>>>>>>>> changes back into develop... Then this is another discussion
>> thread,
>>>>>>>>> until then, I think we should all remind ourselves on our agreed
>>>>>>>>> contributions code of conduct.
>>>>>>>>>
>>>>>>>>> --Udo
>>>>>>>>>
>>>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>>>> Kirk, I believe that creating a Pull Request with multiple
>> commits is
>>>>>>> ok.
>>>>>>>>>> It's just in the end that when it's being pushed to develop
>> branch,
>>>>>> it
>>>>>>>>>> needs to be squash merged. I believe that is what you have
>> mentioned
>>>>>> in
>>>>>>>>> the
>>>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>>>> If you can see in the first screenshot comparison that I had
>> attached
>>>>>>> in
>>>>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>>>>
>>>>>>>>>> Thank you for your feedback.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Naba
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org>
>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Whenever I submit a PR with multiple commits that I intend to
>> rebase
>>>>>>> to
>>>>>>>>>>> develop, I always try to ensure that each commit stands alone as
>> is
>>>>>>>>>>> (compiles and passes tests). Separating file renames and
>> refactoring
>>>>>>>>> from
>>>>>>>>>>> behavior changes into different commits seems very valuable to
>> me,
>>>>>> and
>>>>>>>>> I've
>>>>>>>>>>> had trouble getting people to review PRs without this separation
>>>>>> (but
>>>>>>> it
>>>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>>>
>>>>>>>>>>> It sounds to me like the real problem is (a) some PRs have
>> multiple
>>>>>>>>> commits
>>>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that
>> should
>>>>>>> be
>>>>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>>>>
>>>>>>>>>>> I can submit multiple PRs instead of one PR with multiple
>> commits.
>>>>>> So
>>>>>>>>> I'll
>>>>>>>>>>> change my response to -0 if that helps prevent commits to develop
>>>>>> that
>>>>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
>>>>>>> commits
>>>>>>>>>>> from github, I'm not sure how we can really enforce this or
>> prevent
>>>>>>> (b)
>>>>>>>>>>> above.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>>>> amurmann@pivotal.io>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at
>> odds.
>>>>>>>>>>>>
>>>>>>>>>>>> Make the change easy (warning: this may be hard), then make the
>>>>>> easy
>>>>>>>>>>>>> change."
>>>>>>>>>>>> -Kent Beck
>>>>>>>>>>>>
>>>>>>>>>>>> Following Kent Beck's advise might reasonably split into two
>>>>>> commits.
>>>>>>>>> One
>>>>>>>>>>>> refactor commit and a separate commit that introduces the actual
>>>>>>>>> change.
>>>>>>>>>>>> They should be individually revertible and might be easier
>>>>>> understood
>>>>>>>>> if
>>>>>>>>>>>> split out. I vividly remember a change on our code base where
>>>>>> someone
>>>>>>>>>>> did a
>>>>>>>>>>>> huge amount of refactoring that resulted than in one parameter
>>>>>>> changing
>>>>>>>>>>> in
>>>>>>>>>>>> order to get the desired functionality change. If that was in
>> one
>>>>>>>>> commit,
>>>>>>>>>>>> it would be hard to see the actual change. If split out, it's
>>>>>>> beautiful
>>>>>>>>>>> and
>>>>>>>>>>>> crystal clear.
>>>>>>>>>>>>
>>>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
>>>>>>>>>>> references.
>>>>>>>>>>>> Usually we assume that if there is a commit with the ticket
>> number,
>>>>>>> the
>>>>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>>>>>>> refactoring
>>>>>>>>>>>> ticket.
>>>>>>>>>>>>
>>>>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
>>>>>> wrote:
>>>>>>>>>>>>> It is to help with bisect operations when things start failing
>> ...
>>>>>>>>>>> helps
>>>>>>>>>>>> us
>>>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>>>> also with cherry picking features / fixes to previous versions
>> .
>>>>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
>>>>>>> commits”.
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Naba
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
>>>>>> wrote:
>>>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR
>> and
>>>>>>>>>>> keep
>>>>>>>>>>>>> them
>>>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
>>>>>>> wrote:
>>>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A kind request for using squash commit instead of using
>> merge.
>>>>>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>>>>>> regression/flakiness in the product is introduced. We can
>>>>>> automate
>>>>>>>>>>>> and
>>>>>>>>>>>>> go
>>>>>>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless
>>>>>> fix"
>>>>>>>>>>>> and
>>>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>>>>>>>>>>> branch.
>>>>>>>>>>>>>>> Also, please use the commit format : (helps us to know who
>>>>>> worked
>>>>>>>>>>> on
>>>>>>>>>>>>> it,
>>>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>>>> * explanation line 1 *
>>>>>> explanation
>>>>>>>>>>>> line
>>>>>>>>>>>>> 2*
>>>>>>>>>>>>>>> This is not a rule or anything, but a request to help out
>> your
>>>>>>>>>>> fellow
>>>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
>>>>>> they
>>>>>>>>>>>> have
>>>>>>>>>>>>> a
>>>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>>>>>> attachment]
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>
>>
>> --
> Ju@N
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by "Ju@N" <ju...@gmail.com>.
+1
On Fri 20 Dec 2019 at 16:18, Owen Nichols <on...@pivotal.io> wrote:
> Hi Bruce, this proposal will not waste a single second of your time. It
> just prevents people from accidentally pressing a button that we have
> already agreed should never be pressed, but because we never configured our
> GitHub to match our stated policy, is currently the default.
>
> However, it will save a lot of time and frustration for anyone needing to
> bisect failures, revert, or cherry-pick changes, which has merit even if
> you personally never do any of those three things.
>
> Please start a separate thread if you would like to revisit the community
> decision to require passing PR checks.
>
> > On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <bs...@pivotal.io>
> wrote:
> >
> > I agree with Jake. I would go further by saying that I see very little
> merit in this proposal. I think we're getting more and more bureaucratic
> in our process and that it stifles productivity. I was recently forced to
> spend three days fixing tests in which I had changed an import statement
> before they would pass stress testing. I'm glad the tests now pass
> reliably but I was very frustrated by the process.
> >
> > On 12/19/19 4:49 PM, Jacob Barrett wrote:
> >> I’m in agreement with Dan. Changes to the infrastructure to flat out
> prevent things that should be self policing is annoying. This PR review
> lock we have had already cost us valuable time waiting for PR pipelines to
> pass that have no relevance to the commit, like CI work: I’d hat to see yet
> another process enforced that Kees us from getting work done when necessary.
> >>
> >> -Jake
> >>
> >>
> >>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
> >>>
> >>> -1 to (1) and (2).
> >>>
> >>> I think merge commits are appropriate in certain circumstances, so I
> don't
> >>> think we should make a blanket restriction. In fact I think our release
> >>> process involves some merges.
> >>>
> >>> I think setting standards on what is reasonable to be an individual
> commit
> >>> will do a lot more to clean up our history than blocking merges. We'd
> >>> rather not see commits like "Spotless Apply" in the history, but if
> >>> reasonably separate and well written commits come in as part of a
> merge, I
> >>> think that's fine.
> >>>
> >>> -Dan
> >>>
> >>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io>
> wrote:
> >>>>
> >>>> +1
> >>>>
> >>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io>
> wrote:
> >>>>>
> >>>>> I’d like to advance this topic from an informal request/discussion
> to a
> >>>>> discussion of a concrete proposal.
> >>>>>
> >>>>> To recap, it sounds like there is general agreement that commit
> history
> >>>> on
> >>>>> develop should be linear (no merge commits), and that the biggest
> >>>> obstacle
> >>>>> to this is that the PR merge button in GitHub creates a merge commit
> by
> >>>>> default.
> >>>>>
> >>>>> I propose the following changes:
> >>>>> 1) Change GitHub settings to remove the ability to create a merge
> commit.
> >>>>> This will make Squash & Merge the default.
> >>>>>
> >>>>> 2) Change GitHub settings to require linear history on develop. This
> >>>>> prevents merge commits via command-line (not recommended, but wiki
> still
> >>>>> has instructions for merging PRs this way).
> >>>>>
> >>>>> 3) Update the PR template to change the text "Is your initial
> >>>> contribution
> >>>>> a single, squashed commit” to “Is your initial contribution squashed
> for
> >>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus
> a
> >>>>> ‘fix’ commit)"
> >>>>>
> >>>>> For clarity, I am proposing no-change in the following areas:
> >>>>> i) Leave Rebase & Merge as an option for PRs that have been
> structured to
> >>>>> benefit from it (this can make it easier in a bisect to see whether
> the
> >>>>> refactoring or the “fix” broke something).
> >>>>> ii) Leave existing wording in the wiki as-is [stating that squashing
> is
> >>>>> preferred].
> >>>>>
> >>>>>
> >>>>> Please comment via this email thread.
> >>>>> -Owen
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
> >>>>>>
> >>>>>> I think it's already resolved Udo ;)
> >>>>>>
> >>>>>> Here's the problem, if I fixup a dunit test by removing all uses of
> >>>>> "this."
> >>>>>> and I rename the dunit test, then git doesn't remember that the file
> >>>> is a
> >>>>>> rename -- it forever afterwards interprets it as a new file that I
> >>>>> created
> >>>>>> if I touch more than 50% of the lines (which "this." can easily
> do). If
> >>>>> we
> >>>>>> squash two commits: the rename and the cleanup of that dunit test --
> >>>> then
> >>>>>> we effectively lose the history of that file and it shows that I
> >>>> created
> >>>>> a
> >>>>>> new file.
> >>>>>>
> >>>>>> Also for the record, I've been working on Geode since the beginning
> >>>> and I
> >>>>>> was never made aware of this change in our process. I never voted on
> >>>> it.
> >>>>>> I'm not a big fan of changing various details in our process every
> >>>> single
> >>>>>> week. It's very easy to miss these discussions unless someone
> points it
> >>>>> out
> >>>>>> to me.
> >>>>>>
> >>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <
> ukohlmeyer@pivotal.io>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I'm not sure what this discussion is about... WE, as a community,
> have
> >>>>>>> agreed in common practices, in two place no less...
> >>>>>>>
> >>>>>>> 1) Quoting our PR template
> >>>>>>>
> >>>>>>>
> >>>>>>> For all changes:
> >>>>>>>
> >>>>>>> *
> >>>>>>>
> >>>>>>> Is there a JIRA ticket associated with this PR? Is it referenced
> in
> >>>>>>> the commit message?
> >>>>>>>
> >>>>>>> *
> >>>>>>>
> >>>>>>> Has your PR been rebased against the latest commit within the
> >>>> target
> >>>>>>> branch (typically|develop|)?
> >>>>>>>
> >>>>>>> *
> >>>>>>>
> >>>>>>> ***Is your initial contribution a single, squashed commit?*
> >>>>>>>
> >>>>>>> *
> >>>>>>>
> >>>>>>> Does|gradlew build|run cleanly?
> >>>>>>>
> >>>>>>> *
> >>>>>>>
> >>>>>>> Have you written or updated unit tests to verify your changes?
> >>>>>>>
> >>>>>>> *
> >>>>>>>
> >>>>>>> If adding new dependencies to the code, are these dependencies
> >>>>>>> licensed in a way that is compatible for inclusion underASF 2.0
> >>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> >>>>>>>
> >>>>>>> On our PR template we call out that the initial PR commit should be
> >>>>>>> squashed.
> >>>>>>>
> >>>>>>> 2)
> >>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>> <
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> >>>>>>>
> >>>>>>>
> >>>>>>> @Kirk, if each of your commits "stands alone", I commend you on the
> >>>>>>> diligence, but in reality, they should either then be stand alone
> PR's
> >>>>>>> or just extra work created for yourself.
> >>>>>>>
> >>>>>>> If we want to change the way we have agreed upon we
> >>>> submit/commit/merge
> >>>>>>> changes back into develop... Then this is another discussion
> thread,
> >>>>>>> until then, I think we should all remind ourselves on our agreed
> >>>>>>> contributions code of conduct.
> >>>>>>>
> >>>>>>> --Udo
> >>>>>>>
> >>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >>>>>>>> Kirk, I believe that creating a Pull Request with multiple
> commits is
> >>>>> ok.
> >>>>>>>> It's just in the end that when it's being pushed to develop
> branch,
> >>>> it
> >>>>>>>> needs to be squash merged. I believe that is what you have
> mentioned
> >>>> in
> >>>>>>> the
> >>>>>>>> first paragraph, and I am more than happy with that.
> >>>>>>>> If you can see in the first screenshot comparison that I had
> attached
> >>>>> in
> >>>>>>>> the first email in this thread is what I want to avoid.
> >>>>>>>>
> >>>>>>>> Thank you for your feedback.
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>> Naba
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org>
> wrote:
> >>>>>>>>
> >>>>>>>>> Whenever I submit a PR with multiple commits that I intend to
> rebase
> >>>>> to
> >>>>>>>>> develop, I always try to ensure that each commit stands alone as
> is
> >>>>>>>>> (compiles and passes tests). Separating file renames and
> refactoring
> >>>>>>> from
> >>>>>>>>> behavior changes into different commits seems very valuable to
> me,
> >>>> and
> >>>>>>> I've
> >>>>>>>>> had trouble getting people to review PRs without this separation
> >>>> (but
> >>>>> it
> >>>>>>>>> could be squashed as it's merged to develop).
> >>>>>>>>>
> >>>>>>>>> It sounds to me like the real problem is (a) some PRs have
> multiple
> >>>>>>> commits
> >>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that
> should
> >>>>> be
> >>>>>>>>> merged with squash are not (by accident most likely).
> >>>>>>>>>
> >>>>>>>>> I can submit multiple PRs instead of one PR with multiple
> commits.
> >>>> So
> >>>>>>> I'll
> >>>>>>>>> change my response to -0 if that helps prevent commits to develop
> >>>> that
> >>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
> >>>>> commits
> >>>>>>>>> from github, I'm not sure how we can really enforce this or
> prevent
> >>>>> (b)
> >>>>>>>>> above.
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >>>>> amurmann@pivotal.io>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at
> odds.
> >>>>>>>>>>
> >>>>>>>>>> Make the change easy (warning: this may be hard), then make the
> >>>> easy
> >>>>>>>>>>> change."
> >>>>>>>>>> -Kent Beck
> >>>>>>>>>>
> >>>>>>>>>> Following Kent Beck's advise might reasonably split into two
> >>>> commits.
> >>>>>>> One
> >>>>>>>>>> refactor commit and a separate commit that introduces the actual
> >>>>>>> change.
> >>>>>>>>>> They should be individually revertible and might be easier
> >>>> understood
> >>>>>>> if
> >>>>>>>>>> split out. I vividly remember a change on our code base where
> >>>> someone
> >>>>>>>>> did a
> >>>>>>>>>> huge amount of refactoring that resulted than in one parameter
> >>>>> changing
> >>>>>>>>> in
> >>>>>>>>>> order to get the desired functionality change. If that was in
> one
> >>>>>>> commit,
> >>>>>>>>>> it would be hard to see the actual change. If split out, it's
> >>>>> beautiful
> >>>>>>>>> and
> >>>>>>>>>> crystal clear.
> >>>>>>>>>>
> >>>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
> >>>>>>>>> references.
> >>>>>>>>>> Usually we assume that if there is a commit with the ticket
> number,
> >>>>> the
> >>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
> >>>>>>> refactoring
> >>>>>>>>>> ticket.
> >>>>>>>>>>
> >>>>>>>>>> Would that allow us to have our cake and eat it too?
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
> >>>> wrote:
> >>>>>>>>>>> It is to help with bisect operations when things start failing
> ...
> >>>>>>>>> helps
> >>>>>>>>>> us
> >>>>>>>>>>> it revert and build faster.
> >>>>>>>>>>> also with cherry picking features / fixes to previous versions
> .
> >>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
> >>>>> commits”.
> >>>>>>>>>>> Regards
> >>>>>>>>>>> Naba
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
> >>>> wrote:
> >>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR
> and
> >>>>>>>>> keep
> >>>>>>>>>>> them
> >>>>>>>>>>>> separate when they merge to develop
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
> >>>>> wrote:
> >>>>>>>>>>>>> Hi Geode Committers,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> A kind request for using squash commit instead of using
> merge.
> >>>>>>>>>>>>> This will really help us in our bisect operations when a
> >>>>>>>>>>>>> regression/flakiness in the product is introduced. We can
> >>>> automate
> >>>>>>>>>> and
> >>>>>>>>>>> go
> >>>>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless
> >>>> fix"
> >>>>>>>>>> and
> >>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
> >>>>>>>>> branch.
> >>>>>>>>>>>>> Also, please use the commit format : (helps us to know who
> >>>> worked
> >>>>>>>>> on
> >>>>>>>>>>> it,
> >>>>>>>>>>>>> what is the history)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
> >>>>>>>>>>>>> * explanation line 1 *
> >>>> explanation
> >>>>>>>>>> line
> >>>>>>>>>>> 2*
> >>>>>>>>>>>>> This is not a rule or anything, but a request to help out
> your
> >>>>>>>>> fellow
> >>>>>>>>>>>>> committers in quickly detecting a problem.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
> >>>> they
> >>>>>>>>>> have
> >>>>>>>>>>> a
> >>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
> >>>> attachment]
> >>>>>>>>>>>>> Regards
> >>>>>>>>>>>>> Naba.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>
>
> --
Ju@N
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
Hi Bruce, this proposal will not waste a single second of your time. It just prevents people from accidentally pressing a button that we have already agreed should never be pressed, but because we never configured our GitHub to match our stated policy, is currently the default.
However, it will save a lot of time and frustration for anyone needing to bisect failures, revert, or cherry-pick changes, which has merit even if you personally never do any of those three things.
Please start a separate thread if you would like to revisit the community decision to require passing PR checks.
> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <bs...@pivotal.io> wrote:
>
> I agree with Jake. I would go further by saying that I see very little merit in this proposal. I think we're getting more and more bureaucratic in our process and that it stifles productivity. I was recently forced to spend three days fixing tests in which I had changed an import statement before they would pass stress testing. I'm glad the tests now pass reliably but I was very frustrated by the process.
>
> On 12/19/19 4:49 PM, Jacob Barrett wrote:
>> I’m in agreement with Dan. Changes to the infrastructure to flat out prevent things that should be self policing is annoying. This PR review lock we have had already cost us valuable time waiting for PR pipelines to pass that have no relevance to the commit, like CI work: I’d hat to see yet another process enforced that Kees us from getting work done when necessary.
>>
>> -Jake
>>
>>
>>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>>>
>>> -1 to (1) and (2).
>>>
>>> I think merge commits are appropriate in certain circumstances, so I don't
>>> think we should make a blanket restriction. In fact I think our release
>>> process involves some merges.
>>>
>>> I think setting standards on what is reasonable to be an individual commit
>>> will do a lot more to clean up our history than blocking merges. We'd
>>> rather not see commits like "Spotless Apply" in the history, but if
>>> reasonably separate and well written commits come in as part of a merge, I
>>> think that's fine.
>>>
>>> -Dan
>>>
>>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io> wrote:
>>>>
>>>> +1
>>>>
>>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io> wrote:
>>>>>
>>>>> I’d like to advance this topic from an informal request/discussion to a
>>>>> discussion of a concrete proposal.
>>>>>
>>>>> To recap, it sounds like there is general agreement that commit history
>>>> on
>>>>> develop should be linear (no merge commits), and that the biggest
>>>> obstacle
>>>>> to this is that the PR merge button in GitHub creates a merge commit by
>>>>> default.
>>>>>
>>>>> I propose the following changes:
>>>>> 1) Change GitHub settings to remove the ability to create a merge commit.
>>>>> This will make Squash & Merge the default.
>>>>>
>>>>> 2) Change GitHub settings to require linear history on develop. This
>>>>> prevents merge commits via command-line (not recommended, but wiki still
>>>>> has instructions for merging PRs this way).
>>>>>
>>>>> 3) Update the PR template to change the text "Is your initial
>>>> contribution
>>>>> a single, squashed commit” to “Is your initial contribution squashed for
>>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
>>>>> ‘fix’ commit)"
>>>>>
>>>>> For clarity, I am proposing no-change in the following areas:
>>>>> i) Leave Rebase & Merge as an option for PRs that have been structured to
>>>>> benefit from it (this can make it easier in a bisect to see whether the
>>>>> refactoring or the “fix” broke something).
>>>>> ii) Leave existing wording in the wiki as-is [stating that squashing is
>>>>> preferred].
>>>>>
>>>>>
>>>>> Please comment via this email thread.
>>>>> -Owen
>>>>>
>>>>>
>>>>>
>>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>>>>
>>>>>> I think it's already resolved Udo ;)
>>>>>>
>>>>>> Here's the problem, if I fixup a dunit test by removing all uses of
>>>>> "this."
>>>>>> and I rename the dunit test, then git doesn't remember that the file
>>>> is a
>>>>>> rename -- it forever afterwards interprets it as a new file that I
>>>>> created
>>>>>> if I touch more than 50% of the lines (which "this." can easily do). If
>>>>> we
>>>>>> squash two commits: the rename and the cleanup of that dunit test --
>>>> then
>>>>>> we effectively lose the history of that file and it shows that I
>>>> created
>>>>> a
>>>>>> new file.
>>>>>>
>>>>>> Also for the record, I've been working on Geode since the beginning
>>>> and I
>>>>>> was never made aware of this change in our process. I never voted on
>>>> it.
>>>>>> I'm not a big fan of changing various details in our process every
>>>> single
>>>>>> week. It's very easy to miss these discussions unless someone points it
>>>>> out
>>>>>> to me.
>>>>>>
>>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <uk...@pivotal.io>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm not sure what this discussion is about... WE, as a community, have
>>>>>>> agreed in common practices, in two place no less...
>>>>>>>
>>>>>>> 1) Quoting our PR template
>>>>>>>
>>>>>>>
>>>>>>> For all changes:
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> Is there a JIRA ticket associated with this PR? Is it referenced in
>>>>>>> the commit message?
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> Has your PR been rebased against the latest commit within the
>>>> target
>>>>>>> branch (typically|develop|)?
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> Does|gradlew build|run cleanly?
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> Have you written or updated unit tests to verify your changes?
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>> If adding new dependencies to the code, are these dependencies
>>>>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>>
>>>>>>> On our PR template we call out that the initial PR commit should be
>>>>>>> squashed.
>>>>>>>
>>>>>>> 2)
>>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>>
>>>>>>>
>>>>>>> @Kirk, if each of your commits "stands alone", I commend you on the
>>>>>>> diligence, but in reality, they should either then be stand alone PR's
>>>>>>> or just extra work created for yourself.
>>>>>>>
>>>>>>> If we want to change the way we have agreed upon we
>>>> submit/commit/merge
>>>>>>> changes back into develop... Then this is another discussion thread,
>>>>>>> until then, I think we should all remind ourselves on our agreed
>>>>>>> contributions code of conduct.
>>>>>>>
>>>>>>> --Udo
>>>>>>>
>>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>>> Kirk, I believe that creating a Pull Request with multiple commits is
>>>>> ok.
>>>>>>>> It's just in the end that when it's being pushed to develop branch,
>>>> it
>>>>>>>> needs to be squash merged. I believe that is what you have mentioned
>>>> in
>>>>>>> the
>>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>>> If you can see in the first screenshot comparison that I had attached
>>>>> in
>>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>>
>>>>>>>> Thank you for your feedback.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Naba
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
>>>>>>>>
>>>>>>>>> Whenever I submit a PR with multiple commits that I intend to rebase
>>>>> to
>>>>>>>>> develop, I always try to ensure that each commit stands alone as is
>>>>>>>>> (compiles and passes tests). Separating file renames and refactoring
>>>>>>> from
>>>>>>>>> behavior changes into different commits seems very valuable to me,
>>>> and
>>>>>>> I've
>>>>>>>>> had trouble getting people to review PRs without this separation
>>>> (but
>>>>> it
>>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>>
>>>>>>>>> It sounds to me like the real problem is (a) some PRs have multiple
>>>>>>> commits
>>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that should
>>>>> be
>>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>>
>>>>>>>>> I can submit multiple PRs instead of one PR with multiple commits.
>>>> So
>>>>>>> I'll
>>>>>>>>> change my response to -0 if that helps prevent commits to develop
>>>> that
>>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
>>>>> commits
>>>>>>>>> from github, I'm not sure how we can really enforce this or prevent
>>>>> (b)
>>>>>>>>> above.
>>>>>>>>>
>>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>>> amurmann@pivotal.io>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>>>>>>>>>
>>>>>>>>>> Make the change easy (warning: this may be hard), then make the
>>>> easy
>>>>>>>>>>> change."
>>>>>>>>>> -Kent Beck
>>>>>>>>>>
>>>>>>>>>> Following Kent Beck's advise might reasonably split into two
>>>> commits.
>>>>>>> One
>>>>>>>>>> refactor commit and a separate commit that introduces the actual
>>>>>>> change.
>>>>>>>>>> They should be individually revertible and might be easier
>>>> understood
>>>>>>> if
>>>>>>>>>> split out. I vividly remember a change on our code base where
>>>> someone
>>>>>>>>> did a
>>>>>>>>>> huge amount of refactoring that resulted than in one parameter
>>>>> changing
>>>>>>>>> in
>>>>>>>>>> order to get the desired functionality change. If that was in one
>>>>>>> commit,
>>>>>>>>>> it would be hard to see the actual change. If split out, it's
>>>>> beautiful
>>>>>>>>> and
>>>>>>>>>> crystal clear.
>>>>>>>>>>
>>>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
>>>>>>>>> references.
>>>>>>>>>> Usually we assume that if there is a commit with the ticket number,
>>>>> the
>>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>>>>> refactoring
>>>>>>>>>> ticket.
>>>>>>>>>>
>>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
>>>> wrote:
>>>>>>>>>>> It is to help with bisect operations when things start failing ...
>>>>>>>>> helps
>>>>>>>>>> us
>>>>>>>>>>> it revert and build faster.
>>>>>>>>>>> also with cherry picking features / fixes to previous versions .
>>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
>>>>> commits”.
>>>>>>>>>>> Regards
>>>>>>>>>>> Naba
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
>>>> wrote:
>>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
>>>>>>>>> keep
>>>>>>>>>>> them
>>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
>>>>> wrote:
>>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>>
>>>>>>>>>>>>> A kind request for using squash commit instead of using merge.
>>>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>>>> regression/flakiness in the product is introduced. We can
>>>> automate
>>>>>>>>>> and
>>>>>>>>>>> go
>>>>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless
>>>> fix"
>>>>>>>>>> and
>>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>>>>>>>>> branch.
>>>>>>>>>>>>> Also, please use the commit format : (helps us to know who
>>>> worked
>>>>>>>>> on
>>>>>>>>>>> it,
>>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>>> * explanation line 1 *
>>>> explanation
>>>>>>>>>> line
>>>>>>>>>>> 2*
>>>>>>>>>>>>> This is not a rule or anything, but a request to help out your
>>>>>>>>> fellow
>>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
>>>> they
>>>>>>>>>> have
>>>>>>>>>>> a
>>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>>>> attachment]
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Naba.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Bruce Schuchardt <bs...@pivotal.io>.
I agree with Jake. I would go further by saying that I see very little
merit in this proposal. I think we're getting more and more
bureaucratic in our process and that it stifles productivity. I was
recently forced to spend three days fixing tests in which I had changed
an import statement before they would pass stress testing. I'm glad the
tests now pass reliably but I was very frustrated by the process.
On 12/19/19 4:49 PM, Jacob Barrett wrote:
> I’m in agreement with Dan. Changes to the infrastructure to flat out prevent things that should be self policing is annoying. This PR review lock we have had already cost us valuable time waiting for PR pipelines to pass that have no relevance to the commit, like CI work: I’d hat to see yet another process enforced that Kees us from getting work done when necessary.
>
> -Jake
>
>
>> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>>
>> -1 to (1) and (2).
>>
>> I think merge commits are appropriate in certain circumstances, so I don't
>> think we should make a blanket restriction. In fact I think our release
>> process involves some merges.
>>
>> I think setting standards on what is reasonable to be an individual commit
>> will do a lot more to clean up our history than blocking merges. We'd
>> rather not see commits like "Spotless Apply" in the history, but if
>> reasonably separate and well written commits come in as part of a merge, I
>> think that's fine.
>>
>> -Dan
>>
>>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io> wrote:
>>>
>>> +1
>>>
>>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io> wrote:
>>>>
>>>> I’d like to advance this topic from an informal request/discussion to a
>>>> discussion of a concrete proposal.
>>>>
>>>> To recap, it sounds like there is general agreement that commit history
>>> on
>>>> develop should be linear (no merge commits), and that the biggest
>>> obstacle
>>>> to this is that the PR merge button in GitHub creates a merge commit by
>>>> default.
>>>>
>>>> I propose the following changes:
>>>> 1) Change GitHub settings to remove the ability to create a merge commit.
>>>> This will make Squash & Merge the default.
>>>>
>>>> 2) Change GitHub settings to require linear history on develop. This
>>>> prevents merge commits via command-line (not recommended, but wiki still
>>>> has instructions for merging PRs this way).
>>>>
>>>> 3) Update the PR template to change the text "Is your initial
>>> contribution
>>>> a single, squashed commit” to “Is your initial contribution squashed for
>>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
>>>> ‘fix’ commit)"
>>>>
>>>> For clarity, I am proposing no-change in the following areas:
>>>> i) Leave Rebase & Merge as an option for PRs that have been structured to
>>>> benefit from it (this can make it easier in a bisect to see whether the
>>>> refactoring or the “fix” broke something).
>>>> ii) Leave existing wording in the wiki as-is [stating that squashing is
>>>> preferred].
>>>>
>>>>
>>>> Please comment via this email thread.
>>>> -Owen
>>>>
>>>>
>>>>
>>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>>>
>>>>> I think it's already resolved Udo ;)
>>>>>
>>>>> Here's the problem, if I fixup a dunit test by removing all uses of
>>>> "this."
>>>>> and I rename the dunit test, then git doesn't remember that the file
>>> is a
>>>>> rename -- it forever afterwards interprets it as a new file that I
>>>> created
>>>>> if I touch more than 50% of the lines (which "this." can easily do). If
>>>> we
>>>>> squash two commits: the rename and the cleanup of that dunit test --
>>> then
>>>>> we effectively lose the history of that file and it shows that I
>>> created
>>>> a
>>>>> new file.
>>>>>
>>>>> Also for the record, I've been working on Geode since the beginning
>>> and I
>>>>> was never made aware of this change in our process. I never voted on
>>> it.
>>>>> I'm not a big fan of changing various details in our process every
>>> single
>>>>> week. It's very easy to miss these discussions unless someone points it
>>>> out
>>>>> to me.
>>>>>
>>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <uk...@pivotal.io>
>>>>> wrote:
>>>>>
>>>>>> I'm not sure what this discussion is about... WE, as a community, have
>>>>>> agreed in common practices, in two place no less...
>>>>>>
>>>>>> 1) Quoting our PR template
>>>>>>
>>>>>>
>>>>>> For all changes:
>>>>>>
>>>>>> *
>>>>>>
>>>>>> Is there a JIRA ticket associated with this PR? Is it referenced in
>>>>>> the commit message?
>>>>>>
>>>>>> *
>>>>>>
>>>>>> Has your PR been rebased against the latest commit within the
>>> target
>>>>>> branch (typically|develop|)?
>>>>>>
>>>>>> *
>>>>>>
>>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>>
>>>>>> *
>>>>>>
>>>>>> Does|gradlew build|run cleanly?
>>>>>>
>>>>>> *
>>>>>>
>>>>>> Have you written or updated unit tests to verify your changes?
>>>>>>
>>>>>> *
>>>>>>
>>>>>> If adding new dependencies to the code, are these dependencies
>>>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>>
>>>>>> On our PR template we call out that the initial PR commit should be
>>>>>> squashed.
>>>>>>
>>>>>> 2)
>>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>>
>>>>>>
>>>>>> @Kirk, if each of your commits "stands alone", I commend you on the
>>>>>> diligence, but in reality, they should either then be stand alone PR's
>>>>>> or just extra work created for yourself.
>>>>>>
>>>>>> If we want to change the way we have agreed upon we
>>> submit/commit/merge
>>>>>> changes back into develop... Then this is another discussion thread,
>>>>>> until then, I think we should all remind ourselves on our agreed
>>>>>> contributions code of conduct.
>>>>>>
>>>>>> --Udo
>>>>>>
>>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>>> Kirk, I believe that creating a Pull Request with multiple commits is
>>>> ok.
>>>>>>> It's just in the end that when it's being pushed to develop branch,
>>> it
>>>>>>> needs to be squash merged. I believe that is what you have mentioned
>>> in
>>>>>> the
>>>>>>> first paragraph, and I am more than happy with that.
>>>>>>> If you can see in the first screenshot comparison that I had attached
>>>> in
>>>>>>> the first email in this thread is what I want to avoid.
>>>>>>>
>>>>>>> Thank you for your feedback.
>>>>>>>
>>>>>>> Regards
>>>>>>> Naba
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
>>>>>>>
>>>>>>>> Whenever I submit a PR with multiple commits that I intend to rebase
>>>> to
>>>>>>>> develop, I always try to ensure that each commit stands alone as is
>>>>>>>> (compiles and passes tests). Separating file renames and refactoring
>>>>>> from
>>>>>>>> behavior changes into different commits seems very valuable to me,
>>> and
>>>>>> I've
>>>>>>>> had trouble getting people to review PRs without this separation
>>> (but
>>>> it
>>>>>>>> could be squashed as it's merged to develop).
>>>>>>>>
>>>>>>>> It sounds to me like the real problem is (a) some PRs have multiple
>>>>>> commits
>>>>>>>> that don't compile or don't pass tests, and (b) some PRs that should
>>>> be
>>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>>
>>>>>>>> I can submit multiple PRs instead of one PR with multiple commits.
>>> So
>>>>>> I'll
>>>>>>>> change my response to -0 if that helps prevent commits to develop
>>> that
>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
>>>> commits
>>>>>>>> from github, I'm not sure how we can really enforce this or prevent
>>>> (b)
>>>>>>>> above.
>>>>>>>>
>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>>> amurmann@pivotal.io>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>>>>>>>>
>>>>>>>>> Make the change easy (warning: this may be hard), then make the
>>> easy
>>>>>>>>>> change."
>>>>>>>>> -Kent Beck
>>>>>>>>>
>>>>>>>>> Following Kent Beck's advise might reasonably split into two
>>> commits.
>>>>>> One
>>>>>>>>> refactor commit and a separate commit that introduces the actual
>>>>>> change.
>>>>>>>>> They should be individually revertible and might be easier
>>> understood
>>>>>> if
>>>>>>>>> split out. I vividly remember a change on our code base where
>>> someone
>>>>>>>> did a
>>>>>>>>> huge amount of refactoring that resulted than in one parameter
>>>> changing
>>>>>>>> in
>>>>>>>>> order to get the desired functionality change. If that was in one
>>>>>> commit,
>>>>>>>>> it would be hard to see the actual change. If split out, it's
>>>> beautiful
>>>>>>>> and
>>>>>>>>> crystal clear.
>>>>>>>>>
>>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
>>>>>>>> references.
>>>>>>>>> Usually we assume that if there is a commit with the ticket number,
>>>> the
>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>>>> refactoring
>>>>>>>>> ticket.
>>>>>>>>>
>>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>>
>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
>>> wrote:
>>>>>>>>>> It is to help with bisect operations when things start failing ...
>>>>>>>> helps
>>>>>>>>> us
>>>>>>>>>> it revert and build faster.
>>>>>>>>>> also with cherry picking features / fixes to previous versions .
>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
>>>> commits”.
>>>>>>>>>> Regards
>>>>>>>>>> Naba
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
>>> wrote:
>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
>>>>>>>> keep
>>>>>>>>>> them
>>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
>>>> wrote:
>>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>>
>>>>>>>>>>>> A kind request for using squash commit instead of using merge.
>>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>>> regression/flakiness in the product is introduced. We can
>>> automate
>>>>>>>>> and
>>>>>>>>>> go
>>>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless
>>> fix"
>>>>>>>>> and
>>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>>>>>>>> branch.
>>>>>>>>>>>> Also, please use the commit format : (helps us to know who
>>> worked
>>>>>>>> on
>>>>>>>>>> it,
>>>>>>>>>>>> what is the history)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>>> * explanation line 1 *
>>> explanation
>>>>>>>>> line
>>>>>>>>>> 2*
>>>>>>>>>>>> This is not a rule or anything, but a request to help out your
>>>>>>>> fellow
>>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>>
>>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
>>> they
>>>>>>>>> have
>>>>>>>>>> a
>>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>>> attachment]
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Naba.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Jacob Barrett <jb...@pivotal.io>.
I’m in agreement with Dan. Changes to the infrastructure to flat out prevent things that should be self policing is annoying. This PR review lock we have had already cost us valuable time waiting for PR pipelines to pass that have no relevance to the commit, like CI work: I’d hat to see yet another process enforced that Kees us from getting work done when necessary.
-Jake
> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>
> -1 to (1) and (2).
>
> I think merge commits are appropriate in certain circumstances, so I don't
> think we should make a blanket restriction. In fact I think our release
> process involves some merges.
>
> I think setting standards on what is reasonable to be an individual commit
> will do a lot more to clean up our history than blocking merges. We'd
> rather not see commits like "Spotless Apply" in the history, but if
> reasonably separate and well written commits come in as part of a merge, I
> think that's fine.
>
> -Dan
>
>> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io> wrote:
>>
>> +1
>>
>>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io> wrote:
>>>
>>> I’d like to advance this topic from an informal request/discussion to a
>>> discussion of a concrete proposal.
>>>
>>> To recap, it sounds like there is general agreement that commit history
>> on
>>> develop should be linear (no merge commits), and that the biggest
>> obstacle
>>> to this is that the PR merge button in GitHub creates a merge commit by
>>> default.
>>>
>>> I propose the following changes:
>>> 1) Change GitHub settings to remove the ability to create a merge commit.
>>> This will make Squash & Merge the default.
>>>
>>> 2) Change GitHub settings to require linear history on develop. This
>>> prevents merge commits via command-line (not recommended, but wiki still
>>> has instructions for merging PRs this way).
>>>
>>> 3) Update the PR template to change the text "Is your initial
>> contribution
>>> a single, squashed commit” to “Is your initial contribution squashed for
>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
>>> ‘fix’ commit)"
>>>
>>> For clarity, I am proposing no-change in the following areas:
>>> i) Leave Rebase & Merge as an option for PRs that have been structured to
>>> benefit from it (this can make it easier in a bisect to see whether the
>>> refactoring or the “fix” broke something).
>>> ii) Leave existing wording in the wiki as-is [stating that squashing is
>>> preferred].
>>>
>>>
>>> Please comment via this email thread.
>>> -Owen
>>>
>>>
>>>
>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>>
>>>> I think it's already resolved Udo ;)
>>>>
>>>> Here's the problem, if I fixup a dunit test by removing all uses of
>>> "this."
>>>> and I rename the dunit test, then git doesn't remember that the file
>> is a
>>>> rename -- it forever afterwards interprets it as a new file that I
>>> created
>>>> if I touch more than 50% of the lines (which "this." can easily do). If
>>> we
>>>> squash two commits: the rename and the cleanup of that dunit test --
>> then
>>>> we effectively lose the history of that file and it shows that I
>> created
>>> a
>>>> new file.
>>>>
>>>> Also for the record, I've been working on Geode since the beginning
>> and I
>>>> was never made aware of this change in our process. I never voted on
>> it.
>>>> I'm not a big fan of changing various details in our process every
>> single
>>>> week. It's very easy to miss these discussions unless someone points it
>>> out
>>>> to me.
>>>>
>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <uk...@pivotal.io>
>>>> wrote:
>>>>
>>>>> I'm not sure what this discussion is about... WE, as a community, have
>>>>> agreed in common practices, in two place no less...
>>>>>
>>>>> 1) Quoting our PR template
>>>>>
>>>>>
>>>>> For all changes:
>>>>>
>>>>> *
>>>>>
>>>>> Is there a JIRA ticket associated with this PR? Is it referenced in
>>>>> the commit message?
>>>>>
>>>>> *
>>>>>
>>>>> Has your PR been rebased against the latest commit within the
>> target
>>>>> branch (typically|develop|)?
>>>>>
>>>>> *
>>>>>
>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>
>>>>> *
>>>>>
>>>>> Does|gradlew build|run cleanly?
>>>>>
>>>>> *
>>>>>
>>>>> Have you written or updated unit tests to verify your changes?
>>>>>
>>>>> *
>>>>>
>>>>> If adding new dependencies to the code, are these dependencies
>>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>
>>>>> On our PR template we call out that the initial PR commit should be
>>>>> squashed.
>>>>>
>>>>> 2)
>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>
>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>
>>>>>
>>>>> @Kirk, if each of your commits "stands alone", I commend you on the
>>>>> diligence, but in reality, they should either then be stand alone PR's
>>>>> or just extra work created for yourself.
>>>>>
>>>>> If we want to change the way we have agreed upon we
>> submit/commit/merge
>>>>> changes back into develop... Then this is another discussion thread,
>>>>> until then, I think we should all remind ourselves on our agreed
>>>>> contributions code of conduct.
>>>>>
>>>>> --Udo
>>>>>
>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>> Kirk, I believe that creating a Pull Request with multiple commits is
>>> ok.
>>>>>> It's just in the end that when it's being pushed to develop branch,
>> it
>>>>>> needs to be squash merged. I believe that is what you have mentioned
>> in
>>>>> the
>>>>>> first paragraph, and I am more than happy with that.
>>>>>> If you can see in the first screenshot comparison that I had attached
>>> in
>>>>>> the first email in this thread is what I want to avoid.
>>>>>>
>>>>>> Thank you for your feedback.
>>>>>>
>>>>>> Regards
>>>>>> Naba
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
>>>>>>
>>>>>>> Whenever I submit a PR with multiple commits that I intend to rebase
>>> to
>>>>>>> develop, I always try to ensure that each commit stands alone as is
>>>>>>> (compiles and passes tests). Separating file renames and refactoring
>>>>> from
>>>>>>> behavior changes into different commits seems very valuable to me,
>> and
>>>>> I've
>>>>>>> had trouble getting people to review PRs without this separation
>> (but
>>> it
>>>>>>> could be squashed as it's merged to develop).
>>>>>>>
>>>>>>> It sounds to me like the real problem is (a) some PRs have multiple
>>>>> commits
>>>>>>> that don't compile or don't pass tests, and (b) some PRs that should
>>> be
>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>
>>>>>>> I can submit multiple PRs instead of one PR with multiple commits.
>> So
>>>>> I'll
>>>>>>> change my response to -0 if that helps prevent commits to develop
>> that
>>>>>>> don't compile or pass tests. Without preventing rebase or merge
>>> commits
>>>>>>> from github, I'm not sure how we can really enforce this or prevent
>>> (b)
>>>>>>> above.
>>>>>>>
>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>> amurmann@pivotal.io>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>>>>>>>
>>>>>>>> Make the change easy (warning: this may be hard), then make the
>> easy
>>>>>>>>> change."
>>>>>>>> -Kent Beck
>>>>>>>>
>>>>>>>> Following Kent Beck's advise might reasonably split into two
>> commits.
>>>>> One
>>>>>>>> refactor commit and a separate commit that introduces the actual
>>>>> change.
>>>>>>>> They should be individually revertible and might be easier
>> understood
>>>>> if
>>>>>>>> split out. I vividly remember a change on our code base where
>> someone
>>>>>>> did a
>>>>>>>> huge amount of refactoring that resulted than in one parameter
>>> changing
>>>>>>> in
>>>>>>>> order to get the desired functionality change. If that was in one
>>>>> commit,
>>>>>>>> it would be hard to see the actual change. If split out, it's
>>> beautiful
>>>>>>> and
>>>>>>>> crystal clear.
>>>>>>>>
>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
>>>>>>> references.
>>>>>>>> Usually we assume that if there is a commit with the ticket number,
>>> the
>>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>>> refactoring
>>>>>>>> ticket.
>>>>>>>>
>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>
>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
>> wrote:
>>>>>>>>
>>>>>>>>> It is to help with bisect operations when things start failing ...
>>>>>>> helps
>>>>>>>> us
>>>>>>>>> it revert and build faster.
>>>>>>>>> also with cherry picking features / fixes to previous versions .
>>>>>>>>> And keeping the git history clean with no unnecessary “merge
>>> commits”.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Naba
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
>> wrote:
>>>>>>>>>
>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
>>>>>>> keep
>>>>>>>>> them
>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>
>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>
>>>>>>>>>>> A kind request for using squash commit instead of using merge.
>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>> regression/flakiness in the product is introduced. We can
>> automate
>>>>>>>> and
>>>>>>>>> go
>>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless
>> fix"
>>>>>>>> and
>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>>>>>>> branch.
>>>>>>>>>>> Also, please use the commit format : (helps us to know who
>> worked
>>>>>>> on
>>>>>>>>> it,
>>>>>>>>>>> what is the history)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>> * explanation line 1 *
>> explanation
>>>>>>>> line
>>>>>>>>> 2*
>>>>>>>>>>> This is not a rule or anything, but a request to help out your
>>>>>>> fellow
>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>
>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
>> they
>>>>>>>> have
>>>>>>>>> a
>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>> attachment]
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Naba.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>
>>>
>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Robert Houghton <rh...@pivotal.io>.
@onichols
Correction: The 'git-flow' workflow that Geode follows is to merge a
release commit to master and to develop.
On Thu, Dec 19, 2019 at 4:51 PM Owen Nichols <on...@pivotal.io> wrote:
> Dan, to address some of your concerns:
>
> This proposal is to block merge commit on develop only. The release
> process makes a merge commit to master only.
>
> This proposal explicitly allows reasonably separate and well written
> commits in a single PR. For this case simply choose Rebase & Merge, and
> all of the commits in the PR will be brought to develop individually (no
> merge commit wrapping them).
>
> If you still feel strongly that merge commits should be allowed on
> develop, would you consider approving 1) to prevent accidental GitHub
> accidents, but veto only 2) to allow merge commits to be explicitly created
> manually when explicitly desired?
>
> > On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
> >
> > -1 to (1) and (2).
> >
> > I think merge commits are appropriate in certain circumstances, so I
> don't
> > think we should make a blanket restriction. In fact I think our release
> > process involves some merges.
> >
> > I think setting standards on what is reasonable to be an individual
> commit
> > will do a lot more to clean up our history than blocking merges. We'd
> > rather not see commits like "Spotless Apply" in the history, but if
> > reasonably separate and well written commits come in as part of a merge,
> I
> > think that's fine.
> >
> > -Dan
> >
> > On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io> wrote:
> >
> >> +1
> >>
> >> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io> wrote:
> >>
> >>> I’d like to advance this topic from an informal request/discussion to a
> >>> discussion of a concrete proposal.
> >>>
> >>> To recap, it sounds like there is general agreement that commit history
> >> on
> >>> develop should be linear (no merge commits), and that the biggest
> >> obstacle
> >>> to this is that the PR merge button in GitHub creates a merge commit by
> >>> default.
> >>>
> >>> I propose the following changes:
> >>> 1) Change GitHub settings to remove the ability to create a merge
> commit.
> >>> This will make Squash & Merge the default.
> >>>
> >>> 2) Change GitHub settings to require linear history on develop. This
> >>> prevents merge commits via command-line (not recommended, but wiki
> still
> >>> has instructions for merging PRs this way).
> >>>
> >>> 3) Update the PR template to change the text "Is your initial
> >> contribution
> >>> a single, squashed commit” to “Is your initial contribution squashed
> for
> >>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
> >>> ‘fix’ commit)"
> >>>
> >>> For clarity, I am proposing no-change in the following areas:
> >>> i) Leave Rebase & Merge as an option for PRs that have been structured
> to
> >>> benefit from it (this can make it easier in a bisect to see whether the
> >>> refactoring or the “fix” broke something).
> >>> ii) Leave existing wording in the wiki as-is [stating that squashing is
> >>> preferred].
> >>>
> >>>
> >>> Please comment via this email thread.
> >>> -Owen
> >>>
> >>>
> >>>
> >>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
> >>>>
> >>>> I think it's already resolved Udo ;)
> >>>>
> >>>> Here's the problem, if I fixup a dunit test by removing all uses of
> >>> "this."
> >>>> and I rename the dunit test, then git doesn't remember that the file
> >> is a
> >>>> rename -- it forever afterwards interprets it as a new file that I
> >>> created
> >>>> if I touch more than 50% of the lines (which "this." can easily do).
> If
> >>> we
> >>>> squash two commits: the rename and the cleanup of that dunit test --
> >> then
> >>>> we effectively lose the history of that file and it shows that I
> >> created
> >>> a
> >>>> new file.
> >>>>
> >>>> Also for the record, I've been working on Geode since the beginning
> >> and I
> >>>> was never made aware of this change in our process. I never voted on
> >> it.
> >>>> I'm not a big fan of changing various details in our process every
> >> single
> >>>> week. It's very easy to miss these discussions unless someone points
> it
> >>> out
> >>>> to me.
> >>>>
> >>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <ukohlmeyer@pivotal.io
> >
> >>>> wrote:
> >>>>
> >>>>> I'm not sure what this discussion is about... WE, as a community,
> have
> >>>>> agreed in common practices, in two place no less...
> >>>>>
> >>>>> 1) Quoting our PR template
> >>>>>
> >>>>>
> >>>>> For all changes:
> >>>>>
> >>>>> *
> >>>>>
> >>>>> Is there a JIRA ticket associated with this PR? Is it referenced in
> >>>>> the commit message?
> >>>>>
> >>>>> *
> >>>>>
> >>>>> Has your PR been rebased against the latest commit within the
> >> target
> >>>>> branch (typically|develop|)?
> >>>>>
> >>>>> *
> >>>>>
> >>>>> ***Is your initial contribution a single, squashed commit?*
> >>>>>
> >>>>> *
> >>>>>
> >>>>> Does|gradlew build|run cleanly?
> >>>>>
> >>>>> *
> >>>>>
> >>>>> Have you written or updated unit tests to verify your changes?
> >>>>>
> >>>>> *
> >>>>>
> >>>>> If adding new dependencies to the code, are these dependencies
> >>>>> licensed in a way that is compatible for inclusion underASF 2.0
> >>>>> <http://www.apache.org/legal/resolved.html#category-a>?
> >>>>>
> >>>>> On our PR template we call out that the initial PR commit should be
> >>>>> squashed.
> >>>>>
> >>>>> 2)
> >> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>>> <
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >>>
> >>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
> >>>>>
> >>>>>
> >>>>> @Kirk, if each of your commits "stands alone", I commend you on the
> >>>>> diligence, but in reality, they should either then be stand alone
> PR's
> >>>>> or just extra work created for yourself.
> >>>>>
> >>>>> If we want to change the way we have agreed upon we
> >> submit/commit/merge
> >>>>> changes back into develop... Then this is another discussion thread,
> >>>>> until then, I think we should all remind ourselves on our agreed
> >>>>> contributions code of conduct.
> >>>>>
> >>>>> --Udo
> >>>>>
> >>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >>>>>> Kirk, I believe that creating a Pull Request with multiple commits
> is
> >>> ok.
> >>>>>> It's just in the end that when it's being pushed to develop branch,
> >> it
> >>>>>> needs to be squash merged. I believe that is what you have mentioned
> >> in
> >>>>> the
> >>>>>> first paragraph, and I am more than happy with that.
> >>>>>> If you can see in the first screenshot comparison that I had
> attached
> >>> in
> >>>>>> the first email in this thread is what I want to avoid.
> >>>>>>
> >>>>>> Thank you for your feedback.
> >>>>>>
> >>>>>> Regards
> >>>>>> Naba
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
> >>>>>>
> >>>>>>> Whenever I submit a PR with multiple commits that I intend to
> rebase
> >>> to
> >>>>>>> develop, I always try to ensure that each commit stands alone as is
> >>>>>>> (compiles and passes tests). Separating file renames and
> refactoring
> >>>>> from
> >>>>>>> behavior changes into different commits seems very valuable to me,
> >> and
> >>>>> I've
> >>>>>>> had trouble getting people to review PRs without this separation
> >> (but
> >>> it
> >>>>>>> could be squashed as it's merged to develop).
> >>>>>>>
> >>>>>>> It sounds to me like the real problem is (a) some PRs have multiple
> >>>>> commits
> >>>>>>> that don't compile or don't pass tests, and (b) some PRs that
> should
> >>> be
> >>>>>>> merged with squash are not (by accident most likely).
> >>>>>>>
> >>>>>>> I can submit multiple PRs instead of one PR with multiple commits.
> >> So
> >>>>> I'll
> >>>>>>> change my response to -0 if that helps prevent commits to develop
> >> that
> >>>>>>> don't compile or pass tests. Without preventing rebase or merge
> >>> commits
> >>>>>>> from github, I'm not sure how we can really enforce this or prevent
> >>> (b)
> >>>>>>> above.
> >>>>>>>
> >>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >>> amurmann@pivotal.io>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
> >>>>>>>>
> >>>>>>>> Make the change easy (warning: this may be hard), then make the
> >> easy
> >>>>>>>>> change."
> >>>>>>>> -Kent Beck
> >>>>>>>>
> >>>>>>>> Following Kent Beck's advise might reasonably split into two
> >> commits.
> >>>>> One
> >>>>>>>> refactor commit and a separate commit that introduces the actual
> >>>>> change.
> >>>>>>>> They should be individually revertible and might be easier
> >> understood
> >>>>> if
> >>>>>>>> split out. I vividly remember a change on our code base where
> >> someone
> >>>>>>> did a
> >>>>>>>> huge amount of refactoring that resulted than in one parameter
> >>> changing
> >>>>>>> in
> >>>>>>>> order to get the desired functionality change. If that was in one
> >>>>> commit,
> >>>>>>>> it would be hard to see the actual change. If split out, it's
> >>> beautiful
> >>>>>>> and
> >>>>>>>> crystal clear.
> >>>>>>>>
> >>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
> >>>>>>> references.
> >>>>>>>> Usually we assume that if there is a commit with the ticket
> number,
> >>> the
> >>>>>>>> issue is resolved. Maybe the key here is to create a separate
> >>>>> refactoring
> >>>>>>>> ticket.
> >>>>>>>>
> >>>>>>>> Would that allow us to have our cake and eat it too?
> >>>>>>>>
> >>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
> >> wrote:
> >>>>>>>>
> >>>>>>>>> It is to help with bisect operations when things start failing
> ...
> >>>>>>> helps
> >>>>>>>> us
> >>>>>>>>> it revert and build faster.
> >>>>>>>>> also with cherry picking features / fixes to previous versions .
> >>>>>>>>> And keeping the git history clean with no unnecessary “merge
> >>> commits”.
> >>>>>>>>>
> >>>>>>>>> Regards
> >>>>>>>>> Naba
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
> >> wrote:
> >>>>>>>>>
> >>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR
> and
> >>>>>>> keep
> >>>>>>>>> them
> >>>>>>>>>> separate when they merge to develop
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
> >>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi Geode Committers,
> >>>>>>>>>>>
> >>>>>>>>>>> A kind request for using squash commit instead of using merge.
> >>>>>>>>>>> This will really help us in our bisect operations when a
> >>>>>>>>>>> regression/flakiness in the product is introduced. We can
> >> automate
> >>>>>>>> and
> >>>>>>>>> go
> >>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless
> >> fix"
> >>>>>>>> and
> >>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
> >>>>>>> branch.
> >>>>>>>>>>> Also, please use the commit format : (helps us to know who
> >> worked
> >>>>>>> on
> >>>>>>>>> it,
> >>>>>>>>>>> what is the history)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> * GEODE-xxxx: <brief intro >
> >>>>>>>>>>> * explanation line 1 *
> >> explanation
> >>>>>>>> line
> >>>>>>>>> 2*
> >>>>>>>>>>> This is not a rule or anything, but a request to help out your
> >>>>>>> fellow
> >>>>>>>>>>> committers in quickly detecting a problem.
> >>>>>>>>>>>
> >>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
> >> they
> >>>>>>>> have
> >>>>>>>>> a
> >>>>>>>>>>> complete linear graph for their main branch HEAD [see
> >> attachment]
> >>>>>>>>>>>
> >>>>>>>>>>> Regards
> >>>>>>>>>>> Naba.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>
> >>>
> >>>
> >>
>
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
Dan, to address some of your concerns:
This proposal is to block merge commit on develop only. The release process makes a merge commit to master only.
This proposal explicitly allows reasonably separate and well written commits in a single PR. For this case simply choose Rebase & Merge, and all of the commits in the PR will be brought to develop individually (no merge commit wrapping them).
If you still feel strongly that merge commits should be allowed on develop, would you consider approving 1) to prevent accidental GitHub accidents, but veto only 2) to allow merge commits to be explicitly created manually when explicitly desired?
> On Dec 19, 2019, at 4:43 PM, Dan Smith <ds...@pivotal.io> wrote:
>
> -1 to (1) and (2).
>
> I think merge commits are appropriate in certain circumstances, so I don't
> think we should make a blanket restriction. In fact I think our release
> process involves some merges.
>
> I think setting standards on what is reasonable to be an individual commit
> will do a lot more to clean up our history than blocking merges. We'd
> rather not see commits like "Spotless Apply" in the history, but if
> reasonably separate and well written commits come in as part of a merge, I
> think that's fine.
>
> -Dan
>
> On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io> wrote:
>
>> +1
>>
>> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io> wrote:
>>
>>> I’d like to advance this topic from an informal request/discussion to a
>>> discussion of a concrete proposal.
>>>
>>> To recap, it sounds like there is general agreement that commit history
>> on
>>> develop should be linear (no merge commits), and that the biggest
>> obstacle
>>> to this is that the PR merge button in GitHub creates a merge commit by
>>> default.
>>>
>>> I propose the following changes:
>>> 1) Change GitHub settings to remove the ability to create a merge commit.
>>> This will make Squash & Merge the default.
>>>
>>> 2) Change GitHub settings to require linear history on develop. This
>>> prevents merge commits via command-line (not recommended, but wiki still
>>> has instructions for merging PRs this way).
>>>
>>> 3) Update the PR template to change the text "Is your initial
>> contribution
>>> a single, squashed commit” to “Is your initial contribution squashed for
>>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
>>> ‘fix’ commit)"
>>>
>>> For clarity, I am proposing no-change in the following areas:
>>> i) Leave Rebase & Merge as an option for PRs that have been structured to
>>> benefit from it (this can make it easier in a bisect to see whether the
>>> refactoring or the “fix” broke something).
>>> ii) Leave existing wording in the wiki as-is [stating that squashing is
>>> preferred].
>>>
>>>
>>> Please comment via this email thread.
>>> -Owen
>>>
>>>
>>>
>>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>>
>>>> I think it's already resolved Udo ;)
>>>>
>>>> Here's the problem, if I fixup a dunit test by removing all uses of
>>> "this."
>>>> and I rename the dunit test, then git doesn't remember that the file
>> is a
>>>> rename -- it forever afterwards interprets it as a new file that I
>>> created
>>>> if I touch more than 50% of the lines (which "this." can easily do). If
>>> we
>>>> squash two commits: the rename and the cleanup of that dunit test --
>> then
>>>> we effectively lose the history of that file and it shows that I
>> created
>>> a
>>>> new file.
>>>>
>>>> Also for the record, I've been working on Geode since the beginning
>> and I
>>>> was never made aware of this change in our process. I never voted on
>> it.
>>>> I'm not a big fan of changing various details in our process every
>> single
>>>> week. It's very easy to miss these discussions unless someone points it
>>> out
>>>> to me.
>>>>
>>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <uk...@pivotal.io>
>>>> wrote:
>>>>
>>>>> I'm not sure what this discussion is about... WE, as a community, have
>>>>> agreed in common practices, in two place no less...
>>>>>
>>>>> 1) Quoting our PR template
>>>>>
>>>>>
>>>>> For all changes:
>>>>>
>>>>> *
>>>>>
>>>>> Is there a JIRA ticket associated with this PR? Is it referenced in
>>>>> the commit message?
>>>>>
>>>>> *
>>>>>
>>>>> Has your PR been rebased against the latest commit within the
>> target
>>>>> branch (typically|develop|)?
>>>>>
>>>>> *
>>>>>
>>>>> ***Is your initial contribution a single, squashed commit?*
>>>>>
>>>>> *
>>>>>
>>>>> Does|gradlew build|run cleanly?
>>>>>
>>>>> *
>>>>>
>>>>> Have you written or updated unit tests to verify your changes?
>>>>>
>>>>> *
>>>>>
>>>>> If adding new dependencies to the code, are these dependencies
>>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>>
>>>>> On our PR template we call out that the initial PR commit should be
>>>>> squashed.
>>>>>
>>>>> 2)
>> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>>> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>
>>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>>
>>>>>
>>>>> @Kirk, if each of your commits "stands alone", I commend you on the
>>>>> diligence, but in reality, they should either then be stand alone PR's
>>>>> or just extra work created for yourself.
>>>>>
>>>>> If we want to change the way we have agreed upon we
>> submit/commit/merge
>>>>> changes back into develop... Then this is another discussion thread,
>>>>> until then, I think we should all remind ourselves on our agreed
>>>>> contributions code of conduct.
>>>>>
>>>>> --Udo
>>>>>
>>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>>> Kirk, I believe that creating a Pull Request with multiple commits is
>>> ok.
>>>>>> It's just in the end that when it's being pushed to develop branch,
>> it
>>>>>> needs to be squash merged. I believe that is what you have mentioned
>> in
>>>>> the
>>>>>> first paragraph, and I am more than happy with that.
>>>>>> If you can see in the first screenshot comparison that I had attached
>>> in
>>>>>> the first email in this thread is what I want to avoid.
>>>>>>
>>>>>> Thank you for your feedback.
>>>>>>
>>>>>> Regards
>>>>>> Naba
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
>>>>>>
>>>>>>> Whenever I submit a PR with multiple commits that I intend to rebase
>>> to
>>>>>>> develop, I always try to ensure that each commit stands alone as is
>>>>>>> (compiles and passes tests). Separating file renames and refactoring
>>>>> from
>>>>>>> behavior changes into different commits seems very valuable to me,
>> and
>>>>> I've
>>>>>>> had trouble getting people to review PRs without this separation
>> (but
>>> it
>>>>>>> could be squashed as it's merged to develop).
>>>>>>>
>>>>>>> It sounds to me like the real problem is (a) some PRs have multiple
>>>>> commits
>>>>>>> that don't compile or don't pass tests, and (b) some PRs that should
>>> be
>>>>>>> merged with squash are not (by accident most likely).
>>>>>>>
>>>>>>> I can submit multiple PRs instead of one PR with multiple commits.
>> So
>>>>> I'll
>>>>>>> change my response to -0 if that helps prevent commits to develop
>> that
>>>>>>> don't compile or pass tests. Without preventing rebase or merge
>>> commits
>>>>>>> from github, I'm not sure how we can really enforce this or prevent
>>> (b)
>>>>>>> above.
>>>>>>>
>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>>> amurmann@pivotal.io>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>>>>>>>
>>>>>>>> Make the change easy (warning: this may be hard), then make the
>> easy
>>>>>>>>> change."
>>>>>>>> -Kent Beck
>>>>>>>>
>>>>>>>> Following Kent Beck's advise might reasonably split into two
>> commits.
>>>>> One
>>>>>>>> refactor commit and a separate commit that introduces the actual
>>>>> change.
>>>>>>>> They should be individually revertible and might be easier
>> understood
>>>>> if
>>>>>>>> split out. I vividly remember a change on our code base where
>> someone
>>>>>>> did a
>>>>>>>> huge amount of refactoring that resulted than in one parameter
>>> changing
>>>>>>> in
>>>>>>>> order to get the desired functionality change. If that was in one
>>>>> commit,
>>>>>>>> it would be hard to see the actual change. If split out, it's
>>> beautiful
>>>>>>> and
>>>>>>>> crystal clear.
>>>>>>>>
>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
>>>>>>> references.
>>>>>>>> Usually we assume that if there is a commit with the ticket number,
>>> the
>>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>>> refactoring
>>>>>>>> ticket.
>>>>>>>>
>>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>>
>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
>> wrote:
>>>>>>>>
>>>>>>>>> It is to help with bisect operations when things start failing ...
>>>>>>> helps
>>>>>>>> us
>>>>>>>>> it revert and build faster.
>>>>>>>>> also with cherry picking features / fixes to previous versions .
>>>>>>>>> And keeping the git history clean with no unnecessary “merge
>>> commits”.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Naba
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
>> wrote:
>>>>>>>>>
>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
>>>>>>> keep
>>>>>>>>> them
>>>>>>>>>> separate when they merge to develop
>>>>>>>>>>
>>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>>
>>>>>>>>>>> A kind request for using squash commit instead of using merge.
>>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>>> regression/flakiness in the product is introduced. We can
>> automate
>>>>>>>> and
>>>>>>>>> go
>>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless
>> fix"
>>>>>>>> and
>>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>>>>>>> branch.
>>>>>>>>>>> Also, please use the commit format : (helps us to know who
>> worked
>>>>>>> on
>>>>>>>>> it,
>>>>>>>>>>> what is the history)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>>> * explanation line 1 *
>> explanation
>>>>>>>> line
>>>>>>>>> 2*
>>>>>>>>>>> This is not a rule or anything, but a request to help out your
>>>>>>> fellow
>>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>>
>>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
>> they
>>>>>>>> have
>>>>>>>>> a
>>>>>>>>>>> complete linear graph for their main branch HEAD [see
>> attachment]
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Naba.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>
>>>
>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Dan Smith <ds...@pivotal.io>.
-1 to (1) and (2).
I think merge commits are appropriate in certain circumstances, so I don't
think we should make a blanket restriction. In fact I think our release
process involves some merges.
I think setting standards on what is reasonable to be an individual commit
will do a lot more to clean up our history than blocking merges. We'd
rather not see commits like "Spotless Apply" in the history, but if
reasonably separate and well written commits come in as part of a merge, I
think that's fine.
-Dan
On Thu, Dec 19, 2019 at 4:27 PM Jinmei Liao <ji...@pivotal.io> wrote:
> +1
>
> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io> wrote:
>
> > I’d like to advance this topic from an informal request/discussion to a
> > discussion of a concrete proposal.
> >
> > To recap, it sounds like there is general agreement that commit history
> on
> > develop should be linear (no merge commits), and that the biggest
> obstacle
> > to this is that the PR merge button in GitHub creates a merge commit by
> > default.
> >
> > I propose the following changes:
> > 1) Change GitHub settings to remove the ability to create a merge commit.
> > This will make Squash & Merge the default.
> >
> > 2) Change GitHub settings to require linear history on develop. This
> > prevents merge commits via command-line (not recommended, but wiki still
> > has instructions for merging PRs this way).
> >
> > 3) Update the PR template to change the text "Is your initial
> contribution
> > a single, squashed commit” to “Is your initial contribution squashed for
> > ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
> > ‘fix’ commit)"
> >
> > For clarity, I am proposing no-change in the following areas:
> > i) Leave Rebase & Merge as an option for PRs that have been structured to
> > benefit from it (this can make it easier in a bisect to see whether the
> > refactoring or the “fix” broke something).
> > ii) Leave existing wording in the wiki as-is [stating that squashing is
> > preferred].
> >
> >
> > Please comment via this email thread.
> > -Owen
> >
> >
> >
> > > On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
> > >
> > > I think it's already resolved Udo ;)
> > >
> > > Here's the problem, if I fixup a dunit test by removing all uses of
> > "this."
> > > and I rename the dunit test, then git doesn't remember that the file
> is a
> > > rename -- it forever afterwards interprets it as a new file that I
> > created
> > > if I touch more than 50% of the lines (which "this." can easily do). If
> > we
> > > squash two commits: the rename and the cleanup of that dunit test --
> then
> > > we effectively lose the history of that file and it shows that I
> created
> > a
> > > new file.
> > >
> > > Also for the record, I've been working on Geode since the beginning
> and I
> > > was never made aware of this change in our process. I never voted on
> it.
> > > I'm not a big fan of changing various details in our process every
> single
> > > week. It's very easy to miss these discussions unless someone points it
> > out
> > > to me.
> > >
> > > On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <uk...@pivotal.io>
> > > wrote:
> > >
> > >> I'm not sure what this discussion is about... WE, as a community, have
> > >> agreed in common practices, in two place no less...
> > >>
> > >> 1) Quoting our PR template
> > >>
> > >>
> > >> For all changes:
> > >>
> > >> *
> > >>
> > >> Is there a JIRA ticket associated with this PR? Is it referenced in
> > >> the commit message?
> > >>
> > >> *
> > >>
> > >> Has your PR been rebased against the latest commit within the
> target
> > >> branch (typically|develop|)?
> > >>
> > >> *
> > >>
> > >> ***Is your initial contribution a single, squashed commit?*
> > >>
> > >> *
> > >>
> > >> Does|gradlew build|run cleanly?
> > >>
> > >> *
> > >>
> > >> Have you written or updated unit tests to verify your changes?
> > >>
> > >> *
> > >>
> > >> If adding new dependencies to the code, are these dependencies
> > >> licensed in a way that is compatible for inclusion underASF 2.0
> > >> <http://www.apache.org/legal/resolved.html#category-a>?
> > >>
> > >> On our PR template we call out that the initial PR commit should be
> > >> squashed.
> > >>
> > >> 2)
> https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> > >> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >
> > >> -- See "Accepting a PR Using the Command Line" - Point #3.
> > >>
> > >>
> > >> @Kirk, if each of your commits "stands alone", I commend you on the
> > >> diligence, but in reality, they should either then be stand alone PR's
> > >> or just extra work created for yourself.
> > >>
> > >> If we want to change the way we have agreed upon we
> submit/commit/merge
> > >> changes back into develop... Then this is another discussion thread,
> > >> until then, I think we should all remind ourselves on our agreed
> > >> contributions code of conduct.
> > >>
> > >> --Udo
> > >>
> > >> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > >>> Kirk, I believe that creating a Pull Request with multiple commits is
> > ok.
> > >>> It's just in the end that when it's being pushed to develop branch,
> it
> > >>> needs to be squash merged. I believe that is what you have mentioned
> in
> > >> the
> > >>> first paragraph, and I am more than happy with that.
> > >>> If you can see in the first screenshot comparison that I had attached
> > in
> > >>> the first email in this thread is what I want to avoid.
> > >>>
> > >>> Thank you for your feedback.
> > >>>
> > >>> Regards
> > >>> Naba
> > >>>
> > >>>
> > >>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
> > >>>
> > >>>> Whenever I submit a PR with multiple commits that I intend to rebase
> > to
> > >>>> develop, I always try to ensure that each commit stands alone as is
> > >>>> (compiles and passes tests). Separating file renames and refactoring
> > >> from
> > >>>> behavior changes into different commits seems very valuable to me,
> and
> > >> I've
> > >>>> had trouble getting people to review PRs without this separation
> (but
> > it
> > >>>> could be squashed as it's merged to develop).
> > >>>>
> > >>>> It sounds to me like the real problem is (a) some PRs have multiple
> > >> commits
> > >>>> that don't compile or don't pass tests, and (b) some PRs that should
> > be
> > >>>> merged with squash are not (by accident most likely).
> > >>>>
> > >>>> I can submit multiple PRs instead of one PR with multiple commits.
> So
> > >> I'll
> > >>>> change my response to -0 if that helps prevent commits to develop
> that
> > >>>> don't compile or pass tests. Without preventing rebase or merge
> > commits
> > >>>> from github, I'm not sure how we can really enforce this or prevent
> > (b)
> > >>>> above.
> > >>>>
> > >>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> > amurmann@pivotal.io>
> > >>>> wrote:
> > >>>>
> > >>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
> > >>>>>
> > >>>>> Make the change easy (warning: this may be hard), then make the
> easy
> > >>>>>> change."
> > >>>>> -Kent Beck
> > >>>>>
> > >>>>> Following Kent Beck's advise might reasonably split into two
> commits.
> > >> One
> > >>>>> refactor commit and a separate commit that introduces the actual
> > >> change.
> > >>>>> They should be individually revertible and might be easier
> understood
> > >> if
> > >>>>> split out. I vividly remember a change on our code base where
> someone
> > >>>> did a
> > >>>>> huge amount of refactoring that resulted than in one parameter
> > changing
> > >>>> in
> > >>>>> order to get the desired functionality change. If that was in one
> > >> commit,
> > >>>>> it would be hard to see the actual change. If split out, it's
> > beautiful
> > >>>> and
> > >>>>> crystal clear.
> > >>>>>
> > >>>>> I am unsure how that would be reflected in terms of JIRA ticket
> > >>>> references.
> > >>>>> Usually we assume that if there is a commit with the ticket number,
> > the
> > >>>>> issue is resolved. Maybe the key here is to create a separate
> > >> refactoring
> > >>>>> ticket.
> > >>>>>
> > >>>>> Would that allow us to have our cake and eat it too?
> > >>>>>
> > >>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io>
> wrote:
> > >>>>>
> > >>>>>> It is to help with bisect operations when things start failing ...
> > >>>> helps
> > >>>>> us
> > >>>>>> it revert and build faster.
> > >>>>>> also with cherry picking features / fixes to previous versions .
> > >>>>>> And keeping the git history clean with no unnecessary “merge
> > commits”.
> > >>>>>>
> > >>>>>> Regards
> > >>>>>> Naba
> > >>>>>>
> > >>>>>>
> > >>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org>
> wrote:
> > >>>>>>
> > >>>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
> > >>>> keep
> > >>>>>> them
> > >>>>>>> separate when they merge to develop
> > >>>>>>>
> > >>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
> > wrote:
> > >>>>>>>
> > >>>>>>>> Hi Geode Committers,
> > >>>>>>>>
> > >>>>>>>> A kind request for using squash commit instead of using merge.
> > >>>>>>>> This will really help us in our bisect operations when a
> > >>>>>>>> regression/flakiness in the product is introduced. We can
> automate
> > >>>>> and
> > >>>>>> go
> > >>>>>>>> through fewer commits faster, avoiding commits like "spotless
> fix"
> > >>>>> and
> > >>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
> > >>>> branch.
> > >>>>>>>> Also, please use the commit format : (helps us to know who
> worked
> > >>>> on
> > >>>>>> it,
> > >>>>>>>> what is the history)
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> * GEODE-xxxx: <brief intro >
> > >>>>>>>> * explanation line 1 *
> explanation
> > >>>>> line
> > >>>>>> 2*
> > >>>>>>>> This is not a rule or anything, but a request to help out your
> > >>>> fellow
> > >>>>>>>> committers in quickly detecting a problem.
> > >>>>>>>>
> > >>>>>>>> For inspiration, we can look into Apache Kafka / Spark where
> they
> > >>>>> have
> > >>>>>> a
> > >>>>>>>> complete linear graph for their main branch HEAD [see
> attachment]
> > >>>>>>>>
> > >>>>>>>> Regards
> > >>>>>>>> Naba.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>
> >
> >
>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Mark Hanson <mh...@pivotal.io>.
+1
> On Dec 19, 2019, at 4:27 PM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> +1
>
> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io> wrote:
>
>> I’d like to advance this topic from an informal request/discussion to a
>> discussion of a concrete proposal.
>>
>> To recap, it sounds like there is general agreement that commit history on
>> develop should be linear (no merge commits), and that the biggest obstacle
>> to this is that the PR merge button in GitHub creates a merge commit by
>> default.
>>
>> I propose the following changes:
>> 1) Change GitHub settings to remove the ability to create a merge commit.
>> This will make Squash & Merge the default.
>>
>> 2) Change GitHub settings to require linear history on develop. This
>> prevents merge commits via command-line (not recommended, but wiki still
>> has instructions for merging PRs this way).
>>
>> 3) Update the PR template to change the text "Is your initial contribution
>> a single, squashed commit” to “Is your initial contribution squashed for
>> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
>> ‘fix’ commit)"
>>
>> For clarity, I am proposing no-change in the following areas:
>> i) Leave Rebase & Merge as an option for PRs that have been structured to
>> benefit from it (this can make it easier in a bisect to see whether the
>> refactoring or the “fix” broke something).
>> ii) Leave existing wording in the wiki as-is [stating that squashing is
>> preferred].
>>
>>
>> Please comment via this email thread.
>> -Owen
>>
>>
>>
>>> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>>>
>>> I think it's already resolved Udo ;)
>>>
>>> Here's the problem, if I fixup a dunit test by removing all uses of
>> "this."
>>> and I rename the dunit test, then git doesn't remember that the file is a
>>> rename -- it forever afterwards interprets it as a new file that I
>> created
>>> if I touch more than 50% of the lines (which "this." can easily do). If
>> we
>>> squash two commits: the rename and the cleanup of that dunit test -- then
>>> we effectively lose the history of that file and it shows that I created
>> a
>>> new file.
>>>
>>> Also for the record, I've been working on Geode since the beginning and I
>>> was never made aware of this change in our process. I never voted on it.
>>> I'm not a big fan of changing various details in our process every single
>>> week. It's very easy to miss these discussions unless someone points it
>> out
>>> to me.
>>>
>>> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <uk...@pivotal.io>
>>> wrote:
>>>
>>>> I'm not sure what this discussion is about... WE, as a community, have
>>>> agreed in common practices, in two place no less...
>>>>
>>>> 1) Quoting our PR template
>>>>
>>>>
>>>> For all changes:
>>>>
>>>> *
>>>>
>>>> Is there a JIRA ticket associated with this PR? Is it referenced in
>>>> the commit message?
>>>>
>>>> *
>>>>
>>>> Has your PR been rebased against the latest commit within the target
>>>> branch (typically|develop|)?
>>>>
>>>> *
>>>>
>>>> ***Is your initial contribution a single, squashed commit?*
>>>>
>>>> *
>>>>
>>>> Does|gradlew build|run cleanly?
>>>>
>>>> *
>>>>
>>>> Have you written or updated unit tests to verify your changes?
>>>>
>>>> *
>>>>
>>>> If adding new dependencies to the code, are these dependencies
>>>> licensed in a way that is compatible for inclusion underASF 2.0
>>>> <http://www.apache.org/legal/resolved.html#category-a>?
>>>>
>>>> On our PR template we call out that the initial PR commit should be
>>>> squashed.
>>>>
>>>> 2)https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>>>> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions>
>>>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>>>
>>>>
>>>> @Kirk, if each of your commits "stands alone", I commend you on the
>>>> diligence, but in reality, they should either then be stand alone PR's
>>>> or just extra work created for yourself.
>>>>
>>>> If we want to change the way we have agreed upon we submit/commit/merge
>>>> changes back into develop... Then this is another discussion thread,
>>>> until then, I think we should all remind ourselves on our agreed
>>>> contributions code of conduct.
>>>>
>>>> --Udo
>>>>
>>>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>>>> Kirk, I believe that creating a Pull Request with multiple commits is
>> ok.
>>>>> It's just in the end that when it's being pushed to develop branch, it
>>>>> needs to be squash merged. I believe that is what you have mentioned in
>>>> the
>>>>> first paragraph, and I am more than happy with that.
>>>>> If you can see in the first screenshot comparison that I had attached
>> in
>>>>> the first email in this thread is what I want to avoid.
>>>>>
>>>>> Thank you for your feedback.
>>>>>
>>>>> Regards
>>>>> Naba
>>>>>
>>>>>
>>>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
>>>>>
>>>>>> Whenever I submit a PR with multiple commits that I intend to rebase
>> to
>>>>>> develop, I always try to ensure that each commit stands alone as is
>>>>>> (compiles and passes tests). Separating file renames and refactoring
>>>> from
>>>>>> behavior changes into different commits seems very valuable to me, and
>>>> I've
>>>>>> had trouble getting people to review PRs without this separation (but
>> it
>>>>>> could be squashed as it's merged to develop).
>>>>>>
>>>>>> It sounds to me like the real problem is (a) some PRs have multiple
>>>> commits
>>>>>> that don't compile or don't pass tests, and (b) some PRs that should
>> be
>>>>>> merged with squash are not (by accident most likely).
>>>>>>
>>>>>> I can submit multiple PRs instead of one PR with multiple commits. So
>>>> I'll
>>>>>> change my response to -0 if that helps prevent commits to develop that
>>>>>> don't compile or pass tests. Without preventing rebase or merge
>> commits
>>>>>> from github, I'm not sure how we can really enforce this or prevent
>> (b)
>>>>>> above.
>>>>>>
>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
>> amurmann@pivotal.io>
>>>>>> wrote:
>>>>>>
>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>>>>>>
>>>>>>> Make the change easy (warning: this may be hard), then make the easy
>>>>>>>> change."
>>>>>>> -Kent Beck
>>>>>>>
>>>>>>> Following Kent Beck's advise might reasonably split into two commits.
>>>> One
>>>>>>> refactor commit and a separate commit that introduces the actual
>>>> change.
>>>>>>> They should be individually revertible and might be easier understood
>>>> if
>>>>>>> split out. I vividly remember a change on our code base where someone
>>>>>> did a
>>>>>>> huge amount of refactoring that resulted than in one parameter
>> changing
>>>>>> in
>>>>>>> order to get the desired functionality change. If that was in one
>>>> commit,
>>>>>>> it would be hard to see the actual change. If split out, it's
>> beautiful
>>>>>> and
>>>>>>> crystal clear.
>>>>>>>
>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
>>>>>> references.
>>>>>>> Usually we assume that if there is a commit with the ticket number,
>> the
>>>>>>> issue is resolved. Maybe the key here is to create a separate
>>>> refactoring
>>>>>>> ticket.
>>>>>>>
>>>>>>> Would that allow us to have our cake and eat it too?
>>>>>>>
>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>>>>>>
>>>>>>>> It is to help with bisect operations when things start failing ...
>>>>>> helps
>>>>>>> us
>>>>>>>> it revert and build faster.
>>>>>>>> also with cherry picking features / fixes to previous versions .
>>>>>>>> And keeping the git history clean with no unnecessary “merge
>> commits”.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Naba
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
>>>>>>>>
>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
>>>>>> keep
>>>>>>>> them
>>>>>>>>> separate when they merge to develop
>>>>>>>>>
>>>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Geode Committers,
>>>>>>>>>>
>>>>>>>>>> A kind request for using squash commit instead of using merge.
>>>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>>>> regression/flakiness in the product is introduced. We can automate
>>>>>>> and
>>>>>>>> go
>>>>>>>>>> through fewer commits faster, avoiding commits like "spotless fix"
>>>>>>> and
>>>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>>>>>> branch.
>>>>>>>>>> Also, please use the commit format : (helps us to know who worked
>>>>>> on
>>>>>>>> it,
>>>>>>>>>> what is the history)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>>>> * explanation line 1 * explanation
>>>>>>> line
>>>>>>>> 2*
>>>>>>>>>> This is not a rule or anything, but a request to help out your
>>>>>> fellow
>>>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>>>
>>>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where they
>>>>>>> have
>>>>>>>> a
>>>>>>>>>> complete linear graph for their main branch HEAD [see attachment]
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Naba.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>
>>
>>
Re: [DISCUSS] Proposal to require linear commit history on develop
Posted by Jinmei Liao <ji...@pivotal.io>.
+1
On Thu, Dec 19, 2019, 4:05 PM Owen Nichols <on...@pivotal.io> wrote:
> I’d like to advance this topic from an informal request/discussion to a
> discussion of a concrete proposal.
>
> To recap, it sounds like there is general agreement that commit history on
> develop should be linear (no merge commits), and that the biggest obstacle
> to this is that the PR merge button in GitHub creates a merge commit by
> default.
>
> I propose the following changes:
> 1) Change GitHub settings to remove the ability to create a merge commit.
> This will make Squash & Merge the default.
>
> 2) Change GitHub settings to require linear history on develop. This
> prevents merge commits via command-line (not recommended, but wiki still
> has instructions for merging PRs this way).
>
> 3) Update the PR template to change the text "Is your initial contribution
> a single, squashed commit” to “Is your initial contribution squashed for
> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
> ‘fix’ commit)"
>
> For clarity, I am proposing no-change in the following areas:
> i) Leave Rebase & Merge as an option for PRs that have been structured to
> benefit from it (this can make it easier in a bisect to see whether the
> refactoring or the “fix” broke something).
> ii) Leave existing wording in the wiki as-is [stating that squashing is
> preferred].
>
>
> Please comment via this email thread.
> -Owen
>
>
>
> > On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
> >
> > I think it's already resolved Udo ;)
> >
> > Here's the problem, if I fixup a dunit test by removing all uses of
> "this."
> > and I rename the dunit test, then git doesn't remember that the file is a
> > rename -- it forever afterwards interprets it as a new file that I
> created
> > if I touch more than 50% of the lines (which "this." can easily do). If
> we
> > squash two commits: the rename and the cleanup of that dunit test -- then
> > we effectively lose the history of that file and it shows that I created
> a
> > new file.
> >
> > Also for the record, I've been working on Geode since the beginning and I
> > was never made aware of this change in our process. I never voted on it.
> > I'm not a big fan of changing various details in our process every single
> > week. It's very easy to miss these discussions unless someone points it
> out
> > to me.
> >
> > On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <uk...@pivotal.io>
> > wrote:
> >
> >> I'm not sure what this discussion is about... WE, as a community, have
> >> agreed in common practices, in two place no less...
> >>
> >> 1) Quoting our PR template
> >>
> >>
> >> For all changes:
> >>
> >> *
> >>
> >> Is there a JIRA ticket associated with this PR? Is it referenced in
> >> the commit message?
> >>
> >> *
> >>
> >> Has your PR been rebased against the latest commit within the target
> >> branch (typically|develop|)?
> >>
> >> *
> >>
> >> ***Is your initial contribution a single, squashed commit?*
> >>
> >> *
> >>
> >> Does|gradlew build|run cleanly?
> >>
> >> *
> >>
> >> Have you written or updated unit tests to verify your changes?
> >>
> >> *
> >>
> >> If adding new dependencies to the code, are these dependencies
> >> licensed in a way that is compatible for inclusion underASF 2.0
> >> <http://www.apache.org/legal/resolved.html#category-a>?
> >>
> >> On our PR template we call out that the initial PR commit should be
> >> squashed.
> >>
> >> 2)https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> >> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions>
> >> -- See "Accepting a PR Using the Command Line" - Point #3.
> >>
> >>
> >> @Kirk, if each of your commits "stands alone", I commend you on the
> >> diligence, but in reality, they should either then be stand alone PR's
> >> or just extra work created for yourself.
> >>
> >> If we want to change the way we have agreed upon we submit/commit/merge
> >> changes back into develop... Then this is another discussion thread,
> >> until then, I think we should all remind ourselves on our agreed
> >> contributions code of conduct.
> >>
> >> --Udo
> >>
> >> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> >>> Kirk, I believe that creating a Pull Request with multiple commits is
> ok.
> >>> It's just in the end that when it's being pushed to develop branch, it
> >>> needs to be squash merged. I believe that is what you have mentioned in
> >> the
> >>> first paragraph, and I am more than happy with that.
> >>> If you can see in the first screenshot comparison that I had attached
> in
> >>> the first email in this thread is what I want to avoid.
> >>>
> >>> Thank you for your feedback.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>>
> >>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
> >>>
> >>>> Whenever I submit a PR with multiple commits that I intend to rebase
> to
> >>>> develop, I always try to ensure that each commit stands alone as is
> >>>> (compiles and passes tests). Separating file renames and refactoring
> >> from
> >>>> behavior changes into different commits seems very valuable to me, and
> >> I've
> >>>> had trouble getting people to review PRs without this separation (but
> it
> >>>> could be squashed as it's merged to develop).
> >>>>
> >>>> It sounds to me like the real problem is (a) some PRs have multiple
> >> commits
> >>>> that don't compile or don't pass tests, and (b) some PRs that should
> be
> >>>> merged with squash are not (by accident most likely).
> >>>>
> >>>> I can submit multiple PRs instead of one PR with multiple commits. So
> >> I'll
> >>>> change my response to -0 if that helps prevent commits to develop that
> >>>> don't compile or pass tests. Without preventing rebase or merge
> commits
> >>>> from github, I'm not sure how we can really enforce this or prevent
> (b)
> >>>> above.
> >>>>
> >>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> amurmann@pivotal.io>
> >>>> wrote:
> >>>>
> >>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
> >>>>>
> >>>>> Make the change easy (warning: this may be hard), then make the easy
> >>>>>> change."
> >>>>> -Kent Beck
> >>>>>
> >>>>> Following Kent Beck's advise might reasonably split into two commits.
> >> One
> >>>>> refactor commit and a separate commit that introduces the actual
> >> change.
> >>>>> They should be individually revertible and might be easier understood
> >> if
> >>>>> split out. I vividly remember a change on our code base where someone
> >>>> did a
> >>>>> huge amount of refactoring that resulted than in one parameter
> changing
> >>>> in
> >>>>> order to get the desired functionality change. If that was in one
> >> commit,
> >>>>> it would be hard to see the actual change. If split out, it's
> beautiful
> >>>> and
> >>>>> crystal clear.
> >>>>>
> >>>>> I am unsure how that would be reflected in terms of JIRA ticket
> >>>> references.
> >>>>> Usually we assume that if there is a commit with the ticket number,
> the
> >>>>> issue is resolved. Maybe the key here is to create a separate
> >> refactoring
> >>>>> ticket.
> >>>>>
> >>>>> Would that allow us to have our cake and eat it too?
> >>>>>
> >>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >>>>>
> >>>>>> It is to help with bisect operations when things start failing ...
> >>>> helps
> >>>>> us
> >>>>>> it revert and build faster.
> >>>>>> also with cherry picking features / fixes to previous versions .
> >>>>>> And keeping the git history clean with no unnecessary “merge
> commits”.
> >>>>>>
> >>>>>> Regards
> >>>>>> Naba
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
> >>>>>>
> >>>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
> >>>> keep
> >>>>>> them
> >>>>>>> separate when they merge to develop
> >>>>>>>
> >>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io>
> wrote:
> >>>>>>>
> >>>>>>>> Hi Geode Committers,
> >>>>>>>>
> >>>>>>>> A kind request for using squash commit instead of using merge.
> >>>>>>>> This will really help us in our bisect operations when a
> >>>>>>>> regression/flakiness in the product is introduced. We can automate
> >>>>> and
> >>>>>> go
> >>>>>>>> through fewer commits faster, avoiding commits like "spotless fix"
> >>>>> and
> >>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
> >>>> branch.
> >>>>>>>> Also, please use the commit format : (helps us to know who worked
> >>>> on
> >>>>>> it,
> >>>>>>>> what is the history)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> * GEODE-xxxx: <brief intro >
> >>>>>>>> * explanation line 1 * explanation
> >>>>> line
> >>>>>> 2*
> >>>>>>>> This is not a rule or anything, but a request to help out your
> >>>> fellow
> >>>>>>>> committers in quickly detecting a problem.
> >>>>>>>>
> >>>>>>>> For inspiration, we can look into Apache Kafka / Spark where they
> >>>>> have
> >>>>>> a
> >>>>>>>> complete linear graph for their main branch HEAD [see attachment]
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>> Naba.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>
>
>
[DISCUSS] Proposal to require linear commit history on develop
Posted by Owen Nichols <on...@pivotal.io>.
I’d like to advance this topic from an informal request/discussion to a discussion of a concrete proposal.
To recap, it sounds like there is general agreement that commit history on develop should be linear (no merge commits), and that the biggest obstacle to this is that the PR merge button in GitHub creates a merge commit by default.
I propose the following changes:
1) Change GitHub settings to remove the ability to create a merge commit. This will make Squash & Merge the default.
2) Change GitHub settings to require linear history on develop. This prevents merge commits via command-line (not recommended, but wiki still has instructions for merging PRs this way).
3) Update the PR template to change the text "Is your initial contribution a single, squashed commit” to “Is your initial contribution squashed for ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a ‘fix’ commit)"
For clarity, I am proposing no-change in the following areas:
i) Leave Rebase & Merge as an option for PRs that have been structured to benefit from it (this can make it easier in a bisect to see whether the refactoring or the “fix” broke something).
ii) Leave existing wording in the wiki as-is [stating that squashing is preferred].
Please comment via this email thread.
-Owen
> On Dec 16, 2019, at 10:49 AM, Kirk Lund <kl...@apache.org> wrote:
>
> I think it's already resolved Udo ;)
>
> Here's the problem, if I fixup a dunit test by removing all uses of "this."
> and I rename the dunit test, then git doesn't remember that the file is a
> rename -- it forever afterwards interprets it as a new file that I created
> if I touch more than 50% of the lines (which "this." can easily do). If we
> squash two commits: the rename and the cleanup of that dunit test -- then
> we effectively lose the history of that file and it shows that I created a
> new file.
>
> Also for the record, I've been working on Geode since the beginning and I
> was never made aware of this change in our process. I never voted on it.
> I'm not a big fan of changing various details in our process every single
> week. It's very easy to miss these discussions unless someone points it out
> to me.
>
> On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <uk...@pivotal.io>
> wrote:
>
>> I'm not sure what this discussion is about... WE, as a community, have
>> agreed in common practices, in two place no less...
>>
>> 1) Quoting our PR template
>>
>>
>> For all changes:
>>
>> *
>>
>> Is there a JIRA ticket associated with this PR? Is it referenced in
>> the commit message?
>>
>> *
>>
>> Has your PR been rebased against the latest commit within the target
>> branch (typically|develop|)?
>>
>> *
>>
>> ***Is your initial contribution a single, squashed commit?*
>>
>> *
>>
>> Does|gradlew build|run cleanly?
>>
>> *
>>
>> Have you written or updated unit tests to verify your changes?
>>
>> *
>>
>> If adding new dependencies to the code, are these dependencies
>> licensed in a way that is compatible for inclusion underASF 2.0
>> <http://www.apache.org/legal/resolved.html#category-a>?
>>
>> On our PR template we call out that the initial PR commit should be
>> squashed.
>>
>> 2)https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
>> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions>
>> -- See "Accepting a PR Using the Command Line" - Point #3.
>>
>>
>> @Kirk, if each of your commits "stands alone", I commend you on the
>> diligence, but in reality, they should either then be stand alone PR's
>> or just extra work created for yourself.
>>
>> If we want to change the way we have agreed upon we submit/commit/merge
>> changes back into develop... Then this is another discussion thread,
>> until then, I think we should all remind ourselves on our agreed
>> contributions code of conduct.
>>
>> --Udo
>>
>> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>>> Kirk, I believe that creating a Pull Request with multiple commits is ok.
>>> It's just in the end that when it's being pushed to develop branch, it
>>> needs to be squash merged. I believe that is what you have mentioned in
>> the
>>> first paragraph, and I am more than happy with that.
>>> If you can see in the first screenshot comparison that I had attached in
>>> the first email in this thread is what I want to avoid.
>>>
>>> Thank you for your feedback.
>>>
>>> Regards
>>> Naba
>>>
>>>
>>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
>>>
>>>> Whenever I submit a PR with multiple commits that I intend to rebase to
>>>> develop, I always try to ensure that each commit stands alone as is
>>>> (compiles and passes tests). Separating file renames and refactoring
>> from
>>>> behavior changes into different commits seems very valuable to me, and
>> I've
>>>> had trouble getting people to review PRs without this separation (but it
>>>> could be squashed as it's merged to develop).
>>>>
>>>> It sounds to me like the real problem is (a) some PRs have multiple
>> commits
>>>> that don't compile or don't pass tests, and (b) some PRs that should be
>>>> merged with squash are not (by accident most likely).
>>>>
>>>> I can submit multiple PRs instead of one PR with multiple commits. So
>> I'll
>>>> change my response to -0 if that helps prevent commits to develop that
>>>> don't compile or pass tests. Without preventing rebase or merge commits
>>>> from github, I'm not sure how we can really enforce this or prevent (b)
>>>> above.
>>>>
>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <am...@pivotal.io>
>>>> wrote:
>>>>
>>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>>>>
>>>>> Make the change easy (warning: this may be hard), then make the easy
>>>>>> change."
>>>>> -Kent Beck
>>>>>
>>>>> Following Kent Beck's advise might reasonably split into two commits.
>> One
>>>>> refactor commit and a separate commit that introduces the actual
>> change.
>>>>> They should be individually revertible and might be easier understood
>> if
>>>>> split out. I vividly remember a change on our code base where someone
>>>> did a
>>>>> huge amount of refactoring that resulted than in one parameter changing
>>>> in
>>>>> order to get the desired functionality change. If that was in one
>> commit,
>>>>> it would be hard to see the actual change. If split out, it's beautiful
>>>> and
>>>>> crystal clear.
>>>>>
>>>>> I am unsure how that would be reflected in terms of JIRA ticket
>>>> references.
>>>>> Usually we assume that if there is a commit with the ticket number, the
>>>>> issue is resolved. Maybe the key here is to create a separate
>> refactoring
>>>>> ticket.
>>>>>
>>>>> Would that allow us to have our cake and eat it too?
>>>>>
>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>>>>
>>>>>> It is to help with bisect operations when things start failing ...
>>>> helps
>>>>> us
>>>>>> it revert and build faster.
>>>>>> also with cherry picking features / fixes to previous versions .
>>>>>> And keeping the git history clean with no unnecessary “merge commits”.
>>>>>>
>>>>>> Regards
>>>>>> Naba
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
>>>>>>
>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
>>>> keep
>>>>>> them
>>>>>>> separate when they merge to develop
>>>>>>>
>>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>>>>>>
>>>>>>>> Hi Geode Committers,
>>>>>>>>
>>>>>>>> A kind request for using squash commit instead of using merge.
>>>>>>>> This will really help us in our bisect operations when a
>>>>>>>> regression/flakiness in the product is introduced. We can automate
>>>>> and
>>>>>> go
>>>>>>>> through fewer commits faster, avoiding commits like "spotless fix"
>>>>> and
>>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>>>> branch.
>>>>>>>> Also, please use the commit format : (helps us to know who worked
>>>> on
>>>>>> it,
>>>>>>>> what is the history)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>>> * explanation line 1 * explanation
>>>>> line
>>>>>> 2*
>>>>>>>> This is not a rule or anything, but a request to help out your
>>>> fellow
>>>>>>>> committers in quickly detecting a problem.
>>>>>>>>
>>>>>>>> For inspiration, we can look into Apache Kafka / Spark where they
>>>>> have
>>>>>> a
>>>>>>>> complete linear graph for their main branch HEAD [see attachment]
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Naba.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>
Re: [REQUEST] Squash merge please
Posted by Kirk Lund <kl...@apache.org>.
I think it's already resolved Udo ;)
Here's the problem, if I fixup a dunit test by removing all uses of "this."
and I rename the dunit test, then git doesn't remember that the file is a
rename -- it forever afterwards interprets it as a new file that I created
if I touch more than 50% of the lines (which "this." can easily do). If we
squash two commits: the rename and the cleanup of that dunit test -- then
we effectively lose the history of that file and it shows that I created a
new file.
Also for the record, I've been working on Geode since the beginning and I
was never made aware of this change in our process. I never voted on it.
I'm not a big fan of changing various details in our process every single
week. It's very easy to miss these discussions unless someone points it out
to me.
On Mon, Dec 16, 2019 at 10:34 AM Udo Kohlmeyer <uk...@pivotal.io>
wrote:
> I'm not sure what this discussion is about... WE, as a community, have
> agreed in common practices, in two place no less...
>
> 1) Quoting our PR template
>
>
> For all changes:
>
> *
>
> Is there a JIRA ticket associated with this PR? Is it referenced in
> the commit message?
>
> *
>
> Has your PR been rebased against the latest commit within the target
> branch (typically|develop|)?
>
> *
>
> ***Is your initial contribution a single, squashed commit?*
>
> *
>
> Does|gradlew build|run cleanly?
>
> *
>
> Have you written or updated unit tests to verify your changes?
>
> *
>
> If adding new dependencies to the code, are these dependencies
> licensed in a way that is compatible for inclusion underASF 2.0
> <http://www.apache.org/legal/resolved.html#category-a>?
>
> On our PR template we call out that the initial PR commit should be
> squashed.
>
> 2)https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions>
> -- See "Accepting a PR Using the Command Line" - Point #3.
>
>
> @Kirk, if each of your commits "stands alone", I commend you on the
> diligence, but in reality, they should either then be stand alone PR's
> or just extra work created for yourself.
>
> If we want to change the way we have agreed upon we submit/commit/merge
> changes back into develop... Then this is another discussion thread,
> until then, I think we should all remind ourselves on our agreed
> contributions code of conduct.
>
> --Udo
>
> On 12/16/19 9:59 AM, Nabarun Nag wrote:
> > Kirk, I believe that creating a Pull Request with multiple commits is ok.
> > It's just in the end that when it's being pushed to develop branch, it
> > needs to be squash merged. I believe that is what you have mentioned in
> the
> > first paragraph, and I am more than happy with that.
> > If you can see in the first screenshot comparison that I had attached in
> > the first email in this thread is what I want to avoid.
> >
> > Thank you for your feedback.
> >
> > Regards
> > Naba
> >
> >
> > On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
> >
> >> Whenever I submit a PR with multiple commits that I intend to rebase to
> >> develop, I always try to ensure that each commit stands alone as is
> >> (compiles and passes tests). Separating file renames and refactoring
> from
> >> behavior changes into different commits seems very valuable to me, and
> I've
> >> had trouble getting people to review PRs without this separation (but it
> >> could be squashed as it's merged to develop).
> >>
> >> It sounds to me like the real problem is (a) some PRs have multiple
> commits
> >> that don't compile or don't pass tests, and (b) some PRs that should be
> >> merged with squash are not (by accident most likely).
> >>
> >> I can submit multiple PRs instead of one PR with multiple commits. So
> I'll
> >> change my response to -0 if that helps prevent commits to develop that
> >> don't compile or pass tests. Without preventing rebase or merge commits
> >> from github, I'm not sure how we can really enforce this or prevent (b)
> >> above.
> >>
> >> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <am...@pivotal.io>
> >> wrote:
> >>
> >>> I wonder if Kirk's and Naba's statements are necessarily at odds.
> >>>
> >>> Make the change easy (warning: this may be hard), then make the easy
> >>>> change."
> >>> -Kent Beck
> >>>
> >>> Following Kent Beck's advise might reasonably split into two commits.
> One
> >>> refactor commit and a separate commit that introduces the actual
> change.
> >>> They should be individually revertible and might be easier understood
> if
> >>> split out. I vividly remember a change on our code base where someone
> >> did a
> >>> huge amount of refactoring that resulted than in one parameter changing
> >> in
> >>> order to get the desired functionality change. If that was in one
> commit,
> >>> it would be hard to see the actual change. If split out, it's beautiful
> >> and
> >>> crystal clear.
> >>>
> >>> I am unsure how that would be reflected in terms of JIRA ticket
> >> references.
> >>> Usually we assume that if there is a commit with the ticket number, the
> >>> issue is resolved. Maybe the key here is to create a separate
> refactoring
> >>> ticket.
> >>>
> >>> Would that allow us to have our cake and eat it too?
> >>>
> >>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >>>
> >>>> It is to help with bisect operations when things start failing ...
> >> helps
> >>> us
> >>>> it revert and build faster.
> >>>> also with cherry picking features / fixes to previous versions .
> >>>> And keeping the git history clean with no unnecessary “merge commits”.
> >>>>
> >>>> Regards
> >>>> Naba
> >>>>
> >>>>
> >>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
> >>>>
> >>>>> -1 I really like to sometimes have more than 1 commit in a PR and
> >> keep
> >>>> them
> >>>>> separate when they merge to develop
> >>>>>
> >>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >>>>>
> >>>>>> Hi Geode Committers,
> >>>>>>
> >>>>>> A kind request for using squash commit instead of using merge.
> >>>>>> This will really help us in our bisect operations when a
> >>>>>> regression/flakiness in the product is introduced. We can automate
> >>> and
> >>>> go
> >>>>>> through fewer commits faster, avoiding commits like "spotless fix"
> >>> and
> >>>>>> "re-trigger precheck-in" or other minor commits in the merged
> >> branch.
> >>>>>> Also, please use the commit format : (helps us to know who worked
> >> on
> >>>> it,
> >>>>>> what is the history)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> * GEODE-xxxx: <brief intro >
> >>>>>> * explanation line 1 * explanation
> >>> line
> >>>> 2*
> >>>>>> This is not a rule or anything, but a request to help out your
> >> fellow
> >>>>>> committers in quickly detecting a problem.
> >>>>>>
> >>>>>> For inspiration, we can look into Apache Kafka / Spark where they
> >>> have
> >>>> a
> >>>>>> complete linear graph for their main branch HEAD [see attachment]
> >>>>>>
> >>>>>> Regards
> >>>>>> Naba.
> >>>>>>
> >>>>>>
> >>>>>>
>
Re: [REQUEST] Squash merge please
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
In addition to pointing this out..
I've found this...
https://help.github.com/en/github/administering-a-repository/requiring-a-linear-commit-history
<https://help.github.com/en/github/administering-a-repository/requiring-a-linear-commit-history>
I'm not sure that we need to enable this feature.. As I don't agree with
making the process even more restrictive... BUT, in reality... If our
own members cannot be bothered to follow the rules we have all agreed
upon, then the system has to protect itself.
--Udo
On 12/16/19 10:34 AM, Udo Kohlmeyer wrote:
>
> I'm not sure what this discussion is about... WE, as a community, have
> agreed in common practices, in two place no less...
>
> 1) Quoting our PR template
>
>
> For all changes:
>
> *
>
> Is there a JIRA ticket associated with this PR? Is it referenced
> in the commit message?
>
> *
>
> Has your PR been rebased against the latest commit within the
> target branch (typically|develop|)?
>
> *
>
> ***Is your initial contribution a single, squashed commit?*
>
> *
>
> Does|gradlew build|run cleanly?
>
> *
>
> Have you written or updated unit tests to verify your changes?
>
> *
>
> If adding new dependencies to the code, are these dependencies
> licensed in a way that is compatible for inclusion underASF 2.0
> <http://www.apache.org/legal/resolved.html#category-a>?
>
> On our PR template we call out that the initial PR commit should be
> squashed.
>
> 2)https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
> <https://cwiki.apache.org/confluence/display/GEODE/Code+contributions>
> -- See "Accepting a PR Using the Command Line" - Point #3.
>
>
> @Kirk, if each of your commits "stands alone", I commend you on the
> diligence, but in reality, they should either then be stand alone PR's
> or just extra work created for yourself.
>
> If we want to change the way we have agreed upon we
> submit/commit/merge changes back into develop... Then this is another
> discussion thread, until then, I think we should all remind ourselves
> on our agreed contributions code of conduct.
>
> --Udo
>
> On 12/16/19 9:59 AM, Nabarun Nag wrote:
>> Kirk, I believe that creating a Pull Request with multiple commits is ok.
>> It's just in the end that when it's being pushed to develop branch, it
>> needs to be squash merged. I believe that is what you have mentioned in the
>> first paragraph, and I am more than happy with that.
>> If you can see in the first screenshot comparison that I had attached in
>> the first email in this thread is what I want to avoid.
>>
>> Thank you for your feedback.
>>
>> Regards
>> Naba
>>
>>
>> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund<kl...@apache.org> wrote:
>>
>>> Whenever I submit a PR with multiple commits that I intend to rebase to
>>> develop, I always try to ensure that each commit stands alone as is
>>> (compiles and passes tests). Separating file renames and refactoring from
>>> behavior changes into different commits seems very valuable to me, and I've
>>> had trouble getting people to review PRs without this separation (but it
>>> could be squashed as it's merged to develop).
>>>
>>> It sounds to me like the real problem is (a) some PRs have multiple commits
>>> that don't compile or don't pass tests, and (b) some PRs that should be
>>> merged with squash are not (by accident most likely).
>>>
>>> I can submit multiple PRs instead of one PR with multiple commits. So I'll
>>> change my response to -0 if that helps prevent commits to develop that
>>> don't compile or pass tests. Without preventing rebase or merge commits
>>> from github, I'm not sure how we can really enforce this or prevent (b)
>>> above.
>>>
>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann<am...@pivotal.io>
>>> wrote:
>>>
>>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>>>
>>>> Make the change easy (warning: this may be hard), then make the easy
>>>>> change."
>>>> -Kent Beck
>>>>
>>>> Following Kent Beck's advise might reasonably split into two commits. One
>>>> refactor commit and a separate commit that introduces the actual change.
>>>> They should be individually revertible and might be easier understood if
>>>> split out. I vividly remember a change on our code base where someone
>>> did a
>>>> huge amount of refactoring that resulted than in one parameter changing
>>> in
>>>> order to get the desired functionality change. If that was in one commit,
>>>> it would be hard to see the actual change. If split out, it's beautiful
>>> and
>>>> crystal clear.
>>>>
>>>> I am unsure how that would be reflected in terms of JIRA ticket
>>> references.
>>>> Usually we assume that if there is a commit with the ticket number, the
>>>> issue is resolved. Maybe the key here is to create a separate refactoring
>>>> ticket.
>>>>
>>>> Would that allow us to have our cake and eat it too?
>>>>
>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag<nn...@pivotal.io> wrote:
>>>>
>>>>> It is to help with bisect operations when things start failing ...
>>> helps
>>>> us
>>>>> it revert and build faster.
>>>>> also with cherry picking features / fixes to previous versions .
>>>>> And keeping the git history clean with no unnecessary “merge commits”.
>>>>>
>>>>> Regards
>>>>> Naba
>>>>>
>>>>>
>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund<kl...@apache.org> wrote:
>>>>>
>>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
>>> keep
>>>>> them
>>>>>> separate when they merge to develop
>>>>>>
>>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag<nn...@pivotal.io> wrote:
>>>>>>
>>>>>>> Hi Geode Committers,
>>>>>>>
>>>>>>> A kind request for using squash commit instead of using merge.
>>>>>>> This will really help us in our bisect operations when a
>>>>>>> regression/flakiness in the product is introduced. We can automate
>>>> and
>>>>> go
>>>>>>> through fewer commits faster, avoiding commits like "spotless fix"
>>>> and
>>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>>> branch.
>>>>>>> Also, please use the commit format : (helps us to know who worked
>>> on
>>>>> it,
>>>>>>> what is the history)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> * GEODE-xxxx: <brief intro >
>>>>>>> * explanation line 1 * explanation
>>>> line
>>>>> 2*
>>>>>>> This is not a rule or anything, but a request to help out your
>>> fellow
>>>>>>> committers in quickly detecting a problem.
>>>>>>>
>>>>>>> For inspiration, we can look into Apache Kafka / Spark where they
>>>> have
>>>>> a
>>>>>>> complete linear graph for their main branch HEAD [see attachment]
>>>>>>>
>>>>>>> Regards
>>>>>>> Naba.
>>>>>>>
>>>>>>>
>>>>>>>
Re: [REQUEST] Squash merge please
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
I'm not sure what this discussion is about... WE, as a community, have
agreed in common practices, in two place no less...
1) Quoting our PR template
For all changes:
*
Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
*
Has your PR been rebased against the latest commit within the target
branch (typically|develop|)?
*
***Is your initial contribution a single, squashed commit?*
*
Does|gradlew build|run cleanly?
*
Have you written or updated unit tests to verify your changes?
*
If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion underASF 2.0
<http://www.apache.org/legal/resolved.html#category-a>?
On our PR template we call out that the initial PR commit should be
squashed.
2)https://cwiki.apache.org/confluence/display/GEODE/Code+contributions
<https://cwiki.apache.org/confluence/display/GEODE/Code+contributions>
-- See "Accepting a PR Using the Command Line" - Point #3.
@Kirk, if each of your commits "stands alone", I commend you on the
diligence, but in reality, they should either then be stand alone PR's
or just extra work created for yourself.
If we want to change the way we have agreed upon we submit/commit/merge
changes back into develop... Then this is another discussion thread,
until then, I think we should all remind ourselves on our agreed
contributions code of conduct.
--Udo
On 12/16/19 9:59 AM, Nabarun Nag wrote:
> Kirk, I believe that creating a Pull Request with multiple commits is ok.
> It's just in the end that when it's being pushed to develop branch, it
> needs to be squash merged. I believe that is what you have mentioned in the
> first paragraph, and I am more than happy with that.
> If you can see in the first screenshot comparison that I had attached in
> the first email in this thread is what I want to avoid.
>
> Thank you for your feedback.
>
> Regards
> Naba
>
>
> On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
>
>> Whenever I submit a PR with multiple commits that I intend to rebase to
>> develop, I always try to ensure that each commit stands alone as is
>> (compiles and passes tests). Separating file renames and refactoring from
>> behavior changes into different commits seems very valuable to me, and I've
>> had trouble getting people to review PRs without this separation (but it
>> could be squashed as it's merged to develop).
>>
>> It sounds to me like the real problem is (a) some PRs have multiple commits
>> that don't compile or don't pass tests, and (b) some PRs that should be
>> merged with squash are not (by accident most likely).
>>
>> I can submit multiple PRs instead of one PR with multiple commits. So I'll
>> change my response to -0 if that helps prevent commits to develop that
>> don't compile or pass tests. Without preventing rebase or merge commits
>> from github, I'm not sure how we can really enforce this or prevent (b)
>> above.
>>
>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <am...@pivotal.io>
>> wrote:
>>
>>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>>
>>> Make the change easy (warning: this may be hard), then make the easy
>>>> change."
>>> -Kent Beck
>>>
>>> Following Kent Beck's advise might reasonably split into two commits. One
>>> refactor commit and a separate commit that introduces the actual change.
>>> They should be individually revertible and might be easier understood if
>>> split out. I vividly remember a change on our code base where someone
>> did a
>>> huge amount of refactoring that resulted than in one parameter changing
>> in
>>> order to get the desired functionality change. If that was in one commit,
>>> it would be hard to see the actual change. If split out, it's beautiful
>> and
>>> crystal clear.
>>>
>>> I am unsure how that would be reflected in terms of JIRA ticket
>> references.
>>> Usually we assume that if there is a commit with the ticket number, the
>>> issue is resolved. Maybe the key here is to create a separate refactoring
>>> ticket.
>>>
>>> Would that allow us to have our cake and eat it too?
>>>
>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>>
>>>> It is to help with bisect operations when things start failing ...
>> helps
>>> us
>>>> it revert and build faster.
>>>> also with cherry picking features / fixes to previous versions .
>>>> And keeping the git history clean with no unnecessary “merge commits”.
>>>>
>>>> Regards
>>>> Naba
>>>>
>>>>
>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
>>>>
>>>>> -1 I really like to sometimes have more than 1 commit in a PR and
>> keep
>>>> them
>>>>> separate when they merge to develop
>>>>>
>>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>>>>
>>>>>> Hi Geode Committers,
>>>>>>
>>>>>> A kind request for using squash commit instead of using merge.
>>>>>> This will really help us in our bisect operations when a
>>>>>> regression/flakiness in the product is introduced. We can automate
>>> and
>>>> go
>>>>>> through fewer commits faster, avoiding commits like "spotless fix"
>>> and
>>>>>> "re-trigger precheck-in" or other minor commits in the merged
>> branch.
>>>>>> Also, please use the commit format : (helps us to know who worked
>> on
>>>> it,
>>>>>> what is the history)
>>>>>>
>>>>>>
>>>>>>
>>>>>> * GEODE-xxxx: <brief intro >
>>>>>> * explanation line 1 * explanation
>>> line
>>>> 2*
>>>>>> This is not a rule or anything, but a request to help out your
>> fellow
>>>>>> committers in quickly detecting a problem.
>>>>>>
>>>>>> For inspiration, we can look into Apache Kafka / Spark where they
>>> have
>>>> a
>>>>>> complete linear graph for their main branch HEAD [see attachment]
>>>>>>
>>>>>> Regards
>>>>>> Naba.
>>>>>>
>>>>>>
>>>>>>
Re: [REQUEST] Squash merge please
Posted by Nabarun Nag <nn...@apache.org>.
Kirk, I believe that creating a Pull Request with multiple commits is ok.
It's just in the end that when it's being pushed to develop branch, it
needs to be squash merged. I believe that is what you have mentioned in the
first paragraph, and I am more than happy with that.
If you can see in the first screenshot comparison that I had attached in
the first email in this thread is what I want to avoid.
Thank you for your feedback.
Regards
Naba
On Mon, Dec 16, 2019 at 9:47 AM Kirk Lund <kl...@apache.org> wrote:
> Whenever I submit a PR with multiple commits that I intend to rebase to
> develop, I always try to ensure that each commit stands alone as is
> (compiles and passes tests). Separating file renames and refactoring from
> behavior changes into different commits seems very valuable to me, and I've
> had trouble getting people to review PRs without this separation (but it
> could be squashed as it's merged to develop).
>
> It sounds to me like the real problem is (a) some PRs have multiple commits
> that don't compile or don't pass tests, and (b) some PRs that should be
> merged with squash are not (by accident most likely).
>
> I can submit multiple PRs instead of one PR with multiple commits. So I'll
> change my response to -0 if that helps prevent commits to develop that
> don't compile or pass tests. Without preventing rebase or merge commits
> from github, I'm not sure how we can really enforce this or prevent (b)
> above.
>
> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <am...@pivotal.io>
> wrote:
>
> > I wonder if Kirk's and Naba's statements are necessarily at odds.
> >
> > Make the change easy (warning: this may be hard), then make the easy
> > > change."
> >
> > -Kent Beck
> >
> > Following Kent Beck's advise might reasonably split into two commits. One
> > refactor commit and a separate commit that introduces the actual change.
> > They should be individually revertible and might be easier understood if
> > split out. I vividly remember a change on our code base where someone
> did a
> > huge amount of refactoring that resulted than in one parameter changing
> in
> > order to get the desired functionality change. If that was in one commit,
> > it would be hard to see the actual change. If split out, it's beautiful
> and
> > crystal clear.
> >
> > I am unsure how that would be reflected in terms of JIRA ticket
> references.
> > Usually we assume that if there is a commit with the ticket number, the
> > issue is resolved. Maybe the key here is to create a separate refactoring
> > ticket.
> >
> > Would that allow us to have our cake and eat it too?
> >
> > On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >
> > > It is to help with bisect operations when things start failing ...
> helps
> > us
> > > it revert and build faster.
> > > also with cherry picking features / fixes to previous versions .
> > > And keeping the git history clean with no unnecessary “merge commits”.
> > >
> > > Regards
> > > Naba
> > >
> > >
> > > On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
> > >
> > > > -1 I really like to sometimes have more than 1 commit in a PR and
> keep
> > > them
> > > > separate when they merge to develop
> > > >
> > > > On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
> > > >
> > > > > Hi Geode Committers,
> > > > >
> > > > > A kind request for using squash commit instead of using merge.
> > > > > This will really help us in our bisect operations when a
> > > > > regression/flakiness in the product is introduced. We can automate
> > and
> > > go
> > > > > through fewer commits faster, avoiding commits like "spotless fix"
> > and
> > > > > "re-trigger precheck-in" or other minor commits in the merged
> branch.
> > > > >
> > > > > Also, please use the commit format : (helps us to know who worked
> on
> > > it,
> > > > > what is the history)
> > > > >
> > > > >
> > > > >
> > > > > * GEODE-xxxx: <brief intro >
> > > > > * explanation line 1 * explanation
> > line
> > > 2*
> > > > >
> > > > > This is not a rule or anything, but a request to help out your
> fellow
> > > > > committers in quickly detecting a problem.
> > > > >
> > > > > For inspiration, we can look into Apache Kafka / Spark where they
> > have
> > > a
> > > > > complete linear graph for their main branch HEAD [see attachment]
> > > > >
> > > > > Regards
> > > > > Naba.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [REQUEST] Squash merge please
Posted by Nabarun Nag <nn...@pivotal.io>.
Hi Mark,
I would like to limit the scope of the discussion to pushing PRs to develop
as a squash and merge operation and not just merge. This is to keep the
history linear and clean like other projects which will help with
regression and cherry-pick (reference: first screenshot in the email chain)
How many commits should be there in a PR can be placed in a different
discussion thread.
Regards
Naba
On Mon, Dec 16, 2019 at 10:02 AM Mark Hanson <mh...@pivotal.io> wrote:
> I would strongly prefer smaller as small a commit as possible. And as
> large as necessary. I am less partial when it comes to PRs sizes. Sometimes
> depending on what is done in a PR, I don’t think it makes sense to issue a
> blanket statement that all PRs are one commit. I think there is a strong
> reason to make them one commit, but one size does not fit all. A great
> example is a refactor and a bug fix in one PR.
>
> Thanks,
> Mark
>
> > On Dec 16, 2019, at 9:47 AM, Kirk Lund <kl...@apache.org> wrote:
> >
> > Whenever I submit a PR with multiple commits that I intend to rebase to
> > develop, I always try to ensure that each commit stands alone as is
> > (compiles and passes tests). Separating file renames and refactoring from
> > behavior changes into different commits seems very valuable to me, and
> I've
> > had trouble getting people to review PRs without this separation (but it
> > could be squashed as it's merged to develop).
> >
> > It sounds to me like the real problem is (a) some PRs have multiple
> commits
> > that don't compile or don't pass tests, and (b) some PRs that should be
> > merged with squash are not (by accident most likely).
> >
> > I can submit multiple PRs instead of one PR with multiple commits. So
> I'll
> > change my response to -0 if that helps prevent commits to develop that
> > don't compile or pass tests. Without preventing rebase or merge commits
> > from github, I'm not sure how we can really enforce this or prevent (b)
> > above.
> >
> > On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <am...@pivotal.io>
> > wrote:
> >
> >> I wonder if Kirk's and Naba's statements are necessarily at odds.
> >>
> >> Make the change easy (warning: this may be hard), then make the easy
> >>> change."
> >>
> >> -Kent Beck
> >>
> >> Following Kent Beck's advise might reasonably split into two commits.
> One
> >> refactor commit and a separate commit that introduces the actual change.
> >> They should be individually revertible and might be easier understood if
> >> split out. I vividly remember a change on our code base where someone
> did a
> >> huge amount of refactoring that resulted than in one parameter changing
> in
> >> order to get the desired functionality change. If that was in one
> commit,
> >> it would be hard to see the actual change. If split out, it's beautiful
> and
> >> crystal clear.
> >>
> >> I am unsure how that would be reflected in terms of JIRA ticket
> references.
> >> Usually we assume that if there is a commit with the ticket number, the
> >> issue is resolved. Maybe the key here is to create a separate
> refactoring
> >> ticket.
> >>
> >> Would that allow us to have our cake and eat it too?
> >>
> >> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >>
> >>> It is to help with bisect operations when things start failing ...
> helps
> >> us
> >>> it revert and build faster.
> >>> also with cherry picking features / fixes to previous versions .
> >>> And keeping the git history clean with no unnecessary “merge commits”.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>>
> >>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
> >>>
> >>>> -1 I really like to sometimes have more than 1 commit in a PR and keep
> >>> them
> >>>> separate when they merge to develop
> >>>>
> >>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >>>>
> >>>>> Hi Geode Committers,
> >>>>>
> >>>>> A kind request for using squash commit instead of using merge.
> >>>>> This will really help us in our bisect operations when a
> >>>>> regression/flakiness in the product is introduced. We can automate
> >> and
> >>> go
> >>>>> through fewer commits faster, avoiding commits like "spotless fix"
> >> and
> >>>>> "re-trigger precheck-in" or other minor commits in the merged branch.
> >>>>>
> >>>>> Also, please use the commit format : (helps us to know who worked on
> >>> it,
> >>>>> what is the history)
> >>>>>
> >>>>>
> >>>>>
> >>>>> * GEODE-xxxx: <brief intro >
> >>>>> * explanation line 1 * explanation
> >> line
> >>> 2*
> >>>>>
> >>>>> This is not a rule or anything, but a request to help out your fellow
> >>>>> committers in quickly detecting a problem.
> >>>>>
> >>>>> For inspiration, we can look into Apache Kafka / Spark where they
> >> have
> >>> a
> >>>>> complete linear graph for their main branch HEAD [see attachment]
> >>>>>
> >>>>> Regards
> >>>>> Naba.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: [REQUEST] Squash merge please
Posted by Mark Hanson <mh...@pivotal.io>.
I would strongly prefer smaller as small a commit as possible. And as large as necessary. I am less partial when it comes to PRs sizes. Sometimes depending on what is done in a PR, I don’t think it makes sense to issue a blanket statement that all PRs are one commit. I think there is a strong reason to make them one commit, but one size does not fit all. A great example is a refactor and a bug fix in one PR.
Thanks,
Mark
> On Dec 16, 2019, at 9:47 AM, Kirk Lund <kl...@apache.org> wrote:
>
> Whenever I submit a PR with multiple commits that I intend to rebase to
> develop, I always try to ensure that each commit stands alone as is
> (compiles and passes tests). Separating file renames and refactoring from
> behavior changes into different commits seems very valuable to me, and I've
> had trouble getting people to review PRs without this separation (but it
> could be squashed as it's merged to develop).
>
> It sounds to me like the real problem is (a) some PRs have multiple commits
> that don't compile or don't pass tests, and (b) some PRs that should be
> merged with squash are not (by accident most likely).
>
> I can submit multiple PRs instead of one PR with multiple commits. So I'll
> change my response to -0 if that helps prevent commits to develop that
> don't compile or pass tests. Without preventing rebase or merge commits
> from github, I'm not sure how we can really enforce this or prevent (b)
> above.
>
> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <am...@pivotal.io>
> wrote:
>
>> I wonder if Kirk's and Naba's statements are necessarily at odds.
>>
>> Make the change easy (warning: this may be hard), then make the easy
>>> change."
>>
>> -Kent Beck
>>
>> Following Kent Beck's advise might reasonably split into two commits. One
>> refactor commit and a separate commit that introduces the actual change.
>> They should be individually revertible and might be easier understood if
>> split out. I vividly remember a change on our code base where someone did a
>> huge amount of refactoring that resulted than in one parameter changing in
>> order to get the desired functionality change. If that was in one commit,
>> it would be hard to see the actual change. If split out, it's beautiful and
>> crystal clear.
>>
>> I am unsure how that would be reflected in terms of JIRA ticket references.
>> Usually we assume that if there is a commit with the ticket number, the
>> issue is resolved. Maybe the key here is to create a separate refactoring
>> ticket.
>>
>> Would that allow us to have our cake and eat it too?
>>
>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>
>>> It is to help with bisect operations when things start failing ... helps
>> us
>>> it revert and build faster.
>>> also with cherry picking features / fixes to previous versions .
>>> And keeping the git history clean with no unnecessary “merge commits”.
>>>
>>> Regards
>>> Naba
>>>
>>>
>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
>>>
>>>> -1 I really like to sometimes have more than 1 commit in a PR and keep
>>> them
>>>> separate when they merge to develop
>>>>
>>>> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
>>>>
>>>>> Hi Geode Committers,
>>>>>
>>>>> A kind request for using squash commit instead of using merge.
>>>>> This will really help us in our bisect operations when a
>>>>> regression/flakiness in the product is introduced. We can automate
>> and
>>> go
>>>>> through fewer commits faster, avoiding commits like "spotless fix"
>> and
>>>>> "re-trigger precheck-in" or other minor commits in the merged branch.
>>>>>
>>>>> Also, please use the commit format : (helps us to know who worked on
>>> it,
>>>>> what is the history)
>>>>>
>>>>>
>>>>>
>>>>> * GEODE-xxxx: <brief intro >
>>>>> * explanation line 1 * explanation
>> line
>>> 2*
>>>>>
>>>>> This is not a rule or anything, but a request to help out your fellow
>>>>> committers in quickly detecting a problem.
>>>>>
>>>>> For inspiration, we can look into Apache Kafka / Spark where they
>> have
>>> a
>>>>> complete linear graph for their main branch HEAD [see attachment]
>>>>>
>>>>> Regards
>>>>> Naba.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: [REQUEST] Squash merge please
Posted by Kirk Lund <kl...@apache.org>.
Whenever I submit a PR with multiple commits that I intend to rebase to
develop, I always try to ensure that each commit stands alone as is
(compiles and passes tests). Separating file renames and refactoring from
behavior changes into different commits seems very valuable to me, and I've
had trouble getting people to review PRs without this separation (but it
could be squashed as it's merged to develop).
It sounds to me like the real problem is (a) some PRs have multiple commits
that don't compile or don't pass tests, and (b) some PRs that should be
merged with squash are not (by accident most likely).
I can submit multiple PRs instead of one PR with multiple commits. So I'll
change my response to -0 if that helps prevent commits to develop that
don't compile or pass tests. Without preventing rebase or merge commits
from github, I'm not sure how we can really enforce this or prevent (b)
above.
On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <am...@pivotal.io>
wrote:
> I wonder if Kirk's and Naba's statements are necessarily at odds.
>
> Make the change easy (warning: this may be hard), then make the easy
> > change."
>
> -Kent Beck
>
> Following Kent Beck's advise might reasonably split into two commits. One
> refactor commit and a separate commit that introduces the actual change.
> They should be individually revertible and might be easier understood if
> split out. I vividly remember a change on our code base where someone did a
> huge amount of refactoring that resulted than in one parameter changing in
> order to get the desired functionality change. If that was in one commit,
> it would be hard to see the actual change. If split out, it's beautiful and
> crystal clear.
>
> I am unsure how that would be reflected in terms of JIRA ticket references.
> Usually we assume that if there is a commit with the ticket number, the
> issue is resolved. Maybe the key here is to create a separate refactoring
> ticket.
>
> Would that allow us to have our cake and eat it too?
>
> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io> wrote:
>
> > It is to help with bisect operations when things start failing ... helps
> us
> > it revert and build faster.
> > also with cherry picking features / fixes to previous versions .
> > And keeping the git history clean with no unnecessary “merge commits”.
> >
> > Regards
> > Naba
> >
> >
> > On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
> >
> > > -1 I really like to sometimes have more than 1 commit in a PR and keep
> > them
> > > separate when they merge to develop
> > >
> > > On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
> > >
> > > > Hi Geode Committers,
> > > >
> > > > A kind request for using squash commit instead of using merge.
> > > > This will really help us in our bisect operations when a
> > > > regression/flakiness in the product is introduced. We can automate
> and
> > go
> > > > through fewer commits faster, avoiding commits like "spotless fix"
> and
> > > > "re-trigger precheck-in" or other minor commits in the merged branch.
> > > >
> > > > Also, please use the commit format : (helps us to know who worked on
> > it,
> > > > what is the history)
> > > >
> > > >
> > > >
> > > > * GEODE-xxxx: <brief intro >
> > > > * explanation line 1 * explanation
> line
> > 2*
> > > >
> > > > This is not a rule or anything, but a request to help out your fellow
> > > > committers in quickly detecting a problem.
> > > >
> > > > For inspiration, we can look into Apache Kafka / Spark where they
> have
> > a
> > > > complete linear graph for their main branch HEAD [see attachment]
> > > >
> > > > Regards
> > > > Naba.
> > > >
> > > >
> > > >
> > >
> >
>
Re: [REQUEST] Squash merge please
Posted by Alexander Murmann <am...@pivotal.io>.
I wonder if Kirk's and Naba's statements are necessarily at odds.
Make the change easy (warning: this may be hard), then make the easy
> change."
-Kent Beck
Following Kent Beck's advise might reasonably split into two commits. One
refactor commit and a separate commit that introduces the actual change.
They should be individually revertible and might be easier understood if
split out. I vividly remember a change on our code base where someone did a
huge amount of refactoring that resulted than in one parameter changing in
order to get the desired functionality change. If that was in one commit,
it would be hard to see the actual change. If split out, it's beautiful and
crystal clear.
I am unsure how that would be reflected in terms of JIRA ticket references.
Usually we assume that if there is a commit with the ticket number, the
issue is resolved. Maybe the key here is to create a separate refactoring
ticket.
Would that allow us to have our cake and eat it too?
On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag <nn...@pivotal.io> wrote:
> It is to help with bisect operations when things start failing ... helps us
> it revert and build faster.
> also with cherry picking features / fixes to previous versions .
> And keeping the git history clean with no unnecessary “merge commits”.
>
> Regards
> Naba
>
>
> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
>
> > -1 I really like to sometimes have more than 1 commit in a PR and keep
> them
> > separate when they merge to develop
> >
> > On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
> >
> > > Hi Geode Committers,
> > >
> > > A kind request for using squash commit instead of using merge.
> > > This will really help us in our bisect operations when a
> > > regression/flakiness in the product is introduced. We can automate and
> go
> > > through fewer commits faster, avoiding commits like "spotless fix" and
> > > "re-trigger precheck-in" or other minor commits in the merged branch.
> > >
> > > Also, please use the commit format : (helps us to know who worked on
> it,
> > > what is the history)
> > >
> > >
> > >
> > > * GEODE-xxxx: <brief intro >
> > > * explanation line 1 * explanation line
> 2*
> > >
> > > This is not a rule or anything, but a request to help out your fellow
> > > committers in quickly detecting a problem.
> > >
> > > For inspiration, we can look into Apache Kafka / Spark where they have
> a
> > > complete linear graph for their main branch HEAD [see attachment]
> > >
> > > Regards
> > > Naba.
> > >
> > >
> > >
> >
>
Re: [REQUEST] Squash merge please
Posted by Nabarun Nag <nn...@pivotal.io>.
It is to help with bisect operations when things start failing ... helps us
it revert and build faster.
also with cherry picking features / fixes to previous versions .
And keeping the git history clean with no unnecessary “merge commits”.
Regards
Naba
On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund <kl...@apache.org> wrote:
> -1 I really like to sometimes have more than 1 commit in a PR and keep them
> separate when they merge to develop
>
> On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
>
> > Hi Geode Committers,
> >
> > A kind request for using squash commit instead of using merge.
> > This will really help us in our bisect operations when a
> > regression/flakiness in the product is introduced. We can automate and go
> > through fewer commits faster, avoiding commits like "spotless fix" and
> > "re-trigger precheck-in" or other minor commits in the merged branch.
> >
> > Also, please use the commit format : (helps us to know who worked on it,
> > what is the history)
> >
> >
> >
> > * GEODE-xxxx: <brief intro >
> > * explanation line 1 * explanation line 2*
> >
> > This is not a rule or anything, but a request to help out your fellow
> > committers in quickly detecting a problem.
> >
> > For inspiration, we can look into Apache Kafka / Spark where they have a
> > complete linear graph for their main branch HEAD [see attachment]
> >
> > Regards
> > Naba.
> >
> >
> >
>
Re: [REQUEST] Squash merge please
Posted by Kirk Lund <kl...@apache.org>.
-1 I really like to sometimes have more than 1 commit in a PR and keep them
separate when they merge to develop
On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a
> regression/flakiness in the product is introduced. We can automate and go
> through fewer commits faster, avoiding commits like "spotless fix" and
> "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it,
> what is the history)
>
>
>
> * GEODE-xxxx: <brief intro >
> * explanation line 1 * explanation line 2*
>
> This is not a rule or anything, but a request to help out your fellow
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a
> complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
>
Re: [REQUEST] Squash merge please
Posted by Nabarun Nag <nn...@apache.org>.
Re- attaching the screenshot.
Regards
Naba
On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag <nn...@pivotal.io> wrote:
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a
> regression/flakiness in the product is introduced. We can automate and go
> through fewer commits faster, avoiding commits like "spotless fix" and
> "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it,
> what is the history)
>
>
>
> * GEODE-xxxx: <brief intro >
> * explanation line 1 * explanation line 2*
>
> This is not a rule or anything, but a request to help out your fellow
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a
> complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
>
Re: [REQUEST] Squash merge please
Posted by Mark Hanson <mh...@pivotal.io>.
Yup. I am a little annoyed at myself about that..
Thanks for the reminder though.
Mark
> On Nov 5, 2019, at 11:48 AM, Owen Nichols <on...@pivotal.io> wrote:
>
> +1
>
> When merging a PR from GitHub, if the green button does not already say “Squash and merge”, click the little triangle and select “Squash and merge”.
>
> In addition to all the reasons already listed in this thread, it make reverts a lot cleaner too.
>
>> On Oct 28, 2019, at 12:47 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>>
>> +1
>>
>>
>>> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>>>
>>> Hi Geode Committers,
>>>
>>> A kind request for using squash commit instead of using merge.
>>> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>>>
>>> Also, please use the commit format : (helps us to know who worked on it, what is the history)
>>> GEODE-xxxx: <brief intro >
>>>
>>> * explanation line 1
>>> * explanation line 2
>>>
>>> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>>>
>>> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>>>
>>> Regards
>>> Naba.
>>>
>>>
>>
>
Re: [REQUEST] Squash merge please
Posted by Owen Nichols <on...@pivotal.io>.
+1
When merging a PR from GitHub, if the green button does not already say “Squash and merge”, click the little triangle and select “Squash and merge”.
In addition to all the reasons already listed in this thread, it make reverts a lot cleaner too.
> On Oct 28, 2019, at 12:47 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> +1
>
>
>> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>>
>> Hi Geode Committers,
>>
>> A kind request for using squash commit instead of using merge.
>> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>>
>> Also, please use the commit format : (helps us to know who worked on it, what is the history)
>> GEODE-xxxx: <brief intro >
>>
>> * explanation line 1
>> * explanation line 2
>>
>> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>>
>> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>>
>> Regards
>> Naba.
>>
>>
>
Re: [REQUEST] Squash merge please
Posted by Owen Nichols <on...@pivotal.io>.
+1
> On Oct 28, 2019, at 12:47 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> +1
>
>
>> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>>
>> Hi Geode Committers,
>>
>> A kind request for using squash commit instead of using merge.
>> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>>
>> Also, please use the commit format : (helps us to know who worked on it, what is the history)
>> GEODE-xxxx: <brief intro >
>>
>> * explanation line 1
>> * explanation line 2
>>
>> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>>
>> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>>
>> Regards
>> Naba.
>>
>>
>
Re: [REQUEST] Squash merge please
Posted by Jacob Barrett <jb...@pivotal.io>.
+1
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Aaron Lindsey <al...@vmware.com>.
+1 to keep only "Squash and merge" and "Rebase and merge".
Aaron Lindsey
________________________________________
From: Robert Houghton <rh...@vmware.com>
Sent: Monday, June 28, 2021 2:31 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
I for one do not like revisionist history (rebase) but understand that linear history is easier for bisect.
From: Blake Bender <bb...@vmware.com>
Date: Monday, June 28, 2021 at 2:24 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: RE: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1, only because I only get one vote. Merge commits in develop are a scourge, IMO, and should be avoided in almost all instances.
Blake
-----Original Message-----
From: Donal Evans <do...@vmware.com>
Sent: Monday, June 28, 2021 2:22 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
I definitely approve of this proposal. I accidentally merged (rather than squashed and merged) a PR a while back because my GitHub session had expired and refreshing the page after trying to squash and merge resulted in the default merge option being used, much to my frustration. I've yet to see any explanation of why we would need to merge PRs rather than squash and merge/rebase and merge, so removing it as an option just seems like a good idea.
________________________________
From: Nabarun Nag <nn...@vmware.com>
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols <on...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can't find any example of an intentional merge commit on develop...but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don't like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Calindsey%40vmware.com%7C4e593a623f154464739208d93a7c1a06%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605126957444163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8hqSLfd%2BkE3YWB%2FVzmC1zUFIloQVOKun%2BRjxGpU%2BSx0%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [REQUEST] Squash merge please
I've noticed quite a few PRs in the last week that were merged with "Merge" rather than "Squash and Merge".
While the community consensus was to continue to allow all merge options, please try to default to "Squash and Merge" whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it's easy to miss when it resets itself back to the default of "Merge" some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Robert Houghton <rh...@vmware.com>.
I for one do not like revisionist history (rebase) but understand that linear history is easier for bisect.
From: Blake Bender <bb...@vmware.com>
Date: Monday, June 28, 2021 at 2:24 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: RE: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1, only because I only get one vote. Merge commits in develop are a scourge, IMO, and should be avoided in almost all instances.
Blake
-----Original Message-----
From: Donal Evans <do...@vmware.com>
Sent: Monday, June 28, 2021 2:22 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
I definitely approve of this proposal. I accidentally merged (rather than squashed and merged) a PR a while back because my GitHub session had expired and refreshing the page after trying to squash and merge resulted in the default merge option being used, much to my frustration. I've yet to see any explanation of why we would need to merge PRs rather than squash and merge/rebase and merge, so removing it as an option just seems like a good idea.
________________________________
From: Nabarun Nag <nn...@vmware.com>
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols <on...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can't find any example of an intentional merge commit on develop...but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don't like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Crhoughton%40vmware.com%7C28d3ef66dcbd4a012c2708d93a7b1fae%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605122768804796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B7O6XEhmT%2B%2BYUvSWB1Oo8x7EWeR0QXQJbmX%2FXi5yAjQ%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [REQUEST] Squash merge please
I've noticed quite a few PRs in the last week that were merged with "Merge" rather than "Squash and Merge".
While the community consensus was to continue to allow all merge options, please try to default to "Squash and Merge" whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it's easy to miss when it resets itself back to the default of "Merge" some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
RE: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Blake Bender <bb...@vmware.com>.
+1, only because I only get one vote. Merge commits in develop are a scourge, IMO, and should be avoided in almost all instances.
Blake
-----Original Message-----
From: Donal Evans <do...@vmware.com>
Sent: Monday, June 28, 2021 2:22 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
I definitely approve of this proposal. I accidentally merged (rather than squashed and merged) a PR a while back because my GitHub session had expired and refreshing the page after trying to squash and merge resulted in the default merge option being used, much to my frustration. I've yet to see any explanation of why we would need to merge PRs rather than squash and merge/rebase and merge, so removing it as an option just seems like a good idea.
________________________________
From: Nabarun Nag <nn...@vmware.com>
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols <on...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can't find any example of an intentional merge commit on develop...but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don't like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cbblake%40vmware.com%7C066ef87d04274938120e08d93a7aca8c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605121332992373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=py04h%2Bho30POoZjPcBeuVtp%2FeeSYylGtSTGbN9%2FLylM%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [REQUEST] Squash merge please
I've noticed quite a few PRs in the last week that were merged with "Merge" rather than "Squash and Merge".
While the community consensus was to continue to allow all merge options, please try to default to "Squash and Merge" whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it's easy to miss when it resets itself back to the default of "Merge" some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Donal Evans <do...@vmware.com>.
I definitely approve of this proposal. I accidentally merged (rather than squashed and merged) a PR a while back because my GitHub session had expired and refreshing the page after trying to squash and merge resulted in the default merge option being used, much to my frustration. I've yet to see any explanation of why we would need to merge PRs rather than squash and merge/rebase and merge, so removing it as an option just seems like a good idea.
________________________________
From: Nabarun Nag <nn...@vmware.com>
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols <on...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cdoevans%40vmware.com%7Cef26879ce10c4d1723aa08d93a703283%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605075839553972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sv2SivfEegOYY3p3NnJT85On%2FqT8l8X5%2BwXySPNEKFo%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [REQUEST] Squash merge please
I’ve noticed quite a few PRs in the last week that were merged with “Merge” rather than “Squash and Merge”.
While the community consensus was to continue to allow all merge options, please try to default to “Squash and Merge” whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Nabarun Nag <nn...@vmware.com>.
Looking at the positive feedback, to this, I am skipping the red tape of creating a separate vote thread. The PR has been created and reviewed.[1]
Regards,
Nabarun
[1] https://github.com/apache/geode/pull/6661
________________________________
From: Darrel Schneider <da...@vmware.com>
Sent: Tuesday, June 29, 2021 9:13 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Tuesday, June 29, 2021 7:44 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 For Naba’s proposal
From: Joris Melchior <jm...@vmware.com>
Date: Tuesday, June 29, 2021 at 7:40 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 for Naburan’s proposed options.
From: Nabarun Nag <nn...@vmware.com>
Date: Monday, June 28, 2021 at 4:06 PM
To: Owen Nichols <on...@vmware.com>, dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cnnag%40vmware.com%7C7bf2d2f76d0b4178ced608d93b18d831%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605800176784198%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gm1WMtsbaSzCffY84dCjCEgNSSezeROj24bVWupCQoo%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [REQUEST] Squash merge please
I’ve noticed quite a few PRs in the last week that were merged with “Merge” rather than “Squash and Merge”.
While the community consensus was to continue to allow all merge options, please try to default to “Squash and Merge” whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Darrel Schneider <da...@vmware.com>.
+1
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Tuesday, June 29, 2021 7:44 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 For Naba’s proposal
From: Joris Melchior <jm...@vmware.com>
Date: Tuesday, June 29, 2021 at 7:40 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 for Naburan’s proposed options.
From: Nabarun Nag <nn...@vmware.com>
Date: Monday, June 28, 2021 at 4:06 PM
To: Owen Nichols <on...@vmware.com>, dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cdarrel%40vmware.com%7Cb606c0b76cde45a6544b08d93b0c784e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605747017170771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fN3%2FKtamPVe6HVQqn%2BREi2n%2BP1iQPRtadol6w3xl%2F3I%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [REQUEST] Squash merge please
I’ve noticed quite a few PRs in the last week that were merged with “Merge” rather than “Squash and Merge”.
While the community consensus was to continue to allow all merge options, please try to default to “Squash and Merge” whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Jens Deppe <jd...@vmware.com>.
+1 For Naba’s proposal
From: Joris Melchior <jm...@vmware.com>
Date: Tuesday, June 29, 2021 at 7:40 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 for Naburan’s proposed options.
From: Nabarun Nag <nn...@vmware.com>
Date: Monday, June 28, 2021 at 4:06 PM
To: Owen Nichols <on...@vmware.com>, dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cjdeppe%40vmware.com%7C6fa6793b726442ef3a0808d93b0be198%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637605744486487010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=u2ACIO9HM1BRNpKUpALLp0UtW2vJnioIPqjEvD79f1c%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [REQUEST] Squash merge please
I’ve noticed quite a few PRs in the last week that were merged with “Merge” rather than “Squash and Merge”.
While the community consensus was to continue to allow all merge options, please try to default to “Squash and Merge” whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Joris Melchior <jm...@vmware.com>.
+1 for Naburan’s proposed options.
From: Nabarun Nag <nn...@vmware.com>
Date: Monday, June 28, 2021 at 4:06 PM
To: Owen Nichols <on...@vmware.com>, dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cjmelchior%40vmware.com%7C9d91cbfd72dd431f164a08d93a703563%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605075886246400%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ECvN2VaHpuI3XPq6C2pjue8rHmJetmrOzMPqhgKxfPI%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [REQUEST] Squash merge please
I’ve noticed quite a few PRs in the last week that were merged with “Merge” rather than “Squash and Merge”.
While the community consensus was to continue to allow all merge options, please try to default to “Squash and Merge” whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Nabarun Nag <nn...@vmware.com>.
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [REQUEST] Squash merge please
I’ve noticed quite a few PRs in the last week that were merged with “Merge” rather than “Squash and Merge”.
While the community consensus was to continue to allow all merge options, please try to default to “Squash and Merge” whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Owen Nichols <on...@vmware.com>.
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [REQUEST] Squash merge please
I’ve noticed quite a few PRs in the last week that were merged with “Merge” rather than “Squash and Merge”.
While the community consensus was to continue to allow all merge options, please try to default to “Squash and Merge” whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Jacob Barrett <ja...@vmware.com>.
> On Jun 28, 2021, at 12:38 PM, Nabarun Nag <nn...@vmware.com> wrote:
>
>
> I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Does this proposal remove the option to “Rebase and Merge?
Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Nabarun Nag <nn...@vmware.com>.
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [REQUEST] Squash merge please
I’ve noticed quite a few PRs in the last week that were merged with “Merge” rather than “Squash and Merge”.
While the community consensus was to continue to allow all merge options, please try to default to “Squash and Merge” whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: [REQUEST] Squash merge please
Posted by Owen Nichols <on...@pivotal.io>.
I’ve noticed quite a few PRs in the last week that were merged with “Merge” rather than “Squash and Merge”.
While the community consensus was to continue to allow all merge options, please try to default to “Squash and Merge” whenever you can to keep history as linear as possible. GitHub will save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness in the product is introduced. We can automate and go through fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>