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 <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
