Re: November 2018 Board Report Volunteer

[Robert Houghton]

Yes, it's my first task this morning

On Nov 13, 2018 07:02, "Anthony Baker"  wrote:

Are you able to send out a draft for review today?


> On Nov 7, 2018, at 12:43 PM, Robert Houghton  wrote:
>
> I volunteer as tribute
>
> On Nov 7, 2018 12:42, "Anthony Baker"  wrote:
>
> We need to prepare a report for the ASF Board by Nov 14.  Any volunteers
to
> write up a draft?
>
> You can review the last report [1] and use the report generator [2] to
> auto-fill some sections (if you have committer status).
>
> Anthony
>
> [1] https://whimsy.apache.org/board/minutes/Geode.html
> [2] https://reporter.apache.org/?geode

Re: Develop Compilation Failure

[Juan José Ramos]

Hey Jens,

No worries at all, it's fixed now.
Cheers.


On Tue, Nov 13, 2018 at 3:33 PM Jens Deppe  wrote:

> No worries, and thanks for the heads-up Juan.
>
> I'm really not sure anything can be done that wouldn't end up being
> heavy-handed and mostly just be an impedance.
>
> I should have sent out a notice describing the commons-lang change (given
> its scope) and that any in-flight PRs might be affected.
>
> --Jens
>
> On Tue, Nov 13, 2018 at 6:51 AM Ju@N  wrote:
>
> > Hello devs,
> >
> > Compilation in *develop* is failing after my latest commit.
> > Long story short: the *concourse-ci* tests were all green but the
> > *commons-lang* version was upgraded in develop *AFTER* the build finished
> > but *BEFORE* the merge was executed, so the import is currently outdated
> > (should be *org.apache.commons.lang3.ArrayUtils* instead of
> > *org.apache.commons.lang.ArrayUtils*).
> > I've already submitted a PR with the fix, I'll merge it once the
> > *concourse-ci *finishes.
> > BTW: even when the chances of this happening again are quite low, is
> there
> > anything we can do to automatically prevent the problem?.
> > Cheers.
> >
> > --
> > Ju@N
> >
>


-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Re: Questions about Poms and Publishing

[Bill Burcham]

@Patrick Rhomberg  I've never seen the
dependencyManagement element survive in a published POM before.

Since it sounds like you're asserting that you saw that element in a
published POM (published by Gradle), I decided to verify that. I ran this
from the Geode develop branch just now:

./gradlew build publishMavenPublicationToMavenLocal -x javadoc
-Dskip.tests=true

When I look
at 
~/.m2/repository/org/apache/geode/geode-core/1.9.0-SNAPSHOT/geode-core-1.9.0-SNAPSHOT.pom
I see no dependencyManagement section.

The absence of that element comports with my experience. My experience w/
the dependencyManagement element is that it is used when you're using Maven
to manage your build. It is wonderful for DRYing up what would otherwise be
unmanageable version information spread among lots of pom.xml (source) file.

"dependency constraints" in Gradle sounds like it'd be a big step forward
for similar reasons. I'd assume that "dependency constraints" don't result
in a dependencyManagement element in any published POM file though.


On Wed, Nov 7, 2018 at 10:00 AM Jacob Barrett  wrote:

> The dependency management element applies dependency constraints to first
> class dependencies and transitive dependencies. For example in dependency
> management of this say A:1 and B:2 it does not mean your module will
> necessarily depend on A:1 and B:2 but if the module or transitive module
> does that the versions will be nudged to match these constraints. So then
> if you module you have a dependency section that includes A it will become
> A:1 and if A:1 depends on B:1 then B:1 will be nudged to B:2.
>
> -Jake
>
>
> > On Nov 6, 2018, at 3:25 PM, Anthony Baker  wrote:
> >
> > I want reproducible builds.  If dependency locking [1] works I would be
> open to dynamic versions [2].
> >
> > Anthony
> >
> > [1] https://docs.gradle.org/current/userguide/dependency_locking.html
> > [2]
> https://docs.gradle.org/current/userguide/declaring_dependencies.html#sub:declaring_dependency_with_dynamic_version
> >
> >
> >
> >> On Nov 6, 2018, at 3:02 PM, Patrick Rhomberg 
> wrote:
> >>
> >> My current question surrounds the structure of POMs in specifying
> version
> >> information.  Gradle supports `dependency constraints` to unify library
> >> versioning.  This seems to me to be a clean, concise alternative to our
> >> current approach of cluttering the project property space with
> >> project.'library.version', with mixed adherence throughout our build
> files.
> >
>

Re: Develop Compilation Failure

[Jens Deppe]

No worries, and thanks for the heads-up Juan.

I'm really not sure anything can be done that wouldn't end up being
heavy-handed and mostly just be an impedance.

I should have sent out a notice describing the commons-lang change (given
its scope) and that any in-flight PRs might be affected.

--Jens

On Tue, Nov 13, 2018 at 6:51 AM Ju@N  wrote:

> Hello devs,
>
> Compilation in *develop* is failing after my latest commit.
> Long story short: the *concourse-ci* tests were all green but the
> *commons-lang* version was upgraded in develop *AFTER* the build finished
> but *BEFORE* the merge was executed, so the import is currently outdated
> (should be *org.apache.commons.lang3.ArrayUtils* instead of
> *org.apache.commons.lang.ArrayUtils*).
> I've already submitted a PR with the fix, I'll merge it once the
> *concourse-ci *finishes.
> BTW: even when the chances of this happening again are quite low, is there
> anything we can do to automatically prevent the problem?.
> Cheers.
>
> --
> Ju@N
>

Re: November 2018 Board Report Volunteer

[Anthony Baker]

Are you able to send out a draft for review today?

> On Nov 7, 2018, at 12:43 PM, Robert Houghton  wrote:
> 
> I volunteer as tribute
> 
> On Nov 7, 2018 12:42, "Anthony Baker"  wrote:
> 
> We need to prepare a report for the ASF Board by Nov 14.  Any volunteers to
> write up a draft?
> 
> You can review the last report [1] and use the report generator [2] to
> auto-fill some sections (if you have committer status).
> 
> Anthony
> 
> [1] https://whimsy.apache.org/board/minutes/Geode.html
> [2] https://reporter.apache.org/?geode

Develop Compilation Failure

[Ju@N]

Hello devs,

Compilation in *develop* is failing after my latest commit.
Long story short: the *concourse-ci* tests were all green but the
*commons-lang* version was upgraded in develop *AFTER* the build finished
but *BEFORE* the merge was executed, so the import is currently outdated
(should be *org.apache.commons.lang3.ArrayUtils* instead of
*org.apache.commons.lang.ArrayUtils*).
I've already submitted a PR with the fix, I'll merge it once the
*concourse-ci *finishes.
BTW: even when the chances of this happening again are quite low, is there
anything we can do to automatically prevent the problem?.
Cheers.

-- 
Ju@N

Re: Geode 1.8 release pipeline

[Alexander Murmann]

Thank you, Owen!

On Mon, Nov 12, 2018 at 9:08 PM Owen Nichols  wrote:

> Pipeline is up:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-8-0-main
> <
> 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 set up a Concourse pipeline for the upcoming 1.8
> > release?
> >
> > Thank you very much!
>
>

Re: Is concourse down?

[Patrick Rhomberg]

@Everyone

After some investigation with Kirk, it appears that the newer Concourse PR
resource prioritizes commit time as part of its identification of "newer"
commits on a given PR's branch.
As a result, you can accidentally paint yourself into a corner with git
rebase if your (actually newer) Commit Time does not appear more recent
than your previous commit's Commit Time.
This can particularly be an issue coming from a place where we have pushed
empty commits to kick the old PR resource, since (a) empty commits are
often dropped during a rebase, and (b)


The take away is this:
*If your precheckin isn't firing, you might have accidentally have a HEAD
that is older than the previous precheckin run.*
This generally shouldn't be an issue, but "generally shouldn't be" isn't
the same as "won't be".


If it happens to you:
We are referring here to the Commit Time, not the Author Time.  Use git log
--format=fuller to get all of your commit metadata.

You can find Concourse's view of your PR's history in the resource page
[1].  Search for your PR number there.

If the time shown is newer than your PR's HEAD, you need to get a newer
commit to your HEAD.  Your options are:

* Merge with the develop branch.
* Push an empty commit.
* Amend the commit of your HEAD to update the Commit Time, then force your
push.

I advocate them in that order, but understand there are times where you
want a particular git history.

Good luck out there.

Imagination is Change.
~Patrick

[1]
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/resources/geode

On Tue, Nov 13, 2018 at 9:31 AM, Kirk Lund  wrote:

> Just in case you don't believe me and want to double-check my answer:
>
> My PR which says there are NO CONFLICTS:
> https://github.com/apache/geode/pull/2778
>
> Thanks,
> Kirk
>
> On Tue, Nov 13, 2018 at 9:31 AM, Kirk Lund  wrote:
>
> > Yes github says it merges cleanly (still does in fact):
> >
> > This branch has no conflicts with the base branch when rebasingRebase and
> > merge can be performed automatically.
> >
> > The previous revision DID have a merge conflict which is exactly why I
> > rebased on develop, resolved conflicts and then pushed to my fork.
> > Rerunning the tests against my latest push is what seems to be failing.
> >
> > So I'll change my question since some folks seem convinced that I'm
> > causing the problem:
> >
> > Why does concourse not run tests for my PR after I push changes that
> > resolve a conflict?
> >
> > Thanks,
> > Kirk
> >
> > On Mon, Nov 12, 2018 at 5:26 PM, Robert Houghton 
> > wrote:
> >
> >> 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 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 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 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-data
> >> > > >
> >> > > > Anyone know what that means?
> >> > > >
> >> > > > Thanks,
> >> > > > Kirk
> >> > >
> >> > >
> >> >
> >>
> >
> >
>

Re: Is concourse down?

[Kirk Lund]

Patrick helped me figure this out! Whew, whatta relief. I'll let him
describe it so others benefit (it has something to do with commit time
instead of push time or changes to head sha)...

Thanks,
Kirk

On Tue, Nov 13, 2018 at 9:31 AM, Kirk Lund  wrote:

> Just in case you don't believe me and want to double-check my answer:
>
> My PR which says there are NO CONFLICTS: https://github.com/apache/
> geode/pull/2778
>
> Thanks,
> Kirk
>
> On Tue, Nov 13, 2018 at 9:31 AM, Kirk Lund  wrote:
>
>> Yes github says it merges cleanly (still does in fact):
>>
>> This branch has no conflicts with the base branch when rebasingRebase
>> and merge can be performed automatically.
>>
>> The previous revision DID have a merge conflict which is exactly why I
>> rebased on develop, resolved conflicts and then pushed to my fork.
>> Rerunning the tests against my latest push is what seems to be failing.
>>
>> So I'll change my question since some folks seem convinced that I'm
>> causing the problem:
>>
>> Why does concourse not run tests for my PR after I push changes that
>> resolve a conflict?
>>
>> Thanks,
>> Kirk
>>
>> On Mon, Nov 12, 2018 at 5:26 PM, Robert Houghton 
>> wrote:
>>
>>> 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 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 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 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-data
>>> > > >
>>> > > > Anyone know what that means?
>>> > > >
>>> > > > Thanks,
>>> > > > Kirk
>>> > >
>>> > >
>>> >
>>>
>>
>>
>

Re: [DISCUSS] Disable merge for failing pull requests

[Ryan McMahon]

+1 I like this idea, but I recognize that it will be a challenge when there
is still some flakiness to the pipeline.  I think we'd need clear
guidelines on what to do if your PR fails due to something seemingly
unrelated.  For instance, we ran into GEODE-5943 (flaky EvictionDUnitTest)
in our last PR, and saw that there was already an open ticket for the
flakiness (we even reverted our change and reproduced to be sure).  So we
triggered another PR pipeline and it passed the second time.  Is rerunning
the pipeline again sufficient in this case?  Or should we have stopped what
we were doing and took up GEODE-5943, assuming it wasn't assigned to
someone?  If it was already assigned to someone, do we wait until that bug
is fixed before we run through the PR pipeline again?

I think if anything this will help us treat bugs that are causing a red
pipeline as critical, and I think that is a good thing.  So I'm still +1
despite the flakiness.  Just curious what people think about how we should
handle cases where there is a known failure and it is indeed unrelated to
our PR.

Ryan


On Mon, Nov 12, 2018 at 2:49 PM Jinmei Liao  wrote:

> 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  wrote:
>
> > 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 rerunning the tests and not merging the
> PR
> > until everything passes. If the merge button is greyed out, that might
> help
> > communicate that standard to everyone.
> >
> > Looking at the OpenJDK 8 metrics, it looks to me like most of the issues
> > are recently introduced (builds 81-84 and the EvictionDUnitTest), not old
> > flaky tests. So I think we were a little more disciplined always
> listening
> > to what the checks are telling us we would have less noise in the long
> run.
> >
> >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-metrics/jobs/GeodeDistributedTestOpenJDK8Metrics/builds/23
> >
> > -Dan
> >
> > On Mon, Nov 12, 2018 at 11:21 AM Udo Kohlmeyer  wrote:
> >
> > > 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" apple in the mix this should be addressed, maybe
> not
> > > as public flogging, but with stern communications.
> > >
> > > On the other side, I've also seen the model where the submitter of PR
> is
> > > not allowed to merge + commit their own PR's. That befalls to another
> > > committer to complete this task, avoiding the whole, "I'll just quickly
> > > commit without due diligence".
> > >
> > > --Udo
> > >
> > >
> > > On 11/12/18 10:23, Patrick Rhomberg wrote:
> > > > -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
> > > > must more difficult that it needs to be.  And while it's much better
> > than
> > > > it had been, I am (anecdotally) still seeing plenty of flakiness in
> my
> > > PRs,
> > > > either resulting from infra failures or test classes that need to be
> > > > refactored or reevaluated.
> > > >
> > > > If someone is merging truly broken code that has failed precheckin,
> > that
> > > > seems to me to be a discussion to have with that person.   If it
> > > > persists, perhaps a public flogging would be in order.  But at
> the
> > > end
> > > > of the day, the onus is on us to be responsible developers, and no
> > amount
> > > > of gatekeeping is going to be a substitute for that.
> > > >
> > > > On Mon, Nov 12, 2018 at 9:38 AM, Galen O'Sullivan <
> > gosulli...@pivotal.io
> > > >
> > > > wrote:
> > > >
> > > >> 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
> > > >> commits to trigger a PR build (in between actual PR review) and
> their
> > PR
> > > >> gets delayed by days if not weeks. That's a real bad experience 

Re: A small proposal: Not Sorting in AnalyzeSerializablesJUnitTest

[Kirk Lund]

+1 I've had to reorder the list a few times myself to correct the ordering

On Mon, Nov 12, 2018 at 5:28 PM, Galen O'Sullivan 
wrote:

> 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 fact
> that our sanctionedDataSerializables list has gotten out of order. I would
> like to propose forcing the list (and probably sanctionedSerializables as
> well) to be ordered and the files to be equal, as I see no benefit to
> having the files out of order, and I do see a benefit to having
> configuration files like this rigidly defined so that we can analyze and
> read diffs better.
>
> Thoughts?
>
> Thanks,
> Galen
>

Re: November 2018 Board Report Volunteer

[Anthony Baker]

Thanks Robert, comments below.

> On Nov 13, 2018, at 12:33 PM, Robert Houghton  wrote:
> 
> Here is a draft of the GEODE report. Please comment or amend so that we can
> submit to Apache.
> Thank you,
> -Robert Houghton
> 
> ## Description:
> Apache Geode provides a database-like consistency model, reliable
> transaction
> processing and a shared-nothing architecture to maintain very low latency
> performance with high concurrency processing.
> 
> ## Issues:
> There are no issues requiring board attention at this time.
> 
> ## Activity:
> - We released v1.7.0, containing 859 commits resolving 196 bugs, 98
> improvements
> and features, and a total of 357 JIRA tickets
> - Gradle has been upgraded v4.10.1
> - We added JDK11 tests to our CI pipeline. This compiles with JDK8 and runs
> against JDK11.
> - We have added Windows platform testing to the CI pipeline.
> 

Edit:
- We’ve made a number of build improvements, including upgrading to Gradle 
4.10.1.
- We’ve begun testing with Java 11 and have added automated Windows testing to 
our CI jobs.

Add:
- We have reviewed and acted on a number of code issues reported by lgtm.com 
.
- We discussed use of Lombok and decided that adoption would prove to be a 
barrier to users and contributors.
- We added a notifications@ mailing list to track GitHub PR activity.
- We agreed to adopt a quarterly release schedule to improve predictability of 
releases.
- We reorganized the top-level wiki for better navigation and discoverability.  
We also added a page to track conference presentations, blog postings, and 
other media.
- The Geode Summit at SpringOnePlatform 2018 was very well-attended with over 
400 people filling the conference room.  Both users and committers alike 
presented 15 talks during the conference.  The sessions were recorded and 
available on youtube.

> ## Health report:
> - Overall project momentum is picking back up. We are seeing good results
> from the efforts
> to improve test reliability
> 
> ## PMC changes:
> 
> - Currently 46 PMC members.
> - No new PMC members added in the last 3 months
> - Last PMC addition was Dick Cavender on Tue Feb 20 2018
> 
> ## Committer base changes:
> 
> - Currently 98 committers.
> - New commmitters:
>   - Addison Huddy was added as a committer on Sat Sep 01 2018
>   - Alexander Murmann was added as a committer on Sat Sep 08 2018
>   - Blake Bender was added as a committer on Sat Sep 01 2018
>   - Helena Bales was added as a committer on Sat Sep 01 2018
>   - Ivan Godwin was added as a committer on Sat Sep 01 2018
>   - Juan Ramos was added as a committer on Sat Sep 08 2018
>   - Ryan McMahon was added as a committer on Sat Sep 01 2018
>   - Michael Martell was added as a committer on Sat Sep 08 2018
>   - Michael Oleske was added as a committer on Sat Sep 08 2018
>   - Robert Houghton was added as a committer on Mon Oct 01 2018
>   - Sean Goller was added as a committer on Sat Sep 01 2018
> 
> ## Releases:
> 
> - 1.7.0 was released on Thu Oct 04 2018

Add:
- We have begun work on the 1.8.0 release.  We expect the release to include 
geode-native (a C++/C# client for Geode) for the first time.
- We’re continuing to rotate release manager duties among committers to ensure 
the release process is well documented and repeatable.

> 
> ## Mailing list activity:
> 
> - Mailing lists have remained active and have been seen a marked increase
> in use
> for both development and issues

Add:
- The increase in the user@ mailing list is very encouraging and seems to 
correlate with the Geode Summit.
> 
> - dev@geode.apache.org:
>   - 190 subscribers (up 8 in the last 3 months):
>   - 889 emails sent to list (624 in previous quarter)
> 
> - iss...@geode.apache.org:
>   - 55 subscribers (up 1 in the last 3 months):
>   - 4283 emails sent to list (2707 in previous quarter)
> 
> - notificati...@geode.apache.org:
>   - 7 subscribers (up 7 in the last 3 months):
>   - 1998 emails sent to list (0 in previous quarter)
> 
> - u...@geode.apache.org:
>   - 249 subscribers (up 7 in the last 3 months):
>   - 201 emails sent to list (138 in previous quarter)
> 
> 
> ## JIRA activity:
> 
> - 456 JIRA tickets created in the last 3 months
> - 485 JIRA tickets closed/resolved in the last 3 months
> 
> 
> 
> On Tue, Nov 13, 2018 at 7:04 AM Robert Houghton 
> wrote:
> 
>> Yes, it's my first task this morning
>> 
>> On Nov 13, 2018 07:02, "Anthony Baker"  wrote:
>> 
>> Are you able to send out a draft for review today?
>> 
>> 
>>> On Nov 7, 2018, at 12:43 PM, Robert Houghton 
>> wrote:
>>> 
>>> I volunteer as tribute
>>> 
>>> On Nov 7, 2018 12:42, "Anthony Baker"  wrote:
>>> 
>>> We need to prepare a report for the ASF Board by Nov 14.  Any volunteers
>> to
>>> write up a draft?
>>> 
>>> You can review the last report [1] and use the report generator [2] to
>>> auto-fill some sections (if you have committer status).
>>> 
>>> Anthony
>>> 
>>> [1] https://whimsy.apache.org/board/minutes/Geode.html
>>> [2] 

Re: November 2018 Board Report Volunteer

[Robert Houghton]

Here is a draft of the GEODE report. Please comment or amend so that we can
submit to Apache.
Thank you,
-Robert Houghton

## Description:
Apache Geode provides a database-like consistency model, reliable
transaction
processing and a shared-nothing architecture to maintain very low latency
performance with high concurrency processing.

## Issues:
There are no issues requiring board attention at this time.

## Activity:
- We released v1.7.0, containing 859 commits resolving 196 bugs, 98
improvements
 and features, and a total of 357 JIRA tickets
- Gradle has been upgraded v4.10.1
- We added JDK11 tests to our CI pipeline. This compiles with JDK8 and runs
against JDK11.
- We have added Windows platform testing to the CI pipeline.

## Health report:
- Overall project momentum is picking back up. We are seeing good results
from the efforts
 to improve test reliability

## PMC changes:

- Currently 46 PMC members.
- No new PMC members added in the last 3 months
- Last PMC addition was Dick Cavender on Tue Feb 20 2018

## Committer base changes:

- Currently 98 committers.
- New commmitters:
   - Addison Huddy was added as a committer on Sat Sep 01 2018
   - Alexander Murmann was added as a committer on Sat Sep 08 2018
   - Blake Bender was added as a committer on Sat Sep 01 2018
   - Helena Bales was added as a committer on Sat Sep 01 2018
   - Ivan Godwin was added as a committer on Sat Sep 01 2018
   - Juan Ramos was added as a committer on Sat Sep 08 2018
   - Ryan McMahon was added as a committer on Sat Sep 01 2018
   - Michael Martell was added as a committer on Sat Sep 08 2018
   - Michael Oleske was added as a committer on Sat Sep 08 2018
   - Robert Houghton was added as a committer on Mon Oct 01 2018
   - Sean Goller was added as a committer on Sat Sep 01 2018

## Releases:

- 1.7.0 was released on Thu Oct 04 2018

## Mailing list activity:

- Mailing lists have remained active and have been seen a marked increase
in use
 for both development and issues

- dev@geode.apache.org:
   - 190 subscribers (up 8 in the last 3 months):
   - 889 emails sent to list (624 in previous quarter)

- iss...@geode.apache.org:
   - 55 subscribers (up 1 in the last 3 months):
   - 4283 emails sent to list (2707 in previous quarter)

- notificati...@geode.apache.org:
   - 7 subscribers (up 7 in the last 3 months):
   - 1998 emails sent to list (0 in previous quarter)

- u...@geode.apache.org:
   - 249 subscribers (up 7 in the last 3 months):
   - 201 emails sent to list (138 in previous quarter)


## JIRA activity:

- 456 JIRA tickets created in the last 3 months
- 485 JIRA tickets closed/resolved in the last 3 months



On Tue, Nov 13, 2018 at 7:04 AM Robert Houghton 
wrote:

> Yes, it's my first task this morning
>
> On Nov 13, 2018 07:02, "Anthony Baker"  wrote:
>
> Are you able to send out a draft for review today?
>
>
> > On Nov 7, 2018, at 12:43 PM, Robert Houghton 
> wrote:
> >
> > I volunteer as tribute
> >
> > On Nov 7, 2018 12:42, "Anthony Baker"  wrote:
> >
> > We need to prepare a report for the ASF Board by Nov 14.  Any volunteers
> to
> > write up a draft?
> >
> > You can review the last report [1] and use the report generator [2] to
> > auto-fill some sections (if you have committer status).
> >
> > Anthony
> >
> > [1] https://whimsy.apache.org/board/minutes/Geode.html
> > [2] https://reporter.apache.org/?geode
>
>
>

Re: Questions about Poms and Publishing

[John Blum]

If you'd like Maven dependencyManagement like behavior in Gradle, then you
should have a look at...

https://github.com/spring-gradle-plugins/dependency-management-plugin

-j

On Tue, Nov 13, 2018 at 8:10 AM, Bill Burcham  wrote:

> @Patrick Rhomberg  I've never seen the
> dependencyManagement element survive in a published POM before.
>
> Since it sounds like you're asserting that you saw that element in a
> published POM (published by Gradle), I decided to verify that. I ran this
> from the Geode develop branch just now:
>
> ./gradlew build publishMavenPublicationToMavenLocal -x javadoc
> -Dskip.tests=true
>
> When I look
> at ~/.m2/repository/org/apache/geode/geode-core/1.9.0-
> SNAPSHOT/geode-core-1.9.0-SNAPSHOT.pom
> I see no dependencyManagement section.
>
> The absence of that element comports with my experience. My experience w/
> the dependencyManagement element is that it is used when you're using Maven
> to manage your build. It is wonderful for DRYing up what would otherwise be
> unmanageable version information spread among lots of pom.xml (source)
> file.
>
> "dependency constraints" in Gradle sounds like it'd be a big step forward
> for similar reasons. I'd assume that "dependency constraints" don't result
> in a dependencyManagement element in any published POM file though.
>
>
> On Wed, Nov 7, 2018 at 10:00 AM Jacob Barrett  wrote:
>
> > The dependency management element applies dependency constraints to first
> > class dependencies and transitive dependencies. For example in dependency
> > management of this say A:1 and B:2 it does not mean your module will
> > necessarily depend on A:1 and B:2 but if the module or transitive module
> > does that the versions will be nudged to match these constraints. So then
> > if you module you have a dependency section that includes A it will
> become
> > A:1 and if A:1 depends on B:1 then B:1 will be nudged to B:2.
> >
> > -Jake
> >
> >
> > > On Nov 6, 2018, at 3:25 PM, Anthony Baker  wrote:
> > >
> > > I want reproducible builds.  If dependency locking [1] works I would be
> > open to dynamic versions [2].
> > >
> > > Anthony
> > >
> > > [1] https://docs.gradle.org/current/userguide/dependency_locking.html
> > > [2]
> > https://docs.gradle.org/current/userguide/declaring_
> dependencies.html#sub:declaring_dependency_with_dynamic_version
> > >
> > >
> > >
> > >> On Nov 6, 2018, at 3:02 PM, Patrick Rhomberg 
> > wrote:
> > >>
> > >> My current question surrounds the structure of POMs in specifying
> > version
> > >> information.  Gradle supports `dependency constraints` to unify
> library
> > >> versioning.  This seems to me to be a clean, concise alternative to
> our
> > >> current approach of cluttering the project property space with
> > >> project.'library.version', with mixed adherence throughout our build
> > files.
> > >
> >
>



-- 
-John
john.blum10101 (skype)

Re: Is concourse down?

[Kirk Lund]

Just in case you don't believe me and want to double-check my answer:

My PR which says there are NO CONFLICTS:
https://github.com/apache/geode/pull/2778

Thanks,
Kirk

On Tue, Nov 13, 2018 at 9:31 AM, Kirk Lund  wrote:

> Yes github says it merges cleanly (still does in fact):
>
> This branch has no conflicts with the base branch when rebasingRebase and
> merge can be performed automatically.
>
> The previous revision DID have a merge conflict which is exactly why I
> rebased on develop, resolved conflicts and then pushed to my fork.
> Rerunning the tests against my latest push is what seems to be failing.
>
> So I'll change my question since some folks seem convinced that I'm
> causing the problem:
>
> Why does concourse not run tests for my PR after I push changes that
> resolve a conflict?
>
> Thanks,
> Kirk
>
> On Mon, Nov 12, 2018 at 5:26 PM, Robert Houghton 
> wrote:
>
>> 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 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 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 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-data
>> > > >
>> > > > Anyone know what that means?
>> > > >
>> > > > Thanks,
>> > > > Kirk
>> > >
>> > >
>> >
>>
>
>

Re: Is concourse down?

[Kirk Lund]

Yes github says it merges cleanly (still does in fact):

This branch has no conflicts with the base branch when rebasingRebase and
merge can be performed automatically.

The previous revision DID have a merge conflict which is exactly why I
rebased on develop, resolved conflicts and then pushed to my fork.
Rerunning the tests against my latest push is what seems to be failing.

So I'll change my question since some folks seem convinced that I'm causing
the problem:

Why does concourse not run tests for my PR after I push changes that
resolve a conflict?

Thanks,
Kirk

On Mon, Nov 12, 2018 at 5:26 PM, Robert Houghton 
wrote:

> 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 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 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 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-data
> > > >
> > > > Anyone know what that means?
> > > >
> > > > Thanks,
> > > > Kirk
> > >
> > >
> >
>

Re: A small proposal: Not Sorting in AnalyzeSerializablesJUnitTest

[Anilkumar Gingade]

If it makes easy to find/address failure with AnalyzeSerializablesTest, +1

-Anil.


On Tue, Nov 13, 2018 at 9:34 AM Kirk Lund  wrote:

> +1 I've had to reorder the list a few times myself to correct the ordering
>
> On Mon, Nov 12, 2018 at 5:28 PM, Galen O'Sullivan 
> wrote:
>
> > 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
> fact
> > that our sanctionedDataSerializables list has gotten out of order. I
> would
> > like to propose forcing the list (and probably sanctionedSerializables as
> > well) to be ordered and the files to be equal, as I see no benefit to
> > having the files out of order, and I do see a benefit to having
> > configuration files like this rigidly defined so that we can analyze and
> > read diffs better.
> >
> > Thoughts?
> >
> > Thanks,
> > Galen
> >
>

Re: A small proposal: Not Sorting in AnalyzeSerializablesJUnitTest

[Patrick Rhomberg]

I categorically like style improvement and enforcement.

+1 to this specific style improvement and enforcement.

It's pretty straight-forward to write a regex into our spotless.gradle.
Let me know if you need a hand on that front, since I know I shouldn't use
"straightforward" to refer to either of regex or gradle.

On Mon, Nov 12, 2018 at 5:28 PM, Galen O'Sullivan 
wrote:

> 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 fact
> that our sanctionedDataSerializables list has gotten out of order. I would
> like to propose forcing the list (and probably sanctionedSerializables as
> well) to be ordered and the files to be equal, as I see no benefit to
> having the files out of order, and I do see a benefit to having
> configuration files like this rigidly defined so that we can analyze and
> read diffs better.
>
> Thoughts?
>
> Thanks,
> Galen
>