Re: Time to starting thinking about cutting the 1.11 release branch?

Knowing on what day the release will get cut allows community members to plan their contributions. --geode wiki Oct 25 sounds like a good date to plan around! As much as I would love to volunteer again, this would be a reall

Re: [DISCUSS] Blocking merge button in PR

+1 for the 👶 steps proposal On Fri, Oct 18, 2019 at 3:30 PM Donal Evans wrote: > Big +1 from me on the revised proposal. It seems like there'd rarely be > a case where something needs to be merged so fast that we can't even wait > for the build and unit tests to pass, and preventing the addition

Re: [DISCUSS] Blocking merge button in PR

Big +1 from me on the revised proposal. It seems like there'd rarely be a case where something needs to be merged so fast that we can't even wait for the build and unit tests to pass, and preventing the addition of flaky tests by running the StressNewTest might help address the apparent trend of i

Re: [DISCUSS] Blocking merge button in PR

+1 to Naba's proposal, I appreciate helpful tools On Fri, Oct 18, 2019 at 3:15 PM Nabarun Nag wrote: > @Bruce Schuchardt > I completely agree with that assessment that not all flaky tests are > related to the test but may involve issues with the product itself. > > @Ernie > As you can see with

Re: [DISCUSS] Blocking merge button in PR

@Bruce Schuchardt I completely agree with that assessment that not all flaky tests are related to the test but may involve issues with the product itself. @Ernie As you can see with the example that you provided, even when committers are expected to do their due diligence they sometimes end up do

Re: [DISCUSS] log4j errors/warnings

Be careful to only add logging dependencies as testRuntime dependencies. Do not add any logger implementation/provider (e.g. log4j-core, or otherwise) in either the compile-time or runtime scope. This also means that when users are using and running Apache Geode applications (regardless of context

Re: Time to starting thinking about cutting the 1.11 release branch?

Hi Owen, Thanks for bringing this up! Given our track record, instability we have seen in the pipeline recently and that the holidays are coming up, I wonder if it makes sense to give the release more time to stabilize and cut the branch even earlier. Maybe we could try to find a release manager

Re: [DISCUSS] Blocking merge button in PR

Given the current state of affairs I don't think we should disable the merge button. Ultimately it would be nice if we fixed all of the flaky tests. Personally I don't think all of the tests that we think are "flaky" are test problems.  In the last few months I've fixed product problems that

[DISCUSS] log4j errors/warnings

Not long ago changes were made to the sub-projects that introduced a lot of build noise.  In gradle builds we see a lot of this: ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console... and in Intelli

Re: [DISCUSS] Blocking merge button in PR

I had one recently that was Approved and I merged pre-maturely and had to be reverted: d63638e4654bc6c71a232838b745dec6ef476ec9 Subsequently I have run into some test flakiness, but if a PR submitter has a pre-checkin failure it could be tricky to tell that its a Flaky situation... In my last go a

Time to starting thinking about cutting the 1.11 release branch?

Geode's stated policy is to cut quarterly release branches on a time-based schedule (specifically, the Monday on or after Feb 1, May 1, Aug 1, Nov 1). Here’s a potential timeline: Now [Contributors] Start thinking

Re: [DISCUSS] Blocking merge button in PR

Do you have a recent example of a PR that was merged despite failed PR checks, which then broke the build? At last discussion, one concern raised was providing a way that anyone in the community could re-trigger a failed PR check if it hit an unrelated flaky failure. Let’s be sure we've identi

Re: [DISCUSS] Blocking merge button in PR

Hi Naba, I recall that we last time decided against blocking it because we agreed that the test suite was too flaky at the time. It's my understanding that it has only gotten more flaky. I hope we can see an effort soon to remediate that and at that point revisit the topic. I don't have a strong

[DISCUSS] Blocking merge button in PR

Hi devs, A few months ago a proposal was brought up regarding blocking the merge button on the github PR page in case of failing tests in the precheck. What is the sentiment regarding this now? Do we feel that it should be implemented? Or at least take the minimal step of not allowing merge till