Re: Geode 1.8 release pipeline

Pipeline is up: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-8-0-main > On Nov 12, 2018, at 3:09 PM, Alexander Murmann wrote: > > Hi everyone, > > Would someone be able to se

Re: Spotless Check failing on Windows?

I'll look to make time to play with it and open a PR/Jira if I get anywhere useful. I only bothered with this thread since it is jarring if you are a new dev and clone the project and the build fails on first try. -michael On Monday, November 12, 2018, Patrick Rhomberg wrote: > Spotless has onl

Re: Release branch for Apache Geode 1.8.0 has been cut

Hi Alexander, I would like to cherry pick the following commits from develop to release/1.8.0: https://github.com/apache/geode/commit/e9ea18e18c85b977b91192d4edbb9a4e18b2643e *Reason*: This was a revert of a previous commit which addressed data inconsistencies between WAN sites, but it was found

A small proposal: Not Sorting in AnalyzeSerializablesJUnitTest

Hi all, I wrote a PR (GEODE-5800) recently to remove redundant cases from DataSerializer.readObject etc. calls. This changed the bytecode size (but not the behavior) of a number of DataSerializables, and I realized that the task of updating the list (or viewing the diff) was made harder by the fac

Re: Is concourse down?

Does github say it merges cleanly? I thought their messaging was pretty clear On Nov 12, 2018 17:19, "Alexander Murmann" wrote: I wonder if we somehow could find a way to make the error message clearer. Since it didn't merge cleanly, there is action I need to take as the committer. However, I wo

Re: Is concourse down?

I wonder if we somehow could find a way to make the error message clearer. Since it didn't merge cleanly, there is action I need to take as the committer. However, I would never know that from the error message. On Mon, Nov 12, 2018 at 4:34 PM Patrick Rhomberg wrote: > See also the previous time

Re: Is concourse down?

See also the previous time this occurred. https://markmail.org/thread/apwupkbkg3qipygo On Mon, Nov 12, 2018 at 4:18 PM, Owen Nichols wrote: > This error usually means it didn’t merge cleanly, not that concourse is > “down" > > > On Nov 12, 2018, at 3:58 PM, Kirk Lund wrote: > > > > I'm trying

Re: Is concourse down?

This error usually means it didn’t merge cleanly, not that concourse is “down" > On Nov 12, 2018, at 3:58 PM, Kirk Lund wrote: > > I'm trying to get my PR to run tests, but the latest concourse jobs are > failing with: > > rsync_code_down-OpenJDK8 > missing inputs: geode, instance-data > archiv

Is concourse down?

I'm trying to get my PR to run tests, but the latest concourse jobs are failing with: rsync_code_down-OpenJDK8 missing inputs: geode, instance-data archive-results-OpenJDK8 missing inputs: concourse-metadata-resource, geode, geode-results delete_instance-OpenJDK8 missing inputs: geode, instance-da

Re: Geode 1.8 release pipeline

I will create it. > On Nov 12, 2018, at 3:09 PM, Alexander Murmann wrote: > > Hi everyone, > > Would someone be able to set up a Concourse pipeline for the upcoming 1.8 > release? > > Thank you very much!

Geode 1.8 release pipeline

Hi everyone, Would someone be able to set up a Concourse pipeline for the upcoming 1.8 release? Thank you very much!

Re: [DISCUSS] Disable merge for failing pull requests

Just to clarify, that flaky EvictionDUnitTest is old flaky. The PR to refactor the test passed all checks, even the repeatTest as well. I had a closed PR that just touched the "un-refactored" EvictionDUnitTest, it wouldn't even pass the repeatTest at all. On Mon, Nov 12, 2018 at 2:04 PM Dan Smith

Re: [DISCUSS] Disable merge for failing pull requests

In that case, why don't we make the rule that the owner of the PR is not allowed to merge it. Another committer must then accept and merge it. --Udo On 11/12/18 14:03, Dan Smith wrote: To be clear, I don't think we have an issue of untrustworthy committers pushing code they know is broken to

Re: [DISCUSS] Disable merge for failing pull requests

To be clear, I don't think we have an issue of untrustworthy committers pushing code they know is broken to develop. The problem is that it is all to easy to look at a PR with some failures and *assume* your code didn't cause the failures and merge it anyway. I think we should all be at least reru

Re: [DISCUSS] Disable merge for failing pull requests

0 Patrick does make a point. The committers on the project have been voted in as "responsible, trustworthy and best of breed" and rights and privileges according to those beliefs have been bestowed. We should live those words and trust our committers. In the end.. If there is a "rotten" appl

Re: [DISCUSS] Disable merge for failing pull requests

-1 I really don't think this needs to be codified. If people are merging red PRs, that is a failing as a responsible developer. Defensive programming is all well and good, but this seems like it's a bit beyond the pale in that regard. I foresee it making the correction of a red main pipeline mu

Re: Spotless Check failing on Windows?

Spotless has only been checking our gradle for maybe a week or two. It enforces dependency configurations using parentheses and single-quotes so they would be easier to sort while some of us made dependencies explicit. (Also, a future spotless improvement, once I can shake the bugs out). The issu

Re: [DISCUSS] Disable merge for failing pull requests

I'm in favor of this change, but only if we have a way to restart failing PR builds without being the PR submitter. Any committer should be able to restart the build. The pipeline is still flaky enough and I want to avoid the situation where a new contributor is asked repeatedly to push empty commi

Re: [DISCUSS] Disable merge for failing pull requests

What's the general consensus on flakiness of the pipeline for this purpose? If there is consensus that it's still too flaky to disable the merge button on failure, we should probably consider doubling down on that issue again. It's hard to tell from just looking at the dev pipeline because you cann

Re: [DISCUSS] Disable merge for failing pull requests

I'm in favor of this. Several times over the years we've made a big push to get precheckin to reliably only to see rapid degradation due to crappy code being pushed in the face of precheckin failures.  We've just invested another half year doing it again.  Are we going to do things differently

Re: [DISCUSS] Deprecating JUnit4CacheTestCase (and maybe JUnit4DistributedTestCase?)

I feel like we are mixing two topic in this discussion. One is to improve our user API, and one is to write clean tests. Doing one doesn't have to sacrifice the other. If our rules are using internal APIs, then it's a chance to check if we can improve our APIs like Kirk has done. But stop using the

Re: [DISCUSS] Deprecating JUnit4CacheTestCase (and maybe JUnit4DistributedTestCase?)

Hello all, What about mixing both approaches?. We can use the *Rules* to avoid duplication of code *but re-write them* to directly use the Geode User APIs instead of the Geode Internal API. Just for the record, https://issues.apache.org/jira/browse/GEODE-5739 was created for something similar (use