Re: 1.9 release date

[Owen Nichols]

Definitely makes sense to have some soak time, as it appears we just reached 
“code complete” this morning.

I would love to see the automated tests in the release pipeline run at least 
once a day for a couple weeks to help surface any new issues from the recent 
flurry of changes.  If no one objects, I will go ahead and add a “daily” 
trigger to that pipeline.

-Owen

> On Mar 1, 2019, at 4:10 PM, Jason Huynh  wrote:
> 
> To Alexander's point, I'm use the latest geode snapshot and am seeing an
> issue that looks similar to (if not the same as) GEODE-3780 (but this one
> is closed).
> I'd like to explore this a bit more and decide if that should be reopened
> but I am not sure if it's not an issue important enough to wait for.
> 
> I think some soak time would be nice but I can understand that it's not a
> clear criteria.
> 
> On Fri, Mar 1, 2019 at 3:57 PM Sai Boorlagadda 
> wrote:
> 
>> I started working on LICENSE issues.
>> 
>> On Fri, Mar 1, 2019 at 3:55 PM Anthony Baker  wrote:
>> 
>>> I’ll point out that the license issue I mentioned earlier this week isn’t
>>> resolved.  And that we’re bundling potentially incompatible Jackson jars.
>>> 
>>> Anthony
>>> 
>>> 
 On Mar 1, 2019, at 3:41 PM, Alexander Murmann 
>>> wrote:
 
 Clear quality metrics is definitely great. However, we've also seen in
>>> the
 past that we sometimes find new issues by continue work on the code and
 some folks starting to use them on their own projects. For that
>> reason, I
 think it might be wise to give ourselves some extra time to run into
>>> issues
 organically. Maybe we don't need that as our coverage improves.
 
 On Fri, Mar 1, 2019 at 3:24 PM Owen Nichols 
>> wrote:
 
> The release criteria of “based on meeting quality goals” sounds great.
> 
> What are those quality goals exactly, and can we objectively measure
> progress against them?
> 
> It looks like we already have a number of well-defined quality goals
>> in
> https://cwiki.apache.org/confluence/display/GEODE/Release+process <
> https://cwiki.apache.org/confluence/display/GEODE/Release+process>
> Presuming this is up-to-date, we need to satisfy 8 required quality
>>> goals
> before we can release.
> 
> Thus far, we have not met the goal "Build is successful including
> automated tests”.
> To meet it, is one “all green" run in the release pipeline <
> 
>>> 
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main?groups=complete
 
> sufficient?  Or should we require 2 or 3 “all green” runs on the same
>>> SHA?
> 
> Do Windows tests count toward “all green”?  Currently they are not in
>>> the
> default view (same as 1.8.0).
> 
> The Geode release process document above also lists an additional 11
> quality goals as “optional.”  I assume these are meant as suggestions
>>> the
> community may wish to consider when voting on a release?
> 
> If anyone feels the existing release process documentation does not
> adequately define what quality goals must be met in order to release,
>>> let’s
> discuss (and get those docs updated!)
> 
> -Owen
> 
>> On Mar 1, 2019, at 8:02 AM, Anthony Baker  wrote:
>> 
>> IMHO we start release work based on a quarterly schedule and we
>> finish
> it based on meeting quality goals.  So right now I’m less worried
>> about
> when the release will be done (because uncertainty) and more focused
>> on
> ensuring we have demonstrated stability on the release branch.
>>> Hopefully
> that will happen sooner than 4/1…but it could take longer too.
>> 
>> Anthony
>> 
>> 
>>> On Feb 28, 2019, at 6:00 PM, Alexander Murmann >> 
> wrote:
>>> 
>>> Hi everyone,
>>> 
>>> According to our wiki we were aiming for a March 1st release date
>> for
> our
>>> 1.9 release. We cut the release branch about two weeks late and see
> unusual
>>> amounts of merges still going into the branch. I propose that we
>> give
>>> ourselves some more time to validate what's there. My proposal is to
>>> aim
>>> for last week of March or maybe even week of April 1st.
>>> 
>>> What do you all think?
>> 
> 
> 
 
 --
 Alexander J. Murmann
 (650) 283-1933
>>> 
>>> 
>> 

Re: 1.9 release date

[Jason Huynh]

To Alexander's point, I'm use the latest geode snapshot and am seeing an
issue that looks similar to (if not the same as) GEODE-3780 (but this one
is closed).
I'd like to explore this a bit more and decide if that should be reopened
but I am not sure if it's not an issue important enough to wait for.

I think some soak time would be nice but I can understand that it's not a
clear criteria.

On Fri, Mar 1, 2019 at 3:57 PM Sai Boorlagadda 
wrote:

> I started working on LICENSE issues.
>
> On Fri, Mar 1, 2019 at 3:55 PM Anthony Baker  wrote:
>
> > I’ll point out that the license issue I mentioned earlier this week isn’t
> > resolved.  And that we’re bundling potentially incompatible Jackson jars.
> >
> > Anthony
> >
> >
> > > On Mar 1, 2019, at 3:41 PM, Alexander Murmann 
> > wrote:
> > >
> > > Clear quality metrics is definitely great. However, we've also seen in
> > the
> > > past that we sometimes find new issues by continue work on the code and
> > > some folks starting to use them on their own projects. For that
> reason, I
> > > think it might be wise to give ourselves some extra time to run into
> > issues
> > > organically. Maybe we don't need that as our coverage improves.
> > >
> > > On Fri, Mar 1, 2019 at 3:24 PM Owen Nichols 
> wrote:
> > >
> > >> The release criteria of “based on meeting quality goals” sounds great.
> > >>
> > >> What are those quality goals exactly, and can we objectively measure
> > >> progress against them?
> > >>
> > >> It looks like we already have a number of well-defined quality goals
> in
> > >> https://cwiki.apache.org/confluence/display/GEODE/Release+process <
> > >> https://cwiki.apache.org/confluence/display/GEODE/Release+process>
> > >> Presuming this is up-to-date, we need to satisfy 8 required quality
> > goals
> > >> before we can release.
> > >>
> > >> Thus far, we have not met the goal "Build is successful including
> > >> automated tests”.
> > >> To meet it, is one “all green" run in the release pipeline <
> > >>
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main?groups=complete
> > >
> > >> sufficient?  Or should we require 2 or 3 “all green” runs on the same
> > SHA?
> > >>
> > >> Do Windows tests count toward “all green”?  Currently they are not in
> > the
> > >> default view (same as 1.8.0).
> > >>
> > >> The Geode release process document above also lists an additional 11
> > >> quality goals as “optional.”  I assume these are meant as suggestions
> > the
> > >> community may wish to consider when voting on a release?
> > >>
> > >> If anyone feels the existing release process documentation does not
> > >> adequately define what quality goals must be met in order to release,
> > let’s
> > >> discuss (and get those docs updated!)
> > >>
> > >> -Owen
> > >>
> > >>> On Mar 1, 2019, at 8:02 AM, Anthony Baker  wrote:
> > >>>
> > >>> IMHO we start release work based on a quarterly schedule and we
> finish
> > >> it based on meeting quality goals.  So right now I’m less worried
> about
> > >> when the release will be done (because uncertainty) and more focused
> on
> > >> ensuring we have demonstrated stability on the release branch.
> > Hopefully
> > >> that will happen sooner than 4/1…but it could take longer too.
> > >>>
> > >>> Anthony
> > >>>
> > >>>
> >  On Feb 28, 2019, at 6:00 PM, Alexander Murmann  >
> > >> wrote:
> > 
> >  Hi everyone,
> > 
> >  According to our wiki we were aiming for a March 1st release date
> for
> > >> our
> >  1.9 release. We cut the release branch about two weeks late and see
> > >> unusual
> >  amounts of merges still going into the branch. I propose that we
> give
> >  ourselves some more time to validate what's there. My proposal is to
> > aim
> >  for last week of March or maybe even week of April 1st.
> > 
> >  What do you all think?
> > >>>
> > >>
> > >>
> > >
> > > --
> > > Alexander J. Murmann
> > > (650) 283-1933
> >
> >
>

Re: 1.9 release date

[Sai Boorlagadda]

I started working on LICENSE issues.

On Fri, Mar 1, 2019 at 3:55 PM Anthony Baker  wrote:

> I’ll point out that the license issue I mentioned earlier this week isn’t
> resolved.  And that we’re bundling potentially incompatible Jackson jars.
>
> Anthony
>
>
> > On Mar 1, 2019, at 3:41 PM, Alexander Murmann 
> wrote:
> >
> > Clear quality metrics is definitely great. However, we've also seen in
> the
> > past that we sometimes find new issues by continue work on the code and
> > some folks starting to use them on their own projects. For that reason, I
> > think it might be wise to give ourselves some extra time to run into
> issues
> > organically. Maybe we don't need that as our coverage improves.
> >
> > On Fri, Mar 1, 2019 at 3:24 PM Owen Nichols  wrote:
> >
> >> The release criteria of “based on meeting quality goals” sounds great.
> >>
> >> What are those quality goals exactly, and can we objectively measure
> >> progress against them?
> >>
> >> It looks like we already have a number of well-defined quality goals in
> >> https://cwiki.apache.org/confluence/display/GEODE/Release+process <
> >> https://cwiki.apache.org/confluence/display/GEODE/Release+process>
> >> Presuming this is up-to-date, we need to satisfy 8 required quality
> goals
> >> before we can release.
> >>
> >> Thus far, we have not met the goal "Build is successful including
> >> automated tests”.
> >> To meet it, is one “all green" run in the release pipeline <
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main?groups=complete
> >
> >> sufficient?  Or should we require 2 or 3 “all green” runs on the same
> SHA?
> >>
> >> Do Windows tests count toward “all green”?  Currently they are not in
> the
> >> default view (same as 1.8.0).
> >>
> >> The Geode release process document above also lists an additional 11
> >> quality goals as “optional.”  I assume these are meant as suggestions
> the
> >> community may wish to consider when voting on a release?
> >>
> >> If anyone feels the existing release process documentation does not
> >> adequately define what quality goals must be met in order to release,
> let’s
> >> discuss (and get those docs updated!)
> >>
> >> -Owen
> >>
> >>> On Mar 1, 2019, at 8:02 AM, Anthony Baker  wrote:
> >>>
> >>> IMHO we start release work based on a quarterly schedule and we finish
> >> it based on meeting quality goals.  So right now I’m less worried about
> >> when the release will be done (because uncertainty) and more focused on
> >> ensuring we have demonstrated stability on the release branch.
> Hopefully
> >> that will happen sooner than 4/1…but it could take longer too.
> >>>
> >>> Anthony
> >>>
> >>>
>  On Feb 28, 2019, at 6:00 PM, Alexander Murmann 
> >> wrote:
> 
>  Hi everyone,
> 
>  According to our wiki we were aiming for a March 1st release date for
> >> our
>  1.9 release. We cut the release branch about two weeks late and see
> >> unusual
>  amounts of merges still going into the branch. I propose that we give
>  ourselves some more time to validate what's there. My proposal is to
> aim
>  for last week of March or maybe even week of April 1st.
> 
>  What do you all think?
> >>>
> >>
> >>
> >
> > --
> > Alexander J. Murmann
> > (650) 283-1933
>
>

Re: 1.9 release date

[Anthony Baker]

I’ll point out that the license issue I mentioned earlier this week isn’t 
resolved.  And that we’re bundling potentially incompatible Jackson jars.

Anthony


> On Mar 1, 2019, at 3:41 PM, Alexander Murmann  wrote:
> 
> Clear quality metrics is definitely great. However, we've also seen in the
> past that we sometimes find new issues by continue work on the code and
> some folks starting to use them on their own projects. For that reason, I
> think it might be wise to give ourselves some extra time to run into issues
> organically. Maybe we don't need that as our coverage improves.
> 
> On Fri, Mar 1, 2019 at 3:24 PM Owen Nichols  wrote:
> 
>> The release criteria of “based on meeting quality goals” sounds great.
>> 
>> What are those quality goals exactly, and can we objectively measure
>> progress against them?
>> 
>> It looks like we already have a number of well-defined quality goals in
>> https://cwiki.apache.org/confluence/display/GEODE/Release+process <
>> https://cwiki.apache.org/confluence/display/GEODE/Release+process>
>> Presuming this is up-to-date, we need to satisfy 8 required quality goals
>> before we can release.
>> 
>> Thus far, we have not met the goal "Build is successful including
>> automated tests”.
>> To meet it, is one “all green" run in the release pipeline <
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main?groups=complete>
>> sufficient?  Or should we require 2 or 3 “all green” runs on the same SHA?
>> 
>> Do Windows tests count toward “all green”?  Currently they are not in the
>> default view (same as 1.8.0).
>> 
>> The Geode release process document above also lists an additional 11
>> quality goals as “optional.”  I assume these are meant as suggestions the
>> community may wish to consider when voting on a release?
>> 
>> If anyone feels the existing release process documentation does not
>> adequately define what quality goals must be met in order to release, let’s
>> discuss (and get those docs updated!)
>> 
>> -Owen
>> 
>>> On Mar 1, 2019, at 8:02 AM, Anthony Baker  wrote:
>>> 
>>> IMHO we start release work based on a quarterly schedule and we finish
>> it based on meeting quality goals.  So right now I’m less worried about
>> when the release will be done (because uncertainty) and more focused on
>> ensuring we have demonstrated stability on the release branch.  Hopefully
>> that will happen sooner than 4/1…but it could take longer too.
>>> 
>>> Anthony
>>> 
>>> 
 On Feb 28, 2019, at 6:00 PM, Alexander Murmann 
>> wrote:
 
 Hi everyone,
 
 According to our wiki we were aiming for a March 1st release date for
>> our
 1.9 release. We cut the release branch about two weeks late and see
>> unusual
 amounts of merges still going into the branch. I propose that we give
 ourselves some more time to validate what's there. My proposal is to aim
 for last week of March or maybe even week of April 1st.
 
 What do you all think?
>>> 
>> 
>> 
> 
> -- 
> Alexander J. Murmann
> (650) 283-1933

Re: 1.9 release date

[Alexander Murmann]

Clear quality metrics is definitely great. However, we've also seen in the
past that we sometimes find new issues by continue work on the code and
some folks starting to use them on their own projects. For that reason, I
think it might be wise to give ourselves some extra time to run into issues
organically. Maybe we don't need that as our coverage improves.

On Fri, Mar 1, 2019 at 3:24 PM Owen Nichols  wrote:

> The release criteria of “based on meeting quality goals” sounds great.
>
> What are those quality goals exactly, and can we objectively measure
> progress against them?
>
> It looks like we already have a number of well-defined quality goals in
> https://cwiki.apache.org/confluence/display/GEODE/Release+process <
> https://cwiki.apache.org/confluence/display/GEODE/Release+process>
> Presuming this is up-to-date, we need to satisfy 8 required quality goals
> before we can release.
>
> Thus far, we have not met the goal "Build is successful including
> automated tests”.
> To meet it, is one “all green" run in the release pipeline <
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main?groups=complete>
> sufficient?  Or should we require 2 or 3 “all green” runs on the same SHA?
>
> Do Windows tests count toward “all green”?  Currently they are not in the
> default view (same as 1.8.0).
>
> The Geode release process document above also lists an additional 11
> quality goals as “optional.”  I assume these are meant as suggestions the
> community may wish to consider when voting on a release?
>
> If anyone feels the existing release process documentation does not
> adequately define what quality goals must be met in order to release, let’s
> discuss (and get those docs updated!)
>
> -Owen
>
> > On Mar 1, 2019, at 8:02 AM, Anthony Baker  wrote:
> >
> > IMHO we start release work based on a quarterly schedule and we finish
> it based on meeting quality goals.  So right now I’m less worried about
> when the release will be done (because uncertainty) and more focused on
> ensuring we have demonstrated stability on the release branch.  Hopefully
> that will happen sooner than 4/1…but it could take longer too.
> >
> > Anthony
> >
> >
> >> On Feb 28, 2019, at 6:00 PM, Alexander Murmann 
> wrote:
> >>
> >> Hi everyone,
> >>
> >> According to our wiki we were aiming for a March 1st release date for
> our
> >> 1.9 release. We cut the release branch about two weeks late and see
> unusual
> >> amounts of merges still going into the branch. I propose that we give
> >> ourselves some more time to validate what's there. My proposal is to aim
> >> for last week of March or maybe even week of April 1st.
> >>
> >> What do you all think?
> >
>
>

-- 
Alexander J. Murmann
(650) 283-1933

Re: 1.9 release date

[Owen Nichols]

The release criteria of “based on meeting quality goals” sounds great.

What are those quality goals exactly, and can we objectively measure progress 
against them?

It looks like we already have a number of well-defined quality goals in 
https://cwiki.apache.org/confluence/display/GEODE/Release+process 

Presuming this is up-to-date, we need to satisfy 8 required quality goals 
before we can release.

Thus far, we have not met the goal "Build is successful including automated 
tests”.
To meet it, is one “all green" run in the release pipeline 

 sufficient?  Or should we require 2 or 3 “all green” runs on the same SHA?

Do Windows tests count toward “all green”?  Currently they are not in the 
default view (same as 1.8.0).

The Geode release process document above also lists an additional 11 quality 
goals as “optional.”  I assume these are meant as suggestions the community may 
wish to consider when voting on a release?

If anyone feels the existing release process documentation does not adequately 
define what quality goals must be met in order to release, let’s discuss (and 
get those docs updated!)

-Owen

> On Mar 1, 2019, at 8:02 AM, Anthony Baker  wrote:
> 
> IMHO we start release work based on a quarterly schedule and we finish it 
> based on meeting quality goals.  So right now I’m less worried about when the 
> release will be done (because uncertainty) and more focused on ensuring we 
> have demonstrated stability on the release branch.  Hopefully that will 
> happen sooner than 4/1…but it could take longer too.
> 
> Anthony
> 
> 
>> On Feb 28, 2019, at 6:00 PM, Alexander Murmann  wrote:
>> 
>> Hi everyone,
>> 
>> According to our wiki we were aiming for a March 1st release date for our
>> 1.9 release. We cut the release branch about two weeks late and see unusual
>> amounts of merges still going into the branch. I propose that we give
>> ourselves some more time to validate what's there. My proposal is to aim
>> for last week of March or maybe even week of April 1st.
>> 
>> What do you all think?
> 

Re: 1.9 release date

[Sai Boorlagadda]

I am aligned here that we should not be firm on a date be flexible to get a
more stable release out.

But could someone explain to me how would we measure this stability? The
pipelines are green
and the community members have cherry-picked all issues that were critical.

Unless we have some process or measure to identify the stability there is
no way
we can pick a date whether its April 1st or earlier to create a release
candidate.

Sai

On Fri, Mar 1, 2019 at 8:51 AM Michael Stolz  wrote:

> I think this is exactly the right balance. Yay!
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Lead
> Mobile: +1-631-835-4771
>
>
>
> On Fri, Mar 1, 2019 at 11:48 AM Ryan McMahon  wrote:
>
> > +1 to prioritizing quality over releasing on the desired cadence.  The
> > quarterly release cadence is a good goal, but it shouldn't be a strict
> rule
> > if there is more work to be done to ensure good quality.
> >
> > Ryan
> >
> > On Fri, Mar 1, 2019 at 8:02 AM Anthony Baker  wrote:
> >
> > > IMHO we start release work based on a quarterly schedule and we finish
> it
> > > based on meeting quality goals.  So right now I’m less worried about
> when
> > > the release will be done (because uncertainty) and more focused on
> > ensuring
> > > we have demonstrated stability on the release branch.  Hopefully that
> > will
> > > happen sooner than 4/1…but it could take longer too.
> > >
> > > Anthony
> > >
> > >
> > > > On Feb 28, 2019, at 6:00 PM, Alexander Murmann 
> > > wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > According to our wiki we were aiming for a March 1st release date for
> > our
> > > > 1.9 release. We cut the release branch about two weeks late and see
> > > unusual
> > > > amounts of merges still going into the branch. I propose that we give
> > > > ourselves some more time to validate what's there. My proposal is to
> > aim
> > > > for last week of March or maybe even week of April 1st.
> > > >
> > > > What do you all think?
> > >
> > >
> >
>

Re: I need to merge the fix for 6468 into release/1.9.0

[Bruce Schuchardt]

The fix for GEODE-6468 has been merged into release/1.9.0

On 2/28/19 5:10 PM, Sai Boorlagadda wrote:

+1 for merging this fix to release/1.9.0 as this is required for the
NIO related changes that are already merged.

On Thu, Feb 28, 2019 at 4:47 PM Bruce Schuchardt 
wrote:


This is another ticket associated with the SSL/NIO work that is already
in release/1.9.0

commit 6d1d82a15a5c548b2aafeff8bf023d12044581e7 (HEAD -> develop,
origin/develop)
Author: Bruce Schuchardt 
Date:   Thu Feb 28 16:44:30 2019 -0800

  GEODE-6468 [CI Failure] ClusterCommunicationsDUnitTest fails on
createEntryAndVerifyUpdate

  Modified Connection.java to not modify the app-data input buffer in
the
  handshake thread after notifying the handshake waiter.

Re: 1.9 release date

[Michael Stolz]

I think this is exactly the right balance. Yay!

--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771



On Fri, Mar 1, 2019 at 11:48 AM Ryan McMahon  wrote:

> +1 to prioritizing quality over releasing on the desired cadence.  The
> quarterly release cadence is a good goal, but it shouldn't be a strict rule
> if there is more work to be done to ensure good quality.
>
> Ryan
>
> On Fri, Mar 1, 2019 at 8:02 AM Anthony Baker  wrote:
>
> > IMHO we start release work based on a quarterly schedule and we finish it
> > based on meeting quality goals.  So right now I’m less worried about when
> > the release will be done (because uncertainty) and more focused on
> ensuring
> > we have demonstrated stability on the release branch.  Hopefully that
> will
> > happen sooner than 4/1…but it could take longer too.
> >
> > Anthony
> >
> >
> > > On Feb 28, 2019, at 6:00 PM, Alexander Murmann 
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > According to our wiki we were aiming for a March 1st release date for
> our
> > > 1.9 release. We cut the release branch about two weeks late and see
> > unusual
> > > amounts of merges still going into the branch. I propose that we give
> > > ourselves some more time to validate what's there. My proposal is to
> aim
> > > for last week of March or maybe even week of April 1st.
> > >
> > > What do you all think?
> >
> >
>

Re: 1.9 release date

[Jacob Barrett]

What Anthony said. +1

> On Mar 1, 2019, at 8:02 AM, Anthony Baker  wrote:
> 
> IMHO we start release work based on a quarterly schedule and we finish it 
> based on meeting quality goals.  So right now I’m less worried about when the 
> release will be done (because uncertainty) and more focused on ensuring we 
> have demonstrated stability on the release branch.  Hopefully that will 
> happen sooner than 4/1…but it could take longer too.
> 
> Anthony
> 
> 
>> On Feb 28, 2019, at 6:00 PM, Alexander Murmann  wrote:
>> 
>> Hi everyone,
>> 
>> According to our wiki we were aiming for a March 1st release date for our
>> 1.9 release. We cut the release branch about two weeks late and see unusual
>> amounts of merges still going into the branch. I propose that we give
>> ourselves some more time to validate what's there. My proposal is to aim
>> for last week of March or maybe even week of April 1st.
>> 
>> What do you all think?
> 

Re: 1.9 release date

[Ryan McMahon]

+1 to prioritizing quality over releasing on the desired cadence.  The
quarterly release cadence is a good goal, but it shouldn't be a strict rule
if there is more work to be done to ensure good quality.

Ryan

On Fri, Mar 1, 2019 at 8:02 AM Anthony Baker  wrote:

> IMHO we start release work based on a quarterly schedule and we finish it
> based on meeting quality goals.  So right now I’m less worried about when
> the release will be done (because uncertainty) and more focused on ensuring
> we have demonstrated stability on the release branch.  Hopefully that will
> happen sooner than 4/1…but it could take longer too.
>
> Anthony
>
>
> > On Feb 28, 2019, at 6:00 PM, Alexander Murmann 
> wrote:
> >
> > Hi everyone,
> >
> > According to our wiki we were aiming for a March 1st release date for our
> > 1.9 release. We cut the release branch about two weeks late and see
> unusual
> > amounts of merges still going into the branch. I propose that we give
> > ourselves some more time to validate what's there. My proposal is to aim
> > for last week of March or maybe even week of April 1st.
> >
> > What do you all think?
>
>

Re: 1.9 release date

[Anthony Baker]

IMHO we start release work based on a quarterly schedule and we finish it based 
on meeting quality goals.  So right now I’m less worried about when the release 
will be done (because uncertainty) and more focused on ensuring we have 
demonstrated stability on the release branch.  Hopefully that will happen 
sooner than 4/1…but it could take longer too.

Anthony


> On Feb 28, 2019, at 6:00 PM, Alexander Murmann  wrote:
> 
> Hi everyone,
> 
> According to our wiki we were aiming for a March 1st release date for our
> 1.9 release. We cut the release branch about two weeks late and see unusual
> amounts of merges still going into the branch. I propose that we give
> ourselves some more time to validate what's there. My proposal is to aim
> for last week of March or maybe even week of April 1st.
> 
> What do you all think?

Re: would like to bring GEODE-6447 to 1.9.0 (fix bind exceptions in Windows tests)

[Sai Boorlagadda]

+1

On Thu, Feb 28, 2019 at 6:25 PM Owen Nichols  wrote:

> This would eliminate a lot of noise from Windows tests, any objection to
> cherry-picking it to release/1.9.0?
>
> This is a test-only change.
>
> Thanks,
> -Owen