Re: [DISCUSS] Blocking merge button in PR

2019-10-18 Thread Alexander Murmann
+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?

2019-10-18 Thread Alexander Murmann
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

2019-10-18 Thread Alexander Murmann
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

2019-09-26 Thread Alexander Murmann
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: Propose including GEODE-7085 in 1.10

2019-08-26 Thread Alexander Murmann
+1 While it's not new, it's critical On Mon, Aug 26, 2019 at 10:38 AM Juan José Ramos wrote: > +1 > > On Mon, Aug 26, 2019 at 6:36 PM Dan Smith wrote: > > > Hi, > > > > I'd like to propose including the fixes for GEODE-7085 into 1.10 (SHA's > > below). This is not a new issue, but it does

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

2019-08-20 Thread Alexander Murmann
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

2019-08-19 Thread Alexander Murmann
+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

2019-08-15 Thread Alexander Murmann
+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?

2019-07-30 Thread Alexander Murmann
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?

2019-07-30 Thread Alexander Murmann
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?

2019-07-29 Thread Alexander Murmann
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?

2019-07-26 Thread Alexander Murmann
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?

2019-07-25 Thread Alexander Murmann
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?

2019-07-22 Thread Alexander Murmann
.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?

2019-07-22 Thread Alexander Murmann
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?

2019-07-22 Thread Alexander Murmann
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

2019-07-12 Thread Alexander Murmann
." 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

2019-06-26 Thread Alexander Murmann
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

2019-06-24 Thread Alexander Murmann
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

2019-06-24 Thread Alexander Murmann
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

2019-06-24 Thread Alexander Murmann
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

2019-06-24 Thread Alexander Murmann
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

2019-06-13 Thread Alexander Murmann
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

2019-06-05 Thread Alexander Murmann
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

2019-06-05 Thread Alexander Murmann
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

2019-05-31 Thread Alexander Murmann
+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

2019-05-31 Thread Alexander Murmann
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

2019-05-31 Thread Alexander Murmann
+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

2019-04-15 Thread Alexander Murmann
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

2019-04-03 Thread Alexander Murmann
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

2019-04-03 Thread Alexander Murmann
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

2019-03-20 Thread Alexander Murmann
; 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

2019-03-20 Thread Alexander Murmann
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

2019-03-19 Thread Alexander Murmann
+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

2019-03-01 Thread Alexander Murmann
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

2019-02-28 Thread Alexander Murmann
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

2019-02-20 Thread Alexander Murmann
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

2019-02-20 Thread Alexander Murmann
> > 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

2019-02-14 Thread Alexander Murmann
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

2019-02-14 Thread Alexander Murmann
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

2019-02-14 Thread Alexander Murmann
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

2019-02-13 Thread Alexander Murmann
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

2019-02-07 Thread Alexander Murmann
> > > GfshConsoleModeUnitTest UnitTest failures. > >> > > > > > >> > > > > On Thu, Feb 7, 2019 at 9:57 AM Nabarun Nag > >> wrote: > >> > > > > > >> >

Re: Very red CI -> Hold merges, please

2019-02-07 Thread Alexander Murmann
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

2019-02-07 Thread Alexander Murmann
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

2019-01-29 Thread Alexander Murmann
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

2019-01-24 Thread Alexander Murmann
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

2019-01-23 Thread Alexander Murmann
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

2018-12-31 Thread Alexander Murmann
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

2018-12-21 Thread Alexander Murmann
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

2018-12-21 Thread Alexander Murmann
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

2018-12-20 Thread Alexander Murmann
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

2018-12-12 Thread Alexander Murmann
possible. Regards, Alexander Murmann on behalf of the Apache Geode team

Re: Default branch for geode-examples

2018-12-12 Thread Alexander Murmann
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

2018-12-11 Thread Alexander Murmann
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

2018-12-10 Thread Alexander Murmann
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

2018-12-06 Thread Alexander Murmann
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

2018-12-05 Thread Alexander Murmann
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

2018-12-05 Thread Alexander Murmann
+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

2018-12-03 Thread Alexander Murmann
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

2018-12-03 Thread Alexander Murmann
[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

2018-12-03 Thread Alexander Murmann
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

2018-11-30 Thread Alexander Murmann
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

2018-11-30 Thread Alexander Murmann
: > 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

2018-11-29 Thread Alexander Murmann
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

2018-11-26 Thread Alexander Murmann
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

2018-11-21 Thread Alexander Murmann
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

2018-11-15 Thread Alexander Murmann
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: Release branch for Apache Geode 1.8.0 has been cut

2018-11-15 Thread Alexander Murmann
ween WAN sites, but it was found the fix introduced > >> several other inconsistencies. > >> > >> > >> > https://github.com/apache/geode/commit/aab0198e8478d4246042b2eb889c8ce7e28bb52e > >> *Reason: *This fixes a race condition in the QueryMonitor

Re: Geode 1.8 release pipeline

2018-11-13 Thread Alexander Murmann
> > > 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?

2018-11-12 Thread Alexander Murmann
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

2018-11-12 Thread Alexander Murmann
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

2018-11-12 Thread Alexander Murmann
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

2018-11-09 Thread Alexander Murmann
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

2018-11-09 Thread Alexander Murmann
+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

2018-11-08 Thread Alexander Murmann
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

2018-11-08 Thread Alexander Murmann
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: Our use of Jira "Fix Version/s"

2018-11-07 Thread Alexander Murmann
Kirk, I think most of us are in agreement that it works as you are describing. The notes for the release manager also assume that we are all following this process. However, I also was unable to find something obvious in the wiki. The closest is the "JIRA Guidelines" page

Re: [DISCUSS] Cutting 1.8 release branch

2018-11-02 Thread Alexander Murmann
; >> 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

2018-11-01 Thread Alexander Murmann
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

2018-11-01 Thread Alexander Murmann
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

2018-11-01 Thread Alexander Murmann
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

2018-10-11 Thread Alexander Murmann
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

2018-10-10 Thread Alexander Murmann
+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

2018-10-10 Thread Alexander Murmann
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

2018-10-09 Thread Alexander Murmann
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

2018-10-08 Thread Alexander Murmann
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

2018-10-08 Thread Alexander Murmann
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

2018-10-05 Thread Alexander Murmann
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

2018-10-04 Thread Alexander Murmann
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

2018-10-04 Thread Alexander Murmann
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

2018-10-02 Thread Alexander Murmann
+ 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?

2018-09-14 Thread Alexander Murmann
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?

2018-09-14 Thread Alexander Murmann
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

2018-09-12 Thread Alexander Murmann
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

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

2018-09-12 Thread Alexander Murmann
git hooks as a way to enforce policy > > https://git-scm.com/book/en/v2/Customizing-Git-An-Example- > > Git-Enforced-Policy > > ? > > > > *Pulkit Chandra* > > > > > > On Wed, Sep 12, 2018 at 2:46 PM Alexander Murmann > > wrote: > > >

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

2018-09-12 Thread Alexander Murmann
o is now > > missing? And are we certain that it was indeed pulling from .buildinfo > and > > not the aforementioned GemFireVersion.properties? > > > > On Wed, Sep 12, 2018 at 10:11 AM, Alexander Murmann > > > wrote: > > > > > Hi everyone, > &

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

2018-09-12 Thread Alexander Murmann
Hi everyone, We have a wiki page that discusses why good commit messages matter and links to a even better article on the topic. In addition to what's described in those documents, better commit messages also would make it

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

2018-09-12 Thread Alexander Murmann
hub.com/apache/ > geode/pull/2457> > > > > On Sep 11, 2018, at 3:16 PM, Alexander Murmann > wrote: > > > > What's the consensus on the version info issue Anthony is calling out? > Does > > anyone have a proposal for fixing this for this release? Should Nabarun >

Re: Instructions for Setting Up IntelliJ

2018-09-11 Thread Alexander Murmann
+1 for putting it into the repo. I am fine with either putting it into README.md or linking form there. On Tue, Sep 11, 2018 at 4:33 PM, Ryan McMahon wrote: > Kirk - I have a PR open here which has the "Setting up IntelliJ" section > you've described: > https://github.com/apache/geode/pull/2456

  1   2   >