Re: Re: Re: Time to think about a 3.6.0 release?
- 1. @Andor Thanks for reformatting my email. I must be careful next time. - 2. I absolutely agree with what Olivelli said. --> “I guess that if we start now we can have a 3.6 in September”. maybe not need so fast. But having a planning, especially about what features will be included, what approximate time(A time range) will cut 3.6.0 is a good idea drawing from the previous lessons- 3. I have a question: "After 3.6.0 has landed, the 3.5.* will not be applied any new feature and only fix the bugs and prominent improvements" Is it right? - Original Message - From: Enrico Olivelli To: DevZooKeeper , maoling199210...@sina.com Subject: Re: Re: Time to think about a 3.6.0 release? Date: 2019-07-15 21:55 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 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 > 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 th
Re: Time to think about a 3.6.0 release?
> 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 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 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 >> To: dev@zookeeper.apache.org >>
Re: Time to think about a 3.6.0 release?
A related question: Are we going to deprecate/EOL the 3.4 branch after 3.6.0 stable is released? On Mon, Jul 15, 2019 at 2:23 PM Andor Molnar wrote: > Hi maoling, > > I reformatted your original message, because it was pretty hard to read > (all in a single line) after Apache converted into plain text. Would you > please try to send plain text messages by default to avoid the conversion? > It might help. > > Answers inline. > > > > On 2019. Jul 15., at 11:54, Justin Ling Mao > wrote: > > > > - 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:) > > > I don’t feel it too fast. I’m happy to see people willing to work on > releases and I believe it’s a good thing to speed up ZooKeeper releases. 4 > years release cycle is not something that we should follow in the future. > > The discussion about the next major release is just started and doesn’t > mean we have to cut tomorrow. Talk about it. Your list of upcoming patches > are more than welcome, we need to discuss where to fit them. > > Friends@Facebook are also working hard to get patches into 3.6.0. We need > to synchronize with all contributors. > > > > - 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. > > Sure. Awesome list. > > > > > --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. > > I think this should go into 4.0.0 instead if it’s only is design phase > currently. This is probably true for the rest of patches too: everything > which already has a PR or close to it can fit into 3.6.0, others should go > to 4.0.0. > > > > > > > - 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. > > > > Thanks, > Andor > > > > > > > > - Original Message - > > From: Fangmin Lv > > 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 wrote: > >> Good idea. Agree on including anything we've postponed to a new cycle - > the > >> patch from mapr is an obvious one to consider. > >
Re: Time to think about a 3.6.0 release?
Hi maoling, I reformatted your original message, because it was pretty hard to read (all in a single line) after Apache converted into plain text. Would you please try to send plain text messages by default to avoid the conversion? It might help. Answers inline. > On 2019. Jul 15., at 11:54, Justin Ling Mao wrote: > > - 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:) I don’t feel it too fast. I’m happy to see people willing to work on releases and I believe it’s a good thing to speed up ZooKeeper releases. 4 years release cycle is not something that we should follow in the future. The discussion about the next major release is just started and doesn’t mean we have to cut tomorrow. Talk about it. Your list of upcoming patches are more than welcome, we need to discuss where to fit them. Friends@Facebook are also working hard to get patches into 3.6.0. We need to synchronize with all contributors. > - 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. Sure. Awesome list. > --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. I think this should go into 4.0.0 instead if it’s only is design phase currently. This is probably true for the rest of patches too: everything which already has a PR or close to it can fit into 3.6.0, others should go to 4.0.0. > - 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. > Thanks, Andor > > > - Original Message - > From: Fangmin Lv > 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 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 >&
Re: Re: Time to think about a 3.6.0 release?
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 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 > 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 wrote: > > Good idea. Agree on including anything we've postponed to a new cycle
Re: Re: Time to think about a 3.6.0 release?
- 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 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 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 > > > 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 > > > >
Re: Time to think about a 3.6.0 release?
Il mer 26 giu 2019, 11:20 Norbert Kalmar ha scritto: > Sorry, correction, I just followed up on ZOOKEEPER-2136, patch is not > ready, and maybe not even a blocker for 3.6.0? > I would drop 3.6.0 label from ZOOKEEPER-2136, I have already commented (with Patrick) on that issue about setting priority to "Major" (I have changed it now please Norbert add your comment on the issue as well). Beside note: I will be happy to follow the release as release manager if no one else objects. I would like to see all of those hot pull requests merged (expecially the ones around port unification, batch commits), ant build dropped definitely and zkpython stuff fixed. Regarding the proposal to turn on new features by default I think that ZK 3.5.5 was released only some weeks ago and as 3.5.4 was labelled "beta" people are still on 3.4 branch. So I think it is safer to keep current default similar to the ones in 3.5.5. If we release 3.6.0 as stable it is probable that people with just directly to 3.6.0. But if you are aware of features that it is really better to turn on by default let's do it. Enrico > On Wed, Jun 26, 2019 at 11:16 AM Norbert Kalmar > wrote: > > > Hi Fangmin, > > > > I checked all 3 PRs, looks like they pretty much reviewed, some minor > > questions remain. > > But we have 302 tickets open where fixVersion is 3.6.0, good news is only > > 1 blocker (ZOOKEEPER-2136), which already has a patch. I'll see that this > > blocker gets committed. > > There is also 9 critical for 3.6.0. > > > > Regards, > > Norbert > > > > > > > > On Wed, Jun 26, 2019 at 1:27 AM Fangmin Lv wrote: > > > >> 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 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 > >> >> > > > >> > > 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
Re: Time to think about a 3.6.0 release?
Sorry, correction, I just followed up on ZOOKEEPER-2136, patch is not ready, and maybe not even a blocker for 3.6.0? On Wed, Jun 26, 2019 at 11:16 AM Norbert Kalmar wrote: > Hi Fangmin, > > I checked all 3 PRs, looks like they pretty much reviewed, some minor > questions remain. > But we have 302 tickets open where fixVersion is 3.6.0, good news is only > 1 blocker (ZOOKEEPER-2136), which already has a patch. I'll see that this > blocker gets committed. > There is also 9 critical for 3.6.0. > > Regards, > Norbert > > > > On Wed, Jun 26, 2019 at 1:27 AM Fangmin Lv wrote: > >> 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 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 >> > > > >> > > 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 >> > > >> >> > > >> > >> >
Re: Time to think about a 3.6.0 release?
Hi Fangmin, I checked all 3 PRs, looks like they pretty much reviewed, some minor questions remain. But we have 302 tickets open where fixVersion is 3.6.0, good news is only 1 blocker (ZOOKEEPER-2136), which already has a patch. I'll see that this blocker gets committed. There is also 9 critical for 3.6.0. Regards, Norbert On Wed, Jun 26, 2019 at 1:27 AM Fangmin Lv wrote: > 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 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 > > > > > > 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 > > > >> > > > > > >
Re: Time to think about a 3.6.0 release?
Thanks Fangmin for pointing out these issues. I’ll take a look at them once I have some free cycles - currently on holiday. :) We should consider compiling a list of 3.6 blockers in Jira similar what we had for 3.5. Andor > On 2019. Jun 26., at 1:26, Fangmin Lv wrote: > > 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 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 >> >>> 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 >>> 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 > >>> >>
Re: Time to think about a 3.6.0 release?
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 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 > > > 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 > > 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 > > >> > > >
Re: Time to think about a 3.6.0 release?
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 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 > 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 > 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 > >> >
Re: Time to think about a 3.6.0 release?
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 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 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 >>
Re: Time to think about a 3.6.0 release?
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 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 >
