While we can’t fix *all known bugs*, I think where we do have a fix for an 
important issue we should think hard about the cost of not including that in a 

IMO, the fixed time approach to releases means that we *start* the release 
effort (including stabilization and bug fixing if needed) on a known date and 
we *finish* when new believe the quality of the release branch is sufficient.  
Given the number of important fixes being requested, I’m not sure we are there 

I think the release branch concept has merit because it allows us to isolate 
ongoing work from the changes needed for a release.

+1 for including GEODE-7079.


> On Aug 15, 2019, at 10:51 AM, Udo Kohlmeyer <ukohlme...@gmail.com> wrote:
> Seems everyone is in favor or including a /*non-critical*/ fix to an already 
> cut branch of the a potential release...
> Am I missing something?
> Why cut a release at all... just have a perpetual cycle of fixes added to 
> develop and users can chose what nightly snapshot build they would want to 
> use..
> I'm voting -1 on a non-critical issue, which is existing and worst effect is 
> to fill logs will NPE logs... (yes, not something we want).
> I believed that we (as a Geode community) agreed that once a release has been 
> cut, only critical issue fixes will be included. If we continue just 
> continually adding to the ALREADY CUT 1.10 release, where do we stop and when 
> do we release...
> --Udo
> On 8/15/19 10:19 AM, Nabarun Nag wrote:
>> +1
>> On Thu, Aug 15, 2019 at 10:15 AM Alexander Murmann <amurm...@apache.org>
>> wrote:
>>> +1
>>> Agreed to fixing this. It's impossible for a user to discover they hit an
>>> edge case that we fail to support till they are in prod and restart.
>>> On Thu, Aug 15, 2019 at 10:09 AM Juan José Ramos <jra...@pivotal.io>
>>> wrote:
>>>> Hello Udo,
>>>> Even if it is an existing issue I'd still consider it critical for those
>>>> cases on which there are unprocessed events on the persistent queue
>>> after a
>>>> restart and the region takes long to recover... you can actually see
>>>> millions of *NPEs* flooding the member's logs.
>>>> My two cents anyway, it's up to the community to make the final decision.
>>>> Cheers.
>>>> On Thu, Aug 15, 2019 at 5:58 PM Udo Kohlmeyer <u...@apache.com> wrote:
>>>>> Juan,
>>>>>  From your explanation, it seems this issue is existing and not
>>>>> critical. Could we possibly hold this for 1.11?
>>>>> --Udo
>>>>> On 8/15/19 5:29 AM, Ju@N wrote:
>>>>>> Hello team,
>>>>>> I'd like to propose including the *fix [1]* for *GEODE-7079 [2]* in
>>>>> release
>>>>>> 1.10.0.
>>>>>> Long story short: a *NullPointerException* can be continuously thrown
>>>>>> and flood the member's logs if a serial event processor (either
>>>>>> *async-event-queue* or *gateway-sender*) starts processing events
>>> from
>>>> a
>>>>>> recovered persistent queue before the actual region to which it was
>>>>>> attached is fully operational.
>>>>>> Note: *no events are lost (even without the fix)* but, if the region
>>>>> takes
>>>>>> a while to recover, the logs  for the member can grow pretty quickly
>>>> due
>>>>> to
>>>>>> the continuously thrown *NPEs.*
>>>>>> Best regards.
>>>>>> [1]:
>>> https://github.com/apache/geode/commit/6f4bbbd96bcecdb82cf7753ce1dae9fa6baebf9b
>>>>>> [2]: https://issues.apache.org/jira/browse/GEODE-7079
>>>> --
>>>> Juan José Ramos Cassella
>>>> Senior Software Engineer
>>>> Email: jra...@pivotal.io

Reply via email to