@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!
