Re: Update on CI migration
There is no particular contact. I was o. The build infra slack and asked about it and someone replied saying they are working on making custom instances available to projects. Sai On Sun, Feb 11, 2024, 4:43 AM Kirk Lund wrote: > Hi Sai, > > I'd like to help out on this or take it over. If you have time, please loop > me in with any contact info for the infra team, details about what is > currently disabled, details about what is currently blocked (just running > Windows tests?), and I'll try reaching out to them again for some help. > > Thanks, > Kirk > > On Wed, Jul 19, 2023 at 3:08 PM Mark Bretl wrote: > > > Thanks for the update Sai. Your work is much appreciated! > > > > --Mark > > > > On Wed, Jul 12, 2023 at 9:02 PM Sai Boorlagadda < > sai.boorlaga...@gmail.com > > > > > wrote: > > > > > I found out that the infra team is working actively on providing larger > > > instances for jobs in Github actions. I will resume my work as soon I > see > > > they have an option. > > > > > > Other than that I couldn't keep up contributing to this project in the > > last > > > few weeks. > > > > > > Sai > > > > > >
Re: Contributing to Geode
Oliver, Thanks a lot for your contribution and nudging us on the email, we aren't been active. I will review it soon and get back to you. Geode is actively seeking contributors and would love to have you and your colleagues start contributing. If it's possible, could you outline what are the top items that your team is interested in? As of now my main focus is to migrate from concourse pipelines into Github actions. Sai On Thu, Sep 21, 2023, 8:55 AM VERMEULEN Olivier wrote: > Hello, > > I would like to start contributing to Geode. > I actually already opened a PR a few days ago: > https://github.com/apache/geode/pull/7884 > Can someone approve the workflows and review it ? > > More globally my company is interested in contributing security and bug > fixes. > So some of my fellow developers might also want to join. > How should we proceed ? > > Thanks, > Olivier > *** > This e-mail contains information for the intended recipient only. It may > contain proprietary material or confidential information. Its content and > any attachment hereto are strictly confidential and must not be disclosed > to any unauthorized third party. If you are not the intended recipient, > please delete this email and any attachment and notify us immediately. > Murex cannot guarantee that it is virus free and accepts no responsibility > for any loss or damage arising from its use. If you have received this > e-mail in error please notify immediately the sender and delete the > original email received, any attachments and all copies from your system. >
Update on CI migration
I found out that the infra team is working actively on providing larger instances for jobs in Github actions. I will resume my work as soon I see they have an option. Other than that I couldn't keep up contributing to this project in the last few weeks. Sai
Re: [DRAFT] Geode Board Report For May 2023
Thanks, Mark, looks good to me. Sai On Mon, 8 May 2023 at 13:48, Mark Bretl wrote: > Here is the draft of the board report for the month of May 2023, I will > submit to the board on Wednesday, May 10 > > ## Description: > The mission of Apache Geode is the creation and maintenance of software > related > to a data management platform that provides real-time, consistent access to > data-intensive applications throughout widely distributed cloud > architectures. > > ## Issues: > For the work of moving CI to GitHub Actions, we are waiting on larger VMs > from > Infra for some of the testing pipelines. No ETA has been provided. > > ## Membership Data: > Apache Geode was founded 2016-11-15 (6 years ago) > There are currently 118 committers and 31 PMC members in this project. > While the total membership of the PMC is 31, there are less than 10 active > members. > The Committer-to-PMC ratio is roughly 4:1. > > Community changes, past quarter: > - No new PMC members. Last addition was Calvin Kirs on 2022-11-14. > - No new committers. Last addition was Calvin Kirs on 2022-11-15. > > ## Project Activity: > 1.15.1 was released on 2022-10-10. > Very little activity on mailing lists and source commits the past few > months. We are still working on migrating the Continuous Integration system > over to GitHub actions. > > ## Community Health: > The pulse is low. Besides the volunteers who have joined the PMC, we have > not had any growth with contributors to the project. Currently we have two > individuals working small amounts, so need to find ways to get the word out > for more individuals to join the community. This was also an issue when the > majority of contributors were from the same company. >
Re: Update on DUnit test pipeline on Github actions
Mark, There isn't any specific ticket I created for larger VMs. I heard there is an initiative within the infra team to sponsor bigger VMs than the free tier we use for Github actions, so we have to wait until that initiative picks up steam. On Thu, 4 May 2023 at 13:58, Mark Bretl wrote: > Sai, > > Do you have an INFRA Jira ticket? > > --Mark > > On Tue, May 2, 2023 at 9:53 AM Sai Boorlagadda > wrote: > > > There is no ETA provided. > > > > Sai > > > > On Sat, 29 Apr 2023 at 14:47, Kirk Lund wrote: > > > > > Did INFRA give any hint as to when they might provide the bigger VMs? > > > > > > On Mon, Apr 17, 2023 at 8:24 PM Sai Boorlagadda < > > sai.boorlaga...@gmail.com > > > > > > > wrote: > > > > > > > I went ahead and merged github workflow jobs that tests > > > > WAN, CQ, Assembly and Managment distributed tests. > > > > > > > > Free workers VMs has 2 cores and tuning any sort of > > > > parameters isn't speeding up geode-core DUnits. > > > > > > > > Talking to infra team found that infra is working on providing > > > > self-hosted (sponsored by infra) that are much bigger VMs. > > > > > > > > So until such VMs are available I am going to find if there are any > > > > alternate solution. > > > > > > > > On Thu, 13 Apr 2023 at 15:08, Kirk Lund wrote: > > > > > > > > > I see that there is at least one person concerned about DUnit tests > > > > > requiring longer timeouts. This is the current situation with an > > > unknown > > > > > number of the DUnit tests. One possibility is to move the worst > > > offenders > > > > > to a new src set within geode-core and then give that its own job > > with > > > a > > > > > larger timeout. The longer term solution is to fix or even rewrite > > some > > > > of > > > > > those tests. Excluding them is also not a viable option as we risk > > > > > losing important test coverage that way. I agree that some of these > > > tests > > > > > need a lot more help than tweaking overall job timeout values, but > > > > without > > > > > a lot more time commitment from contributors that might not be an > > > > > option for some time. > > > > > > > > > > -Kirk > > > > > > > > > > On Thu, Apr 13, 2023 at 3:02 PM Kirk Lund > wrote: > > > > > > > > > > > Is the coreDistributedTests the only dunit job that currently > takes > > > too > > > > > > long? If it is we may want to split that into more than one job. > > > > > > > > > > > > -Kirk > > > > > > > > > > > > On Wed, Apr 12, 2023 at 7:58 PM Sai Boorlagadda < > > > > > sai.boorlaga...@gmail.com> > > > > > > wrote: > > > > > > > > > > > >> All, > > > > > >> > > > > > >> There is an upper bound for job execution time on free workers > > (set > > > > to 6 > > > > > >> hours max[1]), which can be configured beyond 6hrs with a > > > self-hosted > > > > > >> worker. All of our pipeline jobs are using `--max-workers` to > > > > > parallelize > > > > > >> gradle tasks but `testMaxParallelForks` is left to default which > > is > > > > > (1/4th > > > > > >> of the available CPU cores), so primarily due to running only a > > > single > > > > > >> test > > > > > >> in each parallel fork geode-core distribution tests are taking > > more > > > > > than 6 > > > > > >> hours. Other than finding a solution for core distributed tests, > > > most > > > > > >> DUnit > > > > > >> tests are passed[2] by splitting them into individual jobs (WAN, > > CQ, > > > > > >> Lucene, assembly, management). > > > > > >> > > > > > >> Will reach out to infra team and trying playing with > > `--max-workers` > > > > to > > > > > >> parallelize more tests than having to run parallel tests with > in a > > > > fork > > > > > >> would be options. > > > > > >> > > > > > >> I am going to wait for few days to get answers from infra team > > > before > > > > I > > > > > >> can > > > > > >> create a PR to add at least the passing DUnits. > > > > > >> > > > > > >> [1] > > > > > >> > > > > > >> > > > > > > > > > > > > > > > https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration > > > > > >> [2] https://github.com/apache/geode/actions/runs/4639012912 > > > > > >> > > > > > >> Sai > > > > > >> > > > > > > > > > > > > > > > > > > > > >
Re: Update on DUnit test pipeline on Github actions
There is no ETA provided. Sai On Sat, 29 Apr 2023 at 14:47, Kirk Lund wrote: > Did INFRA give any hint as to when they might provide the bigger VMs? > > On Mon, Apr 17, 2023 at 8:24 PM Sai Boorlagadda > > wrote: > > > I went ahead and merged github workflow jobs that tests > > WAN, CQ, Assembly and Managment distributed tests. > > > > Free workers VMs has 2 cores and tuning any sort of > > parameters isn't speeding up geode-core DUnits. > > > > Talking to infra team found that infra is working on providing > > self-hosted (sponsored by infra) that are much bigger VMs. > > > > So until such VMs are available I am going to find if there are any > > alternate solution. > > > > On Thu, 13 Apr 2023 at 15:08, Kirk Lund wrote: > > > > > I see that there is at least one person concerned about DUnit tests > > > requiring longer timeouts. This is the current situation with an > unknown > > > number of the DUnit tests. One possibility is to move the worst > offenders > > > to a new src set within geode-core and then give that its own job with > a > > > larger timeout. The longer term solution is to fix or even rewrite some > > of > > > those tests. Excluding them is also not a viable option as we risk > > > losing important test coverage that way. I agree that some of these > tests > > > need a lot more help than tweaking overall job timeout values, but > > without > > > a lot more time commitment from contributors that might not be an > > > option for some time. > > > > > > -Kirk > > > > > > On Thu, Apr 13, 2023 at 3:02 PM Kirk Lund wrote: > > > > > > > Is the coreDistributedTests the only dunit job that currently takes > too > > > > long? If it is we may want to split that into more than one job. > > > > > > > > -Kirk > > > > > > > > On Wed, Apr 12, 2023 at 7:58 PM Sai Boorlagadda < > > > sai.boorlaga...@gmail.com> > > > > wrote: > > > > > > > >> All, > > > >> > > > >> There is an upper bound for job execution time on free workers (set > > to 6 > > > >> hours max[1]), which can be configured beyond 6hrs with a > self-hosted > > > >> worker. All of our pipeline jobs are using `--max-workers` to > > > parallelize > > > >> gradle tasks but `testMaxParallelForks` is left to default which is > > > (1/4th > > > >> of the available CPU cores), so primarily due to running only a > single > > > >> test > > > >> in each parallel fork geode-core distribution tests are taking more > > > than 6 > > > >> hours. Other than finding a solution for core distributed tests, > most > > > >> DUnit > > > >> tests are passed[2] by splitting them into individual jobs (WAN, CQ, > > > >> Lucene, assembly, management). > > > >> > > > >> Will reach out to infra team and trying playing with `--max-workers` > > to > > > >> parallelize more tests than having to run parallel tests with in a > > fork > > > >> would be options. > > > >> > > > >> I am going to wait for few days to get answers from infra team > before > > I > > > >> can > > > >> create a PR to add at least the passing DUnits. > > > >> > > > >> [1] > > > >> > > > >> > > > > > > https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration > > > >> [2] https://github.com/apache/geode/actions/runs/4639012912 > > > >> > > > >> Sai > > > >> > > > > > > > > > >
Re: Update on DUnit test pipeline on Github actions
I went ahead and merged github workflow jobs that tests WAN, CQ, Assembly and Managment distributed tests. Free workers VMs has 2 cores and tuning any sort of parameters isn't speeding up geode-core DUnits. Talking to infra team found that infra is working on providing self-hosted (sponsored by infra) that are much bigger VMs. So until such VMs are available I am going to find if there are any alternate solution. On Thu, 13 Apr 2023 at 15:08, Kirk Lund wrote: > I see that there is at least one person concerned about DUnit tests > requiring longer timeouts. This is the current situation with an unknown > number of the DUnit tests. One possibility is to move the worst offenders > to a new src set within geode-core and then give that its own job with a > larger timeout. The longer term solution is to fix or even rewrite some of > those tests. Excluding them is also not a viable option as we risk > losing important test coverage that way. I agree that some of these tests > need a lot more help than tweaking overall job timeout values, but without > a lot more time commitment from contributors that might not be an > option for some time. > > -Kirk > > On Thu, Apr 13, 2023 at 3:02 PM Kirk Lund wrote: > > > Is the coreDistributedTests the only dunit job that currently takes too > > long? If it is we may want to split that into more than one job. > > > > -Kirk > > > > On Wed, Apr 12, 2023 at 7:58 PM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > > wrote: > > > >> All, > >> > >> There is an upper bound for job execution time on free workers (set to 6 > >> hours max[1]), which can be configured beyond 6hrs with a self-hosted > >> worker. All of our pipeline jobs are using `--max-workers` to > parallelize > >> gradle tasks but `testMaxParallelForks` is left to default which is > (1/4th > >> of the available CPU cores), so primarily due to running only a single > >> test > >> in each parallel fork geode-core distribution tests are taking more > than 6 > >> hours. Other than finding a solution for core distributed tests, most > >> DUnit > >> tests are passed[2] by splitting them into individual jobs (WAN, CQ, > >> Lucene, assembly, management). > >> > >> Will reach out to infra team and trying playing with `--max-workers` to > >> parallelize more tests than having to run parallel tests with in a fork > >> would be options. > >> > >> I am going to wait for few days to get answers from infra team before I > >> can > >> create a PR to add at least the passing DUnits. > >> > >> [1] > >> > >> > https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration > >> [2] https://github.com/apache/geode/actions/runs/4639012912 > >> > >> Sai > >> > > >
Update on DUnit test pipeline on Github actions
All, There is an upper bound for job execution time on free workers (set to 6 hours max[1]), which can be configured beyond 6hrs with a self-hosted worker. All of our pipeline jobs are using `--max-workers` to parallelize gradle tasks but `testMaxParallelForks` is left to default which is (1/4th of the available CPU cores), so primarily due to running only a single test in each parallel fork geode-core distribution tests are taking more than 6 hours. Other than finding a solution for core distributed tests, most DUnit tests are passed[2] by splitting them into individual jobs (WAN, CQ, Lucene, assembly, management). Will reach out to infra team and trying playing with `--max-workers` to parallelize more tests than having to run parallel tests with in a fork would be options. I am going to wait for few days to get answers from infra team before I can create a PR to add at least the passing DUnits. [1] https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration [2] https://github.com/apache/geode/actions/runs/4639012912 Sai
Acceptance tests on Github Actions
I have a PR[1] that adds acceptance tests to the pipeline. I would appreciate a review. Changes: 1) Needed to upgrade testcontainers to the latest version to overcome the 2GB disk space issue causing containers to fail to start 2) Moved a couple of tests as integration tests as they are polluting the test environment by creating a distributed system. Sai 1. https://github.com/apache/geode/pull/7876
Re: Approved your PR Sai
Thanks, Krik. Now we are on to acceptance tests. I got most of it working except two tests: StartLocatorJmxSerialFilterAcceptanceTest. startWithJmxManagerDoesNotConfigureJmxSerialFilter_onJava8 StartServerJmxSerialFilterAcceptanceTest. startWithJmxManagerDoesNotConfigureJmxSerialFilter_onJava8 On Mon, 13 Feb 2023 at 19:36, Kirk Lund wrote: > Sai, > > I approved the only non-draft PR you had waiting for review. Feel free to > ping slack or email me if you have something waiting on me. > > Thanks, > Kirk >
Re: Github actions - Integration tests
Thanks Dan. I choose to remove the test for now. Here is the PR that enables integration tests on linux platform. https://github.com/apache/geode/pull/7872 On Wed, 8 Feb 2023 at 08:34, Dan Smith wrote: > That ConcurrentTestRunnerTest is testing a test utility to see if it can > catch race conditions. We didn't end up using that utility as much as I > thought we might. You could consider just ignoring/deleting that test. > > -Dan > ________ > From: Sai Boorlagadda > Sent: Tuesday, February 7, 2023 5:56 PM > To: dev@geode.apache.org > Subject: Re: Github actions - Integration tests > > !! External Email > > Integration tests pass consistently after configuring the > `--max-workers=12` and by not setting the `testMaxParallelForks` (so it > defaults to max-workers/4), except for one test[1] which is a test called > ConcurrentTestRunnerTest to test the ConcurrentTestRunner. > > This test is expected to fail when an atomic int is modified in parallel > threads. This ensures ConcurrentTestRunner is running in parallel, but > unfortunately, Github actions may be running with a single core > (availableProcessors = 2). The logs are available in the summary section > and saved for up to 5 days. > > Though the available processors are 2 and it seems the atomic int is never > got executed in parallel. Any thoughts? > > @Dan Tagging you as you were the original author to little bit understand > about this test. > > Available processors: 2 > Available processors: 2 > Available processors: 2 > Available processors: 2 > > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Factions%2Fruns%2F4119919022=05%7C01%7Cdasmith%40vmware.com%7C7b2cf42318694513e67208db0977c63d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638114182273485483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=unVvHQh5KW2a9ELRAduFXhGS%2B3ahspCpq1NGP9IFAq8%3D=0 > > > > On Mon, 23 Jan 2023 at 11:05, Sai Boorlagadda > wrote: > > > After working through unit tests and the builds are passing. I am working > > on adding an integration step to the build pipeline. > > > > Looks like there are a few (4 tests) failing[1] on the integration suite. > > Let me know if anyone interested to look into them. It would really good > to > > get integration tests enabled on develop. > > > > Below 4 tests needs to be analyzed and fixed: > > 1) LocatorLauncherJmxSerialFilterPropertyBlankIntegrationTest > > > startDoesNotConfigureJmxSerialFilter_whenPropertyIsBlank_onJava8 > > 2) LocatorLauncherGlobalSerialFilterPropertyEmptyIntegrationTest > > > startDoesNotConfigureGlobalSerialFilter_whenPropertyIsEmpty > > 3) VersionCommandJUnitTest > initializationError > > 4) LoadClusterConfigFromDirInt > canStartWithDeployedJarInClusterConfig > > > > 1. > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Factions%2Fruns%2F3983609395%2Fjobs%2F6829148633=05%7C01%7Cdasmith%40vmware.com%7C7b2cf42318694513e67208db0977c63d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638114182273485483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jIvQuxFsYNFyXEyUuuMVHPdrodXymM9IGYaw4lWIZ2k%3D=0 > > > > Sai > > > > !! External Email: This email originated from outside of the organization. > Do not click links or open attachments unless you recognize the sender. >
Re: Github actions - Integration tests
Integration tests pass consistently after configuring the `--max-workers=12` and by not setting the `testMaxParallelForks` (so it defaults to max-workers/4), except for one test[1] which is a test called ConcurrentTestRunnerTest to test the ConcurrentTestRunner. This test is expected to fail when an atomic int is modified in parallel threads. This ensures ConcurrentTestRunner is running in parallel, but unfortunately, Github actions may be running with a single core (availableProcessors = 2). The logs are available in the summary section and saved for up to 5 days. Though the available processors are 2 and it seems the atomic int is never got executed in parallel. Any thoughts? @Dan Tagging you as you were the original author to little bit understand about this test. Available processors: 2 Available processors: 2 Available processors: 2 Available processors: 2 [1] https://github.com/apache/geode/actions/runs/4119919022 On Mon, 23 Jan 2023 at 11:05, Sai Boorlagadda wrote: > After working through unit tests and the builds are passing. I am working > on adding an integration step to the build pipeline. > > Looks like there are a few (4 tests) failing[1] on the integration suite. > Let me know if anyone interested to look into them. It would really good to > get integration tests enabled on develop. > > Below 4 tests needs to be analyzed and fixed: > 1) LocatorLauncherJmxSerialFilterPropertyBlankIntegrationTest > > startDoesNotConfigureJmxSerialFilter_whenPropertyIsBlank_onJava8 > 2) LocatorLauncherGlobalSerialFilterPropertyEmptyIntegrationTest > > startDoesNotConfigureGlobalSerialFilter_whenPropertyIsEmpty > 3) VersionCommandJUnitTest > initializationError > 4) LoadClusterConfigFromDirInt > canStartWithDeployedJarInClusterConfig > > 1. https://github.com/apache/geode/actions/runs/3983609395/jobs/6829148633 > > Sai >
Re: Buildbot build failing for a long time
It makes sense to remove it and not sure of the intent of this nightly. @gavin sending a PR to delete it. Sai On Thu, 26 Jan 2023 at 13:48, Mark Bretl wrote: > I am not familiar with it and would be in favor to turn it off/delete it > for now. > > --Mark > > On Mon, Jan 23, 2023 at 11:57 AM Gavin McDonald > wrote: > > > > > > > On 2023/01/23 14:59:56 Sai Boorlagadda wrote: > > > Thanks Gavin, > > > > > > This nightly build has been failing for quite a while. I will see > > > whats going on. > > > > > > Devs, Do we know about this nightly build? Any info on the setup and > how > > it > > > is configured? > > > > Your config file lives at:- > > > > https://github.com/apache/infrastructure-bb2/blob/master/geode.py > > > > any changes to it should go live immediately. > > > > I placed the file there as it was transitioned from the old Buildbot > > server to the new. > > > > You can either try and fix it, or delete the file which will remove it > > from the Buildbot config. > > > > Happy to help in any way I can if you feel you would like it fixed. > > > > Gav... > > > > > > > > Sai > > > > > > On Mon, 23 Jan 2023 at 00:58, Gavin McDonald > > wrote: > > > > > > > Hi All, > > > > > > > > https://ci2.apache.org/#/builders/72 > > > > > > > > Has been failing for a long time. can someone investigate please, if > > > > necessary open an INFRA ticket if something is required our end. > > > > > > > > Thanks > > > > > > > > -- > > > > > > > > *Gavin McDonald* > > > > Systems Administrator > > > > ASF Infrastructure Team > > > > > > > > > >
Re: Pullrequest required checks
I have a PR that makes required checks on master same as develop. Need approval. Once github actions are merged, then I will add back in the required checks. https://github.com/apache/geode/pull/7875 On Sun, 22 Jan 2023 at 12:40, Owen Nichols wrote: > Try updating .asf.yaml on master branch to same contents as develop. > > > > *From: *Sai Boorlagadda > *Date: *Sunday, January 22, 2023 at 8:30 AM > *To: *dev@geode.apache.org > *Subject: *Pullrequest required checks > > !! External Email > > Could someone have info regarding how the required checks are enabled on a > Pull Request? > > In the process of setting up the Github Actions, I see there are still > Concourse CI checks as "required" eg: on this PR[1] > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7870=05%7C01%7Conichols%40vmware.com%7C618fc3c1c60b470a337108dafc95ebdb%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638100018100622080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=f0X9PKhKPxJY%2BMEidZAqYnDAj3Q8Z3F5OzDH%2BgiuSLE%3D=0 > > Thanks > Sai > > !! External Email: This email originated from outside of the organization. > Do not click links or open attachments unless you recognize the sender. >
Re: isolated test plugin
Seems like the execute_tests.sh hasn't been updated to remove setting the environment variables after we removed usage of dockerized tests plugin. Sai On Mon, 23 Jan 2023 at 21:49, Sai Boorlagadda wrote: > Could someone provide context on how integration & dunit tests are run in > CI? > > I remember geode had dockerized test plugin that isolates test execution. > But looking at this PR[1] it seems we removed usage of that plugin and have > a customized mechanism to allocate ports so that we don't need to run tests > in docker containers. > > But the CI source (execute_tests.sh) seems to still pass docker > image -PdunitDockerUser=geode -PdunitDockerImage=\$(docker images. So do we > need to run these tests in docker containers? > > 1. https://github.com/apache/geode/pull/6720 > > Sai >
isolated test plugin
Could someone provide context on how integration & dunit tests are run in CI? I remember geode had dockerized test plugin that isolates test execution. But looking at this PR[1] it seems we removed usage of that plugin and have a customized mechanism to allocate ports so that we don't need to run tests in docker containers. But the CI source (execute_tests.sh) seems to still pass docker image -PdunitDockerUser=geode -PdunitDockerImage=\$(docker images. So do we need to run these tests in docker containers? 1. https://github.com/apache/geode/pull/6720 Sai
Re: Pullrequest required checks
Thanks, Owen and Michael. Will check the .asf.yaml file. On Mon, 23 Jan 2023 at 10:05, Michael Oleske wrote: > Quick addendum, it looks like you would have to update the master branch > as well as develop. As the master branch< > https://github.com/apache/geode/blob/master/.asf.yaml#L39> has more > required checks for reason. > > -michael > > From: Michael Oleske > Sent: Monday, January 23, 2023 09:20 > To: dev@geode.apache.org > Subject: Re: Pullrequest required checks > > !! External Email > > I believe the required checks are setup in the .asf.yaml file here< > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2F.asf.yaml%23L35=05%7C01%7Cmoleske%40vmware.com%7Ca08669bc99d24832dd5e08dafd662876%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638100912455129730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=5bKCtDt7LEO1WxYwtH5rtFCch5wJzjuk6uHGx3yQ9lY%3D=0>. > I would hope just deleting those lines would remove the existing checks and > in your migrate to github actions pr you could change the required checks. > I would hope this doesn't need a vote as those current required check's > pipelines seem to all have been removed. > > -michael > > From: Sai Boorlagadda > Sent: Sunday, January 22, 2023 08:28 > To: dev@geode.apache.org > Subject: Pullrequest required checks > > !! External Email > > Could someone have info regarding how the required checks are enabled on a > Pull Request? > > In the process of setting up the Github Actions, I see there are still > Concourse CI checks as "required" eg: on this PR[1] > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7870=05%7C01%7Cmoleske%40vmware.com%7Ca08669bc99d24832dd5e08dafd662876%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638100912455129730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=4OndODLKhyumfbU330712kWLSgrc%2FkcGRh%2Fu4GQeLcs%3D=0 > > Thanks > Sai > > !! External Email: This email originated from outside of the organization. > Do not click links or open attachments unless you recognize the sender. >
Github actions - Integration tests
After working through unit tests and the builds are passing. I am working on adding an integration step to the build pipeline. Looks like there are a few (4 tests) failing[1] on the integration suite. Let me know if anyone interested to look into them. It would really good to get integration tests enabled on develop. Below 4 tests needs to be analyzed and fixed: 1) LocatorLauncherJmxSerialFilterPropertyBlankIntegrationTest > startDoesNotConfigureJmxSerialFilter_whenPropertyIsBlank_onJava8 2) LocatorLauncherGlobalSerialFilterPropertyEmptyIntegrationTest > startDoesNotConfigureGlobalSerialFilter_whenPropertyIsEmpty 3) VersionCommandJUnitTest > initializationError 4) LoadClusterConfigFromDirInt > canStartWithDeployedJarInClusterConfig 1. https://github.com/apache/geode/actions/runs/3983609395/jobs/6829148633 Sai
Re: Buildbot build failing for a long time
Thanks Gavin, This nightly build has been failing for quite a while. I will see whats going on. Devs, Do we know about this nightly build? Any info on the setup and how it is configured? Sai On Mon, 23 Jan 2023 at 00:58, Gavin McDonald wrote: > Hi All, > > https://ci2.apache.org/#/builders/72 > > Has been failing for a long time. can someone investigate please, if > necessary open an INFRA ticket if something is required our end. > > Thanks > > -- > > *Gavin McDonald* > Systems Administrator > ASF Infrastructure Team >
geode-benchmarks migrate to GH Action
Could someone review and approve this PR? https://github.com/apache/geode-benchmarks/pull/170/files Sai
apiCheck - gradle task japicmp
Could some one explain me what is this gradle task requirement? I see that we are running this japicmp only for JDK 11. Does it build using 11? Sai
Simple build pipeline for develop
All, I would appreciate a review of this PR[1] that adds a GitHub action workflow to build and unit test develop and runs it on every PR to develop. This is just the beginning of this migration work and we would like to merge it as soon as possible. Will follow up with apiCheck and adding windows unit tests. Thanks, Sai [1] https://github.com/apache/geode/pull/7870
Pullrequest required checks
Could someone have info regarding how the required checks are enabled on a Pull Request? In the process of setting up the Github Actions, I see there are still Concourse CI checks as "required" eg: on this PR[1] [1] https://github.com/apache/geode/pull/7870 Thanks Sai
Re: rewrite CI pipeline
Seems like there are some environmental-related differences. On Thu, 8 Dec 2022 at 18:56, Sai Boorlagadda wrote: > Kirk, > > I updated the github pipeline[1] to run unit tests across multiple JDK > implementations on the different OS to figure out if there are any JDK/OS > differences and seems like there are common tests that fail on > GithubActions. > > Sai > [1] > https://github.com/apache/geode/actions/runs/3519795068/jobs/5900102040 > > On Thu, 8 Dec 2022 at 12:18, Kirk Lund wrote: > >> Hey Sai, >> >> Quick update on this. On my Mac, I'm able to build and run all unit tests >> without any failures using the very latest Oracle Java 8 JDK. I'll try >> OpenJDK and Azul next. >> >> I do have a number of IntegrationTest failures. Most are BindException >> failures because some process is already bound to a port. One or two >> failures appear to be DNS related which may require either editing >> /etc/hosts or changing the test. Will update again after debugging these >> more. >> >> Cheers, >> Kirk >> >> On Fri, Dec 2, 2022 at 12:58 PM Kirk Lund wrote: >> >>> Sai, I'll be able to spend some time this weekend on these failing >>> tests. Hope to have some more news to share soon! >>> >>> -Kirk >>> >>> On Mon, Nov 21, 2022 at 4:35 PM Sai Boorlagadda < >>> sai.boorlaga...@gmail.com> wrote: >>> >>>> I was thinking it has to do with either JDK or ubuntu. I also tried >>>> 'temurin' >>>> and there were different sets of errors. So to see if the devs can shed >>>> some light on JDK dependency or any prior knowledge on choosing >>>> bellsoft distribution. >>>> >>>> Sai >>>> >>>> On Mon, 21 Nov 2022 at 16:25, Kirk Lund wrote: >>>> >>>> > It's also possible that these issues are specific to using OpenJDK 8 >>>> or >>>> > Ubuntu. I thought we were building and testing with CentOS before. >>>> > >>>> > On Mon, Nov 21, 2022 at 4:20 PM Kirk Lund wrote: >>>> > >>>> > > Looks like membership errors. Membership went through extensive >>>> changes >>>> > to >>>> > > be modularized as geode-membership, and VMware was still fixing >>>> some bugs >>>> > > in it when I left. These could be really difficult to solve for >>>> those of >>>> > us >>>> > > who have no experience with the new membership. >>>> > > >>>> > > I wonder if we could engage VMware for a little more help on these >>>> > > failures before they depart entirely? >>>> > > >>>> > > Last I heard there were also problems with using OpenJDK 8 but I >>>> don't >>>> > > know the details. VMware was using Liberica JDK 8 from Bellsoft. We >>>> may >>>> > > also need VMware to explain what the issue was with OpenJDK 8 so we >>>> can >>>> > > figure out what to do about it. >>>> > > >>>> > > On Mon, Nov 21, 2022 at 3:29 PM Sai Boorlagadda < >>>> > sai.boorlaga...@gmail.com> >>>> > > wrote: >>>> > > >>>> > >> Hello devs, >>>> > >> >>>> > >> I started a parallel activity to tease out CI work on using ASF >>>> jenkins >>>> > >> and >>>> > >> also Github actions (though GHA has several issues). I wanted to >>>> provide >>>> > >> some updates on these efforts and seek if others are interested to >>>> > >> collaborate. >>>> > >> >>>> > >> Jenkins - Was waiting for INFRA to create a high level folder[1] >>>> to host >>>> > >> all Geode jobs and have a basic unit test pipeline[2] that runs >>>> tests on >>>> > >> Ubuntu using Oracle JDK 8. While there are failing tests[3] that >>>> need >>>> > some >>>> > >> help, I am still exploring ways to write pipelines and include >>>> multiple >>>> > >> JDKs into a single JOB, so we can build using 8 while we test >>>> using 11. >>>> > >> >>>> > >> GHA - While it is super quick and easy to start writing a >>>> pipeline[4] >>>> > >> using >>>> > >> "matrix and strategy", There are few tests[5] failing consistently >>>> using >>>> > >> Adopt JDK 8 on Ubuntu. >>>> > >> >>>> > >> [1] https://ci-builds.apache.org/job/Geode/ >>>> > >> [2] >>>> > >> >>>> > >> >>>> > >>>> https://github.com/apache/geode/blob/4abcdc06af536e1188e0f8c432e9b768c175d8c0/.jenkins/Jenkinsfile >>>> > >> [3] >>>> https://ci-builds.apache.org/job/Geode/job/geode-develop/11/console >>>> > >> [4] https://github.com/apache/geode/pull/7870/files >>>> > >> [5] https://github.com/apache/geode/actions/runs/3515795079 >>>> > >> >>>> > > >>>> > >>>> >>>
Re: rewrite CI pipeline
Kirk, I updated the github pipeline[1] to run unit tests across multiple JDK implementations on the different OS to figure out if there are any JDK/OS differences and seems like there are common tests that fail on GithubActions. Sai [1] https://github.com/apache/geode/actions/runs/3519795068/jobs/5900102040 On Thu, 8 Dec 2022 at 12:18, Kirk Lund wrote: > Hey Sai, > > Quick update on this. On my Mac, I'm able to build and run all unit tests > without any failures using the very latest Oracle Java 8 JDK. I'll try > OpenJDK and Azul next. > > I do have a number of IntegrationTest failures. Most are BindException > failures because some process is already bound to a port. One or two > failures appear to be DNS related which may require either editing > /etc/hosts or changing the test. Will update again after debugging these > more. > > Cheers, > Kirk > > On Fri, Dec 2, 2022 at 12:58 PM Kirk Lund wrote: > >> Sai, I'll be able to spend some time this weekend on these failing tests. >> Hope to have some more news to share soon! >> >> -Kirk >> >> On Mon, Nov 21, 2022 at 4:35 PM Sai Boorlagadda < >> sai.boorlaga...@gmail.com> wrote: >> >>> I was thinking it has to do with either JDK or ubuntu. I also tried >>> 'temurin' >>> and there were different sets of errors. So to see if the devs can shed >>> some light on JDK dependency or any prior knowledge on choosing >>> bellsoft distribution. >>> >>> Sai >>> >>> On Mon, 21 Nov 2022 at 16:25, Kirk Lund wrote: >>> >>> > It's also possible that these issues are specific to using OpenJDK 8 or >>> > Ubuntu. I thought we were building and testing with CentOS before. >>> > >>> > On Mon, Nov 21, 2022 at 4:20 PM Kirk Lund wrote: >>> > >>> > > Looks like membership errors. Membership went through extensive >>> changes >>> > to >>> > > be modularized as geode-membership, and VMware was still fixing some >>> bugs >>> > > in it when I left. These could be really difficult to solve for >>> those of >>> > us >>> > > who have no experience with the new membership. >>> > > >>> > > I wonder if we could engage VMware for a little more help on these >>> > > failures before they depart entirely? >>> > > >>> > > Last I heard there were also problems with using OpenJDK 8 but I >>> don't >>> > > know the details. VMware was using Liberica JDK 8 from Bellsoft. We >>> may >>> > > also need VMware to explain what the issue was with OpenJDK 8 so we >>> can >>> > > figure out what to do about it. >>> > > >>> > > On Mon, Nov 21, 2022 at 3:29 PM Sai Boorlagadda < >>> > sai.boorlaga...@gmail.com> >>> > > wrote: >>> > > >>> > >> Hello devs, >>> > >> >>> > >> I started a parallel activity to tease out CI work on using ASF >>> jenkins >>> > >> and >>> > >> also Github actions (though GHA has several issues). I wanted to >>> provide >>> > >> some updates on these efforts and seek if others are interested to >>> > >> collaborate. >>> > >> >>> > >> Jenkins - Was waiting for INFRA to create a high level folder[1] to >>> host >>> > >> all Geode jobs and have a basic unit test pipeline[2] that runs >>> tests on >>> > >> Ubuntu using Oracle JDK 8. While there are failing tests[3] that >>> need >>> > some >>> > >> help, I am still exploring ways to write pipelines and include >>> multiple >>> > >> JDKs into a single JOB, so we can build using 8 while we test using >>> 11. >>> > >> >>> > >> GHA - While it is super quick and easy to start writing a >>> pipeline[4] >>> > >> using >>> > >> "matrix and strategy", There are few tests[5] failing consistently >>> using >>> > >> Adopt JDK 8 on Ubuntu. >>> > >> >>> > >> [1] https://ci-builds.apache.org/job/Geode/ >>> > >> [2] >>> > >> >>> > >> >>> > >>> https://github.com/apache/geode/blob/4abcdc06af536e1188e0f8c432e9b768c175d8c0/.jenkins/Jenkinsfile >>> > >> [3] >>> https://ci-builds.apache.org/job/Geode/job/geode-develop/11/console >>> > >> [4] https://github.com/apache/geode/pull/7870/files >>> > >> [5] https://github.com/apache/geode/actions/runs/3515795079 >>> > >> >>> > > >>> > >>> >>
Re: rewrite CI pipeline
I was thinking it has to do with either JDK or ubuntu. I also tried 'temurin' and there were different sets of errors. So to see if the devs can shed some light on JDK dependency or any prior knowledge on choosing bellsoft distribution. Sai On Mon, 21 Nov 2022 at 16:25, Kirk Lund wrote: > It's also possible that these issues are specific to using OpenJDK 8 or > Ubuntu. I thought we were building and testing with CentOS before. > > On Mon, Nov 21, 2022 at 4:20 PM Kirk Lund wrote: > > > Looks like membership errors. Membership went through extensive changes > to > > be modularized as geode-membership, and VMware was still fixing some bugs > > in it when I left. These could be really difficult to solve for those of > us > > who have no experience with the new membership. > > > > I wonder if we could engage VMware for a little more help on these > > failures before they depart entirely? > > > > Last I heard there were also problems with using OpenJDK 8 but I don't > > know the details. VMware was using Liberica JDK 8 from Bellsoft. We may > > also need VMware to explain what the issue was with OpenJDK 8 so we can > > figure out what to do about it. > > > > On Mon, Nov 21, 2022 at 3:29 PM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > > wrote: > > > >> Hello devs, > >> > >> I started a parallel activity to tease out CI work on using ASF jenkins > >> and > >> also Github actions (though GHA has several issues). I wanted to provide > >> some updates on these efforts and seek if others are interested to > >> collaborate. > >> > >> Jenkins - Was waiting for INFRA to create a high level folder[1] to host > >> all Geode jobs and have a basic unit test pipeline[2] that runs tests on > >> Ubuntu using Oracle JDK 8. While there are failing tests[3] that need > some > >> help, I am still exploring ways to write pipelines and include multiple > >> JDKs into a single JOB, so we can build using 8 while we test using 11. > >> > >> GHA - While it is super quick and easy to start writing a pipeline[4] > >> using > >> "matrix and strategy", There are few tests[5] failing consistently using > >> Adopt JDK 8 on Ubuntu. > >> > >> [1] https://ci-builds.apache.org/job/Geode/ > >> [2] > >> > >> > https://github.com/apache/geode/blob/4abcdc06af536e1188e0f8c432e9b768c175d8c0/.jenkins/Jenkinsfile > >> [3] https://ci-builds.apache.org/job/Geode/job/geode-develop/11/console > >> [4] https://github.com/apache/geode/pull/7870/files > >> [5] https://github.com/apache/geode/actions/runs/3515795079 > >> > > >
Re: priority list
Kirk, I started playing around both ASF jenkins and GHA to tease out the differences between what features are available between the two solutions and how easy it is to write the pipelines with what level of control. Eg: I haven't figured out yet how to write dockerized builds with ASF jenkins. Rather than migrating existing pipelines as-is, we should define the MVP of a pipeline that we should focus on first. I like your idea on having a collaborative setup, let me find some time. Sai On Mon, 21 Nov 2022 at 12:31, Kirk Lund wrote: > I have next to no experience with Jenkins but I'd be happy to get on some > sort of zoom or google or other screen sharing conference call to offer > what little help I can. > > -Kirk > > On Tue, Nov 15, 2022 at 2:19 PM Sai Boorlagadda > > wrote: > > > Thanks Mark. > > > > Dan added me required permissions. So I will try to get a simple build > step > > and configure the job. > > > > Will reach out for specific questions or issues. Do you or anyone have > any > > project reference that uses Jenkins? > > > > Sai > > > > On Mon, 14 Nov 2022 at 07:01, Mark Bretl wrote: > > > > > Jenkins CI in 2014 was limited to say the least, now Jenkins has actual > > > pipelines and stages, with parallel functionality, so it will be much > > > better this time around if we go that route. I think we could go back > to > > > the basics, do a compile build and then add unit/basic/BVT tests on top > > > without too much trouble. I would say if we can get CI running for the > > main > > > Geode project with a compile in Jenkins, it would be a great first > step. > > I > > > do have quite a bit of Jenkins experience, so I can definitely help > out. > > > > > > --Mark > > > > > > On Sat, Nov 12, 2022 at 10:24 PM Kirk Lund wrote: > > > > > > > Do we know why Geode has such a large CI resource requirement? > > > > > > > > I would guess that it was partially due to trying to run as many > tests > > in > > > > parallel as possible to shorten the feedback cycle. The recent CI > > > pipelines > > > > were also built on Pivotal's Concourse which seems to promote a > greater > > > > number of smaller CI jobs (or at least that's my impression). > > > > > > > > This code base did successfully use a Jenkins CI prior to 2014 even > > > though > > > > it took more hours to complete than the more recent Concourse CI. I > > think > > > > Mark Bretl was involved in that Jenkins CI so he might remember some > > > > details or tips or even possible challenges to watch out for. > > > > > > > > -Kirk > > > > > > > > On Sat, Nov 12, 2022 at 4:42 AM Mario Salazar de Torres > > > > wrote: > > > > > > > > > Hi, > > > > > About GitHub actions, there are currently some limitations you I > > > pointed > > > > > out previously in the devlist. > > > > > Even tho, I was stuck in the process of migrating geode-native CI > to > > GH > > > > > actions, mostly since I didn't have the necessary permissions. > > > > > If you want to have further info about GH actions, you can check > > Apache > > > > > BUILDS list. > > > > > > > > > > And as for Geode repository, considering the number of resources > its > > CI > > > > > requires, I'd say GH actions is a no go... > > > > > Also, I think it was Dan Smith, the one that pointed out that > Apache > > > has > > > > a > > > > > Jenkins instance available, so every Apache project can use its > > > > resources. > > > > > My guess is that Apache Jenkins infra would be a better fit for > Geode > > > > > repository. Still, it remains to be seen, since resource > requirements > > > on > > > > > that repository are really high. > > > > > > > > > > Sorry I couldn't be of more help, but at least I hope these > pointers > > > are > > > > > useful. > > > > > > > > > > /Mario > > > > > > > > > > > > > > > From: Niall Pemberton > > > > > Sent: Saturday, November 12, 2022 10:46 AM > > > > > To: dev@geode.apache.org > > > > > Subject: Re: priority list > > > > > > > > > > On Sat, Nov 12, 2022 at 3:24 AM Sai Boorlagadda < > > > > sai.boorlaga...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > Hello Devs, > > > > > > > > > > > > I would like to understand some of the top priority items that we > > > > should > > > > > > focus and spend our time on while we ramp up with new community > > > > members. > > > > > > > > > > > > Any pointers to the scope of the next release or a list of items > we > > > > > should > > > > > > do as part of this transition. While going through the mailing > list > > > > what > > > > > > immediately caught my eye is CI/CD migration to Github actions. > > > > > > > > > > > > > > > > I would say the number one priority is getting a CI instance > setup. I > > > > guess > > > > > you've seen what Mario said about his efforts on GitHub actions? > > > > > > > > > > Niall > > > > > > > > > > > > > > > > > > > > > > Sai > > > > > > > > > > > > > > > > > > > > >
rewrite CI pipeline
Hello devs, I started a parallel activity to tease out CI work on using ASF jenkins and also Github actions (though GHA has several issues). I wanted to provide some updates on these efforts and seek if others are interested to collaborate. Jenkins - Was waiting for INFRA to create a high level folder[1] to host all Geode jobs and have a basic unit test pipeline[2] that runs tests on Ubuntu using Oracle JDK 8. While there are failing tests[3] that need some help, I am still exploring ways to write pipelines and include multiple JDKs into a single JOB, so we can build using 8 while we test using 11. GHA - While it is super quick and easy to start writing a pipeline[4] using "matrix and strategy", There are few tests[5] failing consistently using Adopt JDK 8 on Ubuntu. [1] https://ci-builds.apache.org/job/Geode/ [2] https://github.com/apache/geode/blob/4abcdc06af536e1188e0f8c432e9b768c175d8c0/.jenkins/Jenkinsfile [3] https://ci-builds.apache.org/job/Geode/job/geode-develop/11/console [4] https://github.com/apache/geode/pull/7870/files [5] https://github.com/apache/geode/actions/runs/3515795079
Re: priority list
Thanks Mark. Dan added me required permissions. So I will try to get a simple build step and configure the job. Will reach out for specific questions or issues. Do you or anyone have any project reference that uses Jenkins? Sai On Mon, 14 Nov 2022 at 07:01, Mark Bretl wrote: > Jenkins CI in 2014 was limited to say the least, now Jenkins has actual > pipelines and stages, with parallel functionality, so it will be much > better this time around if we go that route. I think we could go back to > the basics, do a compile build and then add unit/basic/BVT tests on top > without too much trouble. I would say if we can get CI running for the main > Geode project with a compile in Jenkins, it would be a great first step. I > do have quite a bit of Jenkins experience, so I can definitely help out. > > --Mark > > On Sat, Nov 12, 2022 at 10:24 PM Kirk Lund wrote: > > > Do we know why Geode has such a large CI resource requirement? > > > > I would guess that it was partially due to trying to run as many tests in > > parallel as possible to shorten the feedback cycle. The recent CI > pipelines > > were also built on Pivotal's Concourse which seems to promote a greater > > number of smaller CI jobs (or at least that's my impression). > > > > This code base did successfully use a Jenkins CI prior to 2014 even > though > > it took more hours to complete than the more recent Concourse CI. I think > > Mark Bretl was involved in that Jenkins CI so he might remember some > > details or tips or even possible challenges to watch out for. > > > > -Kirk > > > > On Sat, Nov 12, 2022 at 4:42 AM Mario Salazar de Torres > > wrote: > > > > > Hi, > > > About GitHub actions, there are currently some limitations you I > pointed > > > out previously in the devlist. > > > Even tho, I was stuck in the process of migrating geode-native CI to GH > > > actions, mostly since I didn't have the necessary permissions. > > > If you want to have further info about GH actions, you can check Apache > > > BUILDS list. > > > > > > And as for Geode repository, considering the number of resources its CI > > > requires, I'd say GH actions is a no go... > > > Also, I think it was Dan Smith, the one that pointed out that Apache > has > > a > > > Jenkins instance available, so every Apache project can use its > > resources. > > > My guess is that Apache Jenkins infra would be a better fit for Geode > > > repository. Still, it remains to be seen, since resource requirements > on > > > that repository are really high. > > > > > > Sorry I couldn't be of more help, but at least I hope these pointers > are > > > useful. > > > > > > /Mario > > > > > > > > > From: Niall Pemberton > > > Sent: Saturday, November 12, 2022 10:46 AM > > > To: dev@geode.apache.org > > > Subject: Re: priority list > > > > > > On Sat, Nov 12, 2022 at 3:24 AM Sai Boorlagadda < > > sai.boorlaga...@gmail.com > > > > > > > wrote: > > > > > > > Hello Devs, > > > > > > > > I would like to understand some of the top priority items that we > > should > > > > focus and spend our time on while we ramp up with new community > > members. > > > > > > > > Any pointers to the scope of the next release or a list of items we > > > should > > > > do as part of this transition. While going through the mailing list > > what > > > > immediately caught my eye is CI/CD migration to Github actions. > > > > > > > > > > I would say the number one priority is getting a CI instance setup. I > > guess > > > you've seen what Mario said about his efforts on GitHub actions? > > > > > > Niall > > > > > > > > > > > > > > Sai > > > > > > > > > >
Re: priority list
Dan, Could you add me to this ldap group 'hudson-jobadmin' to get administrative account for Jenkins? [1] https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=65147535#Jenkins-HowdoIgetanaccount ? Sai On Sat, Nov 12, 2022, 7:33 AM Sai Boorlagadda wrote: > Thanks, Mario for the context. > > I am also reading about GA performance/scalability issues[1] from other > apache project migration efforts, so it seems Jenkins would be the better > option for Geode. Let me read about getting started with Jenkins. > > [1] > https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+status > > On Sat, 12 Nov 2022 at 04:42, Mario Salazar de Torres > wrote: > >> Hi, >> About GitHub actions, there are currently some limitations you I pointed >> out previously in the devlist. >> Even tho, I was stuck in the process of migrating geode-native CI to GH >> actions, mostly since I didn't have the necessary permissions. >> If you want to have further info about GH actions, you can check Apache >> BUILDS list. >> >> And as for Geode repository, considering the number of resources its CI >> requires, I'd say GH actions is a no go... >> Also, I think it was Dan Smith, the one that pointed out that Apache has >> a Jenkins instance available, so every Apache project can use its resources. >> My guess is that Apache Jenkins infra would be a better fit for Geode >> repository. Still, it remains to be seen, since resource requirements on >> that repository are really high. >> >> Sorry I couldn't be of more help, but at least I hope these pointers are >> useful. >> >> /Mario >> >> >> From: Niall Pemberton >> Sent: Saturday, November 12, 2022 10:46 AM >> To: dev@geode.apache.org >> Subject: Re: priority list >> >> On Sat, Nov 12, 2022 at 3:24 AM Sai Boorlagadda < >> sai.boorlaga...@gmail.com> >> wrote: >> >> > Hello Devs, >> > >> > I would like to understand some of the top priority items that we should >> > focus and spend our time on while we ramp up with new community members. >> > >> > Any pointers to the scope of the next release or a list of items we >> should >> > do as part of this transition. While going through the mailing list what >> > immediately caught my eye is CI/CD migration to Github actions. >> > >> >> I would say the number one priority is getting a CI instance setup. I >> guess >> you've seen what Mario said about his efforts on GitHub actions? >> >> Niall >> >> >> > >> > Sai >> > >> >
Re: priority list
Thanks, Mario for the context. I am also reading about GA performance/scalability issues[1] from other apache project migration efforts, so it seems Jenkins would be the better option for Geode. Let me read about getting started with Jenkins. [1] https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+status On Sat, 12 Nov 2022 at 04:42, Mario Salazar de Torres wrote: > Hi, > About GitHub actions, there are currently some limitations you I pointed > out previously in the devlist. > Even tho, I was stuck in the process of migrating geode-native CI to GH > actions, mostly since I didn't have the necessary permissions. > If you want to have further info about GH actions, you can check Apache > BUILDS list. > > And as for Geode repository, considering the number of resources its CI > requires, I'd say GH actions is a no go... > Also, I think it was Dan Smith, the one that pointed out that Apache has a > Jenkins instance available, so every Apache project can use its resources. > My guess is that Apache Jenkins infra would be a better fit for Geode > repository. Still, it remains to be seen, since resource requirements on > that repository are really high. > > Sorry I couldn't be of more help, but at least I hope these pointers are > useful. > > /Mario > > > From: Niall Pemberton > Sent: Saturday, November 12, 2022 10:46 AM > To: dev@geode.apache.org > Subject: Re: priority list > > On Sat, Nov 12, 2022 at 3:24 AM Sai Boorlagadda > > wrote: > > > Hello Devs, > > > > I would like to understand some of the top priority items that we should > > focus and spend our time on while we ramp up with new community members. > > > > Any pointers to the scope of the next release or a list of items we > should > > do as part of this transition. While going through the mailing list what > > immediately caught my eye is CI/CD migration to Github actions. > > > > I would say the number one priority is getting a CI instance setup. I guess > you've seen what Mario said about his efforts on GitHub actions? > > Niall > > > > > > Sai > > >
priority list
Hello Devs, I would like to understand some of the top priority items that we should focus and spend our time on while we ramp up with new community members. Any pointers to the scope of the next release or a list of items we should do as part of this transition. While going through the mailing list what immediately caught my eye is CI/CD migration to Github actions. Sai
Cloudburst from RISELabs
Devs, I came across Cloudburst paper which introduces function execution integrated into a KV store (Anna) by Berkley folks @ RISELabs which resembles Geode's functions execution engine. I thought I would share this paper with the rest of the community. https://arxiv.org/pdf/2001.04592.pdf Sai
Re: WAN replication issue in cloud native environments
> if one gw receiver stops, the locator will publish to any remote locator that there are no receivers up. I am not sure if locators proactively update remote locators about change in receivers list rather I think the senders figures this out on connection issues. But I see the problem that local-site locators have only one member in the list of receivers that they maintain as all receivers register with a single address. One idea I had earlier is to statically set receivers list to locators (just like remote-locators property) which are exchanged with gw-senders. This way we can introduce a boolean flag to turn off wan discovery and use the statically configured addresses. This can be also useful for remote-locators if they are behind a service. Sai On Thu, Dec 5, 2019 at 2:33 AM Alberto Bustamante Reyes wrote: > Thanks Charlie, but the issue is not about connectivity. Summarizing the > issue, the problem is that if you have two or more gw receivers that are > started with the same value of "hostname-for-senders", "start-port" and > "end-port" (being "start-port" and "end-port" equal) parameters, if one gw > receiver stops, the locator will publish to any remote locator that there > are no receivers up. > > And this use case is likely to happen on cloud-native environments, as > described. > > BR/ > > Alberto B. > > De: Charlie Black > Enviado: miércoles, 4 de diciembre de 2019 18:11 > Para: dev@geode.apache.org > Asunto: Re: WAN replication issue in cloud native environments > > Alberto, > > Something else to think about SNI based routing. I believe Mario might be > working on adding SNI to Geode - he at least had a proposal that he > e-mailed out. > > Basics are the destination host is in the SNI field and the proxy can > inspect and route the request to the right service instance. Plus we > have the option to not terminate the SSL at the proxy. > > Full disclosure - I haven't tried out SNI based routing myself and it is > something that I thought could work as I was reading about it. From the > whiteboard I have done I think this will do ingress and egress just fine. > Potentially easier then port mapping and `hostname for clients` playing > around. > > Just something to think about. > > Charlie > > > On Wed, Dec 4, 2019 at 3:19 AM Alberto Bustamante Reyes > wrote: > > > Hi Jacob, > > > > Yes,we are using LoadBalancer service type. But note the problem is not > > the transport layer but on Geode as GW senders are complaining > > “sender-2-parallel : Could not connect due to: There are no active > > servers.” when one of the servers in the receiving cluster is killed. > > > > So, there is still one server alive in the receiving cluster but GW > sender > > does not know it and the locator is not able to inform about its > existence. > > Looking at the code it seems internal data structures (maps) holding the > > profiles use object whose equality check relies only on hostname and > port. > > This makes it impossible to differentiate servers when the same > > “hostname-for-senders” and port are used. When the killed server comes > back > > up, the locator profiles are updated (internal map back to size()=1 > > although 2+ servers are there) and GW senders happily reconnect. > > > > The solution with the Geode as-is would be to expose each GW receiver on > a > > different port outside of k8s cluster, this includes creating N > Kubernetes > > services for N GW receivers in addition to updating the service mesh > > configuration (if it is used, firewalls etc…). Declarative nature of > > kubernetes means we must know the ports in advance hence start-port and > > end-port when creating each GW receiver must be equal and we should have > > some well-known > > algorithm when creating GW receivers across servers. For example: > server-0 > > port 5000, server-1 port 5001, server-2 port 5002 etc…. So, all GW > > receivers must be wired individually and we must turn off Geode’s random > > port allocation. > > > > But we are exploring the possibility for Geode to handle this > cloud-native > > configuration a bit better. Locators should be capable of holding GW > > receiver information although they are hidden behind same hostname and > port. > > This is a code change in Geode and we would like to have community > opinion > > on it. > > > > Some obvious impacts with the legacy behavior would be when locator picks > > a server on behalf of the client (GW sender in this case) it does so > based > > on the server load. When sender connects and considering all servers are > > using same VIP:PORT it is load balancer that will decide where the > > connection will end up, but likely not on the one selected by locator. So > > here we ignore the locator instructions. Since GW senders normally do not > > create huge number of connections this probably shall not unbalance > cluster > > too much. But this is an impact worth considering. Custom load metrics > > would also be
Re: Proposal of new config property "ssl-server-name-extension"
Hello Mario, I would like to see if having a custom security provider allows you to configure the default SSL context to set the SNI? >From your proposal, I see that you have implemented a Java Security Provider to provide custom KeyManager implementation which distinguishes certificate based on which the wan-site the peer client is connecting to. How are you configuring this security provider? I am assuming you have some bootstrapping code that inserts your security provider before launching Geode, and also set gemfire property `ssl-use-default-context` to true to let Geode use the default SSL context. Can this bootstrapping code create and configure an SSL context with SNI and set it as default context before launching geode? This may appear as a workaround but the rationale behind `ssl-use-default-context` is to delegate the external environment to configure the SSL context in a required manner and let Geode just use it. Sai On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac wrote: > Hi geode dev, > > as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414 > we would like to introduce new config property "ssl-server-name-extension". > > This property will contain generic string, which will be added as Server > Name Indication (SNI) parameter to Client Hello message. > > Do you agree with this proposal? > > Thanks, > Mario >
Re: SSL Alias Support for JMX Connections
+1 for getting this into 1.10 On Thu, Aug 8, 2019 at 11:29 AM Juan José Ramos wrote: > I'd like to propose including the fix for *GEODE-7022 [1]* in release > 1.10.0. > The fix basically improves our own implementation of the > *RMIClientSocketFactory* to fully support the GEODE SSL settings, allowing > our users to specify a default alias when opening an RMI connection. > Best regards. > > [1]: https://issues.apache.org/jira/browse/GEODE-7022 > > -- > Juan José Ramos Cassella > Senior Software Engineer > Email: jra...@pivotal.io >
IntelliJ setup for develop
Building/Rebuilding in IntelliJ fails with error "Cannot start compilation: the output path is not specified for modules". Any help would be appreciated. I have been following BUILDING.md[1] to setup intellij. [1] https://github.com/apache/geode/blob/develop/BUILDING.md
Re: [VOTE] Apache Geode 1.9.0 RC3
I will be traveling and would be away from my computer, so I will not be able to build a new RC when we are ready. Meanwhile Dan & Owen has offered help for 1.9.0 and they will be filling me in as release managers. Thanks Dan & Owen for your help. Sai On Tue, Apr 16, 2019 at 2:18 PM Anthony Baker wrote: > FYI, I reviewed the geode, geode-examples, and geode-native bits. No > issues so far (except as noted by Bruce). > > Anthony > > > > On Apr 16, 2019, at 1:19 PM, Sai Boorlagadda > wrote: > > > > Thanks Bruce. You can -1 this release candidate and I will build a new > one > > once the issue is resolved. > > > > Sai > > > > On Tue, Apr 16, 2019 at 12:11 PM Bruce Schuchardt < > bschucha...@pivotal.io> > > wrote: > > > >> In testing for the CI failure GEODE-6664 I am seeing a test using SSL > >> with conserve-sockets=true hang periodically. That's probably something > >> we should fix for 1.9. The code in question was heavily modified for > >> this release. > >> > >> On 4/15/19 3:06 PM, Sai Boorlagadda wrote: > >>> Hello, Geode dev community, > >>> > >>> > >>> This is the second release candidate for Apache Geode, version 1.9.0. > >>> > >>> Thanks to all the community members for their contributions to this > >> release! > >>> > >>> > >>> Please do a review and give your feedback. The deadline is before 3 PM > >> PST > >>> Thur April 18th, 2019. > >>> > >>> > >>> This release resolves 296 issues on Apache Geode JIRA system. Release > >> notes > >>> can be found at: > >>> > >>> > >> > https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0 > >>> > >>> > >>> Please note that we are voting upon the source tags: rel/v1.9.0.RC3 > >>> > >>> > >>> Apache Geode: > >>> > >>> https://github.com/apache/geode/tree/rel/v1.9.0.RC3 > >>> > >>> Apache Geode examples: > >>> > >>> https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC3 > >>> > >>> Apache Geode Native: > >>> > >>> https://github.com/apache/geode-native/tree/rel/v1.9.0.RC3 > >>> > >>> > >>> Commit ID: > >>> > >>> Apache Geode: 6b05caec551fb04af18b3d6579d443fcb81aa1a0 > >>> > >>> Apache Geode Examples: 461f03614d389325496a82874cd5cf8b3329afdf > >>> > >>> Apache Geode Native: cef8078392f51d9a2d4b6a8b828a17359004b279 > >>> > >>> > >>> Source and binary files: > >>> > >>> https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC3/ > >>> > >>> > >>> Maven staging repo: > >>> > >>> https://repository.apache.org/content/repositories/orgapachegeode-1053 > >>> > >>> > >>> Geode's KEYS file containing PGP keys we use to sign the release: > >>> > >>> https://github.com/apache/geode/blob/develop/KEYS > >>> > >>> > >>> Signed the release with fingerprint: > >>> > >>> rsa4096 2018-01-14 [SC] > >>> > >>> 0889380187C20785C2A7168045936212F0FF55B0 > >>> > >>> > >>> PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl= > >>> https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC3 > >> -PgeodeRepositoryUrl= > >>> https://repository.apache.org/content/repositories/orgapachegeode-1053 > >> build > >>> runAll > >>> > >>> > >>> PS: I have cherry-picked a commit to fix GEODE-3948 > >>> > >>> > >>> Regards, > >>> > >>> Sai Boorlagadda > >>> > >> > >
Re: [VOTE] Apache Geode 1.9.0 RC3
Thanks Bruce. You can -1 this release candidate and I will build a new one once the issue is resolved. Sai On Tue, Apr 16, 2019 at 12:11 PM Bruce Schuchardt wrote: > In testing for the CI failure GEODE-6664 I am seeing a test using SSL > with conserve-sockets=true hang periodically. That's probably something > we should fix for 1.9. The code in question was heavily modified for > this release. > > On 4/15/19 3:06 PM, Sai Boorlagadda wrote: > > Hello, Geode dev community, > > > > > > This is the second release candidate for Apache Geode, version 1.9.0. > > > > Thanks to all the community members for their contributions to this > release! > > > > > > Please do a review and give your feedback. The deadline is before 3 PM > PST > > Thur April 18th, 2019. > > > > > > This release resolves 296 issues on Apache Geode JIRA system. Release > notes > > can be found at: > > > > > https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0 > > > > > > Please note that we are voting upon the source tags: rel/v1.9.0.RC3 > > > > > > Apache Geode: > > > > https://github.com/apache/geode/tree/rel/v1.9.0.RC3 > > > > Apache Geode examples: > > > > https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC3 > > > > Apache Geode Native: > > > > https://github.com/apache/geode-native/tree/rel/v1.9.0.RC3 > > > > > > Commit ID: > > > > Apache Geode: 6b05caec551fb04af18b3d6579d443fcb81aa1a0 > > > > Apache Geode Examples: 461f03614d389325496a82874cd5cf8b3329afdf > > > > Apache Geode Native: cef8078392f51d9a2d4b6a8b828a17359004b279 > > > > > > Source and binary files: > > > > https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC3/ > > > > > > Maven staging repo: > > > > https://repository.apache.org/content/repositories/orgapachegeode-1053 > > > > > > Geode's KEYS file containing PGP keys we use to sign the release: > > > > https://github.com/apache/geode/blob/develop/KEYS > > > > > > Signed the release with fingerprint: > > > > rsa4096 2018-01-14 [SC] > > > > 0889380187C20785C2A7168045936212F0FF55B0 > > > > > > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl= > > https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC3 > -PgeodeRepositoryUrl= > > https://repository.apache.org/content/repositories/orgapachegeode-1053 > build > > runAll > > > > > > PS: I have cherry-picked a commit to fix GEODE-3948 > > > > > > Regards, > > > > Sai Boorlagadda > > >
[VOTE] Apache Geode 1.9.0 RC3
Hello, Geode dev community, This is the second release candidate for Apache Geode, version 1.9.0. Thanks to all the community members for their contributions to this release! Please do a review and give your feedback. The deadline is before 3 PM PST Thur April 18th, 2019. This release resolves 296 issues on Apache Geode JIRA system. Release notes can be found at: https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0 Please note that we are voting upon the source tags: rel/v1.9.0.RC3 Apache Geode: https://github.com/apache/geode/tree/rel/v1.9.0.RC3 Apache Geode examples: https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC3 Apache Geode Native: https://github.com/apache/geode-native/tree/rel/v1.9.0.RC3 Commit ID: Apache Geode: 6b05caec551fb04af18b3d6579d443fcb81aa1a0 Apache Geode Examples: 461f03614d389325496a82874cd5cf8b3329afdf Apache Geode Native: cef8078392f51d9a2d4b6a8b828a17359004b279 Source and binary files: https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC3/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachegeode-1053 Geode's KEYS file containing PGP keys we use to sign the release: https://github.com/apache/geode/blob/develop/KEYS Signed the release with fingerprint: rsa4096 2018-01-14 [SC] 0889380187C20785C2A7168045936212F0FF55B0 PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl= https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC3 -PgeodeRepositoryUrl= https://repository.apache.org/content/repositories/orgapachegeode-1053 build runAll PS: I have cherry-picked a commit to fix GEODE-3948 Regards, Sai Boorlagadda
Re: [VOTE] Apache Geode 1.9.0 RC2
Thanks Dan & Anthony, I will build RC3. I am also cherry-picking GEODE-3948 which was fixed on develop (last friday) as it seems like a good improvement. Any objections? Sai On Mon, Apr 15, 2019 at 11:13 AM Anthony Baker wrote: > To fix this error, we need to change the type of exception we catch on > this line: > > https://github.com/apache/geode/blob/develop/build.gradle#L99 < > https://github.com/apache/geode/blob/develop/build.gradle#L99> > > to ‘org.ajoberstar.grgit.exception.GrgitException’ > > Anthony > > > > On Apr 15, 2019, at 10:36 AM, Anthony Baker wrote: > > > > Custom properties can be set in ~/.gradle/gradle.properties so you don’t > need to modify the project properties. > > > > I’m also getting this error: > > > > 1:16 in apache-geode-1.9.0-src/ > > › ./gradlew build > > > > FAILURE: Build failed with an exception. > > > > * Where: > > Build file '/Users/abaker/working/apache-geode-1.9.0-src/build.gradle' > line: 100 > > > > * What went wrong: > > A problem occurred evaluating root project 'geode'. > >> No .git directory found! > > > > Anthony > > > > > >> On Apr 15, 2019, at 10:30 AM, Dan Smith wrote: > >> > >> Hi Sai, > >> > >> It looks like you left some signing properties in gradle.properties in > the > >> source distribution. Building the source distribution is failing with > this > >> error to this. Maybe you could make a clean source distribution and > >> re-upload it? > >> > >> 1: Task failed with an exception. > >> --- > >> * What went wrong: > >> Execution failed for task ':geode-assembly:signDistTar'. > >>> Cannot perform signing task ':geode-assembly:signDistTar' because it > has > >> no configured signatory > >> > >> * Try: > >> Run with --stacktrace option to get the stack trace. Run with --info or > >> --debug option to get more log output. Run with --scan to get full > insights. > >> > == > >> > >> -Dan > >> > >> On Fri, Apr 12, 2019 at 4:34 PM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > >> wrote: > >> > >>> Hello, Geode dev community, > >>> > >>> > >>> This is the second release candidate for Apache Geode, version 1.9.0. > >>> > >>> Thanks to all the community members for their contributions to this > >>> release! > >>> > >>> > >>> Please do a review and give your feedback. The deadline is before 5 PM > PST > >>> Wed April 17th, 2019. > >>> > >>> > >>> This release resolves 295 issues on Apache Geode JIRA system. Release > notes > >>> can be found at: > >>> > >>> > >>> > https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0 > >>> > >>> > >>> Please note that we are voting upon the source tags: rel/v1.9.0.RC2 > >>> > >>> > >>> Apache Geode: > >>> > >>> https://github.com/apache/geode/tree/rel/v1.9.0.RC2 > >>> > >>> Apache Geode examples: > >>> > >>> https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC2 > >>> > >>> Apache Geode Native: > >>> > >>> https://github.com/apache/geode-native/tree/rel/v1.9.0.RC2 > >>> > >>> > >>> Commit ID: > >>> > >>> Apache Geode: 4a868075e59a26753485958bf86900881b794934 > >>> > >>> Apache Geode Examples: 461f03614d389325496a82874cd5cf8b3329afdf > >>> > >>> Apache Geode Native: cef8078392f51d9a2d4b6a8b828a17359004b279 > >>> > >>> > >>> Source and binary files: > >>> > >>> https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC2/ > >>> > >>> > >>> Maven staging repo: > >>> > >>> https://repository.apache.org/content/repositories/orgapachegeode-1052 > >>> > >>> > >>> Geode's KEYS file containing PGP keys we use to sign the release: > >>> > >>> https://github.com/apache/geode/blob/develop/KEYS > >>> > >>> > >>> Signed the release with fingerprint: > >>> > >>> rsa4096 2018-01-14 [SC] > >>> > >>> 0889380187C20785C2A7168045936212F0FF55B0 > >>> > >>> > >>> PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl= > >>> https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC2 > >>> -PgeodeRepositoryUrl= > >>> https://repository.apache.org/content/repositories/orgapachegeode-1052 > >>> build > >>> runAll > >>> > >>> > >>> Regards, > >>> > >>> Sai Boorlagadda > >>> > > > >
Re: [VOTE] Apache Geode 1.9.0 RC1
I did build an RC2 and uploaded to distro. Sai On Fri, Apr 12, 2019 at 4:21 PM Bruce Schuchardt wrote: > I'm pushing the fix for GEODE-3948 right now. Can you get that into the > new RC? It was reported on geode-user this week. > > On 4/12/19 3:27 PM, Sai Boorlagadda wrote: > > Thanks Dave for catching that. I am going to rebuild a new RC. > > > > Sai > > > > On Fri, Apr 12, 2019 at 3:10 PM Dave Barnes wrote: > > > >> -1 > >> The file geode-book/redirects.rb contains an incorrect version path > >> component: "110". Should be "19". Two occurrences. > >> Customers will not be able to build the user guide from sources without > >> this change. > >> Should be: > >> > >> ``` > >> > >> rewrite '/', '/docs/guide/19/about_geode.html' > >> > >> rewrite '/index.html', '/docs/guide/19/about_geode.html' > >> > >> ``` > >> > >> On Fri, Apr 12, 2019 at 11:16 AM Sai Boorlagadda < > >> sai.boorlaga...@gmail.com> > >> wrote: > >> > >>> Hello, Geode dev community, > >>> > >>> > >>> This is the first release candidate for Apache Geode, version 1.9.0. > >>> > >>> Thanks to all the community members for their contributions to this > >>> release! > >>> > >>> > >>> Please do a review and give your feedback. The deadline is before 12 PM > >> PST > >>> Wed April 17th, 2019. > >>> > >>> > >>> This release resolves 297 issues on Apache Geode JIRA system. Release > >> notes > >>> can be found at: > >>> > >>> > >>> > >> > https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0 > >>> > >>> Please note that we are voting upon the source tags: rel/v1.9.0.RC1 > >>> > >>> > >>> Apache Geode: > >>> > >>> https://github.com/apache/geode/tree/rel/v1.9.0.RC1 > >>> > >>> Apache Geode examples: > >>> > >>> https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC1 > >>> > >>> Apache Geode Native: > >>> > >>> https://github.com/apache/geode-native/tree/rel/v1.9.0.RC1 > >>> > >>> > >>> Commit ID: > >>> > >>> Apache Geode: 75ac49853de0711b9720f168cbed5f3fc03f4668 > >>> > >>> Apache Geode Examples: 461f03614d389325496a82874cd5cf8b3329afdf > >>> > >>> Apache Geode Native: cef8078392f51d9a2d4b6a8b828a17359004b279 > >>> > >>> > >>> Source and binary files: > >>> > >>> https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC1/ > >>> > >>> > >>> Maven staging repo: > >>> > >>> https://repository.apache.org/content/repositories/orgapachegeode-1051 > >>> > >>> > >>> Geode's KEYS file containing PGP keys we use to sign the release: > >>> > >>> https://github.com/apache/geode/blob/develop/KEYS > >>> > >>> > >>> Signed the release with fingerprint: > >>> > >>> rsa4096 2018-01-14 [SC] > >>> > >>> 0889380187C20785C2A7168045936212F0FF55B0 > >>> > >>> > >>> PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl= > >>> https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC1 > >>> -PgeodeRepositoryUrl= > >>> https://repository.apache.org/content/repositories/orgapachegeode-1051 > >>> build runAll > >>> > >>> > >>> Regards > >>> > >>> Sai Boorlagadda > >>> >
[VOTE] Apache Geode 1.9.0 RC2
Hello, Geode dev community, This is the second release candidate for Apache Geode, version 1.9.0. Thanks to all the community members for their contributions to this release! Please do a review and give your feedback. The deadline is before 5 PM PST Wed April 17th, 2019. This release resolves 295 issues on Apache Geode JIRA system. Release notes can be found at: https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0 Please note that we are voting upon the source tags: rel/v1.9.0.RC2 Apache Geode: https://github.com/apache/geode/tree/rel/v1.9.0.RC2 Apache Geode examples: https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC2 Apache Geode Native: https://github.com/apache/geode-native/tree/rel/v1.9.0.RC2 Commit ID: Apache Geode: 4a868075e59a26753485958bf86900881b794934 Apache Geode Examples: 461f03614d389325496a82874cd5cf8b3329afdf Apache Geode Native: cef8078392f51d9a2d4b6a8b828a17359004b279 Source and binary files: https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC2/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachegeode-1052 Geode's KEYS file containing PGP keys we use to sign the release: https://github.com/apache/geode/blob/develop/KEYS Signed the release with fingerprint: rsa4096 2018-01-14 [SC] 0889380187C20785C2A7168045936212F0FF55B0 PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl= https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC2 -PgeodeRepositoryUrl= https://repository.apache.org/content/repositories/orgapachegeode-1052 build runAll Regards, Sai Boorlagadda
Re: [VOTE] Apache Geode 1.9.0 RC1
Thanks Dave for catching that. I am going to rebuild a new RC. Sai On Fri, Apr 12, 2019 at 3:10 PM Dave Barnes wrote: > -1 > The file geode-book/redirects.rb contains an incorrect version path > component: "110". Should be "19". Two occurrences. > Customers will not be able to build the user guide from sources without > this change. > Should be: > > ``` > > rewrite '/', '/docs/guide/19/about_geode.html' > > rewrite '/index.html', '/docs/guide/19/about_geode.html' > > ``` > > On Fri, Apr 12, 2019 at 11:16 AM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > wrote: > > > Hello, Geode dev community, > > > > > > This is the first release candidate for Apache Geode, version 1.9.0. > > > > Thanks to all the community members for their contributions to this > > release! > > > > > > Please do a review and give your feedback. The deadline is before 12 PM > PST > > Wed April 17th, 2019. > > > > > > This release resolves 297 issues on Apache Geode JIRA system. Release > notes > > can be found at: > > > > > > > https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0 > > > > > > Please note that we are voting upon the source tags: rel/v1.9.0.RC1 > > > > > > Apache Geode: > > > > https://github.com/apache/geode/tree/rel/v1.9.0.RC1 > > > > Apache Geode examples: > > > > https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC1 > > > > Apache Geode Native: > > > > https://github.com/apache/geode-native/tree/rel/v1.9.0.RC1 > > > > > > Commit ID: > > > > Apache Geode: 75ac49853de0711b9720f168cbed5f3fc03f4668 > > > > Apache Geode Examples: 461f03614d389325496a82874cd5cf8b3329afdf > > > > Apache Geode Native: cef8078392f51d9a2d4b6a8b828a17359004b279 > > > > > > Source and binary files: > > > > https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC1/ > > > > > > Maven staging repo: > > > > https://repository.apache.org/content/repositories/orgapachegeode-1051 > > > > > > Geode's KEYS file containing PGP keys we use to sign the release: > > > > https://github.com/apache/geode/blob/develop/KEYS > > > > > > Signed the release with fingerprint: > > > > rsa4096 2018-01-14 [SC] > > > > 0889380187C20785C2A7168045936212F0FF55B0 > > > > > > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl= > > https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC1 > > -PgeodeRepositoryUrl= > > https://repository.apache.org/content/repositories/orgapachegeode-1051 > > build runAll > > > > > > Regards > > > > Sai Boorlagadda > > >
[VOTE] Apache Geode 1.9.0 RC1
Hello, Geode dev community, This is the first release candidate for Apache Geode, version 1.9.0. Thanks to all the community members for their contributions to this release! Please do a review and give your feedback. The deadline is before 12 PM PST Wed April 17th, 2019. This release resolves 297 issues on Apache Geode JIRA system. Release notes can be found at: https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0 Please note that we are voting upon the source tags: rel/v1.9.0.RC1 Apache Geode: https://github.com/apache/geode/tree/rel/v1.9.0.RC1 Apache Geode examples: https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC1 Apache Geode Native: https://github.com/apache/geode-native/tree/rel/v1.9.0.RC1 Commit ID: Apache Geode: 75ac49853de0711b9720f168cbed5f3fc03f4668 Apache Geode Examples: 461f03614d389325496a82874cd5cf8b3329afdf Apache Geode Native: cef8078392f51d9a2d4b6a8b828a17359004b279 Source and binary files: https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC1/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachegeode-1051 Geode's KEYS file containing PGP keys we use to sign the release: https://github.com/apache/geode/blob/develop/KEYS Signed the release with fingerprint: rsa4096 2018-01-14 [SC] 0889380187C20785C2A7168045936212F0FF55B0 PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl= https://dist.apache.org/repos/dist/dev/geode/1.9.0.RC1 -PgeodeRepositoryUrl= https://repository.apache.org/content/repositories/orgapachegeode-1051 build runAll Regards Sai Boorlagadda
Re: release/1.9.0 - are we ready?
Thanks. I am creating an RC and starts voting. Sai On Mon, Apr 8, 2019 at 4:29 PM Anthony Baker wrote: > Sounds good to me. > > Anthony > > > > On Apr 8, 2019, at 9:36 AM, Dave Barnes wrote: > > > > The geode-native repo is up to date and ready for the 1.9 release. > > > > On Mon, Apr 8, 2019 at 9:27 AM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > > wrote: > > > >> Hello, > >> > >> It looks like we have fixed required licensing and bom related issues > and > >> the pipeline is looking much stable with other issues that have been > fixed > >> in last couple of weeks after we have re-cut the branch. > >> > >> So I wanted to ask the developers to see if we are ready for building an > >> RC? Are there any other issues that still need to be addressed? > >> > >> [image: image.png] > >> > >> Sai > >> > >
release/1.9.0 - are we ready?
Hello, It looks like we have fixed required licensing and bom related issues and the pipeline is looking much stable with other issues that have been fixed in last couple of weeks after we have re-cut the branch. So I wanted to ask the developers to see if we are ready for building an RC? Are there any other issues that still need to be addressed? [image: image.png] Sai
Re: Dependency review for release 1.9.0
+1 for bringing this on to release branch as this seems like a major bug. Sai On Fri, Mar 29, 2019 at 9:44 AM Jens Deppe wrote: > I'd like to request GEODE-6559 > <https://issues.apache.org/jira/browse/GEODE-6559> > "PdxInstance.getObject() > is using class from older jar in case of Reconnect" be included in 1.9 if > possible. > > Thanks > --Jens > > On Thu, Mar 28, 2019 at 6:50 AM Sai Boorlagadda > > wrote: > > > Changes to LICENSE and NOTICE files are cherry-picked on to release/1.9.0 > > branch. > > > > On Wed, Mar 27, 2019 at 1:10 PM Anthony Baker wrote: > > > > > Sai and I are almost done with updating the LICENSE and NOTICE files. > I > > > also noticed that the geode jars are missing the NOTICE file (sorry for > > the > > > bad pun). > > > > > > Anthony > > > > > > > > > > On Mar 15, 2019, at 11:07 AM, Sai Boorlagadda < > > sai.boorlaga...@gmail.com> > > > wrote: > > > > > > > > I have a PR[1] to include LICENSE and NOTICE changes to develop. > > > > Once I have merged this to develop then I will cherry-pick this onto > > > 1.9.0 > > > > release branch. > > > > > > > > [1] https://github.com/apache/geode/pull/3313 > > > > > > > > On Wed, Feb 27, 2019 at 5:32 PM Anthony Baker > > wrote: > > > > > > > >> I was reviewing the release branch and noticed a number of new > > > >> dependencies have been added since the last release. When you add a > > new > > > >> dependency, please review and follow the project license guide [1]. > > In > > > >> particular, update the LICENSE file in geode-assembly/src/main/dist > > > >> depending on the license type. > > > >> > > > >> Currently we need to update the LICENSE file with the additional > > > >> MIT/BSD/CDDL dependencies. We may also need to update NOTICE files. > > > >> There’s also a version conflict with multiple versions of Jackson in > > use > > > >> (2.9.6 / 2.9.8). > > > >> > > > >> @Sai - these need to be fixed on release/1.9.0 > > > >> > > > >> Here’s the list of additions: > > > >> > > > >>animal-sniffer-annotations-1.17.jar > > > >>checker-qual-2.5.2.jar > > > >>commons-math3-3.2.jar > > > >>error_prone_annotations-2.2.0.jar > > > >>failureaccess-1.0.jar > > > >>geo-0.7.1.jar > > > >>grumpy-core-0.2.2.jar > > > >>istack-commons-runtime-2.2.jar > > > >>j2objc-annotations-1.1.jar > > > >>javax.activation-1.2.0.jar > > > >>javax.activation-api-1.2.0.jar > > > >>jsr305-3.0.2.jar > > > >> > listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar > > > >> > > > >> Removed: > > > >> > > > >>activation-1.1.1 > > > >>jaxb-core-2.2.11.jar > > > >> > > > >> Anthony > > > >> > > > >> [1] > > > >> > > > > > > https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors > > > >> < > > > >> > > > > > > https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors > > > >>> > > > >> > > > >> > > > > > > > > >
Re: Dependency review for release 1.9.0
Changes to LICENSE and NOTICE files are cherry-picked on to release/1.9.0 branch. On Wed, Mar 27, 2019 at 1:10 PM Anthony Baker wrote: > Sai and I are almost done with updating the LICENSE and NOTICE files. I > also noticed that the geode jars are missing the NOTICE file (sorry for the > bad pun). > > Anthony > > > > On Mar 15, 2019, at 11:07 AM, Sai Boorlagadda > wrote: > > > > I have a PR[1] to include LICENSE and NOTICE changes to develop. > > Once I have merged this to develop then I will cherry-pick this onto > 1.9.0 > > release branch. > > > > [1] https://github.com/apache/geode/pull/3313 > > > > On Wed, Feb 27, 2019 at 5:32 PM Anthony Baker wrote: > > > >> I was reviewing the release branch and noticed a number of new > >> dependencies have been added since the last release. When you add a new > >> dependency, please review and follow the project license guide [1]. In > >> particular, update the LICENSE file in geode-assembly/src/main/dist > >> depending on the license type. > >> > >> Currently we need to update the LICENSE file with the additional > >> MIT/BSD/CDDL dependencies. We may also need to update NOTICE files. > >> There’s also a version conflict with multiple versions of Jackson in use > >> (2.9.6 / 2.9.8). > >> > >> @Sai - these need to be fixed on release/1.9.0 > >> > >> Here’s the list of additions: > >> > >>animal-sniffer-annotations-1.17.jar > >>checker-qual-2.5.2.jar > >>commons-math3-3.2.jar > >>error_prone_annotations-2.2.0.jar > >>failureaccess-1.0.jar > >>geo-0.7.1.jar > >>grumpy-core-0.2.2.jar > >>istack-commons-runtime-2.2.jar > >>j2objc-annotations-1.1.jar > >>javax.activation-1.2.0.jar > >>javax.activation-api-1.2.0.jar > >>jsr305-3.0.2.jar > >>listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar > >> > >> Removed: > >> > >>activation-1.1.1 > >>jaxb-core-2.2.11.jar > >> > >> Anthony > >> > >> [1] > >> > https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors > >> < > >> > https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors > >>> > >> > >> > >
Re: release/1.9.0 branch has been re-cut
I have updated JIRA tickets to 1.9.0 as in "update fixVersion = '1.9.0' where fixVersion = '1.10.0' AND status in (closed, resolved)" On Mon, Mar 25, 2019 at 8:49 AM Sai Boorlagadda wrote: > Hello Everyone, > > As discussed in other email thread I have re-cut a new release branch for > Apache Geode 1.9.0 - "release/1.9.0" off of sha > "ec5a24b78c51b6a29b8bf656f91004d09510d244". > > > We already have an existing pipeline for 1.9.0[1], So I will rename the > current release branch as "release/1.9.0-old" until the pipeline is green and > there are no concerns about the new branch. Also I am still working on > updating LICENSE and NOTICE files, I will cherry-pick these onto release > branch. > > 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. > > > [1] > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main > > Regards > Sai > >
release/1.9.0 branch has been re-cut
Hello Everyone, As discussed in other email thread I have re-cut a new release branch for Apache Geode 1.9.0 - "release/1.9.0" off of sha "ec5a24b78c51b6a29b8bf656f91004d09510d244". We already have an existing pipeline for 1.9.0[1], So I will rename the current release branch as "release/1.9.0-old" until the pipeline is green and there are no concerns about the new branch. Also I am still working on updating LICENSE and NOTICE files, I will cherry-pick these onto release branch. 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. [1] https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main Regards Sai
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
Thanks Owen. I am going to re-cut the branch for 1.9.0 and request community to do the sanity check for the new branch. On Fri, Mar 22, 2019 at 4:24 PM Owen Nichols wrote: > @Sai, this discussion has received no objections and enough +1’s to > proceed with re-cutting the release 1.9.0 branch. > > Looking at the pipeline this week, it has been pretty green since SHA > ec5a24b78c51b6a29b8bf656f91004d09510d244. I recommend re-cutting the 1.9.0 > release branch from this SHA. > > -Owen > > > On Mar 21, 2019, at 9:26 AM, Dan Smith wrote: > > > > I'm fine releasing with just the service loader API for micrometer. > > > > I'd just like the folks working on these new public APIs agree that they > > are ok with these APIs getting released to end users and put to use in > the > > state they are right now. > > > > -Dan > > > > On Wed, Mar 20, 2019 at 12:43 PM Dale Emery wrote: > > > >>> On Mar 20, 2019, at 11:25 AM, Alexander Murmann > >> wrote: > >>> > >>> Dale, is there any downside to making these changes in 1.10 other than > >>> plainly having them later? > >> > >> I don’t think so, but I’d want to hear Dan’s opinion on that, given that > >> his approval of our PR was contingent on our promise to do it. > >> > >> FYI, the additional work to improve usability is non-trivial, which is > why > >> we haven’t done it already. > >> > >> — > >> Dale Emery > >> dem...@pivotal.io > >> > >> > >> > >>> On Mar 20, 2019, at 11:25 AM, Alexander Murmann > >> wrote: > >>> > >>> Dale, is there any downside to making these changes in 1.10 other than > >>> plainly having them later? > >>> > >>> On Wed, Mar 20, 2019 at 11:15 AM Dave Barnes > wrote: > >>> > >>>> geode-native is ready to into the 1.9 release candidate build. > >>>> > >>>> On Wed, Mar 20, 2019 at 10:42 AM Dave Barnes > >> wrote: > >>>> > >>>>> 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 < > amurm...@apache.org > >>> > >>>>> wrote: > >>>>> > >>>>>> 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 > >>>>>> the > >>>>>> two versions and what would be the implications of this not making > it > >>>> into > >>>>>> this release? > >>>>>> > >>>>>> On Tue, Mar 19, 2019 at 5:29 PM Dave Barnes > >> wrote: > >>>>>> > >>>>>>> The Geode 1.9.0 release includes a source-only release of the > >>>>>> geode-native > >>>>>>> repo. There's a pull-request in process to update version numbers > and > >>>>>> the > >>>>>>> doc build environment in that repo; should be ready to merge > tomorrow > >>>>>>> morning. > >>>>>>> > >>>>>>> On Tue, Mar 19, 2019 at 5:20 PM Dale Emery > >> wrote: > >>>>>>> > >>>>>>>> The Micrometer API is in, and marked as experimental. But we have > >>>> not > >>>>>> yet > >>>>>>>> updated CacheFactory to allow injecting a meter registry (or > metrics > >>>>>>>> publishing service) there. So currently the only way to publish is > >>>> to > >>>>>> add > >>>>>>>> metrics publishing service via the ServiceLoader mechanism. > >>>>>>>> > >>>>>>>> — > >>>>>>>> Dale Emery > >>>>>>>> dem...@pivotal.io > >>>>>>>> > >>>>>>>> > >>>>>>>>> On Mar 19, 2019, at 3:29 PM, Dan Smit
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
I would like to resolve the issue around NOTICE and LICENSE files related to new/removed dependencies on develop, which I have a PR[1] open and would need some guidance. There is some feedback provided by Dick earlier this week and I would like to see if I can get some help. [1] https://github.com/apache/geode/pull/3313 On Wed, Mar 20, 2019 at 12:43 PM Dale Emery wrote: > > On Mar 20, 2019, at 11:25 AM, Alexander Murmann > wrote: > > > > Dale, is there any downside to making these changes in 1.10 other than > > plainly having them later? > > I don’t think so, but I’d want to hear Dan’s opinion on that, given that > his approval of our PR was contingent on our promise to do it. > > FYI, the additional work to improve usability is non-trivial, which is why > we haven’t done it already. > > — > Dale Emery > dem...@pivotal.io > > > > > On Mar 20, 2019, at 11:25 AM, Alexander Murmann > wrote: > > > > Dale, is there any downside to making these changes in 1.10 other than > > plainly having them later? > > > > On Wed, Mar 20, 2019 at 11:15 AM Dave Barnes wrote: > > > >> geode-native is ready to into the 1.9 release candidate build. > >> > >> On Wed, Mar 20, 2019 at 10:42 AM Dave Barnes > wrote: > >> > >>> 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 > >>>> 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 > >>>> the > >>>> two versions and what would be the implications of this not making it > >> into > >>>> this release? > >>>> > >>>> On Tue, Mar 19, 2019 at 5:29 PM Dave Barnes > wrote: > >>>> > >>>>> The Geode 1.9.0 release includes a source-only release of the > >>>> geode-native > >>>>> repo. There's a pull-request in process to update version numbers and > >>>> the > >>>>> doc build environment in that repo; should be ready to merge tomorrow > >>>>> morning. > >>>>> > >>>>> On Tue, Mar 19, 2019 at 5:20 PM Dale Emery > wrote: > >>>>> > >>>>>> The Micrometer API is in, and marked as experimental. But we have > >> not > >>>> yet > >>>>>> updated CacheFactory to allow injecting a meter registry (or metrics > >>>>>> publishing service) there. So currently the only way to publish is > >> to > >>>> add > >>>>>> metrics publishing service via the ServiceLoader mechanism. > >>>>>> > >>>>>> — > >>>>>> Dale Emery > >>>>>> dem...@pivotal.io > >>>>>> > >>>>>> > >>>>>>> On Mar 19, 2019, at 3:29 PM, Dan Smith wrote: > >>>>>>> > >>>>>>> Is the geode-managability sub-project and the new micrometer API > >> in > >>>> a > >>>>>> place > >>>>>>> where we can cut a release branch? I know a bunch of changes have > >>>> gone > >>>>> in > >>>>>>> since the release branch, are we comfortable releasing these new > >>>>>>> experimental features as they are right now? > >>>>>>> > >>>>>>> -Dan > >>>>>>> > >>>>>>> On Tue, Mar 19, 2019 at 2:38 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 < > >>>>>> bschucha...@pivotal.io> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> If we recut th
Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch
> It was known at the time that develop was not as stable as desired, so we planned to cherry-pick fixes from develop until the release branch was stable enough to ship. I want to clarify that we decided to cut the release branch not that develop was not stable. But really that it is desirable to cut the branch sooner to avoid any regression risk that can be introduced by on-going work on develop. Nevertheless looks like develop is more stable than release branch due to some test fixes that were not cherry-picked into the release branch. I think its a good idea to re-cut the branch as our current position to stabilize release branch before releasing. +1 to re-cut. Sai On Tue, Mar 19, 2019 at 12:19 PM Owen Nichols wrote: > The Geode 1.9.0 release branch was originally cut 4 weeks ago on Feb 19. > It was known at the time that develop was not as stable as desired, so we > planned to cherry-pick fixes from develop until the release branch was > stable enough to ship. While this is a good strategy when starting from a > fairly good baseline, it seems in this case it has only added complexity > without leading to stability. > > Looking at the pipelines over the last week (see attached metrics), it > appears we have been far more successful at stabilizing *develop* than > *release/1.9.0*. Rather than trying to cherry-pick more and more fixes > to the release branch, I propose we RE-CUT the 1.9.0 release branch later > this week in order to start from a much more stable baseline. > > -Owen > > > >
Re: Dependency review for release 1.9.0
I have a PR[1] to include LICENSE and NOTICE changes to develop. Once I have merged this to develop then I will cherry-pick this onto 1.9.0 release branch. [1] https://github.com/apache/geode/pull/3313 On Wed, Feb 27, 2019 at 5:32 PM Anthony Baker wrote: > I was reviewing the release branch and noticed a number of new > dependencies have been added since the last release. When you add a new > dependency, please review and follow the project license guide [1]. In > particular, update the LICENSE file in geode-assembly/src/main/dist > depending on the license type. > > Currently we need to update the LICENSE file with the additional > MIT/BSD/CDDL dependencies. We may also need to update NOTICE files. > There’s also a version conflict with multiple versions of Jackson in use > (2.9.6 / 2.9.8). > > @Sai - these need to be fixed on release/1.9.0 > > Here’s the list of additions: > > animal-sniffer-annotations-1.17.jar > checker-qual-2.5.2.jar > commons-math3-3.2.jar > error_prone_annotations-2.2.0.jar > failureaccess-1.0.jar > geo-0.7.1.jar > grumpy-core-0.2.2.jar > istack-commons-runtime-2.2.jar > j2objc-annotations-1.1.jar > javax.activation-1.2.0.jar > javax.activation-api-1.2.0.jar > jsr305-3.0.2.jar > listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar > > Removed: > > activation-1.1.1 > jaxb-core-2.2.11.jar > > Anthony > > [1] > https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors > < > https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors > > > >
Re: broken IntegrationTestOpenJDK11 on develop?
Thanks, Bruce. I have cherry-picked these on to release/1.9.0 branch. Sai On Mon, Mar 4, 2019 at 11:44 AM Bruce Schuchardt wrote: > I've updated the SSL test on develop > > commit e77145bd7d55b72770ce041d5d859aef432c (HEAD -> develop, > origin/develop) > Author: Bruce Schuchardt > Date: Mon Mar 4 11:39:32 2019 -0800 > > GEODE-2059 client SSL handshake attempts do not time out > > Updating tests to allow an SSLException with cause > SocketTimeoutException. > > > On 3/4/19 10:12 AM, Sai Boorlagadda wrote: > > I see integration tests are failing on develop. Is there anyone working > on > > it? > > This is failing on release branch too, so I would want to chery-pick if > > there is a fix. > > > > Sai > > >
broken IntegrationTestOpenJDK11 on develop?
I see integration tests are failing on develop. Is there anyone working on it? This is failing on release branch too, so I would want to chery-pick if there is a fix. Sai
Re: 1.9 release date
I started working on LICENSE issues. On Fri, Mar 1, 2019 at 3:55 PM Anthony Baker wrote: > I’ll point out that the license issue I mentioned earlier this week isn’t > resolved. And that we’re bundling potentially incompatible Jackson jars. > > Anthony > > > > On Mar 1, 2019, at 3:41 PM, Alexander Murmann > wrote: > > > > Clear quality metrics is definitely great. However, we've also seen in > the > > past that we sometimes find new issues by continue work on the code and > > some folks starting to use them on their own projects. For that reason, I > > think it might be wise to give ourselves some extra time to run into > issues > > organically. Maybe we don't need that as our coverage improves. > > > > On Fri, Mar 1, 2019 at 3:24 PM Owen Nichols wrote: > > > >> The release criteria of “based on meeting quality goals” sounds great. > >> > >> What are those quality goals exactly, and can we objectively measure > >> progress against them? > >> > >> It looks like we already have a number of well-defined quality goals in > >> https://cwiki.apache.org/confluence/display/GEODE/Release+process < > >> https://cwiki.apache.org/confluence/display/GEODE/Release+process> > >> Presuming this is up-to-date, we need to satisfy 8 required quality > goals > >> before we can release. > >> > >> Thus far, we have not met the goal "Build is successful including > >> automated tests”. > >> To meet it, is one “all green" run in the release pipeline < > >> > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main?groups=complete > > > >> sufficient? Or should we require 2 or 3 “all green” runs on the same > SHA? > >> > >> Do Windows tests count toward “all green”? Currently they are not in > the > >> default view (same as 1.8.0). > >> > >> The Geode release process document above also lists an additional 11 > >> quality goals as “optional.” I assume these are meant as suggestions > the > >> community may wish to consider when voting on a release? > >> > >> If anyone feels the existing release process documentation does not > >> adequately define what quality goals must be met in order to release, > let’s > >> discuss (and get those docs updated!) > >> > >> -Owen > >> > >>> On Mar 1, 2019, at 8:02 AM, Anthony Baker wrote: > >>> > >>> IMHO we start release work based on a quarterly schedule and we finish > >> it based on meeting quality goals. So right now I’m less worried about > >> 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, at 6:00 PM, Alexander Murmann > >> wrote: > > 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 is to > aim > for last week of March or maybe even week of April 1st. > > What do you all think? > >>> > >> > >> > > > > -- > > Alexander J. Murmann > > (650) 283-1933 > >
Re: 1.9 release date
I am aligned here that we should not be firm on a date be flexible to get a more stable release out. But could someone explain to me how would we measure this stability? The pipelines are green and the community members have cherry-picked all issues that were critical. Unless we have some process or measure to identify the stability there is no way we can pick a date whether its April 1st or earlier to create a release candidate. Sai On Fri, Mar 1, 2019 at 8:51 AM Michael Stolz wrote: > I think this is exactly the right balance. Yay! > > -- > Mike Stolz > Principal Engineer, GemFire Product Lead > Mobile: +1-631-835-4771 > > > > On Fri, Mar 1, 2019 at 11:48 AM Ryan McMahon wrote: > > > +1 to prioritizing quality over releasing on the desired cadence. The > > quarterly release cadence is a good goal, but it shouldn't be a strict > rule > > if there is more work to be done to ensure good quality. > > > > Ryan > > > > On Fri, Mar 1, 2019 at 8:02 AM Anthony Baker wrote: > > > > > IMHO we start release work based on a quarterly schedule and we finish > it > > > based on meeting quality goals. So right now I’m less worried about > 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, at 6:00 PM, Alexander Murmann > > > wrote: > > > > > > > > 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 is to > > aim > > > > for last week of March or maybe even week of April 1st. > > > > > > > > What do you all think? > > > > > > > > >
Re: would like to bring GEODE-6447 to 1.9.0 (fix bind exceptions in Windows tests)
+1 On Thu, Feb 28, 2019 at 6:25 PM Owen Nichols wrote: > This would eliminate a lot of noise from Windows tests, any objection to > cherry-picking it to release/1.9.0? > > This is a test-only change. > > Thanks, > -Owen
Re: I need to merge the fix for 6468 into release/1.9.0
+1 for merging this fix to release/1.9.0 as this is required for the NIO related changes that are already merged. On Thu, Feb 28, 2019 at 4:47 PM Bruce Schuchardt wrote: > This is another ticket associated with the SSL/NIO work that is already > in release/1.9.0 > > commit 6d1d82a15a5c548b2aafeff8bf023d12044581e7 (HEAD -> develop, > origin/develop) > Author: Bruce Schuchardt > Date: Thu Feb 28 16:44:30 2019 -0800 > > GEODE-6468 [CI Failure] ClusterCommunicationsDUnitTest fails on > createEntryAndVerifyUpdate > > Modified Connection.java to not modify the app-data input buffer in > the > handshake thread after notifying the handshake waiter. > >
Merging GEODE-6464 to release/1.9.0
This is a change to windows packer image to use a pinned version of OpenSSH to 7.2.2.1 as the newer version caused the ssh session to not be terminated even after the gradle completes successfully leading the actual CI job to timeout[1]. We never had a green run of *IntegrationTest jobs on windows on the release branch, so I would like to get this change to the packer images. [1] https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main/jobs/WindowsIntegrationTestOpenJDK11/builds/6
next steps on release/1.9.0
By end of this week, I am planning to create the first release candidate. Are there any other issues other than this last one? - GEODE-6359 - Bruce is looking into it. - geode-examples using https in build scripts. There are about 6[1] issues in JIRA that are in open/in-progress/re-opened status for 1.9.0. Can I request all the devs to reflect JIRA with current status? GEODE-6067 - add gfsh list data-source command - Darrel Schneider GEODE-5817 - CI Failure: StopServerAccepta... - Kenneth Howe GEODE-5816 - ClusterStartupRule fails to ... - Dan Smith GEODE-5711 - create jndi-binding gfsh ... - Karen Smoler Miller GEODE-4794 - ConfigurePDXCommand - Joey McAllister GEODE-2113 - Implement SSL over NIO - Joey McAllister [1]https://issues.apache.org /jira/browse/GEODE-6107?jql=project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%201.9.0
Re: GEODE-6389 fixed in release/1.9.0
FYI all. GEODE-6338 is already on the release branch. Thanks, Bruce for the update. https://issues.apache.org/jira/browse/GEODE-6338 On Wed, Feb 27, 2019 at 10:10 AM Anthony Baker wrote: > Sorry I meant GEODE-6338. > > > On Feb 27, 2019, at 9:41 AM, Sai Boorlagadda > wrote: > > > > Are you asking about GEODE-6343? > > > > Sai > > > > On Wed, Feb 27, 2019 at 7:51 AM Anthony Baker wrote: > > > >> Cool! Is GEODE-63438 also important to fix and merge into 1.9.0? > >> > >> Anthony > >> > >> > >>> On Feb 22, 2019, at 9:01 AM, Bruce Schuchardt > >> wrote: > >>> > >>> This issue has been resolved on develop and release/1.9.0 > >>> > >> > >> > >
Re: GEODE-6389 fixed in release/1.9.0
Are you asking about GEODE-6343? Sai On Wed, Feb 27, 2019 at 7:51 AM Anthony Baker wrote: > Cool! Is GEODE-63438 also important to fix and merge into 1.9.0? > > Anthony > > > > On Feb 22, 2019, at 9:01 AM, Bruce Schuchardt > wrote: > > > > This issue has been resolved on develop and release/1.9.0 > > > >
Re: Release branch for Apache Geode 1.9.0 has been cut
Jason, You can go ahead and cherry pick onto the release branch. Sai On Wed, Feb 27, 2019 at 8:54 AM Jason Huynh wrote: > Hi Sai, > > Fix for GEODE-6404 is now on develop > (2be6375a775b6b0d00d0c41a1e2a3bf4b8745a46) > Would you be able to pull it into the 1.9 branch or would you like me to? > > Thanks, > -Jason > > On Thu, Feb 21, 2019 at 3:37 PM Sai Boorlagadda > > wrote: > > > GEODE-6359 is unassigned in JIRA. Who is working on it? > > > > On Wed, Feb 20, 2019 at 9:08 AM Jason Huynh wrote: > > > > > 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 processLeaveRequests. I think the fix would be to just copy > > the > > > list or not log the list of members. > > > > > > > > > > > > On Tue, Feb 19, 2019 at 5:35 PM Sai Boorlagadda < > > sai.boorlaga...@gmail.com > > > > > > > wrote: > > > > > > > GEODE-6404 can be cherry-picked when it is ready. > > > > The release branch is cut to avoid any risk of regression that > > > > can be introduced by new work being merged to develop. > > > > > > > > Do you mean GEODE-6369? > > > > > > > > On Tue, Feb 19, 2019 at 4:50 PM Jason Huynh > wrote: > > > > > > > > > Correction, GEODE-6359 and GEODE-6404. > > > > > > > > > > On Tue, Feb 19, 2019 at 4:49 PM Jason Huynh > > wrote: > > > > > > > > > > > I still haven't gotten GEODE-6404 in... I assumed that the > tickets > > > from > > > > > > the last thread were going to make it into this release? > > > > > > > > > > > > Also I think GEODE-6539 should be fixed, it looks like an NPE > that > > > > occurs > > > > > > when we process leave requests. > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 19, 2019 at 2:25 PM Sai Boorlagadda < > > > > > sai.boorlaga...@gmail.com> > > > > > > wrote: > > > > > > > > > > > >> My earlier release branch has created as 'release/1.9' without > the > > > > patch > > > > > >> number in semver. > > > > > >> So I have re-created a new release branch 'release/1.9.0'. > > > > > >> > > > > > >> I will go ahead delete the unwanted branch 'release/1.9' > > > > > >> > > > > > >> Sai > > > > > >> On Tue, Feb 19, 2019 at 2:17 PM Sai Boorlagadda < > > > > > >> sai.boorlaga...@gmail.com> > > > > > >> wrote: > > > > > >> > > > > > >> > Hello Everyone, > > > > > >> > > > > > > >> > As discussed in my earlier email I have created a new release > > > branch > > > > > >> for Apache Geode 1.9.0 - "release/1.9" > > > > > >> > > > > > > >> > 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. > > > > > >> > > > > > > >> > Regards > > > > > >> > Sai > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > >
Re: build is broken on develop
I fixed the build. My apologies I didn't rebase before merging my PR. On Tue, Feb 26, 2019 at 12:33 PM Sai Boorlagadda wrote: > My commit broke the build on develop. I am on it. > >
build is broken on develop
My commit broke the build on develop. I am on it.
Re: Merging GEODE-6424 into release/1.9.0
+1 for bringing in this fix to 1.9.0 (esp if this fixes a race condition that is introduced by GEODE-6424 which is already merged). On Fri, Feb 22, 2019 at 10:56 AM Helena Bales wrote: > Does anyone have an issue with merging > https://github.com/apache/geode/pull/3220 to the 1.9.0 release branch? > > It fixes a race condition introduced by the fix to GEODE-6424 that was > approved above. It is critical that we keep the fix to GEODE-6424 in 1.9.0 > in order to be able to proceed with benchmarking Geode, so we should also > merge this fix to avoid issues with concurrent access and modification of > gauge statistics. > > ~Helena > > On Wed, Feb 20, 2019 at 3:58 PM Jacob Barrett wrote: > > > My bad! Sorry! > > > > > On Feb 20, 2019, at 3:22 PM, Sai Boorlagadda < > sai.boorlaga...@gmail.com> > > 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 Barrett > > wrote: > > >> > > >> 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 < > > >> 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 > fix > > >> baselines will continue to vary by as much as 45% making them useless. > > >>>> > > >>>> It’s also a big performance boost. Concurrent local cache gets see > > >> about a 50% bump in throughput due to reduced contention for stats, > even > > >> with timed stats enabled. Other operations haven’t been benchmarked > but > > >> should see similar improvements where stats were the bottleneck. > > >>>> > > >>>> -Jake > > >>>> > > >>>> > > >> > > >
Re: Release branch for Apache Geode 1.9.0 has been cut
GEODE-6359 is unassigned in JIRA. Who is working on it? On Wed, Feb 20, 2019 at 9:08 AM Jason Huynh wrote: > 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 processLeaveRequests. I think the fix would be to just copy the > list or not log the list of members. > > > > On Tue, Feb 19, 2019 at 5:35 PM Sai Boorlagadda > > wrote: > > > GEODE-6404 can be cherry-picked when it is ready. > > The release branch is cut to avoid any risk of regression that > > can be introduced by new work being merged to develop. > > > > Do you mean GEODE-6369? > > > > On Tue, Feb 19, 2019 at 4:50 PM Jason Huynh wrote: > > > > > Correction, GEODE-6359 and GEODE-6404. > > > > > > On Tue, Feb 19, 2019 at 4:49 PM Jason Huynh wrote: > > > > > > > I still haven't gotten GEODE-6404 in... I assumed that the tickets > from > > > > the last thread were going to make it into this release? > > > > > > > > Also I think GEODE-6539 should be fixed, it looks like an NPE that > > occurs > > > > when we process leave requests. > > > > > > > > > > > > > > > > On Tue, Feb 19, 2019 at 2:25 PM Sai Boorlagadda < > > > sai.boorlaga...@gmail.com> > > > > wrote: > > > > > > > >> My earlier release branch has created as 'release/1.9' without the > > patch > > > >> number in semver. > > > >> So I have re-created a new release branch 'release/1.9.0'. > > > >> > > > >> I will go ahead delete the unwanted branch 'release/1.9' > > > >> > > > >> Sai > > > >> On Tue, Feb 19, 2019 at 2:17 PM Sai Boorlagadda < > > > >> sai.boorlaga...@gmail.com> > > > >> wrote: > > > >> > > > >> > Hello Everyone, > > > >> > > > > >> > As discussed in my earlier email I have created a new release > branch > > > >> for Apache Geode 1.9.0 - "release/1.9" > > > >> > > > > >> > 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. > > > >> > > > > >> > Regards > > > >> > Sai > > > >> > > > > >> > > > > >> > > > > > > > > > >
Re: Release branch for Apache Geode 1.9.0 has been cut
I want to merge a change related to CI infrastructure (windows image that we use to run tests on Windows). This change will fix the failing windows tests. Find more details on GEODE-6438 Sai On Wed, Feb 20, 2019 at 9:26 AM Alexander Murmann wrote: > > > > 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 > <https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule>, the > actual release shouldn't happen till March 1st. > > On Wed, Feb 20, 2019 at 9:08 AM Jason Huynh wrote: > > > 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 processLeaveRequests. I think the fix would be to just copy > the > > list or not log the list of members. > > > > > > > > On Tue, Feb 19, 2019 at 5:35 PM Sai Boorlagadda < > sai.boorlaga...@gmail.com > > > > > wrote: > > > > > GEODE-6404 can be cherry-picked when it is ready. > > > The release branch is cut to avoid any risk of regression that > > > can be introduced by new work being merged to develop. > > > > > > Do you mean GEODE-6369? > > > > > > On Tue, Feb 19, 2019 at 4:50 PM Jason Huynh wrote: > > > > > > > Correction, GEODE-6359 and GEODE-6404. > > > > > > > > On Tue, Feb 19, 2019 at 4:49 PM Jason Huynh > wrote: > > > > > > > > > I still haven't gotten GEODE-6404 in... I assumed that the tickets > > from > > > > > the last thread were going to make it into this release? > > > > > > > > > > Also I think GEODE-6539 should be fixed, it looks like an NPE that > > > occurs > > > > > when we process leave requests. > > > > > > > > > > > > > > > > > > > > On Tue, Feb 19, 2019 at 2:25 PM Sai Boorlagadda < > > > > sai.boorlaga...@gmail.com> > > > > > wrote: > > > > > > > > > >> My earlier release branch has created as 'release/1.9' without the > > > patch > > > > >> number in semver. > > > > >> So I have re-created a new release branch 'release/1.9.0'. > > > > >> > > > > >> I will go ahead delete the unwanted branch 'release/1.9' > > > > >> > > > > >> Sai > > > > >> On Tue, Feb 19, 2019 at 2:17 PM Sai Boorlagadda < > > > > >> sai.boorlaga...@gmail.com> > > > > >> wrote: > > > > >> > > > > >> > Hello Everyone, > > > > >> > > > > > >> > As discussed in my earlier email I have created a new release > > branch > > > > >> for Apache Geode 1.9.0 - "release/1.9" > > > > >> > > > > > >> > 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. > > > > >> > > > > > >> > Regards > > > > >> > Sai > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > >
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, 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 < > 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 fix > baselines will continue to vary by as much as 45% making them useless. > >> > >> It’s also a big performance boost. Concurrent local cache gets see > about a 50% bump in throughput due to reduced contention for stats, even > with timed stats enabled. Other operations haven’t been benchmarked but > should see similar improvements where stats were the bottleneck. > >> > >> -Jake > >> > >> >
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 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 with release/1.7.0 and release/1.8.0? > > -Jake > >
Re: Release branch for Apache Geode 1.9.0 has been cut
GEODE-6404 can be cherry-picked when it is ready. The release branch is cut to avoid any risk of regression that can be introduced by new work being merged to develop. Do you mean GEODE-6369? On Tue, Feb 19, 2019 at 4:50 PM Jason Huynh wrote: > Correction, GEODE-6359 and GEODE-6404. > > On Tue, Feb 19, 2019 at 4:49 PM Jason Huynh wrote: > > > I still haven't gotten GEODE-6404 in... I assumed that the tickets from > > the last thread were going to make it into this release? > > > > Also I think GEODE-6539 should be fixed, it looks like an NPE that occurs > > when we process leave requests. > > > > > > > > On Tue, Feb 19, 2019 at 2:25 PM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > > wrote: > > > >> My earlier release branch has created as 'release/1.9' without the patch > >> number in semver. > >> So I have re-created a new release branch 'release/1.9.0'. > >> > >> I will go ahead delete the unwanted branch 'release/1.9' > >> > >> Sai > >> On Tue, Feb 19, 2019 at 2:17 PM Sai Boorlagadda < > >> sai.boorlaga...@gmail.com> > >> wrote: > >> > >> > Hello Everyone, > >> > > >> > As discussed in my earlier email I have created a new release branch > >> for Apache Geode 1.9.0 - "release/1.9" > >> > > >> > 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. > >> > > >> > Regards > >> > Sai > >> > > >> > > >> > > >
Re: Release pipeline for 1.9.0
I am on it. On Tue, Feb 19, 2019 at 2:25 PM Sai Boorlagadda wrote: > Hello Geode Dev Community, > > As we have created a release branch for Apache Geode 1.9.0 - "release/1.9.0" > please create a CI pipeline for running tests on this branch. > > Regards > Sai > >
Regarding variable name 1.10.0 ordinal?
I am in process of adding a new ordinal for 1.10.0 and see that currently the variables are named as GEODE_XYZ for a release x.y.x (eg, private static final byte GEODE_1100_ORDINAL = 105;) Question is are there any side effects for naming it as GEODE_1100_ORDINAL for 1.10.0? Not sure if there is a better way of doing this. Sai
Re: Release branch for Apache Geode 1.9.0 has been cut
My earlier release branch has created as 'release/1.9' without the patch number in semver. So I have re-created a new release branch 'release/1.9.0'. I will go ahead delete the unwanted branch 'release/1.9' Sai On Tue, Feb 19, 2019 at 2:17 PM Sai Boorlagadda wrote: > Hello Everyone, > > As discussed in my earlier email I have created a new release branch for > Apache Geode 1.9.0 - "release/1.9" > > 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. > > Regards > Sai > >
Release pipeline for 1.9.0
Hello Geode Dev Community, As we have created a release branch for Apache Geode 1.9.0 - "release/1.9.0" please create a CI pipeline for running tests on this branch. Regards Sai
Re: Geode 1.9 Release Manager
Thanks Bruce. I will chery-pick this commit onto the new release branch. On Tue, Feb 19, 2019 at 1:06 PM Bruce Schuchardt wrote: > The fix for Geode-6369 has been pushed to develop. This needs to go in > the 1.9 release as it fixes some serious issues in auto-reconnect > including a distributed deadlock. > > On 2/15/19 2:15 PM, Sai Boorlagadda wrote: > > There are about 8[1] issues in JIRA that are in > open/in-progress/re-opened > > status for 1.9.0. > > Can I request all the devs to reflect JIRA with current status? > > > > [1] > > > https://issues.apache.org/jira/browse/GEODE-6107?jql=project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%201.9.0 > > > > Sai > > > > On Fri, Feb 15, 2019 at 12:56 PM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > > wrote: > > > >> Thanks Dave. I keep a note to include Geode Native. > >> > >> As we are including only a source release for Geode Native > >> do we need to create a release branch? Or just tag it? > >> > >> Though we will eventually be tagging Geode & Geode Examples repos. > >> So until it gets released I think as a place holder I can go ahead still > >> create a release branch for Geode Native? > >> > >> Sai > >> > >> > >> On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes wrote: > >> > >>> Sai, > >>> The Geode 1.8 release included (for the first time) a source snapshot > of > >>> the geode-native repo. > >>> As far as I know, the same treatment would be in order for v1.9. > >>> > >>> > >>> On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt < > bschucha...@pivotal.io> > >>> wrote: > >>> > >>>> I would like to get GEODE-6369 into the next release but that can be > >>>> done in a cherry-pick after I finish testing. The changes are in in > >>>> discovery, joining the cluster and in failure detection so they've > >>>> needed extensive testing. > >>>> > >>>> On 2/15/19 7:53 AM, Sai Boorlagadda wrote: > >>>>> I am planning to cut the1.9 release branch today after merging this > >>>>> PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345. > >>>>> > >>>>> Is there anything other than that I should be aware of? > >>>>> > >>>>> Here is the list of issues that were requested to be included into > >>> 1.9. > >>>>> If there is any plan to merge any of these today let me know and > >>>>> I can cut the branch after that. > >>>>> > >>>>> GEODE-6334 - CachePerfStats operation count stats may wrap to > negative > >>>>> values > >>>>> > >>>>> GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative > >>> value > >>>>> GEODE-6369 - Cache-creation failure after a successful auto-reconnect > >>>>> causes subsequent NPE > >>>>> > >>>>> GEODE-6391 - Event IDs must be included in the PartitioneRegion > >>> messages > >>>>> GEODE-6404 - review use of computeIfAbsent across the code base > >>>>> > >>>>> > >>>>> (experimental and dropped) > >>>>> > >>>>> GEODE-6393 - Replace synchronization lock with AtomicReference for > >>>>> InternalLocator > >>>>> > >>>>> > >>>>> - > >>>>> > >>>>> Sai > >>>>> > >>>>> On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda < > >>>> sai.boorlaga...@gmail.com> > >>>>> wrote: > >>>>> > >>>>>> I didn't mean blocking a release but the release process (including > >>>>>> cutting the branch). > >>>>>> > >>>>>> > >>>>>> I thought there was a consensus about strictly cutting a > >>>>>> > >>>>>> branch[1] with our new fixed minor release cadence and > >>>>>> > >>>>>> only allow critical fixes. > >>>>>> > >>>>>> > >>>>>> I assumed that any critical fixes that are allowed onto the > >>>>>> > >>>>>> release branch are
Release branch for Apache Geode 1.9.0 has been cut
Hello Everyone, As discussed in my earlier email I have created a new release branch for Apache Geode 1.9.0 - "release/1.9" 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. Regards Sai
Re: Geode 1.9 Release Manager
There are about 8[1] issues in JIRA that are in open/in-progress/re-opened status for 1.9.0. Can I request all the devs to reflect JIRA with current status? [1] https://issues.apache.org/jira/browse/GEODE-6107?jql=project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%201.9.0 Sai On Fri, Feb 15, 2019 at 12:56 PM Sai Boorlagadda wrote: > Thanks Dave. I keep a note to include Geode Native. > > As we are including only a source release for Geode Native > do we need to create a release branch? Or just tag it? > > Though we will eventually be tagging Geode & Geode Examples repos. > So until it gets released I think as a place holder I can go ahead still > create a release branch for Geode Native? > > Sai > > > On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes wrote: > >> Sai, >> The Geode 1.8 release included (for the first time) a source snapshot of >> the geode-native repo. >> As far as I know, the same treatment would be in order for v1.9. >> >> >> On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt >> wrote: >> >> > I would like to get GEODE-6369 into the next release but that can be >> > done in a cherry-pick after I finish testing. The changes are in in >> > discovery, joining the cluster and in failure detection so they've >> > needed extensive testing. >> > >> > On 2/15/19 7:53 AM, Sai Boorlagadda wrote: >> > > I am planning to cut the1.9 release branch today after merging this >> > > PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345. >> > > >> > > Is there anything other than that I should be aware of? >> > > >> > > Here is the list of issues that were requested to be included into >> 1.9. >> > > If there is any plan to merge any of these today let me know and >> > > I can cut the branch after that. >> > > >> > > GEODE-6334 - CachePerfStats operation count stats may wrap to negative >> > > values >> > > >> > > GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative >> value >> > > >> > > GEODE-6369 - Cache-creation failure after a successful auto-reconnect >> > > causes subsequent NPE >> > > >> > > GEODE-6391 - Event IDs must be included in the PartitioneRegion >> messages >> > > >> > > GEODE-6404 - review use of computeIfAbsent across the code base >> > > >> > > >> > > (experimental and dropped) >> > > >> > > GEODE-6393 - Replace synchronization lock with AtomicReference for >> > > InternalLocator >> > > >> > > >> > > - >> > > >> > > Sai >> > > >> > > On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda < >> > sai.boorlaga...@gmail.com> >> > > wrote: >> > > >> > >> I didn't mean blocking a release but the release process (including >> > >> cutting the branch). >> > >> >> > >> >> > >> I thought there was a consensus about strictly cutting a >> > >> >> > >> branch[1] with our new fixed minor release cadence and >> > >> >> > >> only allow critical fixes. >> > >> >> > >> >> > >> I assumed that any critical fixes that are allowed onto the >> > >> >> > >> release branch are the ones that are identified on the branch >> > >> >> > >> after it is cut and not the ones that are already known. >> > >> >> > >> >> > >> Correct me if my understanding is wrong. >> > >> >> > >> >> > >> [1] >> > >> >> > >> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E >> > >> >> > >> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag >> wrote: >> > >> >> > >>> I could not find any DISCUSS mails about not blocking a release. I >> may >> > be >> > >>> wrong, I apologize for that but could point me to the mail / >> > documentation >> > >>> about the release management. >> > >>> >> > >>> Regards >> > >>> Naba >> > >>> >> > >>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda < >> >
Re: Geode 1.9 Release Manager
Thanks Dave. I keep a note to include Geode Native. As we are including only a source release for Geode Native do we need to create a release branch? Or just tag it? Though we will eventually be tagging Geode & Geode Examples repos. So until it gets released I think as a place holder I can go ahead still create a release branch for Geode Native? Sai On Fri, Feb 15, 2019 at 9:51 AM Dave Barnes wrote: > Sai, > The Geode 1.8 release included (for the first time) a source snapshot of > the geode-native repo. > As far as I know, the same treatment would be in order for v1.9. > > > On Fri, Feb 15, 2019 at 9:01 AM Bruce Schuchardt > wrote: > > > I would like to get GEODE-6369 into the next release but that can be > > done in a cherry-pick after I finish testing. The changes are in in > > discovery, joining the cluster and in failure detection so they've > > needed extensive testing. > > > > On 2/15/19 7:53 AM, Sai Boorlagadda wrote: > > > I am planning to cut the1.9 release branch today after merging this > > > PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345. > > > > > > Is there anything other than that I should be aware of? > > > > > > Here is the list of issues that were requested to be included into 1.9. > > > If there is any plan to merge any of these today let me know and > > > I can cut the branch after that. > > > > > > GEODE-6334 - CachePerfStats operation count stats may wrap to negative > > > values > > > > > > GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative value > > > > > > GEODE-6369 - Cache-creation failure after a successful auto-reconnect > > > causes subsequent NPE > > > > > > GEODE-6391 - Event IDs must be included in the PartitioneRegion > messages > > > > > > GEODE-6404 - review use of computeIfAbsent across the code base > > > > > > > > > (experimental and dropped) > > > > > > GEODE-6393 - Replace synchronization lock with AtomicReference for > > > InternalLocator > > > > > > > > > - > > > > > > Sai > > > > > > On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda < > > sai.boorlaga...@gmail.com> > > > wrote: > > > > > >> I didn't mean blocking a release but the release process (including > > >> cutting the branch). > > >> > > >> > > >> I thought there was a consensus about strictly cutting a > > >> > > >> branch[1] with our new fixed minor release cadence and > > >> > > >> only allow critical fixes. > > >> > > >> > > >> I assumed that any critical fixes that are allowed onto the > > >> > > >> release branch are the ones that are identified on the branch > > >> > > >> after it is cut and not the ones that are already known. > > >> > > >> > > >> Correct me if my understanding is wrong. > > >> > > >> > > >> [1] > > >> > > > https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E > > >> > > >> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag wrote: > > >> > > >>> I could not find any DISCUSS mails about not blocking a release. I > may > > be > > >>> wrong, I apologize for that but could point me to the mail / > > documentation > > >>> about the release management. > > >>> > > >>> 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? > > >>>> > > >>>> > > >>>> On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann < > > amurm...@apache.org > > >>>> > > >>>> wrote: > > >>>> > > >>>>> Usually I am a proponent of cutting a branch and then fixing things > > on > > >>>>> there where things are more stable. In this case we seem to have a > > >>> large > > >>>>> number of fairly serious concerns. Do we think the cost of putting > > >>> this > > >>>>> many fixes on develop + the release branch out-weights the benefit > of > > >>>> less > > >>>>> risk of new issues being introduced? > > >>>>> > > >>>>> Thoughts? > > >>>>> > > >>>>> Thank you, Sai for taking over! > > >>>>> > > >>>>> On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda < > > >>>>> sai.boorlaga...@gmail.com> > > >>>>> wrote: > > >>>>> > > >>>>>> I volunteer to be the release manager for 1.9. > > >>>>>> > > >>>>>> Sai > > >>>>>> > > >>>>>> On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann < > > >>> amurm...@apache.org > > >>>>>> wrote: > > >>>>>> > > >>>>>>> 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 < > > >>>> amurm...@apache.org > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>>> 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: Geode 1.9 Release Manager
BTW, Is PR #3195 is planned to merge today? On Fri, Feb 15, 2019 at 7:53 AM Sai Boorlagadda wrote: > I am planning to cut the1.9 release branch today after merging this > PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345. > > Is there anything other than that I should be aware of? > > Here is the list of issues that were requested to be included into 1.9. > If there is any plan to merge any of these today let me know and > I can cut the branch after that. > > GEODE-6334 - CachePerfStats operation count stats may wrap to negative > values > > GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative value > > GEODE-6369 - Cache-creation failure after a successful auto-reconnect > causes subsequent NPE > > GEODE-6391 - Event IDs must be included in the PartitioneRegion messages > > GEODE-6404 - review use of computeIfAbsent across the code base > > > (experimental and dropped) > > GEODE-6393 - Replace synchronization lock with AtomicReference for > InternalLocator > > > - > > Sai > > On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda > wrote: > >> I didn't mean blocking a release but the release process (including >> cutting the branch). >> >> >> I thought there was a consensus about strictly cutting a >> >> branch[1] with our new fixed minor release cadence and >> >> only allow critical fixes. >> >> >> I assumed that any critical fixes that are allowed onto the >> >> release branch are the ones that are identified on the branch >> >> after it is cut and not the ones that are already known. >> >> >> Correct me if my understanding is wrong. >> >> >> [1] >> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E >> >> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag wrote: >> >>> I could not find any DISCUSS mails about not blocking a release. I may be >>> wrong, I apologize for that but could point me to the mail / >>> documentation >>> about the release management. >>> >>> 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? >>> > >>> > >>> > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann < >>> amurm...@apache.org> >>> > wrote: >>> > >>> > > Usually I am a proponent of cutting a branch and then fixing things >>> on >>> > > there where things are more stable. In this case we seem to have a >>> large >>> > > number of fairly serious concerns. Do we think the cost of putting >>> this >>> > > many fixes on develop + the release branch out-weights the benefit of >>> > less >>> > > risk of new issues being introduced? >>> > > >>> > > Thoughts? >>> > > >>> > > Thank you, Sai for taking over! >>> > > >>> > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda < >>> > > sai.boorlaga...@gmail.com> >>> > > wrote: >>> > > >>> > > > I volunteer to be the release manager for 1.9. >>> > > > >>> > > > Sai >>> > > > >>> > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann < >>> amurm...@apache.org >>> > > >>> > > > wrote: >>> > > > >>> > > > > 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 < >>> > amurm...@apache.org >>> > > > >>> > > > > wrote: >>> > > > > >>> > > > > > 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: Geode 1.9 Release Manager
I am planning to cut the1.9 release branch today after merging this PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345. Is there anything other than that I should be aware of? Here is the list of issues that were requested to be included into 1.9. If there is any plan to merge any of these today let me know and I can cut the branch after that. GEODE-6334 - CachePerfStats operation count stats may wrap to negative values GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative value GEODE-6369 - Cache-creation failure after a successful auto-reconnect causes subsequent NPE GEODE-6391 - Event IDs must be included in the PartitioneRegion messages GEODE-6404 - review use of computeIfAbsent across the code base (experimental and dropped) GEODE-6393 - Replace synchronization lock with AtomicReference for InternalLocator - Sai On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda wrote: > I didn't mean blocking a release but the release process (including > cutting the branch). > > > I thought there was a consensus about strictly cutting a > > branch[1] with our new fixed minor release cadence and > > only allow critical fixes. > > > I assumed that any critical fixes that are allowed onto the > > release branch are the ones that are identified on the branch > > after it is cut and not the ones that are already known. > > > Correct me if my understanding is wrong. > > > [1] > https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E > > On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag wrote: > >> I could not find any DISCUSS mails about not blocking a release. I may be >> wrong, I apologize for that but could point me to the mail / documentation >> about the release management. >> >> 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? >> > >> > >> > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann > > >> > wrote: >> > >> > > Usually I am a proponent of cutting a branch and then fixing things on >> > > there where things are more stable. In this case we seem to have a >> large >> > > number of fairly serious concerns. Do we think the cost of putting >> this >> > > many fixes on develop + the release branch out-weights the benefit of >> > less >> > > risk of new issues being introduced? >> > > >> > > Thoughts? >> > > >> > > Thank you, Sai for taking over! >> > > >> > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda < >> > > sai.boorlaga...@gmail.com> >> > > wrote: >> > > >> > > > I volunteer to be the release manager for 1.9. >> > > > >> > > > Sai >> > > > >> > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann < >> amurm...@apache.org >> > > >> > > > wrote: >> > > > >> > > > > 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 < >> > amurm...@apache.org >> > > > >> > > > > wrote: >> > > > > >> > > > > > 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: Geode 1.9 Release Manager
I didn't mean blocking a release but the release process (including cutting the branch). I thought there was a consensus about strictly cutting a branch[1] with our new fixed minor release cadence and only allow critical fixes. I assumed that any critical fixes that are allowed onto the release branch are the ones that are identified on the branch after it is cut and not the ones that are already known. Correct me if my understanding is wrong. [1] https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag wrote: > I could not find any DISCUSS mails about not blocking a release. I may be > wrong, I apologize for that but could point me to the mail / documentation > about the release management. > > 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? > > > > > > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann > > wrote: > > > > > Usually I am a proponent of cutting a branch and then fixing things on > > > there where things are more stable. In this case we seem to have a > large > > > number of fairly serious concerns. Do we think the cost of putting this > > > many fixes on develop + the release branch out-weights the benefit of > > less > > > risk of new issues being introduced? > > > > > > Thoughts? > > > > > > Thank you, Sai for taking over! > > > > > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda < > > > sai.boorlaga...@gmail.com> > > > wrote: > > > > > > > I volunteer to be the release manager for 1.9. > > > > > > > > Sai > > > > > > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann < > amurm...@apache.org > > > > > > > wrote: > > > > > > > > > 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 < > > amurm...@apache.org > > > > > > > > > wrote: > > > > > > > > > > > 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: Geode 1.9 Release Manager
Did we not agreed that we won't be blocking a release to include fixes as we are in a fixed release schedule? On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann wrote: > Usually I am a proponent of cutting a branch and then fixing things on > there where things are more stable. In this case we seem to have a large > number of fairly serious concerns. Do we think the cost of putting this > many fixes on develop + the release branch out-weights the benefit of less > risk of new issues being introduced? > > Thoughts? > > Thank you, Sai for taking over! > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > 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 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 is interested in being the release manager for > > 1.9? > > > > > > > > Thank you! > > > > > > > > > >
Re: Geode 1.9 Release Manager
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 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 is interested in being the release manager for 1.9? > > > > Thank you! > > >
Re: [VOTE] Apache Geode 1.8.0 RC2
Thanks Naba. I couldn't get this test to pass. Anyways if it still counts +1 for the release. I am okay to release native code if the version doesn't default to 1.8.0 as we are not including binaries. Sai On Tue, Dec 11, 2018 at 7:15 AM Jacob Barrett wrote: > The java bits generate a property file that goes in the source release > that encapsulates all the version info. Maybe native should too. > > > On Dec 11, 2018, at 6:47 AM, Ernest Burghardt > wrote: > > > > If the community desires the default dev version to match the release, > > let's file a JIRA and change this... anyone else have an opinion on this > > default version? > > Thanks! > > EB > > > >> On Mon, Dec 10, 2018 at 10:28 PM Jacob Barrett > wrote: > >> > >> -0 > >> > >> I don’t think a user should have to specify a version when building the > >> source release of geode-native. If you don’t specify a version it > defaults > >> to the development version of 0.0.42. It should probably default to the > >> source release version. > >> > >> Outside of that issue the native sources build as expected. > >> > >> -Jake > >> > >> >
Re: [VOTE] Apache Geode 1.8.0 RC2
-0 - Ran examples - Building geode from source distribution or release branch consistently fails 1 unit test org.apache.geode.internal.cache.partitioned.rebalance.PartitionedRegionLoadModelJUnitTest > testRedundancySatisfactionPreferRemoteIp FAILED As CI is green on unit tests, I am considering this to do with my environment. If someone has already seen this and has a solution I can go with +1. Sai On Mon, Dec 10, 2018 at 9:27 PM Jacob Barrett wrote: > -0 > > I don’t think a user should have to specify a version when building the > source release of geode-native. If you don’t specify a version it defaults > to the development version of 0.0.42. It should probably default to the > source release version. > > Outside of that issue the native sources build as expected. > > -Jake > >
Re: [DISCUSS] Cutting 1.8 release branch
Sure! agree that we should hold the releases unless there is a critical issue. This is not a gating issue and the code is already committed to develop. Sai On Thu, Nov 1, 2018 at 1:03 PM Alexander Murmann wrote: > In the spirit of the previously discussed timed releases, we should only > hold cutting the release for critical issues, that for some reason (not > sure how that might be) should not be fixed after the branch has been cut. > Waiting for features leads us down the slippery slope we are trying to > avoid 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: > > > > > 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: [DISCUSS] Cutting 1.8 release branch
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: > 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: [Discuss] showcasing community work
That a great suggestion. I will see if I can add a new page. On Thu, Oct 18, 2018 at 11:21 AM Swapnil Bawaskar wrote: > Would it make sense to put these under an "extensions" page, rather than a > "community" page? > > On Tue, Oct 16, 2018 at 5:05 PM Sai Boorlagadda > > wrote: > > > Thanks, John for your inputs. I will be adding the page to capture these > > details. > > If there are no objections then I would go ahead and add a new section to > > http://geode.apache.org/community/ > > > > Sai > > > > On Thu, Oct 11, 2018 at 12:07 PM John Blum wrote: > > > > > This is a very nice idea Sai. > > > > > > Perhaps a page with a table containing... > > > > > > * Project Name > > > * Project Description (Summary) > > > * Project License > > > * Project URL (to GitHub page, Website, etc, where users can find out > > more > > > information) > > > > > > Food for thought. > > > > > > > > > On Thu, Oct 11, 2018 at 12:04 PM, Sai Boorlagadda < > > > sai.boorlaga...@gmail.com > > > > wrote: > > > > > > > I would like to discuss what's best to capture all the community work > > in > > > > one place. There are some good plugins/extensions that are built by > the > > > > community which does not necessarily be merged into the mainstream > but > > > > would be a great value for others in the community. Capturing all > these > > > at > > > > one place would a great help for someone looking for a solution. > > > > > > > > Also, I would like to capture (if any) requirements (Eg: licenses > etc) > > > that > > > > these developers need to adhere to showcase their work. Are there any > > > > Apache guidelines for such work? > > > > > > > > There are many ways to do this. if everyone agrees about the idea of > > > > capturing all at one place then I propose we add a page/section > > capturing > > > > both the requirements and a table of references URLs to those > > open-source > > > > work. That way it easy for someone to update the page and create a PR > > for > > > > the website. > > > > > > > > Sai > > > > > > > > > > > > > > > > -- > > > -John > > > john.blum10101 (skype) > > > > > >
Re: [Discuss] showcasing community work
Thanks, John for your inputs. I will be adding the page to capture these details. If there are no objections then I would go ahead and add a new section to http://geode.apache.org/community/ Sai On Thu, Oct 11, 2018 at 12:07 PM John Blum wrote: > This is a very nice idea Sai. > > Perhaps a page with a table containing... > > * Project Name > * Project Description (Summary) > * Project License > * Project URL (to GitHub page, Website, etc, where users can find out more > information) > > Food for thought. > > > On Thu, Oct 11, 2018 at 12:04 PM, Sai Boorlagadda < > sai.boorlaga...@gmail.com > > wrote: > > > I would like to discuss what's best to capture all the community work in > > one place. There are some good plugins/extensions that are built by the > > community which does not necessarily be merged into the mainstream but > > would be a great value for others in the community. Capturing all these > at > > one place would a great help for someone looking for a solution. > > > > Also, I would like to capture (if any) requirements (Eg: licenses etc) > that > > these developers need to adhere to showcase their work. Are there any > > Apache guidelines for such work? > > > > There are many ways to do this. if everyone agrees about the idea of > > capturing all at one place then I propose we add a page/section capturing > > both the requirements and a table of references URLs to those open-source > > work. That way it easy for someone to update the page and create a PR for > > the website. > > > > Sai > > > > > > -- > -John > john.blum10101 (skype) >
[Discuss] showcasing community work
I would like to discuss what's best to capture all the community work in one place. There are some good plugins/extensions that are built by the community which does not necessarily be merged into the mainstream but would be a great value for others in the community. Capturing all these at one place would a great help for someone looking for a solution. Also, I would like to capture (if any) requirements (Eg: licenses etc) that these developers need to adhere to showcase their work. Are there any Apache guidelines for such work? There are many ways to do this. if everyone agrees about the idea of capturing all at one place then I propose we add a page/section capturing both the requirements and a table of references URLs to those open-source work. That way it easy for someone to update the page and create a PR for the website. Sai
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
>Do we know what third party libraries are using java internals that >we might have problems with? #2 isn't going to work for those >libraries, unless they also add a module-info.class. So maybe we >will need to do #3 for third-party libraries? Adding these third-party libs on module path[1] rather than class path seems to address this issue. [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#automatic-modules
Re: Release process for Apache Geode wiki
Thanks Naba! it looks comprehensive. I have not done a release myself so cannot ask more. If it's possible would you be able to capture software dependencies that a release manager have to install on his workstation. Following the steps I see docker & svn is needed. On Wed, Oct 10, 2018, 7:01 PM Nabarun Nag wrote: > Hi, > > I have created a new wiki page on how to release Apache Geode. > Please do a review and let me know if there are any suggestions or > modifications required. > > https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode > > Regard > Nabarun Nag >
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
+1 to Dan's idea if its possible. There is a maven plugin to invoke javac twice with respective java targets. https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html On Wed, Oct 10, 2018 at 1:52 PM Galen O'Sullivan wrote: > er, lost the end of that first sentence there. I think that reducing > dependencies on Unsafe is a good goal regardless. > > On Wed, Oct 10, 2018 at 1:51 PM Galen O'Sullivan > wrote: > > > #1 sounds awesome but may be unrealistic given our advertised feature > set. > > I think that reducing dependencies on Unsafe > > > > If we can conditionally use Jigsaw modules for Java versions later than 8 > > while maintaining Java 8 compatiblity, that seems like the best solution. > > > > +2 to Dan's idea if it allows this. > > > > On Wed, Oct 10, 2018 at 1:47 PM Jacob Barrett > wrote: > > > >> Here is a discussion from Google Guava project about compiling > >> module-info.java in Java 9+ and including it in a jar with classes > >> compiled > >> for Java 8. > >> > >> https://github.com/google/guava/issues/2970 > >> > >> > >> On Wed, Oct 10, 2018 at 1:39 PM Jacob Barrett > >> wrote: > >> > >> > I like Dan’s idea! I would rather we work towards the correct > solution. > >> > > >> > > On Oct 10, 2018, at 1:22 PM, Dan Smith wrote: > >> > > > >> > > #2 seems like the least hacky way to continue using things like > >> > > sun.misc.Unsafe. Could we just compile a module-info.java with Java > 9 > >> and > >> > > bundle it? This would also help consumers of geode that want to use > >> Java > >> > 9 > >> > > modules. > >> > > > >> > > I'm a little bit sceptical of this permit-reflect libary, seeing as > >> it's > >> > > been around for about 1 month, has 0 tests in the source that I can > >> see, > >> > > and seems to be tripling down on relying on sun.misc.Unsafe to do > >> stuff. > >> > > I'd be inclined to do #3 before this. > >> > > > >> > > -Dan > >> > > > >> > > On Wed, Oct 10, 2018 at 12:20 PM Owen Nichols > >> > wrote: > >> > > > >> > >> Goal: > >> > >> > >> > >> Run Geode on Java 11 (GEODE-3 < > >> > >> https://issues.apache.org/jira/browse/GEODE-3>). > >> > >> > >> > >> > >> > >> Problem: > >> > >> > >> > >> Java 8 allows Geode (and its 3rd party libraries) full access to > all > >> > Java > >> > >> APIs, including internal APIs. However, Java 11 restricts access > to > >> > many > >> > >> of these APIs by default. > >> > >> > >> > >> > >> > >> Solution #1: > >> > >> > >> > >> Remove all usage of restricted APIs from all Geode code, and find > >> > >> replacements for all 3rd party libraries that depend on restricted > >> APIs. > >> > >> > >> > >> Solution #2: > >> > >> > >> > >> Adopt Java 11’s “Jigsaw" Module System and properly declare > >> dependencies > >> > >> on restricted APIs. > >> > >> > >> > >> Solution #3: > >> > >> > >> > >> Update all existing public and personal scripts, wrappers, IDE > >> > >> configurations, test harnesses, and other java invocations to add a > >> > handful > >> > >> of --add-opens flags to the java commandline to override the > default > >> > Java > >> > >> 11 restrictions. > >> > >> > >> > >> Solution #4: > >> > >> > >> > >> Use the MIT-licensed permit-reflect < > >> > >> https://github.com/nqzero/permit-reflect> library to > >> programmatically > >> > >> override Java 11’s API restrictions. > >> > >> > >> > >> > >> > >> In terms of feasibility: > >> > >> #1 would be extremely difficult. Geode has a large number of > >> > dependencies > >> > >> on internal Java APIs in critical areas, and replacing them would > be > >> > >> time-consuming, potentially destabilizing, and very likely to > >> negatively > >> > >> impact performance. > >> > >> #2 is complex because we still need Geode to run on Java 8, so not > >> using > >> > >> any Java 11 features seems safer than introducing multi-version > jars, > >> > >> cross-compilation, or separate releases per target Java platform. > >> > >> #3 is easy enough to implement in scripts that are under source > >> control, > >> > >> but users or developers that have their own IDE configurations or > >> test > >> > >> environments may struggle to understand why they are getting errors > >> and > >> > how > >> > >> to fix them. > >> > >> #4 restores full Java8-like permissions with essentially just a > >> change > >> > to > >> > >> main() method. > >> > >> > >> > >> > >> > >> Which strategy do you prefer? Java 11 test jobs are in the > pipeline > >> < > >> > >> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop > > > >> as > >> > of > >> > >> today — let’s make them green! > >> > >> > >> > >> > >> > >> -Owen > >> > > >> > > >> > > >
Re: [VOTE] Time-based release schedule for minor releases
Sure! I am all in for time-based releases. I see the point that we can only do Minors as patches(or maintenance) are reserved for hotfixes and security bugs. So +1 for a time-based release to ship whatever has changed since the last release. On Wed, Oct 10, 2018 at 10:29 AM Alexander Murmann wrote: > 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 for a > patch or major, this would likely impact our branching strategy. Breaking > changes would be permitted for a major and we'd need to think about how to > work with a support branch for the previous major etc. If we aimed for a > patch we couldn't merge features, etc. > > On Wed, Oct 10, 2018 at 10:17 AM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > wrote: > > > Looking at the current definition it sounds like we can only decide if > its > > a Minor at the time of release and cannot be scheduled. Thoughts? > > > > *> MINOR*: Minor releases can contain minor new features and must > > definitely include significant improvements > > > to current API or components that justify not be configured as > > *maintenance* changes. Minor releases can also > > > be increased if extensions or sub-projects add new features or are > > updated somehow. > > > > On Wed, Oct 10, 2018 at 9:35 AM Anthony Baker wrote: > > > > > Practically speaking, a quarterly release cycle means there’s *always* > > > some feature addition or improvement included in the release. That’s > > why I > > > agree with the suggestion of a release cadence based on minor version > > > bumps. See [1] for the outcome of prior discussions on SemVer. > > > > > > Anthony > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching > > > > > > > > > > On Oct 10, 2018, at 8:44 AM, Ryan McMahon > > > wrote: > > > > > > > > I’m with Sai that it seems like we need to clear up our definitions > of > > > > minor versus patch releases. The referenced SemVer definition > > indicates > > > > that any backwards compatible bug fix qualifies for a patch release. > > But > > > > it was stated earlier that only security-related or critidal bug > fixes > > > > justify a patch release. I personally prefer SemVer’s definition, > but > > > it’s > > > > up for debate. > > > > > > > > Perhaps we can do 3-month release cycles, and determine whether the > > > release > > > > would be patch or minor based on the changes added since the last > > release > > > > (bug fixes vs new functionality). > > > > > > > > Ryan > > > > > > > > >
Re: [VOTE] Time-based release schedule for minor releases
Looking at the current definition it sounds like we can only decide if its a Minor at the time of release and cannot be scheduled. Thoughts? *> MINOR*: Minor releases can contain minor new features and must definitely include significant improvements > to current API or components that justify not be configured as *maintenance* changes. Minor releases can also > be increased if extensions or sub-projects add new features or are updated somehow. On Wed, Oct 10, 2018 at 9:35 AM Anthony Baker wrote: > Practically speaking, a quarterly release cycle means there’s *always* > some feature addition or improvement included in the release. That’s why I > agree with the suggestion of a release cadence based on minor version > bumps. See [1] for the outcome of prior discussions on SemVer. > > Anthony > > [1] > https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching > > > > On Oct 10, 2018, at 8:44 AM, Ryan McMahon > wrote: > > > > I’m with Sai that it seems like we need to clear up our definitions of > > minor versus patch releases. The referenced SemVer definition indicates > > that any backwards compatible bug fix qualifies for a patch release. But > > it was stated earlier that only security-related or critidal bug fixes > > justify a patch release. I personally prefer SemVer’s definition, but > it’s > > up for debate. > > > > Perhaps we can do 3-month release cycles, and determine whether the > release > > would be patch or minor based on the changes added since the last release > > (bug fixes vs new functionality). > > > > Ryan > >
Re: [VOTE] Time-based release schedule for minor releases
After looking at these definitions are we not talking about time-based patch releases? It is again subjective how much functionality makes a MINOR release. Though this thread is seeking consensus on time-based scheduled it is specifically for minors. it appears to me like we need to update our definitions before we make a decision on schedule. On Tue, Oct 9, 2018 at 10:06 AM Alexander Murmann wrote: > Bruce, agreed. I think we should eliminate all the fluff language around > "significant improvements". What's "significant" is entirely subjective. > I'd prefer to stick to the much simpler definition from semver.org: > > > > Given a version number MAJOR.MINOR.PATCH, increment the: > > > >1. MAJOR version when you make incompatible API changes, > >2. MINOR version when you add functionality in a backwards-compatible > >manner, and > >3. PATCH version when you make backwards-compatible bug fixes. > > > > > On Tue, Oct 9, 2018 at 9:03 AM Bruce Schuchardt > wrote: > > > -1 > > > > To me the definition of major vs minor releases is too muddy. Our > > Versioning and Branching > > < > > > https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching > > > > > > page has requirements for a Minor release that seem orthogonal to this > > discussion. A Minor release "must definitely include significant > > improvements to current API or components that justify not be configured > > (sic) as /maintenance/ changes". > > > > The page also describes a Maintenance release that seems to be more what > > we're talking 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 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: > > > https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule > > > > > > There are also some discussions about patch releases. Let's please > focus > > > this vote on the proposed minor release schedule and carry on other > > > discussions in the [DISCUSS] thread. > > > > > > Thank you all! > > > > > > > >
