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 <u...@apache.com> 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 <gz...@pivotal.io> 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 <onich...@pivotal.io> > wrote: > >> > >>>> On Sep 19, 2019, at 11:15 AM, Xiaojian Zhou <gz...@pivotal.io> 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 <onich...@pivotal.io> > >>> 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 <e...@pivotal.io> wrote: > >>>>>> > >>>>>>> +1 > >>>>>>> > >>>>>>> > >>>>>>> On Thu, Sep 19, 2019 at 10:59 AM Benjamin Ross <br...@pivotal.io> > >>>>> wrote: > >>>>>>>> +1 > >>>>>>>> > >>>>>>>> On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag <n...@pivotal.io> > >>> wrote: > >>>>>>>>> +1 > >>>>>>>>> > >>>>>>>>> On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou <gz...@pivotal.io > > > >>>>>>> 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 > >>>>>>>>>> > >>>>> > >>> >
