Re: [DISCUSS] Predictable minor release cadence

[Sai Boorlagadda]

I agree with Robert that we should release based on features that go in.

I am not sure if Apache Kafka & Spark are a good reference for GEODE.
These tools were evolving rapidly in the last couple of years and frequent
releases would be good for a growing community.

Should we do a patch release every few months to include bug fixes?

Sai


On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton  wrote:

> I have found it refreshing that the geode released cadence has been based
> on features being done,  rather than a set schedule.
>
> I come from an environment where we had quarterly releases and monthly
> patches to all supported previous releases, and I can tell you that it
> became a grind. That being said, within that release cadence a one-month
> ramp for bug fixes on the release branch was almost always sufficient.
>
> On Thu, Oct 4, 2018, 18:32 Ryan McMahon  wrote:
>
> > +1 for scheduled releases and cutting the branch one month prior to
> > release. Given the time it took to fully root out, classify, and solve
> > issues with this 1.7 release, I think a month is the right amount of time
> > between cutting the branch and releasing.  If it ends up being too much
> or
> > too little, we can always adjust.
> >
> > I don’t feel strongly about the release cadence, but I generally favor
> more
> > frequent releases if possible (3 month over 6 month).  That way new
> > features can get into the hands of users sooner, assuming the feature
> takes
> > less than 3 months to complete.  Again, we can adjust the cadence if
> > necessary if it is too frequent or infrequent.
> >
> > Ryan
> >
> > On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
> > wrote:
> >
> > > Anil, releasing every 3 months should give us 3 months of dev work.
> Don't
> > > forget that there will be one month during which the next release is
> > > already cut, but the vast majority of the work is going to the release
> > > after that. So while we cut 1.7 one month ago and release 1.7 today, we
> > > already have one month of work on develop again. It's not going to work
> > out
> > > for this first release though, due to my suggestion to cut a month
> early
> > to
> > > avoid holidays. If I recall correctly our past problem was that it took
> > > longer to iron out issue on the release branch than expected. The
> > solution
> > > to that would be to cut the release even earlier, but 1 month feels
> very
> > > generous.
> > >
> > > On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade 
> > > wrote:
> > >
> > > > If I remember from earlier discussion; the plan was to deliver a
> > release
> > > > once 3 months. But from the past release history we had difficulty in
> > > > achieving that, either the features are not completely ready or the
> > > > bug-fixes have taken more time. We need verify what is right for
> Apache
> > > > Geode, 3, 4 or 6 months; and there is any community dev/activity that
> > > > depends on Geode release.
> > > > My vote will be for 4 or 6 months, as it provides at least 3+ month
> for
> > > dev
> > > > activity and 1 month for QA.
> > > >
> > > > -Anil.
> > > >
> > > >
> > > > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> > > >
> > > > > +1 I definitely like the idea of scheduled releases.
> > > > >
> > > > > I wonder if cutting the release branch a month ahead of time is
> > > overkill,
> > > > > but I guess we do seem to keep finding issues after the branch is
> > cut.
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
> > amurm...@pivotal.io>
> > > > > wrote:
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > I want to propose shipping Geode on a regular cadence. My
> concrete
> > > > > proposal
> > > > > > is to ship Geode every 3 months on the first weekday. To make
> sure
> > we
> > > > hit
> > > > > > that date we would cut the release 1 months prior to that day.
> > > > > >
> > > > > > *Why?*
> > > > > > Knowing on what day the release will get cut and on what day we
> > ship
> > > > > allows
> > > > > > community members to plan their contributions. If I want my
> feature
> > > to
> > > > be
> > > > > > in the next release I know by when I need to have it merged to
> > > develop
> > > > > and
> > > > > > can plan accordingly. As a user who is waiting for a particular
> > > feature
> > > > > or
> > > > > > fix that's already on develop, I know when to expect the release
> > that
> > > > > > includes this work and again, can plan accordingly.
> > > > > >
> > > > > > This makes working and using Apache Geode more predictable which
> > > makes
> > > > > all
> > > > > > our lives less stressful. To make this work, it's important to be
> > > > strict
> > > > > > about cutting the release branch on the set date and only allow
> > > > critical
> > > > > > fixes after the release has been cut. Once we start compromising
> on
> > > > this,
> > > > > > we go down a slippery slope that ultimately leads to not getting
> > the
> > > > > > predictability benefits described 

Re: [DISCUSS] Predictable minor release cadence

[Robert Houghton]

I have found it refreshing that the geode released cadence has been based
on features being done,  rather than a set schedule.

I come from an environment where we had quarterly releases and monthly
patches to all supported previous releases, and I can tell you that it
became a grind. That being said, within that release cadence a one-month
ramp for bug fixes on the release branch was almost always sufficient.

On Thu, Oct 4, 2018, 18:32 Ryan McMahon  wrote:

> +1 for scheduled releases and cutting the branch one month prior to
> release. Given the time it took to fully root out, classify, and solve
> issues with this 1.7 release, I think a month is the right amount of time
> between cutting the branch and releasing.  If it ends up being too much or
> too little, we can always adjust.
>
> I don’t feel strongly about the release cadence, but I generally favor more
> frequent releases if possible (3 month over 6 month).  That way new
> features can get into the hands of users sooner, assuming the feature takes
> less than 3 months to complete.  Again, we can adjust the cadence if
> necessary if it is too frequent or infrequent.
>
> Ryan
>
> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
> wrote:
>
> > Anil, releasing every 3 months should give us 3 months of dev work. Don't
> > forget that there will be one month during which the next release is
> > already cut, but the vast majority of the work is going to the release
> > after that. So while we cut 1.7 one month ago and release 1.7 today, we
> > already have one month of work on develop again. It's not going to work
> out
> > for this first release though, due to my suggestion to cut a month early
> to
> > avoid holidays. If I recall correctly our past problem was that it took
> > longer to iron out issue on the release branch than expected. The
> solution
> > to that would be to cut the release even earlier, but 1 month feels very
> > generous.
> >
> > On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade 
> > wrote:
> >
> > > If I remember from earlier discussion; the plan was to deliver a
> release
> > > once 3 months. But from the past release history we had difficulty in
> > > achieving that, either the features are not completely ready or the
> > > bug-fixes have taken more time. We need verify what is right for Apache
> > > Geode, 3, 4 or 6 months; and there is any community dev/activity that
> > > depends on Geode release.
> > > My vote will be for 4 or 6 months, as it provides at least 3+ month for
> > dev
> > > activity and 1 month for QA.
> > >
> > > -Anil.
> > >
> > >
> > > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> > >
> > > > +1 I definitely like the idea of scheduled releases.
> > > >
> > > > I wonder if cutting the release branch a month ahead of time is
> > overkill,
> > > > but I guess we do seem to keep finding issues after the branch is
> cut.
> > > >
> > > > -Dan
> > > >
> > > > On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
> amurm...@pivotal.io>
> > > > wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > I want to propose shipping Geode on a regular cadence. My concrete
> > > > proposal
> > > > > is to ship Geode every 3 months on the first weekday. To make sure
> we
> > > hit
> > > > > that date we would cut the release 1 months prior to that day.
> > > > >
> > > > > *Why?*
> > > > > Knowing on what day the release will get cut and on what day we
> ship
> > > > allows
> > > > > community members to plan their contributions. If I want my feature
> > to
> > > be
> > > > > in the next release I know by when I need to have it merged to
> > develop
> > > > and
> > > > > can plan accordingly. As a user who is waiting for a particular
> > feature
> > > > or
> > > > > fix that's already on develop, I know when to expect the release
> that
> > > > > includes this work and again, can plan accordingly.
> > > > >
> > > > > This makes working and using Apache Geode more predictable which
> > makes
> > > > all
> > > > > our lives less stressful. To make this work, it's important to be
> > > strict
> > > > > about cutting the release branch on the set date and only allow
> > > critical
> > > > > fixes after the release has been cut. Once we start compromising on
> > > this,
> > > > > we go down a slippery slope that ultimately leads to not getting
> the
> > > > > predictability benefits described here.
> > > > >
> > > > > Some other successful Apache projects share similar approaches:
> > > > >
> > > > >- Kafka
> > > > ><
> > > >
> https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan>
> > > > >releases every 4 months and cuts the release 1 month prior
> > > > >- PredictionIO <
> > https://predictionio.apache.org/resources/release/>
> > > > > releases
> > > > >every 2 months
> > > > >- Spark  does
> > not
> > > > seem
> > > > >to have a hard date, but aims to ship every 6 months, so there
> is
> > at
> > > > > least
> > > > >a goal 

Re: [DISCUSS] Predictable minor release cadence

[Ryan McMahon]

+1 for scheduled releases and cutting the branch one month prior to
release. Given the time it took to fully root out, classify, and solve
issues with this 1.7 release, I think a month is the right amount of time
between cutting the branch and releasing.  If it ends up being too much or
too little, we can always adjust.

I don’t feel strongly about the release cadence, but I generally favor more
frequent releases if possible (3 month over 6 month).  That way new
features can get into the hands of users sooner, assuming the feature takes
less than 3 months to complete.  Again, we can adjust the cadence if
necessary if it is too frequent or infrequent.

Ryan

On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
wrote:

> Anil, releasing every 3 months should give us 3 months of dev work. Don't
> forget that there will be one month during which the next release is
> already cut, but the vast majority of the work is going to the release
> after that. So while we cut 1.7 one month ago and release 1.7 today, we
> already have one month of work on develop again. It's not going to work out
> for this first release though, due to my suggestion to cut a month early to
> avoid holidays. If I recall correctly our past problem was that it took
> longer to iron out issue on the release branch than expected. The solution
> to that would be to cut the release even earlier, but 1 month feels very
> generous.
>
> On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade 
> wrote:
>
> > If I remember from earlier discussion; the plan was to deliver a release
> > once 3 months. But from the past release history we had difficulty in
> > achieving that, either the features are not completely ready or the
> > bug-fixes have taken more time. We need verify what is right for Apache
> > Geode, 3, 4 or 6 months; and there is any community dev/activity that
> > depends on Geode release.
> > My vote will be for 4 or 6 months, as it provides at least 3+ month for
> dev
> > activity and 1 month for QA.
> >
> > -Anil.
> >
> >
> > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> >
> > > +1 I definitely like the idea of scheduled releases.
> > >
> > > I wonder if cutting the release branch a month ahead of time is
> overkill,
> > > but I guess we do seem to keep finding issues after the branch is cut.
> > >
> > > -Dan
> > >
> > > On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann 
> > > wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > I want to propose shipping Geode on a regular cadence. My concrete
> > > proposal
> > > > is to ship Geode every 3 months on the first weekday. To make sure we
> > hit
> > > > that date we would cut the release 1 months prior to that day.
> > > >
> > > > *Why?*
> > > > Knowing on what day the release will get cut and on what day we ship
> > > allows
> > > > community members to plan their contributions. If I want my feature
> to
> > be
> > > > in the next release I know by when I need to have it merged to
> develop
> > > and
> > > > can plan accordingly. As a user who is waiting for a particular
> feature
> > > or
> > > > fix that's already on develop, I know when to expect the release that
> > > > includes this work and again, can plan accordingly.
> > > >
> > > > This makes working and using Apache Geode more predictable which
> makes
> > > all
> > > > our lives less stressful. To make this work, it's important to be
> > strict
> > > > about cutting the release branch on the set date and only allow
> > critical
> > > > fixes after the release has been cut. Once we start compromising on
> > this,
> > > > we go down a slippery slope that ultimately leads to not getting the
> > > > predictability benefits described here.
> > > >
> > > > Some other successful Apache projects share similar approaches:
> > > >
> > > >- Kafka
> > > ><
> > > https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan>
> > > >releases every 4 months and cuts the release 1 month prior
> > > >- PredictionIO <
> https://predictionio.apache.org/resources/release/>
> > > > releases
> > > >every 2 months
> > > >- Spark  does
> not
> > > seem
> > > >to have a hard date, but aims to ship every 6 months, so there is
> at
> > > > least
> > > >a goal date
> > > >
> > > >
> > > > *What?*
> > > > As stated above, I suggest to release every three months. Given we
> just
> > > > shipped the next release would go out on January 2nd. That timing in
> > > > unfortunate, due to the holidays. Therefore I propose to aim for a
> > > December
> > > > 3rd (1st Monday in December) release. In order to meet that date, we
> > > should
> > > > cut the release branch on November 1st. That also means that we
> should
> > > > start finding a volunteer to manager the release on October 25th. I
> > know
> > > > this seems really close, given we just shipped, but keep in mind that
> > > this
> > > > is to avoid the holidays and that we already have close to a month
> > worth
> > > of
> 

Re: [DISCUSS] Predictable minor release cadence

[Alexander Murmann]

Anil, releasing every 3 months should give us 3 months of dev work. Don't
forget that there will be one month during which the next release is
already cut, but the vast majority of the work is going to the release
after that. So while we cut 1.7 one month ago and release 1.7 today, we
already have one month of work on develop again. It's not going to work out
for this first release though, due to my suggestion to cut a month early to
avoid holidays. If I recall correctly our past problem was that it took
longer to iron out issue on the release branch than expected. The solution
to that would be to cut the release even earlier, but 1 month feels very
generous.

On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade 
wrote:

> If I remember from earlier discussion; the plan was to deliver a release
> once 3 months. But from the past release history we had difficulty in
> achieving that, either the features are not completely ready or the
> bug-fixes have taken more time. We need verify what is right for Apache
> Geode, 3, 4 or 6 months; and there is any community dev/activity that
> depends on Geode release.
> My vote will be for 4 or 6 months, as it provides at least 3+ month for dev
> activity and 1 month for QA.
>
> -Anil.
>
>
> On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
>
> > +1 I definitely like the idea of scheduled releases.
> >
> > I wonder if cutting the release branch a month ahead of time is overkill,
> > but I guess we do seem to keep finding issues after the branch is cut.
> >
> > -Dan
> >
> > On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann 
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I want to propose shipping Geode on a regular cadence. My concrete
> > proposal
> > > is to ship Geode every 3 months on the first weekday. To make sure we
> hit
> > > that date we would cut the release 1 months prior to that day.
> > >
> > > *Why?*
> > > Knowing on what day the release will get cut and on what day we ship
> > allows
> > > community members to plan their contributions. If I want my feature to
> be
> > > in the next release I know by when I need to have it merged to develop
> > and
> > > can plan accordingly. As a user who is waiting for a particular feature
> > or
> > > fix that's already on develop, I know when to expect the release that
> > > includes this work and again, can plan accordingly.
> > >
> > > This makes working and using Apache Geode more predictable which makes
> > all
> > > our lives less stressful. To make this work, it's important to be
> strict
> > > about cutting the release branch on the set date and only allow
> critical
> > > fixes after the release has been cut. Once we start compromising on
> this,
> > > we go down a slippery slope that ultimately leads to not getting the
> > > predictability benefits described here.
> > >
> > > Some other successful Apache projects share similar approaches:
> > >
> > >- Kafka
> > ><
> > https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan>
> > >releases every 4 months and cuts the release 1 month prior
> > >- PredictionIO 
> > > releases
> > >every 2 months
> > >- Spark  does not
> > seem
> > >to have a hard date, but aims to ship every 6 months, so there is at
> > > least
> > >a goal date
> > >
> > >
> > > *What?*
> > > As stated above, I suggest to release every three months. Given we just
> > > shipped the next release would go out on January 2nd. That timing in
> > > unfortunate, due to the holidays. Therefore I propose to aim for a
> > December
> > > 3rd (1st Monday in December) release. In order to meet that date, we
> > should
> > > cut the release branch on November 1st. That also means that we should
> > > start finding a volunteer to manager the release on October 25th. I
> know
> > > this seems really close, given we just shipped, but keep in mind that
> > this
> > > is to avoid the holidays and that we already have close to a month
> worth
> > of
> > > work on develop.
> > >
> > > *Proposed near future schedule:*
> > > October 25th: Find release manager
> > > November 1st: Cut 1.8 release branch
> > > December 1st: Ship 1.8
> > > January 28th: Find release manager
> > > February 1st: Cut 1.9 release branch
> > > March 1st: Ship 1.9
> > > and so on...
> > >
> > > Thanks for sharing your thoughts and feedback on this!
> > >
> >
>

Re: [DISCUSS] Predictable minor release cadence

[Anilkumar Gingade]

If I remember from earlier discussion; the plan was to deliver a release
once 3 months. But from the past release history we had difficulty in
achieving that, either the features are not completely ready or the
bug-fixes have taken more time. We need verify what is right for Apache
Geode, 3, 4 or 6 months; and there is any community dev/activity that
depends on Geode release.
My vote will be for 4 or 6 months, as it provides at least 3+ month for dev
activity and 1 month for QA.

-Anil.


On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:

> +1 I definitely like the idea of scheduled releases.
>
> I wonder if cutting the release branch a month ahead of time is overkill,
> but I guess we do seem to keep finding issues after the branch is cut.
>
> -Dan
>
> On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann 
> wrote:
>
> > Hi everyone,
> >
> > I want to propose shipping Geode on a regular cadence. My concrete
> proposal
> > is to ship Geode every 3 months on the first weekday. To make sure we hit
> > that date we would cut the release 1 months prior to that day.
> >
> > *Why?*
> > Knowing on what day the release will get cut and on what day we ship
> allows
> > community members to plan their contributions. If I want my feature to be
> > in the next release I know by when I need to have it merged to develop
> and
> > can plan accordingly. As a user who is waiting for a particular feature
> or
> > fix that's already on develop, I know when to expect the release that
> > includes this work and again, can plan accordingly.
> >
> > This makes working and using Apache Geode more predictable which makes
> all
> > our lives less stressful. To make this work, it's important to be strict
> > about cutting the release branch on the set date and only allow critical
> > fixes after the release has been cut. Once we start compromising on this,
> > we go down a slippery slope that ultimately leads to not getting the
> > predictability benefits described here.
> >
> > Some other successful Apache projects share similar approaches:
> >
> >- Kafka
> ><
> https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan>
> >releases every 4 months and cuts the release 1 month prior
> >- PredictionIO 
> > releases
> >every 2 months
> >- Spark  does not
> seem
> >to have a hard date, but aims to ship every 6 months, so there is at
> > least
> >a goal date
> >
> >
> > *What?*
> > As stated above, I suggest to release every three months. Given we just
> > shipped the next release would go out on January 2nd. That timing in
> > unfortunate, due to the holidays. Therefore I propose to aim for a
> December
> > 3rd (1st Monday in December) release. In order to meet that date, we
> should
> > cut the release branch on November 1st. That also means that we should
> > start finding a volunteer to manager the release on October 25th. I know
> > this seems really close, given we just shipped, but keep in mind that
> this
> > is to avoid the holidays and that we already have close to a month worth
> of
> > work on develop.
> >
> > *Proposed near future schedule:*
> > October 25th: Find release manager
> > November 1st: Cut 1.8 release branch
> > December 1st: Ship 1.8
> > January 28th: Find release manager
> > February 1st: Cut 1.9 release branch
> > March 1st: Ship 1.9
> > and so on...
> >
> > Thanks for sharing your thoughts and feedback on this!
> >
>

proposing reduced default for "membership-port-range"

[Brian Rowe]

Currently the default value for this parameter covers the default locator
and server port values.  As a result of this, when launching a locator and
then a server on the same system using gfsh, it's possible to see the
server fail because the locator has already bound the default server
socket.  We've actually seen a couple of test runs fail with this issue.

The proposed new range is 41000-61000, which, in addition to not
overlapping the other default port values, has the benefit of being a
subset of the linux ephemeral ports (for users who care about such
things).  Please let me know if there are any objections to this change.

Here's the current javadoc for this parameter:

Description: The allowed range of ports for use in forming an unique
membership identifier (UDP), for failure detection purposes (TCP) and to
listen on for peer connections (TCP). This range is given as two numbers
separated by a minus sign. Minimum 3 values in range are required to
successfully startup.
Default: 1024-65535

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1060 was SUCCESSFUL (with 2456 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #1060 was successful.
---
Scheduled
2458 tests in total.

https://build.spring.io/browse/SGF-NAG-1060/





--
This message is automatically generated by Atlassian Bamboo

Re: [DISCUSS] Predictable minor release cadence

[Nabarun Nag]

+1 on the scheduled release and also on one month prior to release we cut
the branch.

@Dan  I feel keeping a one month will give a very comfortable time frame to
test + retest the release branch and we will be releasing a stable release
candidate.
For 1.7.0, it did take a month from cutting the branch till releasing RC2.
As testing of release/1.7.0 + RC1 was time bounded as voting time frame was
72hours. If we have the release branch for a month, we don't have to hurry
with the testing.

Regards
Nabarun Nag

On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:

> +1 I definitely like the idea of scheduled releases.
>
> I wonder if cutting the release branch a month ahead of time is overkill,
> but I guess we do seem to keep finding issues after the branch is cut.
>
> -Dan
>
> On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann 
> wrote:
>
> > Hi everyone,
> >
> > I want to propose shipping Geode on a regular cadence. My concrete
> proposal
> > is to ship Geode every 3 months on the first weekday. To make sure we hit
> > that date we would cut the release 1 months prior to that day.
> >
> > *Why?*
> > Knowing on what day the release will get cut and on what day we ship
> allows
> > community members to plan their contributions. If I want my feature to be
> > in the next release I know by when I need to have it merged to develop
> and
> > can plan accordingly. As a user who is waiting for a particular feature
> or
> > fix that's already on develop, I know when to expect the release that
> > includes this work and again, can plan accordingly.
> >
> > This makes working and using Apache Geode more predictable which makes
> all
> > our lives less stressful. To make this work, it's important to be strict
> > about cutting the release branch on the set date and only allow critical
> > fixes after the release has been cut. Once we start compromising on this,
> > we go down a slippery slope that ultimately leads to not getting the
> > predictability benefits described here.
> >
> > Some other successful Apache projects share similar approaches:
> >
> >- Kafka
> ><
> https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan>
> >releases every 4 months and cuts the release 1 month prior
> >- PredictionIO 
> > releases
> >every 2 months
> >- Spark  does not
> seem
> >to have a hard date, but aims to ship every 6 months, so there is at
> > least
> >a goal date
> >
> >
> > *What?*
> > As stated above, I suggest to release every three months. Given we just
> > shipped the next release would go out on January 2nd. That timing in
> > unfortunate, due to the holidays. Therefore I propose to aim for a
> December
> > 3rd (1st Monday in December) release. In order to meet that date, we
> should
> > cut the release branch on November 1st. That also means that we should
> > start finding a volunteer to manager the release on October 25th. I know
> > this seems really close, given we just shipped, but keep in mind that
> this
> > is to avoid the holidays and that we already have close to a month worth
> of
> > work on develop.
> >
> > *Proposed near future schedule:*
> > October 25th: Find release manager
> > November 1st: Cut 1.8 release branch
> > December 1st: Ship 1.8
> > January 28th: Find release manager
> > February 1st: Cut 1.9 release branch
> > March 1st: Ship 1.9
> > and so on...
> >
> > Thanks for sharing your thoughts and feedback on this!
> >
>

Re: [DISCUSS] Predictable minor release cadence

[Dan Smith]

+1 I definitely like the idea of scheduled releases.

I wonder if cutting the release branch a month ahead of time is overkill,
but I guess we do seem to keep finding issues after the branch is cut.

-Dan

On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann 
wrote:

> Hi everyone,
>
> I want to propose shipping Geode on a regular cadence. My concrete proposal
> is to ship Geode every 3 months on the first weekday. To make sure we hit
> that date we would cut the release 1 months prior to that day.
>
> *Why?*
> Knowing on what day the release will get cut and on what day we ship allows
> community members to plan their contributions. If I want my feature to be
> in the next release I know by when I need to have it merged to develop and
> can plan accordingly. As a user who is waiting for a particular feature or
> fix that's already on develop, I know when to expect the release that
> includes this work and again, can plan accordingly.
>
> This makes working and using Apache Geode more predictable which makes all
> our lives less stressful. To make this work, it's important to be strict
> about cutting the release branch on the set date and only allow critical
> fixes after the release has been cut. Once we start compromising on this,
> we go down a slippery slope that ultimately leads to not getting the
> predictability benefits described here.
>
> Some other successful Apache projects share similar approaches:
>
>- Kafka
>
>releases every 4 months and cuts the release 1 month prior
>- PredictionIO 
> releases
>every 2 months
>- Spark  does not seem
>to have a hard date, but aims to ship every 6 months, so there is at
> least
>a goal date
>
>
> *What?*
> As stated above, I suggest to release every three months. Given we just
> shipped the next release would go out on January 2nd. That timing in
> unfortunate, due to the holidays. Therefore I propose to aim for a December
> 3rd (1st Monday in December) release. In order to meet that date, we should
> cut the release branch on November 1st. That also means that we should
> start finding a volunteer to manager the release on October 25th. I know
> this seems really close, given we just shipped, but keep in mind that this
> is to avoid the holidays and that we already have close to a month worth of
> work on develop.
>
> *Proposed near future schedule:*
> October 25th: Find release manager
> November 1st: Cut 1.8 release branch
> December 1st: Ship 1.8
> January 28th: Find release manager
> February 1st: Cut 1.9 release branch
> March 1st: Ship 1.9
> and so on...
>
> Thanks for sharing your thoughts and feedback on this!
>

Re: AnalyzeSerializablesJUnitTestBase failure

[Bruce Schuchardt]

By ClassName I meant the name of the offending class, not a class named 
ClassName.  Sorry for the confusion there.


You're hitting a failure in a test that ensures that classes in 
sanctioned-geode-core-serializables.txt can be serialized and 
deserialized.  The serialization filter is objecting to some class 
that's being deserialized and the test ought to have logged the name of 
that class.  You don't have to have modified the attributesImpl class to 
cause this kind of failure - you only need to have changed some class 
used by a default instance of the attributesImpl class.


If I had to guess I'd say there is a new Enumeration or something 
similar that's now being used and needs to be put into the 
sanctioned-geode-core-serializables.txt file.


This begs another question:  Is the change you made going to break 
rolling upgrade?  I don't know why the attributesImpl class is 
serializable but if it's used to exchange region configuration 
information between servers then it's not satisfactory to adjust the 
sanctioned-geode-core-serializables.txt file to fix this unit test failure.



On 10/4/18 1:24 PM, Kirk Lund wrote:

But I didn't add or touch the class ClassName -- according to git log,
Jinmei and Patrick created it in the following commit on 1/29/18 -- I
haven't touched this at all on my branch:

GEODE-3915: use ClassName type for cache-loader, writer and listeners
(#1327)

* GEODE-3915: use ClassName type for cache-loader, writer and listeners

* use json string to specify the init properties
* make sure the parser works when multiple ClassNames are specified in the
command line.
* rework AlterRegionCommandDUnitTest
* make sure AnalyzeSerializableJunitTest works in IDEA.

Signed-off-by: Patrick Rhomberg 

On Thu, Oct 4, 2018 at 11:10 AM, Bruce Schuchardt 
wrote:


It looks like your region attributes contain an instance of a class that
isn't in sanctioned-geode-core-serializables.txt.  It's also possible
that you added the class to that file but it didn't get properly copied to
the output directory, so you might check that too.

Output of this test should include a Fatal level log message that tells
you what the rejected class was:

Serialization filter is rejecting class ClassName



On 10/3/18 1:10 PM, Kirk Lund wrote:


Sure is! https://github.com/kirklund/geode/tree/GEODE-2644-Appenders-
steps3

My branch has no changes to org.apache.geode.cache.AttributesFactory or
its
inner class(es) though. I even double-checked with:

$ git log
./geode-core/src/main/java/org/apache/geode/cache/AttributesFactory.java

It just shows a couple commits by Bruce which came to my branch via
develop.

On Wed, Oct 3, 2018 at 10:38 AM, Nabarun Nag  wrote:

I used to see this issue when I  make changes in the serializable class or

its members but don't reflect it in the
sanctioned-geode-core-serializables.txt file.
If I am using a custom object in a test or something I add it
as SERIALIZABLE_OBJECT_FILTER property.

Is your branch hosted in github?

Regards
Nabarun


On Wed, Oct 3, 2018 at 10:24 AM Kirk Lund  wrote:

I have a failure on my branch that doesn't seem related to my changes.

Anyone know what's causing this failure?

Thanks!

java.lang.AssertionError: I was unable to deserialize
org.apache.geode.cache.AttributesFactory$RegionAttributesImpl
at

org.apache.geode.codeAnalysis.AnalyzeSerializablesJUnitTestBase.


serializeAndDeserializeSanctionedObject(AnalyzeSerializablesJUnitTestB
ase.java:401)


at

org.apache.geode.codeAnalysis.AnalyzeSerializablesJUnitTestBase.


testSanctionedClassesExistAndDoDeserialize(AnalyzeSerializab
lesJUnitTestB
ase.java:318)


at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

sun.reflect.NativeMethodAccessorImpl.invoke(


NativeMethodAccessorImpl.java:62)


at

sun.reflect.DelegatingMethodAccessorImpl.invoke(


DelegatingMethodAccessorImpl.java:43)


at java.lang.reflect.Method.invoke(Method.java:498)
at

org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(


FrameworkMethod.java:50)


at

org.junit.internal.runners.model.ReflectiveCallable.run(


ReflectiveCallable.java:12)


at

org.junit.runners.model.FrameworkMethod.invokeExplosively(


FrameworkMethod.java:47)


at

org.junit.internal.runners.statements.InvokeMethod.


evaluate(InvokeMethod.java:17)


at

org.junit.internal.runners.statements.RunBefores.


evaluate(RunBefores.java:26)


at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at

org.junit.runners.BlockJUnit4ClassRunner.runChild(


BlockJUnit4ClassRunner.java:78)


at

org.junit.runners.BlockJUnit4ClassRunner.runChild(


BlockJUnit4ClassRunner.java:57)


at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at 

Re: AnalyzeSerializablesJUnitTestBase failure

[Kirk Lund]

It's possible that I ran build/precheckin with a different version of Java.
Is it possible that would change the bits that
AnalyzeSerializablesJUnitTestBase is looking at and cause an unexpected
failure?

On Thu, Oct 4, 2018 at 1:24 PM, Kirk Lund  wrote:

> But I didn't add or touch the class ClassName -- according to git log,
> Jinmei and Patrick created it in the following commit on 1/29/18 -- I
> haven't touched this at all on my branch:
>
> GEODE-3915: use ClassName type for cache-loader, writer and listeners
> (#1327)
>
> * GEODE-3915: use ClassName type for cache-loader, writer and listeners
>
> * use json string to specify the init properties
> * make sure the parser works when multiple ClassNames are specified in the
> command line.
> * rework AlterRegionCommandDUnitTest
> * make sure AnalyzeSerializableJunitTest works in IDEA.
>
> Signed-off-by: Patrick Rhomberg 
>
> On Thu, Oct 4, 2018 at 11:10 AM, Bruce Schuchardt 
> wrote:
>
>> It looks like your region attributes contain an instance of a class that
>> isn't in sanctioned-geode-core-serializables.txt.  It's also possible
>> that you added the class to that file but it didn't get properly copied to
>> the output directory, so you might check that too.
>>
>> Output of this test should include a Fatal level log message that tells
>> you what the rejected class was:
>>
>> Serialization filter is rejecting class ClassName
>>
>>
>>
>> On 10/3/18 1:10 PM, Kirk Lund wrote:
>>
>>> Sure is! https://github.com/kirklund/geode/tree/GEODE-2644-Appenders-
>>> steps3
>>>
>>> My branch has no changes to org.apache.geode.cache.AttributesFactory or
>>> its
>>> inner class(es) though. I even double-checked with:
>>>
>>> $ git log
>>> ./geode-core/src/main/java/org/apache/geode/cache/AttributesFactory.java
>>>
>>> It just shows a couple commits by Bruce which came to my branch via
>>> develop.
>>>
>>> On Wed, Oct 3, 2018 at 10:38 AM, Nabarun Nag  wrote:
>>>
>>> I used to see this issue when I  make changes in the serializable class
 or
 its members but don't reflect it in the
 sanctioned-geode-core-serializables.txt file.
 If I am using a custom object in a test or something I add it
 as SERIALIZABLE_OBJECT_FILTER property.

 Is your branch hosted in github?

 Regards
 Nabarun


 On Wed, Oct 3, 2018 at 10:24 AM Kirk Lund  wrote:

 I have a failure on my branch that doesn't seem related to my changes.
> Anyone know what's causing this failure?
>
> Thanks!
>
> java.lang.AssertionError: I was unable to deserialize
> org.apache.geode.cache.AttributesFactory$RegionAttributesImpl
> at
>
> org.apache.geode.codeAnalysis.AnalyzeSerializablesJUnitTestBase.
>
 serializeAndDeserializeSanctionedObject(AnalyzeSerializablesJUnitTestB
 ase.java:401)

> at
>
> org.apache.geode.codeAnalysis.AnalyzeSerializablesJUnitTestBase.
>
 testSanctionedClassesExistAndDoDeserialize(AnalyzeSerializab
 lesJUnitTestB
 ase.java:318)

> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(
>
 NativeMethodAccessorImpl.java:62)

> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>
 DelegatingMethodAccessorImpl.java:43)

> at java.lang.reflect.Method.invoke(Method.java:498)
> at
>
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
>
 FrameworkMethod.java:50)

> at
>
> org.junit.internal.runners.model.ReflectiveCallable.run(
>
 ReflectiveCallable.java:12)

> at
>
> org.junit.runners.model.FrameworkMethod.invokeExplosively(
>
 FrameworkMethod.java:47)

> at
>
> org.junit.internal.runners.statements.InvokeMethod.
>
 evaluate(InvokeMethod.java:17)

> at
>
> org.junit.internal.runners.statements.RunBefores.
>
 evaluate(RunBefores.java:26)

> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
>
> org.junit.runners.BlockJUnit4ClassRunner.runChild(
>
 BlockJUnit4ClassRunner.java:78)

> at
>
> org.junit.runners.BlockJUnit4ClassRunner.runChild(
>
 BlockJUnit4ClassRunner.java:57)

> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
>
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.
>
 

Re: AnalyzeSerializablesJUnitTestBase failure

[Kirk Lund]

But I didn't add or touch the class ClassName -- according to git log,
Jinmei and Patrick created it in the following commit on 1/29/18 -- I
haven't touched this at all on my branch:

GEODE-3915: use ClassName type for cache-loader, writer and listeners
(#1327)

* GEODE-3915: use ClassName type for cache-loader, writer and listeners

* use json string to specify the init properties
* make sure the parser works when multiple ClassNames are specified in the
command line.
* rework AlterRegionCommandDUnitTest
* make sure AnalyzeSerializableJunitTest works in IDEA.

Signed-off-by: Patrick Rhomberg 

On Thu, Oct 4, 2018 at 11:10 AM, Bruce Schuchardt 
wrote:

> It looks like your region attributes contain an instance of a class that
> isn't in sanctioned-geode-core-serializables.txt.  It's also possible
> that you added the class to that file but it didn't get properly copied to
> the output directory, so you might check that too.
>
> Output of this test should include a Fatal level log message that tells
> you what the rejected class was:
>
> Serialization filter is rejecting class ClassName
>
>
>
> On 10/3/18 1:10 PM, Kirk Lund wrote:
>
>> Sure is! https://github.com/kirklund/geode/tree/GEODE-2644-Appenders-
>> steps3
>>
>> My branch has no changes to org.apache.geode.cache.AttributesFactory or
>> its
>> inner class(es) though. I even double-checked with:
>>
>> $ git log
>> ./geode-core/src/main/java/org/apache/geode/cache/AttributesFactory.java
>>
>> It just shows a couple commits by Bruce which came to my branch via
>> develop.
>>
>> On Wed, Oct 3, 2018 at 10:38 AM, Nabarun Nag  wrote:
>>
>> I used to see this issue when I  make changes in the serializable class or
>>> its members but don't reflect it in the
>>> sanctioned-geode-core-serializables.txt file.
>>> If I am using a custom object in a test or something I add it
>>> as SERIALIZABLE_OBJECT_FILTER property.
>>>
>>> Is your branch hosted in github?
>>>
>>> Regards
>>> Nabarun
>>>
>>>
>>> On Wed, Oct 3, 2018 at 10:24 AM Kirk Lund  wrote:
>>>
>>> I have a failure on my branch that doesn't seem related to my changes.
 Anyone know what's causing this failure?

 Thanks!

 java.lang.AssertionError: I was unable to deserialize
 org.apache.geode.cache.AttributesFactory$RegionAttributesImpl
 at

 org.apache.geode.codeAnalysis.AnalyzeSerializablesJUnitTestBase.

>>> serializeAndDeserializeSanctionedObject(AnalyzeSerializablesJUnitTestB
>>> ase.java:401)
>>>
 at

 org.apache.geode.codeAnalysis.AnalyzeSerializablesJUnitTestBase.

>>> testSanctionedClassesExistAndDoDeserialize(AnalyzeSerializab
>>> lesJUnitTestB
>>> ase.java:318)
>>>
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at

 sun.reflect.NativeMethodAccessorImpl.invoke(

>>> NativeMethodAccessorImpl.java:62)
>>>
 at

 sun.reflect.DelegatingMethodAccessorImpl.invoke(

>>> DelegatingMethodAccessorImpl.java:43)
>>>
 at java.lang.reflect.Method.invoke(Method.java:498)
 at

 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(

>>> FrameworkMethod.java:50)
>>>
 at

 org.junit.internal.runners.model.ReflectiveCallable.run(

>>> ReflectiveCallable.java:12)
>>>
 at

 org.junit.runners.model.FrameworkMethod.invokeExplosively(

>>> FrameworkMethod.java:47)
>>>
 at

 org.junit.internal.runners.statements.InvokeMethod.

>>> evaluate(InvokeMethod.java:17)
>>>
 at

 org.junit.internal.runners.statements.RunBefores.

>>> evaluate(RunBefores.java:26)
>>>
 at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
 at org.junit.rules.RunRules.evaluate(RunRules.java:20)
 at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
 at

 org.junit.runners.BlockJUnit4ClassRunner.runChild(

>>> BlockJUnit4ClassRunner.java:78)
>>>
 at

 org.junit.runners.BlockJUnit4ClassRunner.runChild(

>>> BlockJUnit4ClassRunner.java:57)
>>>
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
 at

 org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.

>>> runTestClass(JUnitTestClassExecutor.java:106)
>>>
 at

 org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.

>>> execute(JUnitTestClassExecutor.java:58)
>>>
 at

 org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.

>>> execute(JUnitTestClassExecutor.java:38)
>>>
 at

 org.gradle.api.internal.tasks.testing.junit.

>>> AbstractJUnitTestClassProcessor.processTestClass(

[DISCUSS] Predictable minor release cadence

[Alexander Murmann]

Hi everyone,

I want to propose shipping Geode on a regular cadence. My concrete proposal
is to ship Geode every 3 months on the first weekday. To make sure we hit
that date we would cut the release 1 months prior to that day.

*Why?*
Knowing on what day the release will get cut and on what day we ship allows
community members to plan their contributions. If I want my feature to be
in the next release I know by when I need to have it merged to develop and
can plan accordingly. As a user who is waiting for a particular feature or
fix that's already on develop, I know when to expect the release that
includes this work and again, can plan accordingly.

This makes working and using Apache Geode more predictable which makes all
our lives less stressful. To make this work, it's important to be strict
about cutting the release branch on the set date and only allow critical
fixes after the release has been cut. Once we start compromising on this,
we go down a slippery slope that ultimately leads to not getting the
predictability benefits described here.

Some other successful Apache projects share similar approaches:

   - Kafka
   
   releases every 4 months and cuts the release 1 month prior
   - PredictionIO  releases
   every 2 months
   - Spark  does not seem
   to have a hard date, but aims to ship every 6 months, so there is at least
   a goal date


*What?*
As stated above, I suggest to release every three months. Given we just
shipped the next release would go out on January 2nd. That timing in
unfortunate, due to the holidays. Therefore I propose to aim for a December
3rd (1st Monday in December) release. In order to meet that date, we should
cut the release branch on November 1st. That also means that we should
start finding a volunteer to manager the release on October 25th. I know
this seems really close, given we just shipped, but keep in mind that this
is to avoid the holidays and that we already have close to a month worth of
work on develop.

*Proposed near future schedule:*
October 25th: Find release manager
November 1st: Cut 1.8 release branch
December 1st: Ship 1.8
January 28th: Find release manager
February 1st: Cut 1.9 release branch
March 1st: Ship 1.9
and so on...

Thanks for sharing your thoughts and feedback on this!

DSFIDNotFoundException: Unknown DataSerializableFixedID: 2145

[Kirk Lund]

Sai and I noticed that the Acceptance style dunit tests that are starting
up locators in vm0 are generating a bunch of log statements about "Unknown
DataSerializableFixedID: 2145" and this looks wrong in several ways. I
reviewed it with Darrel and neither of us are familiar with TcpServer or
with WANFactoryImpl which seems to be responsible for registering the
DSFIDs that causing these exceptions.

1) run StartLocatorCommandDUnit or similar test and you'll see these info
level log statements:

[vm0] [info 2018/10/04 11:34:21.463 PDT 
tid=0x33] Exception in processing request from 127.0.0.1
[vm0] org.apache.geode.internal.DSFIDNotFoundException: Unknown
DataSerializableFixedID: 2145
[vm0]   at
org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1007)
[vm0]   at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2761)
[vm0]   at
org.apache.geode.DataSerializer.readObject(DataSerializer.java:2977)
[vm0]   at
org.apache.geode.distributed.internal.tcpserver.TcpServer.processOneConnection(TcpServer.java:470)
[vm0]   at
org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:379)
[vm0]   at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[vm0]   at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[vm0]   at java.lang.Thread.run(Thread.java:748)

This is occurring in acceptance style tests -- ie, full end-to-end tests so
all of geode should be in the classpath -- nothing is missing including
wan. Or is geode-wan actually missing from the classpath?

Apparently this is the current normal for Geode -- you can expect to see
these messages being logged for some reason.

2) why is something that seems this bad being logged at info instead of
warn or error?

3) why is 2145 (DataSerializableFixedID.REMOTE_LOCATOR_JOIN_REQUEST) not
registered with DSFIDFactory?

Apparently it's registered in WANFactoryImpl:

  @Override
  public void initialize() {

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_JOIN_REQUEST,
RemoteLocatorJoinRequest.class);

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_JOIN_RESPONSE,
RemoteLocatorJoinResponse.class);

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_REQUEST,
RemoteLocatorRequest.class);
DSFIDFactory.registerDSFID(DataSerializableFixedID.LOCATOR_JOIN_MESSAGE,
LocatorJoinMessage.class);

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_PING_REQUEST,
RemoteLocatorPingRequest.class);

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_PING_RESPONSE,
RemoteLocatorPingResponse.class);

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_RESPONSE,
RemoteLocatorResponse.class);
  }

... but why aren't the WANFactoryImpl messages being registered?

4) why aren't these info-level log statements causing grep for suspect
strings to fail? StartLocatorCommandDUnit is a dunit so grep for suspect
strings should occur at the end of every test method.

5) why aren't any tests failing if things are this broken?

Re: AnalyzeSerializablesJUnitTestBase failure

[Bruce Schuchardt]

It looks like your region attributes contain an instance of a class that 
isn't in sanctioned-geode-core-serializables.txt.  It's also possible 
that you added the class to that file but it didn't get properly copied 
to the output directory, so you might check that too.


Output of this test should include a Fatal level log message that tells 
you what the rejected class was:


Serialization filter is rejecting class ClassName


On 10/3/18 1:10 PM, Kirk Lund wrote:

Sure is! https://github.com/kirklund/geode/tree/GEODE-2644-Appenders-steps3

My branch has no changes to org.apache.geode.cache.AttributesFactory or its
inner class(es) though. I even double-checked with:

$ git log
./geode-core/src/main/java/org/apache/geode/cache/AttributesFactory.java

It just shows a couple commits by Bruce which came to my branch via develop.

On Wed, Oct 3, 2018 at 10:38 AM, Nabarun Nag  wrote:


I used to see this issue when I  make changes in the serializable class or
its members but don't reflect it in the
sanctioned-geode-core-serializables.txt file.
If I am using a custom object in a test or something I add it
as SERIALIZABLE_OBJECT_FILTER property.

Is your branch hosted in github?

Regards
Nabarun


On Wed, Oct 3, 2018 at 10:24 AM Kirk Lund  wrote:


I have a failure on my branch that doesn't seem related to my changes.
Anyone know what's causing this failure?

Thanks!

java.lang.AssertionError: I was unable to deserialize
org.apache.geode.cache.AttributesFactory$RegionAttributesImpl
at

org.apache.geode.codeAnalysis.AnalyzeSerializablesJUnitTestBase.

serializeAndDeserializeSanctionedObject(AnalyzeSerializablesJUnitTestB
ase.java:401)

at

org.apache.geode.codeAnalysis.AnalyzeSerializablesJUnitTestBase.

testSanctionedClassesExistAndDoDeserialize(AnalyzeSerializablesJUnitTestB
ase.java:318)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

sun.reflect.NativeMethodAccessorImpl.invoke(

NativeMethodAccessorImpl.java:62)

at

sun.reflect.DelegatingMethodAccessorImpl.invoke(

DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)
at

org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(

FrameworkMethod.java:50)

at

org.junit.internal.runners.model.ReflectiveCallable.run(

ReflectiveCallable.java:12)

at

org.junit.runners.model.FrameworkMethod.invokeExplosively(

FrameworkMethod.java:47)

at

org.junit.internal.runners.statements.InvokeMethod.

evaluate(InvokeMethod.java:17)

at

org.junit.internal.runners.statements.RunBefores.

evaluate(RunBefores.java:26)

at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at

org.junit.runners.BlockJUnit4ClassRunner.runChild(

BlockJUnit4ClassRunner.java:78)

at

org.junit.runners.BlockJUnit4ClassRunner.runChild(

BlockJUnit4ClassRunner.java:57)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at

org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.

runTestClass(JUnitTestClassExecutor.java:106)

at

org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.

execute(JUnitTestClassExecutor.java:58)

at

org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.

execute(JUnitTestClassExecutor.java:38)

at

org.gradle.api.internal.tasks.testing.junit.

AbstractJUnitTestClassProcessor.processTestClass(
AbstractJUnitTestClassProcessor.java:66)

at

org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.

processTestClass(SuiteTestClassProcessor.java:51)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

sun.reflect.NativeMethodAccessorImpl.invoke(

NativeMethodAccessorImpl.java:62)

at

sun.reflect.DelegatingMethodAccessorImpl.invoke(

DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)
at

org.gradle.internal.dispatch.ReflectionDispatch.dispatch(

ReflectionDispatch.java:35)

at

org.gradle.internal.dispatch.ReflectionDispatch.dispatch(

ReflectionDispatch.java:24)

at

org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(

ContextClassLoaderDispatch.java:32)

at

org.gradle.internal.dispatch.ProxyDispatchAdapter$

DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)

at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at

org.gradle.api.internal.tasks.testing.worker.TestWorker.

processTestClass(TestWorker.java:117)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

sun.reflect.NativeMethodAccessorImpl.invoke(

NativeMethodAccessorImpl.java:62)

at

sun.reflect.DelegatingMethodAccessorImpl.invoke(

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1059 was SUCCESSFUL (with 2456 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #1059 was successful (rerun once).
---
This build was rerun by John Blum.
2458 tests in total.

https://build.spring.io/browse/SGF-NAG-1059/





--
This message is automatically generated by Atlassian Bamboo

[ANNOUNCE] Apache Geode 1.7.0

[Nabarun Nag]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.7.0.

Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high concurrency
processing.

Geode 1.7.0 contains a number of improvements and bug fixes. It includes
performance improvements in OQL order-by and distinct queries in
client/server when security is enabled. New GFSH commands were added to
get/set cluster config and to destroy gateway receivers. A new post
processor was added to the new client protocol. Pulse now supports legacy
SSL options. Auto-reconnecting members no more reuse old addresses and IDs.
Duplicated or member-specific receivers are removed from cluster config
during rolling upgrades. Users are encouraged to upgrade to the latest
release.

For the full list of changes please review the release notes:
https://cwiki.apache.org/confluence/display/GEODE/
Release+Notes#ReleaseNotes-1.7.0

The release artifacts can be downloaded from the project website:
http://geode.apache.org/releases/

The release documentation is available at:
http://geode.apache.org/docs/guide/17/about_geode.html

We would like to thank all the contributors that made the release possible.

Regards,
Nabarun Nag on behalf of the Apache Geode team