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
rele
geode-6393 was experimental and should be dropped. The fix for the
cluster-configuration deadlock will be included in the fix for GEODE-6369.
On 2/14/19 10:20 AM, Anthony Baker wrote:
There’s also GEODE-6393 and GEODE-6369 related to auto-reconnect issues.
On Feb 14, 2019, at 9:09 AM, Nabaru
Ahhh. Thank you Alexander. That makes sense.
I agree with you, as I mentioned in an earlier email
*I agree with the cutting the release branch, keep it sanitized from
additional commits going into develop but ensure only these important
critical fixes mentioned above in this chain makes it into th
Naba, I agree that we should fix these before releasing. I was talking
about the trade offs between fixing on develop and then branch or branching
first and then fixing on develop and release branch.
On Thu, Feb 14, 2019 at 1:18 PM Nabarun Nag wrote:
> I agree but not putting in these fixes mean
Here's a PR for a revert of the offending commits.
https://github.com/apache/geode/pull/3195
Seems valuable to revert for now and decide a path forward rather than rush
to get in 1.9
-michael
On Wed, Feb 13, 2019 at 9:51 PM Jacob Barrett wrote:
> How about mod MAX_INT? It would wrap back to 0
I agree but not putting in these fixes means that we are releasing with
serious known issues in the product. Hence in my opinion this risk is
acceptable.
Regards
Naba
On Thu, Feb 14, 2019 at 12:34 PM Alexander Murmann
wrote:
> >
> > For the second part, I am not sure how it was determined that
>
> For the second part, I am not sure how it was determined that fixes for
> GEODE-6391, GEODE-6393, GEODE-6369, GEODE-6404 contains risk of introducing
> more failures. Are we lacking tests , reviews etc. I apologize but I was
> not able to understand.
>
Not sure if you were responding to me. My
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
wrote:
> Did we not agreed that we won't be blocking a
I agree with the cutting the release branch, keep it sanitized from
additional commits going into develop but ensure only these important
critical fixes mentioned above in this chain makes it into the release
branch.
For the second part, I am not sure how it was determined that fixes for
GEODE-639
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
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
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
I volunteer to be the release manager for 1.9.
Sai
On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann
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
> wrote:
>
> > Hi
Oops, I also would like to see GEODE-6404 resolved for 1.9
On Thu, Feb 14, 2019 at 10:20 AM Anthony Baker wrote:
> There’s also GEODE-6393 and GEODE-6369 related to auto-reconnect issues.
>
> > On Feb 14, 2019, at 9:09 AM, Nabarun Nag wrote:
> >
> > I think also GEODE-6391, which is to fix a NP
There’s also GEODE-6393 and GEODE-6369 related to auto-reconnect issues.
> On Feb 14, 2019, at 9:09 AM, Nabarun Nag wrote:
>
> I think also GEODE-6391, which is to fix a NPE while propagating región
> destroy and invalidate region messages.
>
> Regards
> Naba
>
>
> On Thu, Feb 14, 2019 at 9:0
I think also GEODE-6391, which is to fix a NPE while propagating región
destroy and invalidate region messages.
Regards
Naba
On Thu, Feb 14, 2019 at 9:06 AM Jason Huynh wrote:
> I think Kirk's topic and any solution related to stats (int to long) should
> be resolved before cutting the branch?
I think Kirk's topic and any solution related to stats (int to long) should
be resolved before cutting the branch?
On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann
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
org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
> cannotStopServerAsClusterReaderOverHttp FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
17 matches
Mail list logo
