zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andor Molnar <an...@apache.org>
Subject Re: Time to think about a 3.6.0 release?
Date Tue, 16 Jul 2019 08:56:55 GMT
> So my plan would be:
> - merge pending pull requests that are ready
> - stabilize the codebase  (no more BLOCKER issues for the release)
> - start release process

Sounds like a good plan. +1

Quick Jira stats: (3.6.0 only tickets)

- 77 Improvement
- 14 New Feature (Followers host observers, new metrics system, Prometheus.io integration,
log-size based snapshots, new docs,
- 23 Bugfix
- 6 Task

I wouldn’t say we should not commit more stuff, but sounds like a good time to start stabilization.

Andor




> On 2019. Jul 15., at 14:08, Enrico Olivelli <eolivelli@gmail.com> wrote:
> 
> Justin,
> I think that current master has already plenty of new features and it is
> worth to start thinking to a release.
> The more with add code the more we add risk.
> 
> The point of this thread is more about 'stop adding new stuff, complete
> ongoing work and start a rampdown phase', it is not "cut a release right
> now"
> 
> As far as I know current master is very different from branch 3.5,
> expecially on server side code, lots of feature came in and stalled on
> master branch for months or even years,
> so feedback from 3.5 is useful but not so blocker
> 
> We should make current master stable
> 
> IMHO the recipe for a great release is:
> 1) enough stuff committed to the release branch sothat it is worth to cut a
> release
> 2) code in good shape: tests are passing, automatic checks are passing
> (spotbugs, rat...)
> 3) licensing stuff is okay
> 4)  upgrade instructions and changelog about breaking changes/new
> beheaviours are complete
> 5) CI is doing well
> 6) consensus of the community about the release
> 
> 
> Hopefully now that we got out of the 3.5-BETA  problem and we are stable we
> can think about a time based release schedule, if a feature can't be
> delivered on a release it won't pass so much time for a new release, say
> 3-4 months
> 
> I don't know how many companies are using "current master" (or something
> like that) in production, I feel that running 3.5 does not tell very much
> about the stability of current 3.6
> 
> So my plan would be:
> - merge pending pull requests that are ready
> - stabilize the codebase  (no more BLOCKER issues for the release)
> - start release process
> 
> I guess that if we start now we can have a 3.6 in September
> 
> Enrico
> 
> 
> 
> 
> Il lun 15 lug 2019, 11:55 Justin Ling Mao <maoling199210191@sina.com> ha
> scritto:
> 
>> - 1.Since the 3.5.5 has just released in May. we still need some time to
>> collect the users' feedback.we cannot make sure the release time of 3.6.0?
>> Giving the experience from the previous release history:)- 2.please Let me
>> share some my thoughts, and the work in progress will be arriving into
>> 3.6.0. Plz correct me if I got something wrong.
>> ------------------------------------------P0----------------------------------------------------------------
>>   - Support the backend store engine:LMDB. this work needs a very detailed
>> proposal which I will send to the community for being discussed fully.
>> - Add a complete backup mechanism for zookeeper internal(PR-917) which I
>> will sharp it this week.     - A very powerful benchmark tool(PR-1011)
>> which will be available within these two week.     - improve the
>> performance of read/write to have the distinct advantages compared to etcd
>> v3.4 which will be released soon.     - To strengthen the quota
>> feature(PR-934,PR-936,PR-938) and implement the throughout quota.     - To
>> strengthen the implements of TTL node(PR-1010)     - Add some new very
>> useful CLIs: quorumInfo, watch .etc     - Observe and strengthen the new
>> metric system continuously.
>> ------------------------------------------P1----------------------------------------------------------------
>>   - strength the docs, especially about the c client, local session,
>> security(TLS),ZAB protocol .etc     - introduce some chaos, fuzzy tests and
>> tools to hit and check the zk.     - Clean up the all the checkstyle
>> violations in the zookeeper-server module(ZOOKEEPER-3431)
>> -----------------------------------------
>> P2------------------------------------------------------------------     -
>> Debug mode feature. Look at an example of redis     - the tracing
>> feature(PR-994). if having another time, integrating with opentracing
>> sounds a very good idea.     - replace jute with thrift or PB may be put
>> into the 4.0.0 when wanting to break the backward compatibility? And at the
>> 4.0.0, implementing the restful api is also a  very good idea.
>> 
>> 
>> 
>> ----- Original Message -----
>> From: Fangmin Lv <lvfangmin@gmail.com>
>> To: dev@zookeeper.apache.org
>> Subject: Re: Time to think about a 3.6.0 release?
>> Date: 2019-06-26 07:33
>> 
>> It's great to have a 3.6.0 release, currently all the FB contributed
>> features has been running inside FB for more than a month, so it
>> should be stable enough for community to use.
>> Also I agreed with Patrick's point to review all flags and consider to turn
>> on by default.
>> For the pending PRs, the following might be higher priority and would be
>> nice to include in the 3.6.0 release:
>> * ZOOKEEPER-3356: Implement advanced Netty flow control based on feedback
>> from ZK to avoid OOM issue
>> * ZOOKEEPER-3145: Avoid watch missing issue due to stale pzxid when
>> replaying CloseSession txn with fuzzy snapshot
>> * ZOOKEEPER-3240: Close socket on Learner shutdown to avoid dangling socket
>> Thanks,
>> Fangmin
>> On Sat, Jun 15, 2019 at 9:21 AM Patrick Hunt <phunt@apache.org> wrote:
>>> Good idea. Agree on including anything we've postponed to a new cycle -
>> the
>>> patch from mapr is an obvious one to consider.
>>> 
>>> We should also look at things we've disabled by default and consider
>>> whether we can turn them on by default. If not why not, and what can we
>> do
>>> to fix this in a subsequent release.
>>> 
>>> Have we deprecated anything that we should now remove?
>>> 
>>> Also a good time to review the state of Java versions and make changes
>> wrt
>>> supported versions and so forth.
>>> 
>>> There was a proposal to remove contribs, or at least consider the ones
>> that
>>> are still valuable vs moving some out. We should do that as well.
>>> 
>>> Regards,
>>> 
>>> Patrick
>>> 
>>> On Sat, Jun 15, 2019 at 9:02 AM Jordan Zimmerman <
>>> jordan@jordanzimmerman.com>
>>> wrote:
>>> 
>>>> On Persistent/Recursive watches: I’m willing to rebase, etc if there’s
>>>> confidence it will be merged.
>>>> 
>>>> ====================
>>>> Jordan Zimmerman
>>>> 
>>>>> On Jun 15, 2019, at 10:59 AM, Andor Molnar
>> <andor@cloudera.com.invalid
>>>> 
>>>> wrote:
>>>>> 
>>>>> Hi Enrico!
>>>>> 
>>>>> Very good point, I entirely support the idea.
>>>>> 
>>>>> Question to Friends@Facebook and Twitter contributors: how many
>>>> outstanding
>>>>> Jiras/PRs do you have which you would like to see in 3.6?
>>>>> 
>>>>> I'd also like to highlight the long outstanding PR from Mapr:
>>>>> https://github.com/apache/zookeeper/pull/730
>>>>> 
>>>>> And some great new features which are still looking for to be merged:
>>>>> - Persistent recursive watchers:
>>>>> https://github.com/apache/zookeeper/pull/136
>>>>> - Enforce client auth: https://github.com/apache/zookeeper/pull/118
>>>>> - Slow operation log
>>>>> - Jetty port unification
>>>>> 
>>>>> Regards,
>>>>> Andor
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Sat, Jun 15, 2019 at 1:31 PM Enrico Olivelli <
>> eolivelli@gmail.com>
>>>> wrote:
>>>>>> 
>>>>>> Hi Zookeepers !
>>>>>> I checked on JIRA and it seems that master in good shape, no real
>>>> blockers
>>>>>> that mine the stability of the code.
>>>>>> 
>>>>>> We have plenty of cool pull requests almost ready to be merged
>> (mostly
>>>> from
>>>>>> Facebook friends and Twitter fork)
>>>>>> 
>>>>>> Current master branch is full of great features in respect to 3.5.
>>>>>> 
>>>>>> AFAIK There is no incompatibility with 3.5 so it is okay to stay
>> with
>>>>>> 3.6.0, although I think that there is so much stuff to legit a
>> switch
>>> to
>>>>>> 4.0.0 (but we can reserve such bump for the time we will separate
>> the
>>>> java
>>>>>> client and create a minimal compatibility breakage)
>>>>>> 
>>>>>> Thoughts?
>>>>>> 
>>>>>> Enrico
>>>>>> 
>>>> 
>>> 
>> 


Mime
View raw message