Re: Geode 1.9 Release Manager
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 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 < 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!
Bug Numbers and Trac Numbers in comments
Hey Geode Dev Friends! I was reviewing a PR (this one https://github.com/apache/geode/pull/3197) and made a note that maybe we should remove comments that make references to bug and trac numbers that people cannot reach (like me for one). Kirk mentioned that some people (like him) have access to those bugs and have proven helpful for some history. So there is this balance between noise (people who cannot access those old issues) and getting context (people who can access those issues). So I guess my point is to start a discussion on what a path forward might be (if any)? My opinion is that they are noise and we should remove them. If someone has access to the original issue, then making sure there is a test case covering it should be done. Then it makes even more sense to me to remove the comment. -michael
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
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 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 > >>> t
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: 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 > >
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 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 > >
Re: Release branch for Apache Geode 1.9.0 has been cut
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 > 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 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 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 > > 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: Bug Numbers and Trac Numbers in comments
Comments that don’t provide meaningful context beyond what is already expressed in the code should be removed. A number to a system that the general public can’t access is not meaningful. Delete or replace with meaningful comment. -jake > On Feb 19, 2019, at 1:41 PM, Michael Oleske wrote: > > Hey Geode Dev Friends! > > I was reviewing a PR (this one https://github.com/apache/geode/pull/3197) > and made a note that maybe we should remove comments that make references > to bug and trac numbers that people cannot reach (like me for one). Kirk > mentioned that some people (like him) have access to those bugs and have > proven helpful for some history. So there is this balance between noise > (people who cannot access those old issues) and getting context (people who > can access those issues). > > So I guess my point is to start a discussion on what a path forward might > be (if any)? My opinion is that they are noise and we should remove them. > If someone has access to the original issue, then making sure there is a > test case covering it should be done. Then it makes even more sense to me > to remove the comment. > > -michael
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 > >> > > >> > > >> > > >
