+1
On 8/6/19 1:33 PM, Nabarun Nag wrote:
+1 on getting the Fix [Upgrade
log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
in the geode-core pom.] in.
Spring Data for Apache Geode has been removed from Spring Initializr
because of the issue with log4j dependencies, also IntelliJ doesn't list
it as a NoSQL dependency. I would prefer that it is resolved in this
release and not wait for 3-4 months.
Regards
Naba
On Tue, Aug 6, 2019 at 1:00 PM Owen Nichols <onich...@pivotal.io> wrote:
Hi Kirk, thank you for bringing your concern.
Yes, release/1.10.0 was created last week <
https://lists.apache.org/thread.html/4d4388ccab1170d94b8b6d204efe9197a4d3ddc2d25cbb6e6cecee0d@%3Cdev.geode.apache.org%3E>
as planned. Our current process <
https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E>
dictates a time-based schedule to cut release branches. Once cut, the
“critical fixes” rule allows critical fixes to be brought to the release
branch by proposal on the dev list.
Currently the 1.10.0 release pipeline <
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main>
is all green. If there is consensus from the Geode community that this
log4j change satisfies the “critical fixes” rule, Dick or I will be happy
to bring it to the 1.10.0 release branch.
-Owen
On Aug 6, 2019, at 12:49 PM, Kirk Lund <kl...@apache.org> wrote:
Did we already cut the 1.10 branch?
I'd like to find out if it's possible to get a change into 1.10: Upgrade
log4j from 2.11.1 to 2.12.0 and mark log4j-core as an optional dependency
in the geode-core pom.
Getting this change into 1.10 will make things much easier for Spring
Boot
Data Geode. When using Geode with Spring Boot, log4j-core has to be
manually excluded so that logback can be used instead. The change to
log4j
2.12.0 will also help as they have already have some dependency on 2.12.0
(probably log4j-to-slf4j). I can find out more precise details if needed.
On Wed, Jul 31, 2019 at 9:35 AM Dick Cavender <di...@apache.org> wrote:
In preparation for cutting the release branch have we confirmed that
Geode's LICENSE and NOTICE file been confirmed to accurately reflect
what
is being shipped for v1.10?
From Apache: http://www.apache.org/dev/licensing-howto.html
*"*The LICENSE and NOTICE files must exactly represent the contents of
the
distribution they reside in."
Ideally this is kept up to date during development as the dependencies
change or are added but this often is missed and needs to be reconciled
on
develop before we cut a release branch.
-Dick
On Tue, Jul 30, 2019 at 6:04 PM Owen Nichols <onich...@pivotal.io>
wrote:
From that email:
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.
We are perilously close to the "slippery slope”:
* Geode 1.8.0 was announced on Dec 12 — almost 8 months ago
* Geode 1.9.0 was announced on Apr 25 — putting us about 5 weeks late
already on cutting the 1.10 branch
It seems like the community reaction to branching from the SHA
initially
proposed is “woah, not quite yet”.
To get last-minute stuff in (or out) and get back on track, I propose
setting a strict CUT date for the 1.10 branch at 3PM PDT Thursday
August
1.
-Owen
On Jul 30, 2019, at 5:31 PM, Alexander Murmann <amurm...@apache.org>
wrote:
Hi Karen,
Here is the previous discussion that was very positively received:
https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
However, JIRA tells me that GEODE-7013 is already fixed. If we were to
go
with a SHA from this week, for which Jake also chimed in with plenty
of
reasons, this should be in the release.
On Tue, Jul 30, 2019 at 5:10 PM Karen Miller <kmil...@pivotal.io>
wrote:
Alexander, can you point me at the policy decision for the "critical
issue"
rule you mention? I always though it was up
to the release manager.
I want GEODE-7013 fixes in because it is the right thing to do. Our
gfsh
help/hint wasn't working the way we say that it did.
With the fix, it does. I want either the documentation to match the
code,
or I want the code to match the documentation.
The fix in GEODE-7013 changes the code to match the existing
documentation,
so we don't have to change the documentation
(which would have needed to be cherry-picked into our 1.10 release
branch).
On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols <onich...@pivotal.io>
wrote:
Our "critical issue” rule has the effect that the bar to commit to
develop
is “low”, but the bar to cherry-pick to support branch is “very
high”.
Contributors could plan around this disparity more easily if any of
the
following were true:
- releases were more frequent
- planned cut date of release branch was announced in advance
(rather
than
retroactively)
- a process existed for making exceptions to the “critical issue”
rule
I agree that the proposed SHA looks like a relatively stable
branchpoint
(coming near the end of a nice period of solid green in the
pipeline),
and
I acknowledge that fair warning was given a week ago that a branch
was
“coming soon”, but I wonder if there is anything we can do to make
the
rules for what gets in a release and what doesn’t feel a little less
arbitrary?
-Owen
On Jul 30, 2019, at 11:16 AM, Alexander Murmann <
amurm...@apache.org>
wrote:
Dick, thank you for stepping up!
I think it's great to cut the branch sooner rather than later.
There
already is GEODE-7012 which introduces a distributed deadlock
during
startup. That seems like a critical issue to fix. That should be
able
to
happen after we cut the branch though.
Karen, I wonder if that could be merged after the branch got cut,
but
also
wonder if that fits our "critical issue" rule for being merged
after
the
branch has been cut or hold up the release. This has been broken
since
a
very long time. Thoughts?
On Tue, Jul 30, 2019 at 10:51 AM Karen Miller <kmil...@pivotal.io>
wrote:
I'd like to see the changes from
https://issues.apache.org/jira/browse/GEODE-7013 included in the
Geode
1.10
release. GEODE-7013's changes restore gfsh help/hint behavior that
was
lost
during a refactor in the earliest
releases of Geode. The commit occurred after SHA1
dc6890107a2651d8ba1450e8db8a1c39d712fdc7.
Thanks. Karen
On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender <di...@apache.org>
wrote:
I'll take on the Release Manager role for Geode 1.10 with the
1.9.0
release
manager's help (Owen:).
I'd like to propose cutting the release/1.10 branch off develop
sha:
dc6890107a2651d8ba1450e8db8a1c39d712fdc7
aka: 1.10.0-SNAPSHOT.476
Please speak up and discuss. We'll then start taking
considerations
for
additional changes for 1.1.0 after we get the branch and pipeline
in
place.
-Dick
On Mon, Jul 29, 2019 at 4:08 PM Alexander Murmann <
amurm...@apache.org
wrote:
Thanks for calling this out Ernie!
It might be a good idea to cut the release and at the same time
keep
looking for urgent issues that need to be resolved and merged.
Once
the
branch is cut, we release likelihood of new issues being
introduced.
Does anyone know of any other issues, we'd want to make sure get
addressed
before we ship?
On Mon, Jul 29, 2019 at 3:36 PM Ernest Burghardt <
eburgha...@pivotal.io>
wrote:
There is a PR #3844 <https://github.com/apache/geode/pull/3844
up
to
address GEODE-7012 <
https://issues.apache.org/jira/browse/GEODE-7012
I
think this should be in the next release...
EB
On Fri, Jul 26, 2019 at 4:07 PM Alexander Murmann <
amurm...@apache.org
wrote:
*Cutting the release*
Do we have any volunteers to take over the release manager
role?
*Re: Udo's concerns*
While I believe that iterations of this particular work have
been
discussed
on the mailing list as far back as March 2018, I do think that
we
should
take Udo's response as an indicator that something with our
larger
proposal
process needs to be improved. We used to have synchronous
Geode
club
house
sessions. For future discussions and for proposals in
particular,
I
think
it would be great to supplement our asynchronous mailing list
communication
with a synchronous video chat discussions by the community.
On Fri, Jul 26, 2019 at 4:02 PM Dan Smith <dsm...@pivotal.io>
wrote:
+1 for cutting a 1.10.0 release branch.
On Fri, Jul 26, 2019 at 3:55 PM Nabarun Nag <n...@apache.org
wrote:
Hi,
I believe the original authors of the feature has done their
due
diligence
and followed all steps, we can get this feature in under the
Experimental
flag and let the community improve on it, if there is
anything
else
that
needs to be done.
We have done this before for Lucene re-index feature, where
we
involved
the
entire community in its development, phase by phase. The
wiki
is
up
and
running, if someone has any concerns can raise it as a JIRA
or
comment
in
the wiki and the community as a whole can decide if it is a
valid
concern or not and act upon it.
Regards
Nabarun Nag
On Fri, Jul 26, 2019 at 3:40 PM Udo Kohlmeyer <
u...@apache.com>
wrote:
@Alexander + @Jared,
So maybe that was my misunderstanding on the RFC (not being
optional
on
new feature work). Given that this is a new feature, there
is
significant risk to getting it "wrong".
I was expecting more discussion around this. I have some
objections
to
the current approach/design. Given that my day job does not
allow
me
to
respond in a timely manner, I would have not been able to
get
all
my
concerns raised. In addition, throwing something onto the
wiki,
and
then
a few weeks before we'd like to cut a version raising a
discussion
thread on work that has been going on for months already
does
not
help
with the community being able to read, digest, think,
reason
and
respond
BEFORE it is released.
I know `@Experimental` is non-binding on API's or usage,
BUT
I
prefer
some of the ground work to have been discussed, API's
validated
BEFORE
it is released into the wild. I mean this is a PUBLIC API,
so
we'd
prefer to get it more correct than the previous one.
Maybe it is just me, taking it too serious... Where I
prefer
not
release
something as close to 95% correct (and discussed).
Anyway.. If we want to cut 1.10... and we should... Let's
do
so..
but
I'd prefer that more on the correctness on the approach.
--Udo
On 7/25/19 11:08 AM, Alexander Murmann wrote:
I don't believe we should be including anything into the
Geode
release
that has not gone through the correct process of feature
proposal.
All work under the experimental cluster management
service
has
not
yet
been approved by the agreed upon RFC process.
Udo, I didn't take the RFC process that we agreed on to be
a
gate
keeper,
but rather a way to de-risk work before making a PR.
From the RFC doc in the wiki:
When to write an RFC?
Writing an RFC should be entirely voluntary. There is
always
the
option
of
going straight to a pull request. However, for larger
changes,
it
might
be
wise to de-risk the risk of rejection of the pull request
by
first
gathering input from the community. Therefore it’s up to
every
member
of
our community to decide themselves when they want to
reach
for
this
tool.
If we want to change the role of the RFC process, that's
fine
with
me,
but
we should have that discussion first.
On Tue, Jul 23, 2019 at 10:30 AM Jared Stewart <
stewart.ja...@gmail.com>
wrote:
What was missing from the RFC process for the cluster
management
service?
I saw a [Discuss] thread for it, as well as a proposal at
https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
On Tue, Jul 23, 2019 at 10:02 AM Udo Kohlmeyer <
u...@apache.com>
wrote:
I don't believe we should be including anything into the
Geode
release
that has not gone through the correct process of feature
proposal.
All work under the experimental cluster management
service
has
not
yet
been approved by the agreed upon RFC process.
I don't believe we should be including this work,
experimental
or
otherwise.
--Udo
On 7/22/19 4:51 PM, Alexander Murmann wrote:
Udo, do you mind explaining how the RFC process comes
into
this?
Are
you
suggesting that we should wait if an RFC had a target
release
attached?
On Mon, Jul 22, 2019 at 4:47 PM Udo Kohlmeyer <
u...@apache.com
wrote:
I don't think we need to wait for this, as there has
been
no
RFC
process
followed.
--Udo
On 7/22/19 3:38 PM, Jinmei Liao wrote:
Work is still being planned to move the cluster
management
rest
service
under an experimental version flag and use a geode
property
to
turn
it
on/off. I would say we are ready to cut the geode
1.10.0
after
that
work
is
complete.
On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann <
amurm...@apache.org
wrote:
Hi everyone!
We released Geode 1.9.0 on April 25th. That's about
3
months
ago.
End
of
last year we discussed releasing quarterly. In the
past
we've
had
about
a
month between cutting a release branch and actually
shipping
our
new
minor.
This means we are already behind our target release
cadence.
What are your thoughts on cutting a 1.10.0 release
branch
this
week?
Would anyone like to volunteer to be the release
manager
for
geode
1.10.0?
Thank you all!
