Re: [DISCUSS] Proposal to require linear commit history on develop

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 a

Re: [DISCUSS] What should we do with @Ignore tests?

Hi Naba, While I think what you are suggesting sounds reasonable, I think what you are proposing is a more painful process then leaving them in. I am encountering maybe two of them at once when addressing a flaky test. If we want to do big bulk removes then the burden of research becomes les

Re: [DISCUSS] Proposal to require linear commit history on develop

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

Re: [DISCUSS] Proposal to require linear commit history on develop

-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 wrote: > > To recap, this proposal is now revised to remove 2 of the 3 merge options > from Gi

Re: [DISCUSS] Proposal to require linear commit history on develop

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 wrote: >

Re: [DISCUSS] What should we do with @Ignore tests?

+1 to Dan's suggestions. - Remove in batches. - Send review requests for those PRs to relevant committers (authors of those tests etc.) - A brief explanation on why these tests are being deleted, and there is no loss of test coverage as it is covered by these other tests (or some other reason). R

Re: [DISCUSS] Proposal to require linear commit history on develop

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 reso

Re: [DISCUSS] Proposal to require linear commit history on develop

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 f

Re: [DISCUSS] What should we do with @Ignore tests?

Some of these test have been ignored for a long time. However, looking at the history, I see we have ignored some tests as recently as in the last month, for what seem like some questionable reasons. I'm concerned that this could be a two step process to losing test coverage - someone who things t

Re: [DISCUSS] Proposal to require linear commit history on develop

-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 mak

Re: [DISCUSS] What should we do with @Ignore tests?

I’m in favor of deleting all except the ones that have JIRA tickets open for them, like Bruce said. Also going forward I’d like to see us not be checking in @Ignored tests — just delete them instead. If we need to get it back we have revision history. Just my two cents. Aaron > On Dec 31, 201

Re: [DISCUSS] Proposal to require linear commit history on develop

To recap, this proposal is now revised to remove 2 of the 3 merge options from GitHub, leaving only Squash and Merge. PR #4513 serves as an exhibit of what is proposed (it is not to be merged unless discussion leads to consensus and a successful vote).

Re: [DISCUSS] What should we do with @Ignore tests?

I agree with deleting @Ignored tests except for the few that have JIRA tickets open for them.  There are less than 1/2 dozen of these and we should consider keeping them since we have a way of tracking them. On 12/31/19 2:07 PM, Alexander Murmann wrote: Here are a few things that are true for

Re: [DISCUSS] What should we do with @Ignore tests?

+1 to Alexander > On Dec 31, 2019, at 2:07 PM, Alexander Murmann wrote: > > Here are a few things that are true for me or I believe are true in general: > > - Our test suite is more flaky than we'd like it to be > - I don't believe that adding more Unit tests that follow existing > patter

Re: [DISCUSS] What should we do with @Ignore tests?

Here are a few things that are true for me or I believe are true in general: - Our test suite is more flaky than we'd like it to be - I don't believe that adding more Unit tests that follow existing patterns buys us that much. I'd rather see something similar to what some folks are doi

[DISCUSS] What should we do with @Ignore tests?

Hi All, As part of what I am doing to fix flaky tests, I periodically come across tests that are @Ignore’d. I am curious what we would like to do with them generally speaking. We could fix them, which would seem obvious, but we are struggling to fix flaky tests as it is. We could delete them,

RFC is about to finish collecting feedback: Support for clear operation on partitioned region

Hi, We have published the RFC: "Support for clear operation on partitioned region" for about 2 weeks. Thank the community to have given a lot of valuable feedback. https://cwiki.apache.org/confluence/display/GEODE/Support+for+clear+operation+on+partitioned+region We have updated the RFC accordin

Re: [DISCUSS] Proposal to require linear commit history on develop

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 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 th

[ANNOUNCE] Apache Geode 1.11.0

The Apache Geode community is pleased to announce the availability of Apache Geode 1.11.0. Apache Geode is a data management platform that provides a database-like consistency model, reliable transaction processing and a shared-nothing architecture to maintain very low latency performance with hig

Errored: apache/geode-examples#397 (release/1.11.0 - eed34d3)

Build Update for apache/geode-examples - Build: #397 Status: Errored Duration: 20 secs Commit: eed34d3 (release/1.11.0) Author: Mark Hanson Message: Revert "temporarily point to staging repo for CI purposes" View the changeset: https://github.com/apache/geode

Review #4537

I’m looking for a +1 (or other feedback) on https://github.com/apache/geode/pull/4537 if anyone has cycles today. Thanks! Anthony