Re: Access to upload Apache Geode to Docker Hub.

Done On Tue, Nov 19, 2019 at 3:51 PM Mark Hanson wrote: > Hi, > > I would like to have access to upload to Docker Hub, so I can release > Apache Geode to Docker Hub. > > My DockerHub ID is mhansonp. > > Thanks, > Mark

Re: Release candidate target date...

t takes > more than one RC? > > * some people might prefer to give feedback against a formal RC rather > than informally against the branch? > > * impact of Thanksgiving? > > > >> On Nov 12, 2019, at 4:05 PM, Alexander Murmann > wrote: > >> > >>

Re: Release candidate target date...

I think it's really great to agree on the date by which we want to have a RC1 early. However, I thought the target release date is beginning of December, which would probably bring us to December 2nd, given the first is a Sunday. The voting period is 3 days. I would have expected that we'd create

Re: [Proposal] Cut 1.11.0 branch on November 4th, 2019.

 This matches what we discussed on the previous thread! Thanks of stepping up! On Mon, Oct 28, 2019 at 2:33 PM Mark Hanson wrote: > Hi All, > > Looks like I won the contest to be release manager by default, so let's > get started…. > > I think we should cut the branch on November 4th, 2019.

Re: [VOLUNTEER] I am volunteering to handle the 1.11 Apache Geode release.

Owen, could you remind me which step requires PMC creds? I don't recall needing them when I managed a release earlier this year. On Mon, Oct 28, 2019 at 2:10 PM Owen Nichols wrote: > Fantastic, Mark! > > Please having a look at >

Re: [VOTE] Apache Geode 1.9.2.RC1

+1 Downloaded source code, build and ran tests. Started a cluster and was able to execute basic operations. Compiled and ran examples Validated pipeline was run successfully for the SHA we are shipping On Tue, Oct 22, 2019 at 2:17 AM Ju@N wrote: > +1, > > Downloaded and built from source,

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

date to plan around! > > > > As much as I would love to volunteer again, this would be a really > fantastic opportunity for a new committer who hasn’t done a release > before. Don’t be shy! No prior experience required! > > > > -Owen > > > >>

Re: [DISCUSS] Blocking merge button in PR

Udo, I think you are making a great point! I am fully bought into trusting our committers to know how many reviews are needed for their PRs. We should be able to have the same trust into knowing when it's OK to merge. If a committer wants to they can after all, always merge and push without a PR.

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

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

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

Re: dockerhub mojo

Dick, you should have access now. On Thu, Sep 26, 2019 at 9:38 AM Dick Cavender wrote: > Can someone with the ability give my docker hub account (docdixie) > permissions to upload the new geode 1.10.0 docker image? > > Thanks! >

Re: [DISCUSS] what region types to support in the new management rest api

Hey folks, I want to make sure that any other's product's roadmaps have no impact on any decisions we make about Apache Geode. Thanks! On Tue, Aug 20, 2019 at 10:45 AM Darrel Schneider wrote: > Is "group" support on the PCC roadmap or is the plan for the members of a > cluster to always be

Re: I propose including the fix for GEODE-3780 in 1.10

+1 it's a regression in 1.10 and a serious problem. On Mon, Aug 19, 2019 at 7:38 AM Bruce Schuchardt wrote: > It sounds like Udo is okay with this now. Any other concerns? > > On 8/17/19 2:07 AM, Owen Nichols wrote: > > On Aug 15, 2019, at 2:09 PM, Bruce Schuchardt > wrote: > > > > This is a

Re: Proposal to Include GEODE-7079 in 1.10.0

+1 Agreed to fixing this. It's impossible for a user to discover they hit an edge case that we fail to support till they are in prod and restart. On Thu, Aug 15, 2019 at 10:09 AM Juan José Ramos wrote: > Hello Udo, > > Even if it is an existing issue I'd still consider it critical for those >

Re: [DISCUSS] Time to cut Geode 1.10.0?

point > > (coming near the end of a nice period of solid green in the pipeline), > and > > I acknowledge that fair warning was given a week ago that a branch was > > “coming soon”, but I wonder if there is anything we can do to make the > > rules for what gets in a release and

Re: [DISCUSS] Time to cut Geode 1.10.0?

ke sure get > > addressed > > > before we ship? > > > > > > On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt < > eburgha...@pivotal.io> > > > wrote: > > > > > > > There is a PR #3844 <https://github.com/apache/geode/pull/3844&

Re: [DISCUSS] Time to cut Geode 1.10.0?

ext release... > > EB > > On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann > wrote: > > > *Cutting the release* > > Do we have any volunteers to take over the release manager role? > > > > *Re: Udo's concerns* > > While I believe that iterations of this

Re: [DISCUSS] Time to cut Geode 1.10.0?

the ground work to have been discussed, API's validated BEFORE > > > it is released into the wild. I mean this is a PUBLIC API, so we'd > > > prefer to get it more correct than the previous one. > > > > > > Maybe it is just me, taking it too serious... Where I pre

Re: [DISCUSS] Time to cut Geode 1.10.0?

proposal. > > > > All work under the experimental cluster management service has not yet > > been approved by the agreed upon RFC process. > > > > I don't believe we should be including this work, experimental or > > otherwise. > > > > --Udo >

Re: [DISCUSS] Time to cut Geode 1.10.0?

.0 after that work > is > > complete. > > > > On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann > > wrote: > > > >> Hi everyone! > >> > >> We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of > >> last year we d

Re: [DISCUSS] Time to cut Geode 1.10.0?

geode property to turn it > on/off. I would say we are ready to cut the geode 1.10.0 after that work is > complete. > > On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann > wrote: > > > Hi everyone! > > > > We released Geode 1.9.0 on April 25th. That's about 3 mon

[DISCUSS] Time to cut Geode 1.10.0?

Hi everyone! We released Geode 1.9.0 on April 25th. That's about 3 months ago. End of last year we discussed releasing quarterly. In the past we've had about a month between cutting a release branch and actually shipping our new minor. This means we are already behind our target release cadence.

Re: [DISCUSS] RFC 0: Lightweight RFC Process

." If you know what state these > > proposals are in, please move them! > > > > > https://cwiki.apache.org/confluence/display/GEODE/Project+Proposals+and+Specifications > > > > On Wed, Jun 26, 2019 at 11:20 AM Alexander Murmann > > wrote: > > >

Re: [DISCUSS] RFC 0: Lightweight RFC Process

Given discussion here and previous discussion on the PR, I consider this proposal approved and updated its state accordingly. I also incorporated Dan's suggestion of moving deprecated proposals and added a reference to the new process at the top of the Project Proposals and Specifications page

Re: [DISCUSS] RFC 0: Lightweight RFC Process

posal actively > under development? It might be nice to clearly distinguish between > proposals that are under development vs. finished. > > -Dan > > On Mon, Jun 24, 2019 at 2:31 PM Alexander Murmann > wrote: > >> Having the RFC discussion in a pull request was by fa

Re: [DISCUSS] Adoption of a Coding Standard

ou feel is > irrelevant or incorrect? Please pick an example with a link to it so we can > discuss it. > > PS: There aren't any other Coding Standards that I would personally write > or recommend. > > On Mon, Jun 24, 2019 at 2:50 PM Alexander Murmann > wrote: > &

Re: [DISCUSS] Adoption of a Coding Standard

Hi Kirk, I think having a coding standard that goes beyond a formatting style guide is a great idea. There are many interesting things in the SEI CERT standard. However, it's also massive. I see 13 rules just about methods. Yet some guidelines that would be most important to me like limiting

Re: [DISCUSS] RFC 0: Lightweight RFC Process

are. Please take a look there <https://cwiki.apache.org/confluence/display/GEODE/Lightweight+RFC+Process> and let's discuss here if any changes should be made. Otherwise I intent to move the proposal to `active` tomorrow. Thank you everyone! On Thu, Jun 13, 2019 at 4:26 PM Alexander Murmann

[DISCUSS] RFC 0: Lightweight RFC Process

Hi everyone, I am proposing a new process that is aimed to address some of the issues we've recently encountered in making collective decisions. The process I am proposing would use pull request to discuss proposals. To demonstrate the process, I submitted my proposal as a pull request

Re: [DISCUSS] require reviews before merging a PR

I am one. But I also know that I > mistakes are made regardless of intent. If we trust committers, why > review at all? Just commit... and we might catch a problem, we might not. > > --Udo > > On 6/5/19 11:20, Alexander Murmann wrote: > > Udo, I agree with many of the

Re: [DISCUSS] require reviews before merging a PR

Udo, I agree with many of the pains you are addressing, but am pessimistic that having more reviewers will solve them. You are absolutely correct in calling out that the code is ugly complex and missing coverage. The best way to address this is to clean up the code and improve coverage. You say

Re: what is the best way to update a geode pull request

+1 to updating the checklist. About single vs multiple commits: I think either is fine as long as it is deliberate and makes it easier to understand what someone is doing. If there is a large refactor that enables a small change, it is often easier to understand when these changes are in separate

Re: [DISCUSS] require reviews before merging a PR

Jake, Owen is quoting the "VOTES ON CODE MODIFICATION" section from https://www.apache.org/foundation/voting.html . "code modification" == "every PR" is a interpretation that I think would bring the project to a grinding halt. On Fri, May 31, 2019 at 9:01 AM Jacob Barrett wrote: > > > > On May

Re: [DISCUSS] require reviews before merging a PR

+1 to Jake's interpretation of the voting system not having been adjusted yet for the new world that is GitHub. When I read the Apache voting guidelines they make sense to me for bug decisions but not for a regular PR. The inertia coming with three votes on every PR is way more costly than the

Test coverage and PRs

Hi everyone, TL;DR: 1. Let's call each other out on our PRs when test coverage is missing or insufficient 2. Let's require test coverage for code that gets refactored as well We already have a really great wiki page

Re: [DISCUSS] Move or remove org.apache.geode.admin

Would we announce that we aren't following semver anymore because bumping the major version is somehow too expensive? On Wed, Apr 3, 2019 at 3:29 PM Kirk Lund wrote: > 1) +1 YES. If we continue to *not* have at least one major release per > year, then I 100% support the removal of deprecated

Re: [DISCUSS] Move or remove org.apache.geode.admin

The way I interpret https://semver.org/, deprecated functionality should be removed in a major release. Users should be able to update to a new minor release without having to worry that any of their code will break. It's certainly more convenient for us to mark as deprecated and then remove

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

; The geode-native PR will be ready to check in momentarily. Just waiting > > for Travis to do its diligence. > > > > On Wed, Mar 20, 2019 at 9:47 AM Alexander Murmann > > wrote: > > > >> Dale, do I understand correctly that the only concern around the > &

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

Dale, do I understand correctly that the only concern around the Micrometer work right now it that it's not useful yet, however it's not harmful either? Dave, is it correct that if that PR doesn't make it into the newly cut branch, we'd be shipping with a older version of geode-native? What are

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

+1. We want to ship with confidence and we have more trust in develop right now. On Tue, Mar 19, 2019 at 2:11 PM Dick Cavender wrote: > +1 to re-cutting the 1.9 release branch off a more stable develop sha > within the last couple days. > > On Tue, Mar 19, 2019 at 1:14 PM Bruce Schuchardt >

Re: 1.9 release date

ut > when the release will be done (because uncertainty) and more focused on > ensuring we have demonstrated stability on the release branch. Hopefully > that will happen sooner than 4/1…but it could take longer too. > > > > Anthony > > > > > >> On Feb 28, 2019

1.9 release date

Hi everyone, According to our wiki we were aiming for a March 1st release date for our 1.9 release. We cut the release branch about two weeks late and see unusual amounts of merges still going into the branch. I propose that we give ourselves some more time to validate what's there. My proposal

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 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: Geode 1.9 Release Manager

xes means that we are releasing with > serious known issues in the product. Hence in my opinion this risk is > acceptable. > > Regards > Naba > > On Thu, Feb 14, 2019 at 12:34 PM Alexander Murmann > wrote: > > > > > > > For the second part, I am not sure

Re: Geode 1.9 Release Manager

t; Regards > Naba > > On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > wrote: > > > Did we not agreed that we won't be blocking a release to include fixes as > > we are in a fixed release schedule? > > > > > >

Re: Geode 1.9 Release Manager

of new issues being introduced? Thoughts? Thank you, Sai for taking over! On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda wrote: > I volunteer to be the release manager for 1.9. > > Sai > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann > wrote: > > > If there are

Re: Geode 1.9 Release Manager

If there are no other takers, I can act as release manager for 1.9 and will cut a release branch this week. On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann wrote: > Hi everyone! > > February 1st is approaching rapidly which means it's almost time to cut > the 1.9 release. Who i

Re: Very red CI -> Hold merges, please

> > > GfshConsoleModeUnitTest UnitTest failures. > >> > > > > > >> > > > > On Thu, Feb 7, 2019 at 9:57 AM Nabarun Nag > >> wrote: > >> > > > > > >> >

Re: Very red CI -> Hold merges, please

eb 7, 2019 at 9:57 AM Nabarun Nag > wrote: > > > > > > > > > >> FYI, I have just merged a ci timeout fix to increase the timeout > for > > > > >> geode-benchmarks to 4h. This does not influence any geode modules. > >

Very red CI -> Hold merges, please

Hi folks, Our CI is very red since ~24 hours . It looks like a substantial new issue was introduced. Can we hold off on merging new changes to the develop branch till this issue is

Geode 1.9 Release Manager

Hi everyone! February 1st is approaching rapidly which means it's almost time to cut the 1.9 release. Who is interested in being the release manager for 1.9? Thank you!

Re: [Proposal] Change default gemfire.memoryEventTolerance from 1 to 0

Geode 2.0, since it is a behavior change and apparently there are > several > >> config parameters for which we'd like to change the default, but we > pushed > >> it to 2.0. I don't feel super strongly either way. Do you want to > reply > >> to this thread or talk to Alex

Re: [Proposal] Change default gemfire.memoryEventTolerance from 1 to 0

Ryan, thank you so much for the great explanation of your proposal! This seems very sound and you and David got me convinced that it's the right thing to change the default. To me the question now is one of timing. Is this something we can change in a minor release or do we have to wait for Geode

Re: Geode 1.8.0 maven repository is missing sources and javadoc jars

se.proofpoint.com/v2/url?u=https-3A__docs.gradle.org_current_userguide_publishing-5Fmaven.html=DwIFaQ=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw=8M4XmygR-osgvDf8FLkB4n2RvfRhwyzAlOKrA4FtaMg=bYynbqFa-3l4TVUv4MYWqwOfv9JX2mUXDmoJC99epyw=EV0YYGiuNbQX3rGXJF25KLeZiDQEr1VBK1CttR8TJj8= > >> < > >> &g

Re: Geode 1.8.0 maven repository is missing sources and javadoc jars

nse. If we can put the > missing jars in place manually for 1.8.0 that should be sufficient. > > -Owen > > > On Dec 21, 2018, at 9:16 AM, Alexander Murmann > wrote: > > > > I confirmed what we upload to the Nexus staging site again with both 1.7 > > and 1

Re: Geode 1.8.0 maven repository is missing sources and javadoc jars

I confirmed what we upload to the Nexus staging site again with both 1.7 and 1.8. I think we must have stopped uploading these files when we switched to the maven-publish plugin as part of GEODE-5597. Can someone who worked on the recent build changes please take a look? I created GEODE-6235 to

Re: Geode 1.8.0 maven repository is missing sources and javadoc jars

Thank you for catching this Brian! I will take a look and see how we can address this. On Thu, Dec 20, 2018 at 3:21 PM Brian Rowe wrote: > The maven repository for 1.8.0 seems to be missing the 1.8.0 source jars. > This means people using an IDE can't download these jars automatically to > see

[ANNOUNCE] Apache Geode 1.8.0

possible. Regards, Alexander Murmann on behalf of the Apache Geode team

Re: Default branch for geode-examples

I agree that there is a conflict here of what might be most usable for users vs. developers contributing to the geode-examples repo. No matter which route we go down, we should improve guidance. If we keep master the default, I +1 Owen's suggestion of amending the template. If we make develop the

Re: [VOTE] Apache Geode 1.8.0 RC2

It's past the announced deadline and we have enough votes to close the vote. Voting status == +1: 5 votes. PMC members: * Anthony Baker * Ernest Burghardt * Sai Boorlagadda * Nabarun Nag Committers: * Ryan McMahon -0: 2 votes * Dan Smith * Jacob Barrett -1: zero votes The

Re: [VOTE] Apache Geode 1.8.0 RC2

A reminder for everyone that the vote is scheduled to end tonight. Please verify and vote! @Galen I'll take a look and fix the handwritten note.

Re: [VOTE] Apache Geode 1.8.0 RC2

ball seems to have a lot of files that > aren't in source control. See attached: > > > > -Dan > > > >> On Wed, Dec 5, 2018 at 6:19 PM Alexander Murmann > wrote: > >> Hi Apache Geode community, > >> > >> Below you find all the information for

[VOTE] Apache Geode 1.8.0 RC2

Hi Apache Geode community, Below you find all the information for the the second release candidate of Geode 1.8.0. All packaging issues related to Geode native should be resolved in this candidate. Everything else is unchanged. Please review and provide feedback, so that the vote can end by the

Re: PowerMock and mock ClassLoader

+1 to Galen's point. We already follow a PR process and if a committer bypasses that to sneak PowerMock back in, it seems like we have much larger problems. On Wed, Dec 5, 2018 at 10:35 AM Galen O'Sullivan wrote: > Can we just remove PowerMock from our dependencies and skip the rule? I'd > like

Re: [VOTE] Apache Geode 1.8.0 RC1

parts of the release - I think the java bits look okay > > now. I dug up the old email conversation and we did agree to remove the > zip > > distribution. The new signatures look good. > > > > -Dan > > > > > > > > On Mon, Dec 3, 2018 at 1

Re: [VOTE] Apache Geode 1.8.0 RC1

[3] > > > > > > Regarding SHA512 vs SHA256 - we should probably just move everything to > > > SHA512 in the future. > > > > > > [1] https://dist.apache.org/repos/dist/dev/geode/1.8.0.RC1/ > > > [2] https://www.apache.org/dist/geode/1.7.0/ >

Re: [VOTE] Apache Geode 1.8.0 RC1

e release > apache-geode-1.8.0-src. > > Apologies if these changes are expected. > > Regards > Nabarun Nag > > > > > On Fri, Nov 30, 2018 at 5:38 PM Alexander Murmann > wrote: > > > Hi everyone, > > > > Per above discussion the release now contains Ge

Re: [VOTE] Apache Geode 1.8.0 RC1

ubproject with a separate PMC and a viable community. > > @Alexander, I don’t think you need to issue a new release candidate. Just > add the geode-native source distribution and update the VOTE email. > > > Anthony > > > > On Nov 30, 2018, at 8:08 AM, Alexan

Re: [VOTE] Apache Geode 1.8.0 RC1

: > Is there a reason the geode-native repo was not included in the release? > > Anthony > > > > On Nov 29, 2018, at 11:15 PM, Alexander Murmann > wrote: > > > > Hello Geode dev community! > > > > I am happy to announce the first release candidate for Apache Geode

[VOTE] Apache Geode 1.8.0 RC1

Hello Geode dev community! I am happy to announce the first release candidate for Apache Geode 1.8.0! Thanks to all the community members for their contributions to this release! Please review and give your feedback! The deadline is the end of day Dec. 4th 2018. It resolves 162 issues on Apache

Re: Adding index for Like operartor

Hi, Have you thought about using the built-in Lucene functionality for this? Fuzzy text search is exactly what it's made for. On Mon, Nov 26, 2018 at 12:15 PM anjana_nair wrote: > > Hi, > > I would like to add an index to key (keyindex) and the query executed is > going to be like > >

Re: Release branch for Apache Geode 1.8.0 has been cut

Thanks, > Ryan > > On Thu, Nov 15, 2018 at 10:19 AM Alexander Murmann > wrote: > > > Ryan, Jason & Nabarun, these all look like critical issues to me that we > > should address in 1.8 to not introduce a regression. If nobody else has > an > > objection, I am fi

Release 1.8.0 pipeline issue

Hi community, With the fix that Owen contributed the build on the 1.8.0 release pipeline is passing. However, the PublishArtifacts job is failing with the below error: > > Failed to publish publication 'maven' to repository 'maven' > >

Re: Geode 1.8 release pipeline

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

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

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

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

Re: [DISCUSS] LGTM on pull requests

I don't have strong opinions on this, but I am always suspect of CI jobs that indicate quality that only run periodically. If the job discovers something that needs improvement who is going to do the work and when? On Fri, Nov 9, 2018 at 2:36 PM Kirk Lund wrote: > Well, we could run it

Re: [DISCUSS] Disable merge for failing pull requests

+1 On Fri, Nov 9, 2018 at 12:58 PM Robert Houghton wrote: > +1 > > On Fri, Nov 9, 2018, 12:55 Dan Smith > > Hi all, > > > > Kirks emails reminded me - I think we are at the point now with our PR > > checks where we should not be merging anything to develop that doesn't > pass > > all of the PR

Release branch for Apache Geode 1.8.0 has been cut

Hello everyone, As discussed previously created a new release branch for Apache Geode 1.8.0 - "release/1.8.0" Please do review and raise any concern with the release branch. If no concerns are raised, we will start with the voting for the release candidate soon. This also means that all tickets

Permissions for Docker & JIRA

Hi everyone, In order to perform all necessary steps to release 1.8.0, I need the following permissions: * Admin permissions for JIRA (username "amurmann") * Upload permissions for Docker Hub (username "ajmurmann") Thank you!

Re: [DISCUSS] Cutting 1.8 release branch

; >> I would like to get this PR in the release: > > >> https://github.com/apache/geode/pull/2757 > > >> >> > > >> >> I'm testing the merge to develop now > > >> >> > > >> >> > > >> >> On 11/1/18 1:18 PM, Sai Boorlag

Re: [DISCUSS] Cutting 1.8 release branch

by having timed releases. Does that make sense? On Thu, Nov 1, 2018 at 12:45 PM Sai Boorlagadda wrote: > I would like to resolve GEODE-5338 as it is currently waiting for > doc update. > > Sai > > On Thu, Nov 1, 2018 at 10:00 AM Alexander Murmann > wrote: > > >

[DISCUSS] Cutting 1.8 release branch

Hi everyone, It's time to cut the release branch, since we are moving to time based releases. Are there any reasons why a release branch should not be cut as soon as possible?

Re: Geode 1.8 Release Manager

I am happy to take on the role for the 1.8 release. On Wed, Oct 31, 2018 at 8:58 AM Dan Smith wrote: > We are coming up on the date where we said we would start the 1.8 release > (Nov 1st). > > Any volunteers to be release manager for this release? > > -Dan >

Re: [DISCUSS] Java 11 jobs in the pipeline

unhide each one as it gets fixed? Or wait for 100% green and then > unhide them all at once? Either way that’s a lot of PRs just for hiding > and un-hiding. > > Even better, feel free to help get to green by picking up a subtask of > GEODE-3 <https://issues.apache.org/jira/browse/G

Re: [DISCUSS] Java 11 jobs in the pipeline

+1 to keeping them off the main tab. Having red jobs that aren't actionable will train us to ignore red jobs. On Wed, Oct 10, 2018 at 2:13 PM Dan Smith wrote: > I feel like it would be better to keep the Java 11 jobs off of the main tab > in the pipeline until they are actually working. In the

Re: [VOTE] Time-based release schedule for minor releases

Sai, I think what you are saying is theoretically 100% correct. As Anthony points out in practice we'd never go for three months without a single feature. I think it makes sense to agree to aim for the quarterly release being a minor release as opposed to aiming for a patch or major. If we aimed

Re: [VOTE] Time-based release schedule for minor releases

king about here. > > I think we need a new proposal for Major / Minor / Maintenance release > definitions. That's what we should be voting on. > > > > On 10/8/18 2:24 PM, Alexander Murmann wrote: > > Hi everyone, > > > > As discussed in "Predictable minor re

[VOTE] Time-based release schedule for minor releases

Hi everyone, As discussed in "Predictable minor release cadence", I'd like us to find agreement on releasing a new minor version every three months. There are more details in the other thread and I should have captured everything relevant on the wiki:

Re: [DISCUSS] Predictable minor release cadence

Hi all, Given the overwhelmingly positive response, I added a release schedule page to the wiki: https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule Given the many "+1"s in this thread, can this be seen as agreed or do we need a formal [VOTE] thread? On Mon, Oct 8, 2018 at 1:34

Re: [DISCUSS] Predictable minor release cadence

from the past release history we had difficulty in > >>>>> achieving that, either the features are not completely ready or the > >>>>> bug-fixes have taken more time. We need verify what is right for > >> Apache > >>>>> Geode,

Re: [DISCUSS] Predictable minor release cadence

ill, > > but I guess we do seem to keep finding issues after the branch is cut. > > > > -Dan > > > > On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann > > wrote: > > > > > Hi everyone, > > > > > > I want to propose shipping Geode

[DISCUSS] Predictable minor release cadence

Hi everyone, I want to propose shipping Geode on a regular cadence. My concrete proposal is to ship Geode every 3 months on the first weekday. To make sure we hit that date we would cut the release 1 months prior to that day. *Why?* Knowing on what day the release will get cut and on what day we

Re: [VOTE] Apache Geode 1.7.0 RC2

+ 1 verified clean build verified green pipeline verified basic functionality On Tue, Oct 2, 2018 at 11:54 AM Dan Smith wrote: > +1 > > Ran geode-release-check. Verified pipeline is green. Looks good! > > -Dan > > On Tue, Oct 2, 2018 at 11:50 AM Anthony Baker wrote: > > > +1 > > > > -

Re: [discuss] Should we evaluate at commit messages as part of PR review?

t; GEODE-: polishing stuff > > GEODE-: CompositePropertySourceTest is failing intermittently > > > > Just to be clear, these last 5 are examples of how you should NOT word > the > > commit message. > > > > On Fri, Sep 14, 2018 at 12:11 PM, Alexander Murmann &g

Re: [discuss] Should we evaluate at commit messages as part of PR review?

I do find it very helpful to have the ticket number at the beginning of the title. It makes it really easy to scan the output of `git log --oneline` or GitX to see what tickets happened recently or since a certain tag. On Fri, Sep 14, 2018 at 11:55 AM, Bradford Boyle wrote: > How would people

Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created

t; > > me where .buildinfo is intended to be consumed. > > > > > > > > On Wed, Sep 12, 2018 at 3:08 PM, Nabarun Nag > wrote: > > > > > > > > > Yes Alexander, we are still waiting on the build info reverts from > > > > Patrick, &g

<    1   2   3   >