> 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 <eolive...@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 <maoling199210...@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 <lvfang...@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 <ph...@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 < >>> jor...@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 >> <an...@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 < >> eolive...@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 >>>>>> >>>> >>> >>
