Passed: apache/geode-native#2099 (rel/v1.10.0.RC2 - 0668f6b)
Build Update for apache/geode-native - Build: #2099 Status: Passed Duration: 1 hr, 36 mins, and 26 secs Commit: 0668f6b (rel/v1.10.0.RC2) Author: Owen Nichols Message: GEODE-7182: fix a warning in TcpSslConn.cpp that prevents successful compilation on gcc 8.3 (#515) (cherry picked from commit 9b1c5ab31558c9d0ead6927398cb608521a5c20d) View the changeset: https://github.com/apache/geode-native/compare/rel/v1.10.0.RC2 View the full build log and details: https://travis-ci.org/apache/geode-native/builds/587241786?utm_medium=notification_source=email -- You can unsubscribe from build emails from the apache/geode-native repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=11948127_medium=notification_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Errored: apache/geode-examples#364 (rel/v1.10.0.RC2 - 075158b)
Build Update for apache/geode-examples - Build: #364 Status: Errored Duration: 55 secs Commit: 075158b (rel/v1.10.0.RC2) Author: Dick Cavender Message: temporarily point to staging repo for CI purposes View the changeset: https://github.com/apache/geode-examples/compare/rel/v1.10.0.RC2 View the full build log and details: https://travis-ci.org/apache/geode-examples/builds/587241768?utm_medium=notification_source=email -- You can unsubscribe from build emails from the apache/geode-examples repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=11483039_medium=notification_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
Given that we have ALREADY merged this in AND it has passed through the majority of our pipeline without incident, I'll change to a -0... I make this is a " - " because I'm quietly objecting to the fact that we have not followed process and merged without waiting for consensus. Also the reasoning to include this issue provides me absolutely NO compelling reason to include it in 1.10. The fact that there was a majority "+1" without the evaluation of the "does this improve the stability" of the release. I'm not talking about the correctness, but stability. Also given it is an existing issue, makes be believe that this is/was not a issue that affected stability. Anyway... Hopefully we can get better at releasing. --Udo On 9/19/19 2:19 PM, Dick Cavender wrote: This problem has happened before, and will probably happen in the future. Recently we adjusted the Geode release process to dictate that the Geode release manager will handle the merging of approved changes to a release branch while also allowing the community time for input and discussion on those. In this case, neither happened. The change was merged by the committer as soon as there were three votes and I as the release manager failed to communicate the intended process to them before that happened. This process needs to be an on-going discussion for us as a community. What, when and how changes come into a release branch after creation and until its release. It's enough to scare off future Release Manager volunteers if not solved. The GEODE-7208 change is already moving through the 1.10.0 pipeline and is (at the moment) the final change for 1.10.0.RC2 moving us closer to release. Udo- would you consider making your vote a +0 and then being part of the future work towards improving this part of the process rather than having to revert the change due to your minus one? On Thu, Sep 19, 2019 at 1:17 PM Udo Kohlmeyer wrote: -1 I must agree with Owen's analysis. It's a known problem, and it will not cause the system to stop working. Yes, it is a bug and will cause issues with results, BUT it will NOT affect the stability of the system. Which is one of the only reasons we should be adding fixes to an already cut release branch. --Udo On 9/19/19 11:48 AM, Owen Nichols wrote: Thank you for providing some context for what is being voted here. Based on this information, I will give my vote as “+0” (imho it may not meet the definition of a “critical fix”, but seems like the risk is low and the community wants it, so I have no real objection). On Sep 19, 2019, at 11:38 AM, Xiaojian Zhou wrote: Owen: Here are the answers: - Is this fixing an issue of Data loss? Performance degradation? Backward-compatibility issue? Availability impacts? Resource exhaustion (threads, disk, cpu, memory, sockets, etc)? Without the fix, fields in the inherited attributes cannot be indexed, if it's user object. For example, I have a Customer class, which contains phoneBook. I have a subclass LocalCustomer to inherit Customer class, then I cannot index on phoneBook. - Did this issue exist in the previous release? Yes. - What is the impact of not fixing it? Customer will see it and they have seen it. - What are the risks of introducing this change so close to shipping? No risk. It's standalone fix. Not to impact any where else. And it will be backported in future if we did not do it now. - How extensively has the fix been tested on develop? We introduced several dunit and junit tests. - How “sensitive” is the area of code it touches? Not sensitive. - What new tests have been added? New dunit tests and junit tests. Regards Gester On Thu, Sep 19, 2019 at 11:21 AM Owen Nichols wrote: On Sep 19, 2019, at 11:15 AM, Xiaojian Zhou wrote: Owen: The reason is: it's already cherry-picked to 1.9. Can you kindly point me to the specific SHA where this was fixed in 1.9? I am not able to find it... Gester On Thu, Sep 19, 2019 at 11:13 AM Owen Nichols wrote: It looks like this has already passed the vote, but I don’t see an explanation anywhere in this thread for what makes this a "critical fix". As I recall release/1.10.0 was branched at the beginning of August, so it seems appropriate to apply a very high level of scrutiny to any continuing proposals to further delay the release of 1.10.0. - Is this fixing an issue of Data loss? Performance degradation? Backward-compatibility issue? Availability impacts? Resource exhaustion (threads, disk, cpu, memory, sockets, etc)? - Did this issue exist in the previous release? - What is the impact of not fixing it? - What are the risks of introducing this change so close to shipping? - How extensively has the fix been tested on develop? - How “sensitive” is the area of code it touches? - What new tests have been added? On Sep 19, 2019, at 11:08 AM, Anilkumar Gingade < aging...@pivotal.io> wrote: +1 On Thu, Sep 19, 2019 at 11:02 AM Eric Shu wrote: +1 On Thu, Sep 19, 2019 at
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
This problem has happened before, and will probably happen in the future. Recently we adjusted the Geode release process to dictate that the Geode release manager will handle the merging of approved changes to a release branch while also allowing the community time for input and discussion on those. In this case, neither happened. The change was merged by the committer as soon as there were three votes and I as the release manager failed to communicate the intended process to them before that happened. This process needs to be an on-going discussion for us as a community. What, when and how changes come into a release branch after creation and until its release. It's enough to scare off future Release Manager volunteers if not solved. The GEODE-7208 change is already moving through the 1.10.0 pipeline and is (at the moment) the final change for 1.10.0.RC2 moving us closer to release. Udo- would you consider making your vote a +0 and then being part of the future work towards improving this part of the process rather than having to revert the change due to your minus one? On Thu, Sep 19, 2019 at 1:17 PM Udo Kohlmeyer wrote: > -1 > > I must agree with Owen's analysis. > > It's a known problem, and it will not cause the system to stop working. > Yes, it is a bug and will cause issues with results, BUT it will NOT > affect the stability of the system. Which is one of the only reasons we > should be adding fixes to an already cut release branch. > > --Udo > > On 9/19/19 11:48 AM, Owen Nichols wrote: > > Thank you for providing some context for what is being voted here. > Based on this information, I will give my vote as “+0” (imho it may not > meet the definition of a “critical fix”, but seems like the risk is low and > the community wants it, so I have no real objection). > > > > > >> On Sep 19, 2019, at 11:38 AM, Xiaojian Zhou wrote: > >> > >> Owen: > >> Here are the answers: > >> > >> - Is this fixing an issue of Data loss? Performance degradation? > >> Backward-compatibility issue? Availability impacts? Resource exhaustion > >> (threads, disk, cpu, memory, sockets, etc)? > >> > >> Without the fix, fields in the inherited attributes cannot be indexed, > if > >> it's user object. For example, I have a Customer class, which contains > >> phoneBook. I have a subclass LocalCustomer to inherit Customer class, > then > >> I cannot index on phoneBook. > >> > >> - Did this issue exist in the previous release? > >> Yes. > >> > >> - What is the impact of not fixing it? > >> Customer will see it and they have seen it. > >> > >> - What are the risks of introducing this change so close to shipping? > >> No risk. It's standalone fix. Not to impact any where else. And it will > be > >> backported in future if we did not do it now. > >> > >> - How extensively has the fix been tested on develop? > >> We introduced several dunit and junit tests. > >> > >> - How “sensitive” is the area of code it touches? > >> Not sensitive. > >> > >> - What new tests have been added? > >> New dunit tests and junit tests. > >> > >> Regards > >> Gester > >> > >> On Thu, Sep 19, 2019 at 11:21 AM Owen Nichols > wrote: > >> > On Sep 19, 2019, at 11:15 AM, Xiaojian Zhou wrote: > > Owen: > > The reason is: it's already cherry-picked to 1.9. > >>> > >>> Can you kindly point me to the specific SHA where this was fixed in > 1.9? > >>> I am not able to find it... > >>> > Gester > > On Thu, Sep 19, 2019 at 11:13 AM Owen Nichols > >>> wrote: > > It looks like this has already passed the vote, but I don’t see an > > explanation anywhere in this thread for what makes this a "critical > >>> fix". > > As I recall release/1.10.0 was branched at the beginning of August, > so > >>> it > > seems appropriate to apply a very high level of scrutiny to any > >>> continuing > > proposals to further delay the release of 1.10.0. > > > > - Is this fixing an issue of Data loss? Performance degradation? > > Backward-compatibility issue? Availability impacts? Resource > exhaustion > > (threads, disk, cpu, memory, sockets, etc)? > > - Did this issue exist in the previous release? > > - What is the impact of not fixing it? > > - What are the risks of introducing this change so close to shipping? > > - How extensively has the fix been tested on develop? > > - How “sensitive” is the area of code it touches? > > - What new tests have been added? > > > > > >> On Sep 19, 2019, at 11:08 AM, Anilkumar Gingade < > aging...@pivotal.io> > > wrote: > >> +1 > >> > >> On Thu, Sep 19, 2019 at 11:02 AM Eric Shu wrote: > >> > >>> +1 > >>> > >>> > >>> On Thu, Sep 19, 2019 at 10:59 AM Benjamin Ross > > wrote: > +1 > > On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag > >>> wrote: > > +1 > > > > On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou > > >>> wrote: > >> I want to
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
-1 I must agree with Owen's analysis. It's a known problem, and it will not cause the system to stop working. Yes, it is a bug and will cause issues with results, BUT it will NOT affect the stability of the system. Which is one of the only reasons we should be adding fixes to an already cut release branch. --Udo On 9/19/19 11:48 AM, Owen Nichols wrote: Thank you for providing some context for what is being voted here. Based on this information, I will give my vote as “+0” (imho it may not meet the definition of a “critical fix”, but seems like the risk is low and the community wants it, so I have no real objection). On Sep 19, 2019, at 11:38 AM, Xiaojian Zhou wrote: Owen: Here are the answers: - Is this fixing an issue of Data loss? Performance degradation? Backward-compatibility issue? Availability impacts? Resource exhaustion (threads, disk, cpu, memory, sockets, etc)? Without the fix, fields in the inherited attributes cannot be indexed, if it's user object. For example, I have a Customer class, which contains phoneBook. I have a subclass LocalCustomer to inherit Customer class, then I cannot index on phoneBook. - Did this issue exist in the previous release? Yes. - What is the impact of not fixing it? Customer will see it and they have seen it. - What are the risks of introducing this change so close to shipping? No risk. It's standalone fix. Not to impact any where else. And it will be backported in future if we did not do it now. - How extensively has the fix been tested on develop? We introduced several dunit and junit tests. - How “sensitive” is the area of code it touches? Not sensitive. - What new tests have been added? New dunit tests and junit tests. Regards Gester On Thu, Sep 19, 2019 at 11:21 AM Owen Nichols wrote: On Sep 19, 2019, at 11:15 AM, Xiaojian Zhou wrote: Owen: The reason is: it's already cherry-picked to 1.9. Can you kindly point me to the specific SHA where this was fixed in 1.9? I am not able to find it... Gester On Thu, Sep 19, 2019 at 11:13 AM Owen Nichols wrote: It looks like this has already passed the vote, but I don’t see an explanation anywhere in this thread for what makes this a "critical fix". As I recall release/1.10.0 was branched at the beginning of August, so it seems appropriate to apply a very high level of scrutiny to any continuing proposals to further delay the release of 1.10.0. - Is this fixing an issue of Data loss? Performance degradation? Backward-compatibility issue? Availability impacts? Resource exhaustion (threads, disk, cpu, memory, sockets, etc)? - Did this issue exist in the previous release? - What is the impact of not fixing it? - What are the risks of introducing this change so close to shipping? - How extensively has the fix been tested on develop? - How “sensitive” is the area of code it touches? - What new tests have been added? On Sep 19, 2019, at 11:08 AM, Anilkumar Gingade wrote: +1 On Thu, Sep 19, 2019 at 11:02 AM Eric Shu wrote: +1 On Thu, Sep 19, 2019 at 10:59 AM Benjamin Ross wrote: +1 On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag wrote: +1 On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou wrote: I want to merge GEODE-7208, which is lucene specific fix The fix will enable indexing on inherited attributes in user object. revision 4ec87419d456748a7d853e979c90ad4e301b2405 Regards Gester
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
Thank you for providing some context for what is being voted here. Based on this information, I will give my vote as “+0” (imho it may not meet the definition of a “critical fix”, but seems like the risk is low and the community wants it, so I have no real objection). > On Sep 19, 2019, at 11:38 AM, Xiaojian Zhou wrote: > > Owen: > Here are the answers: > > - Is this fixing an issue of Data loss? Performance degradation? > Backward-compatibility issue? Availability impacts? Resource exhaustion > (threads, disk, cpu, memory, sockets, etc)? > > Without the fix, fields in the inherited attributes cannot be indexed, if > it's user object. For example, I have a Customer class, which contains > phoneBook. I have a subclass LocalCustomer to inherit Customer class, then > I cannot index on phoneBook. > > - Did this issue exist in the previous release? > Yes. > > - What is the impact of not fixing it? > Customer will see it and they have seen it. > > - What are the risks of introducing this change so close to shipping? > No risk. It's standalone fix. Not to impact any where else. And it will be > backported in future if we did not do it now. > > - How extensively has the fix been tested on develop? > We introduced several dunit and junit tests. > > - How “sensitive” is the area of code it touches? > Not sensitive. > > - What new tests have been added? > New dunit tests and junit tests. > > Regards > Gester > > On Thu, Sep 19, 2019 at 11:21 AM Owen Nichols wrote: > >>> On Sep 19, 2019, at 11:15 AM, Xiaojian Zhou wrote: >>> >>> Owen: >>> >>> The reason is: it's already cherry-picked to 1.9. >> >> >> Can you kindly point me to the specific SHA where this was fixed in 1.9? >> I am not able to find it... >> >>> >>> Gester >>> >>> On Thu, Sep 19, 2019 at 11:13 AM Owen Nichols >> wrote: >>> It looks like this has already passed the vote, but I don’t see an explanation anywhere in this thread for what makes this a "critical >> fix". As I recall release/1.10.0 was branched at the beginning of August, so >> it seems appropriate to apply a very high level of scrutiny to any >> continuing proposals to further delay the release of 1.10.0. - Is this fixing an issue of Data loss? Performance degradation? Backward-compatibility issue? Availability impacts? Resource exhaustion (threads, disk, cpu, memory, sockets, etc)? - Did this issue exist in the previous release? - What is the impact of not fixing it? - What are the risks of introducing this change so close to shipping? - How extensively has the fix been tested on develop? - How “sensitive” is the area of code it touches? - What new tests have been added? > On Sep 19, 2019, at 11:08 AM, Anilkumar Gingade wrote: > > +1 > > On Thu, Sep 19, 2019 at 11:02 AM Eric Shu wrote: > >> +1 >> >> >> On Thu, Sep 19, 2019 at 10:59 AM Benjamin Ross wrote: >> >>> +1 >>> >>> On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag >> wrote: >>> +1 On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou >> wrote: > I want to merge GEODE-7208, which is lucene specific fix > > The fix will enable indexing on inherited attributes in user >> object. > > revision 4ec87419d456748a7d853e979c90ad4e301b2405 > > Regards > Gester > >>> >> >> >>
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
Owen: Here are the answers: - Is this fixing an issue of Data loss? Performance degradation? Backward-compatibility issue? Availability impacts? Resource exhaustion (threads, disk, cpu, memory, sockets, etc)? Without the fix, fields in the inherited attributes cannot be indexed, if it's user object. For example, I have a Customer class, which contains phoneBook. I have a subclass LocalCustomer to inherit Customer class, then I cannot index on phoneBook. - Did this issue exist in the previous release? Yes. - What is the impact of not fixing it? Customer will see it and they have seen it. - What are the risks of introducing this change so close to shipping? No risk. It's standalone fix. Not to impact any where else. And it will be backported in future if we did not do it now. - How extensively has the fix been tested on develop? We introduced several dunit and junit tests. - How “sensitive” is the area of code it touches? Not sensitive. - What new tests have been added? New dunit tests and junit tests. Regards Gester On Thu, Sep 19, 2019 at 11:21 AM Owen Nichols wrote: > > On Sep 19, 2019, at 11:15 AM, Xiaojian Zhou wrote: > > > > Owen: > > > > The reason is: it's already cherry-picked to 1.9. > > > Can you kindly point me to the specific SHA where this was fixed in 1.9? > I am not able to find it... > > > > > Gester > > > > On Thu, Sep 19, 2019 at 11:13 AM Owen Nichols > wrote: > > > >> It looks like this has already passed the vote, but I don’t see an > >> explanation anywhere in this thread for what makes this a "critical > fix". > >> > >> As I recall release/1.10.0 was branched at the beginning of August, so > it > >> seems appropriate to apply a very high level of scrutiny to any > continuing > >> proposals to further delay the release of 1.10.0. > >> > >> - Is this fixing an issue of Data loss? Performance degradation? > >> Backward-compatibility issue? Availability impacts? Resource exhaustion > >> (threads, disk, cpu, memory, sockets, etc)? > >> - Did this issue exist in the previous release? > >> - What is the impact of not fixing it? > >> - What are the risks of introducing this change so close to shipping? > >> - How extensively has the fix been tested on develop? > >> - How “sensitive” is the area of code it touches? > >> - What new tests have been added? > >> > >> > >>> On Sep 19, 2019, at 11:08 AM, Anilkumar Gingade > >> wrote: > >>> > >>> +1 > >>> > >>> On Thu, Sep 19, 2019 at 11:02 AM Eric Shu wrote: > >>> > +1 > > > On Thu, Sep 19, 2019 at 10:59 AM Benjamin Ross > >> wrote: > > > +1 > > > > On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag > wrote: > > > >> +1 > >> > >> On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou > wrote: > >> > >>> I want to merge GEODE-7208, which is lucene specific fix > >>> > >>> The fix will enable indexing on inherited attributes in user > object. > >>> > >>> revision 4ec87419d456748a7d853e979c90ad4e301b2405 > >>> > >>> Regards > >>> Gester > >>> > >> > > > > >> > >> > >
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
> On Sep 19, 2019, at 11:15 AM, Xiaojian Zhou wrote: > > Owen: > > The reason is: it's already cherry-picked to 1.9. Can you kindly point me to the specific SHA where this was fixed in 1.9? I am not able to find it... > > Gester > > On Thu, Sep 19, 2019 at 11:13 AM Owen Nichols wrote: > >> It looks like this has already passed the vote, but I don’t see an >> explanation anywhere in this thread for what makes this a "critical fix". >> >> As I recall release/1.10.0 was branched at the beginning of August, so it >> seems appropriate to apply a very high level of scrutiny to any continuing >> proposals to further delay the release of 1.10.0. >> >> - Is this fixing an issue of Data loss? Performance degradation? >> Backward-compatibility issue? Availability impacts? Resource exhaustion >> (threads, disk, cpu, memory, sockets, etc)? >> - Did this issue exist in the previous release? >> - What is the impact of not fixing it? >> - What are the risks of introducing this change so close to shipping? >> - How extensively has the fix been tested on develop? >> - How “sensitive” is the area of code it touches? >> - What new tests have been added? >> >> >>> On Sep 19, 2019, at 11:08 AM, Anilkumar Gingade >> wrote: >>> >>> +1 >>> >>> On Thu, Sep 19, 2019 at 11:02 AM Eric Shu wrote: >>> +1 On Thu, Sep 19, 2019 at 10:59 AM Benjamin Ross >> wrote: > +1 > > On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag wrote: > >> +1 >> >> On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou wrote: >> >>> I want to merge GEODE-7208, which is lucene specific fix >>> >>> The fix will enable indexing on inherited attributes in user object. >>> >>> revision 4ec87419d456748a7d853e979c90ad4e301b2405 >>> >>> Regards >>> Gester >>> >> > >> >>
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
Owen: The reason is: it's already cherry-picked to 1.9. Gester On Thu, Sep 19, 2019 at 11:13 AM Owen Nichols wrote: > It looks like this has already passed the vote, but I don’t see an > explanation anywhere in this thread for what makes this a "critical fix". > > As I recall release/1.10.0 was branched at the beginning of August, so it > seems appropriate to apply a very high level of scrutiny to any continuing > proposals to further delay the release of 1.10.0. > > - Is this fixing an issue of Data loss? Performance degradation? > Backward-compatibility issue? Availability impacts? Resource exhaustion > (threads, disk, cpu, memory, sockets, etc)? > - Did this issue exist in the previous release? > - What is the impact of not fixing it? > - What are the risks of introducing this change so close to shipping? > - How extensively has the fix been tested on develop? > - How “sensitive” is the area of code it touches? > - What new tests have been added? > > > > On Sep 19, 2019, at 11:08 AM, Anilkumar Gingade > wrote: > > > > +1 > > > > On Thu, Sep 19, 2019 at 11:02 AM Eric Shu wrote: > > > >> +1 > >> > >> > >> On Thu, Sep 19, 2019 at 10:59 AM Benjamin Ross > wrote: > >> > >>> +1 > >>> > >>> On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag wrote: > >>> > +1 > > On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou > >> wrote: > > > I want to merge GEODE-7208, which is lucene specific fix > > > > The fix will enable indexing on inherited attributes in user object. > > > > revision 4ec87419d456748a7d853e979c90ad4e301b2405 > > > > Regards > > Gester > > > > >>> > >> > >
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
It looks like this has already passed the vote, but I don’t see an explanation anywhere in this thread for what makes this a "critical fix". As I recall release/1.10.0 was branched at the beginning of August, so it seems appropriate to apply a very high level of scrutiny to any continuing proposals to further delay the release of 1.10.0. - Is this fixing an issue of Data loss? Performance degradation? Backward-compatibility issue? Availability impacts? Resource exhaustion (threads, disk, cpu, memory, sockets, etc)? - Did this issue exist in the previous release? - What is the impact of not fixing it? - What are the risks of introducing this change so close to shipping? - How extensively has the fix been tested on develop? - How “sensitive” is the area of code it touches? - What new tests have been added? > On Sep 19, 2019, at 11:08 AM, Anilkumar Gingade wrote: > > +1 > > On Thu, Sep 19, 2019 at 11:02 AM Eric Shu wrote: > >> +1 >> >> >> On Thu, Sep 19, 2019 at 10:59 AM Benjamin Ross wrote: >> >>> +1 >>> >>> On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag wrote: >>> +1 On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou >> wrote: > I want to merge GEODE-7208, which is lucene specific fix > > The fix will enable indexing on inherited attributes in user object. > > revision 4ec87419d456748a7d853e979c90ad4e301b2405 > > Regards > Gester > >>> >>
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
+1 On Thu, Sep 19, 2019 at 11:02 AM Eric Shu wrote: > +1 > > > On Thu, Sep 19, 2019 at 10:59 AM Benjamin Ross wrote: > > > +1 > > > > On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag wrote: > > > > > +1 > > > > > > On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou > wrote: > > > > > > > I want to merge GEODE-7208, which is lucene specific fix > > > > > > > > The fix will enable indexing on inherited attributes in user object. > > > > > > > > revision 4ec87419d456748a7d853e979c90ad4e301b2405 > > > > > > > > Regards > > > > Gester > > > > > > > > > >
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
+1 On Thu, Sep 19, 2019 at 10:59 AM Benjamin Ross wrote: > +1 > > On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag wrote: > > > +1 > > > > On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou wrote: > > > > > I want to merge GEODE-7208, which is lucene specific fix > > > > > > The fix will enable indexing on inherited attributes in user object. > > > > > > revision 4ec87419d456748a7d853e979c90ad4e301b2405 > > > > > > Regards > > > Gester > > > > > >
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
+1 On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag wrote: > +1 > > On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou wrote: > > > I want to merge GEODE-7208, which is lucene specific fix > > > > The fix will enable indexing on inherited attributes in user object. > > > > revision 4ec87419d456748a7d853e979c90ad4e301b2405 > > > > Regards > > Gester > > >
Re: [VOTE] Adding a lucene specific fix to release/1.10.0
+1 On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou wrote: > I want to merge GEODE-7208, which is lucene specific fix > > The fix will enable indexing on inherited attributes in user object. > > revision 4ec87419d456748a7d853e979c90ad4e301b2405 > > Regards > Gester >
[VOTE] Adding a lucene specific fix to release/1.10.0
I want to merge GEODE-7208, which is lucene specific fix The fix will enable indexing on inherited attributes in user object. revision 4ec87419d456748a7d853e979c90ad4e301b2405 Regards Gester
Re: Please review PR #4024
Hi All, This has been merged. It got three reviews already so we merged it. Thanks, Mark > On Sep 18, 2019, at 4:15 PM, Kirk Lund wrote: > > Please review PR #4024 > https://github.com/apache/geode/pull/4024 > > The purpose of this PR is to reduce flaky failures involving ServerLauncher > tests.
Re: Backward compatibility issue in 1.10
I agree that it is not needed in 1.10 since this interface is not meant to be implemented by users On Thu, Sep 19, 2019 at 5:25 AM Jacob Barrett wrote: > Good find. I agree that it’s fine since it’s not a user implemented > interface. > > > On Sep 19, 2019, at 1:20 AM, Alberto Bustamante Reyes > wrote: > > > > Hi, > > > > During PR review of GEODE-6871 it was found that GEODE-5222 introduced a > backward compatibility issue by adding a new method to a public interface > without providing a default implementation. > > According to comments in the PR, although the impacted interface > (DiskStoreMXBean) is public, it should not be implemented by applications, > so the risk of breaking backward compatibility is low, but it exists. > > > > Do you think this issue should be fixed in 1.10? > > > > BR/ > > > > Alberto >
Re: Backward compatibility issue in 1.10
Good find. I agree that it’s fine since it’s not a user implemented interface. > On Sep 19, 2019, at 1:20 AM, Alberto Bustamante Reyes > wrote: > > Hi, > > During PR review of GEODE-6871 it was found that GEODE-5222 introduced a > backward compatibility issue by adding a new method to a public interface > without providing a default implementation. > According to comments in the PR, although the impacted interface > (DiskStoreMXBean) is public, it should not be implemented by applications, so > the risk of breaking backward compatibility is low, but it exists. > > Do you think this issue should be fixed in 1.10? > > BR/ > > Alberto
Backward compatibility issue in 1.10
Hi, During PR review of GEODE-6871 it was found that GEODE-5222 introduced a backward compatibility issue by adding a new method to a public interface without providing a default implementation. According to comments in the PR, although the impacted interface (DiskStoreMXBean) is public, it should not be implemented by applications, so the risk of breaking backward compatibility is low, but it exists. Do you think this issue should be fixed in 1.10? BR/ Alberto
