Re: Geode 1.9 Release Manager

I would love for GEODE-6399 / PR #3190 to be included in this release. This PR resolves the earlier issues we had delegating dependencies to the geode-all-bom BOM and massively reduces the POMs for each module we publish. As it is, the published POMs are functional, and I understand that such

Re: Merging GEODE-6424 into release/1.9.0

My bad! Sorry! > On Feb 20, 2019, at 3:22 PM, Sai Boorlagadda > wrote: > > Jake, > > release branch build seems broken due to spotless changes. > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main > > Sai > >> On Wed, Feb 20, 2019 at 2:59 PM Jacob

Re: Merging GEODE-6424 into release/1.9.0

Jake, release branch build seems broken due to spotless changes. https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main Sai On Wed, Feb 20, 2019 at 2:59 PM Jacob Barrett wrote: > Done! > > > On Feb 20, 2019, at 1:22 PM, Udo Kohlmeyer wrote: > > > > +1,

Re: Merging GEODE-6424 into release/1.9.0

Done! > On Feb 20, 2019, at 1:22 PM, Udo Kohlmeyer wrote: > > +1, Go,Go,GO!! > >> On 2/20/19 12:24, Jacob Barrett wrote: >> Anyone have issue with merging >> https://issues.apache.org/jira/browse/GEODE-6424 >> into release/1.9.0? >> >>

Re: Bug Numbers and Trac Numbers in comments

+1 We shouldn't even reference Apache JIRA tickets.  References to outside things like Trac tickets, JIRA tickets or even commit SHAs become outdated over time. On 2/20/19 11:28 AM, Alexander Murmann wrote: I think it's important that we enable everyone in the community to be equally

Re: Merging GEODE-6424 into release/1.9.0

+1, Go,Go,GO!! On 2/20/19 12:24, Jacob Barrett wrote: Anyone have issue with merging https://issues.apache.org/jira/browse/GEODE-6424 into release/1.9.0? Without it we will have to wait for the next release before we can have meaningful

Re: Merging GEODE-6424 into release/1.9.0

+1 On Wed, Feb 20, 2019 at 12:24 PM Jacob Barrett wrote: > Anyone have issue with merging > https://issues.apache.org/jira/browse/GEODE-6424 < > https://issues.apache.org/jira/browse/GEODE-6424> into release/1.9.0? > > Without it we will have to wait for the next release before we can have >

Re: Merging GEODE-6424 into release/1.9.0

My vote: Let’s get this into 1.9 On Wed, Feb 20, 2019 at 12:25 PM Jacob Barrett wrote: > Anyone have issue with merging > https://issues.apache.org/jira/browse/GEODE-6424 < > https://issues.apache.org/jira/browse/GEODE-6424> into release/1.9.0? > > Without it we will have to wait for the next

Merging GEODE-6424 into release/1.9.0

Anyone have issue with merging https://issues.apache.org/jira/browse/GEODE-6424 into release/1.9.0? Without it we will have to wait for the next release before we can have meaningful baselines for function and query benchmarks. Without this

Re: Bug Numbers and Trac Numbers in comments

I think it's important that we enable everyone in the community to be equally successful and on top of that do NOT rely on non-Apache resources. If we find value in Trac numbers, we should either find a way to make them accessible to everyone or update the comment so that there is no value in

Re: Release Managers

I added a 1.10.0 release to JIRA. -Dan On Wed, Feb 20, 2019 at 9:29 AM Sai Boorlagadda wrote: > Do we need to create an infra ticket to create a new release? > I don't seem to have permissions to create releases in Jira. > > On Wed, Feb 20, 2019 at 8:42 AM Jacob Barrett wrote: > > > Release

Re: Bug Numbers and Trac Numbers in comments

Well, the problem is that different people disagree on what's "meaningful" in this context. For example: See PersistentPartitionHangsDuringRestartRegressionTest.java * /*** * * RegressionTest for bug 42226. * * * 1. Member A has the bucket * * * 2. Member B starts creating the bucket. It

Re: Bug Numbers and Trac Numbers in comments

+1 - What Jake said. > On Feb 19, 2019, at 5:21 PM, Jacob Barrett wrote: > > Comments that don’t provide meaningful context beyond what is already > expressed in the code should be removed. A number to a system that the > general public can’t access is not meaningful. Delete or replace with

feature/GEODE-6389b -> release/1.9.0

I'm planning to merge the fix for 6389 to release/1.9.0 after it passes precheckin/review. This fix is essential unless we back out the changes for GEODE-2113

Re: Release Managers

Do we need to create an infra ticket to create a new release? I don't seem to have permissions to create releases in Jira. On Wed, Feb 20, 2019 at 8:42 AM Jacob Barrett wrote: > Release manager need to add the next version number to JIRA when they > branch the release. Changes going into

Re: Release branch for Apache Geode 1.9.0 has been cut

> > Oh ok I thought I read that voting was going to start soon > Are you referring to the RC vote? Per the previous discussed release schedule and the wiki , the actual release shouldn't happen till March 1st. On Wed, Feb 20,

Re: Release Managers

great - that works for me On 2/20/19 9:05 AM, Jacob Barrett wrote: On Feb 20, 2019, at 8:58 AM, Bruce Schuchardt wrote: I would _really_ like to keep the release branches for historical purposes. It's very useful to be able to look back and see what was/wasn't in a release when someone

Re: Release branch for Apache Geode 1.9.0 has been cut

Oh ok I thought I read that voting was going to start soon, so I thought I'd raise a concern about the tickets not being fixed yet. I meant this ticket https://issues.apache.org/jira/browse/GEODE-6359 This seems like a bad thing to have in the product. It looks like a possible issue when

Re: Release Managers

> On Feb 20, 2019, at 8:58 AM, Bruce Schuchardt wrote: > > I would _really_ like to keep the release branches for historical purposes. > It's very useful to be able to look back and see what was/wasn't in a release > when someone has a problem. If we delete the branches we need some other

Re: Release Managers

I would _really_ like to keep the release branches for historical purposes.  It's very useful to be able to look back and see what was/wasn't in a release when someone has a problem.  If we delete the branches we need some other way to record that information so that it's readily available.

Release Managers

Release manager need to add the next version number to JIRA when they branch the release. Changes going into develop need to be marked finished with a version but may not be merged to the current release branch. Also, after release isn’t the release branch supposed to be deleted? So what gives

Re: Regarding variable name 1.10.0 ordinal?

The backward-compatibility serialization methods based on Version.methodSuffix already add underscores between the major/minor/release numbers.  I think it would be nice to rename all of the ordinals and versions to use the same convention, like GEODE_1_10_0_ORDINAL On 2/19/19 2:42 PM, Sai