> If I understand the patch correctly, it is not re-opening the old security > problem
Correct. My only issue is the loss of the reconfig() methods that have been in ZooKeeper.java for over 2 years. > The bit I'm not so sure is why Curator can't adapt to the change, which is > what I'd expect given that 3.5 is alpha. ZooKeeper.java is part of Curator’s public API. There are additional issues. Curator has a refactor() API itself. To be ideally compatible with ZooKeeperAdmin Curator would add something similar which would, of course, break our current public API. There are similar things throughout the code. > given that 3.5 is alpha I respectfully disagree :D 3.5 and variants have been in Maven Central for over 2 years. A large of number of companies have deployed 3.5 in production. The horse has left the barn on this one. -Jordan > On Dec 11, 2016, at 11:45 AM, Flavio Junqueira <[email protected]> wrote: > > It is not the inclusion of ZK-2014 that is being questioned, it is the fact > that we made API changes without deprecating methods and making the changes > compatible. I don't mind making the changes Jordan is suggesting as it is > pretty much just bringing back the old calls and marking them as deprecated. > If I understand the patch correctly, it is not re-opening the old security > problem, but I'd need to do a more thorough review to be sure, I really just > skimmed through the patch. > > If it is just a matter of marking old API calls as deprecated without > compromising security, then I don't see it being a big problem. The bit I'm > not so sure is why Curator can't adapt to the change, which is what I'd > expect given that 3.5 is alpha. > > -Flavio > >> On 08 Dec 2016, at 16:19, Patrick Hunt <[email protected]> wrote: >> >> The inclusion of ZOOKEEPER-2014 has been raised as a problem by Jordan (see >> the separate thread on this list). I don't feel I can cut a 3.5.3-alpha >> release until the issue has been resolved by the community. I was hoping to >> get a release candidate created before vacation starts, so please comment >> on that thread asap so that we can progress. >> >> Patrick >> >> On Thu, Nov 24, 2016 at 8:53 AM, Flavio Junqueira <[email protected]> wrote: >> >>> We need to regenerate the documentation to include recent changes. I have >>> created ZK-2635 and assigned to myself. It should be simple enough, though. >>> I've marked the fix version to include 3.5.3 and 3.6.0, but I'm not sure if >>> anything has been merged recently into the 3.4 branch that had >>> documentation changes. If anyone is aware of such a change, please change >>> the jira accordingly. >>> >>> This is not necessarily a blocker, but there is one issue that we need to >>> resolve with our current workflow. Previously, we submitted patches by >>> uploading the patch and hitting the "Submit Patch" button. Submitting the >>> patch triggers the QA build, which executes the test script, which goes to >>> jira and fetches the patch to test. With pull requests, the process is >>> different. The github plugin triggers the build, which fetches the diff >>> from the PR and runs the test script. >>> >>> Ideally, if it is a pull request, we change the status of the jira to >>> "Patch Available", but we do not trigger the QA for jira patches. I don't >>> know how to do it, though, so the choices we have are: >>> >>> 1- To only change the status to "Patch Available" if there is a jira >>> patch, which is not ideal. >>> 2- To disable the jira patch QA and rely only on pull requests. >>> >>> Unless someone comes up with a solution that enables us to change the >>> status of the jira to path available and only triggers QA in the case there >>> is a jira patch, I believe the best option is number 2 and the [DISCUSS] >>> thread I started about this seems to indicate that others prefer that >>> option too. If folks feel it is necessary to vote to capture more precisely >>> the decision, I can start a vote thread on the dev list. >>> >>> -Flavio >>> >>> >>>> On 23 Nov 2016, at 17:39, Patrick Hunt <[email protected]> wrote: >>>> >>>> Forgot to mention. These will be our first releases using git rather than >>>> svn. Does anyone know of remaining issues we need to resolve related to >>>> this prior to cutting a release? >>>> >>>> Patrick >>>> >>>> On Wed, Nov 23, 2016 at 9:38 AM, Patrick Hunt <[email protected]> wrote: >>>> >>>>> Hi folks. Now that ZOOKEEPER-2014 has been committed I think we should >>> cut >>>>> a 3.5.3-alpha release. We're getting close to beta with that one >>> finalized. >>>>> There are about 10 blockers, although I have not recently gone through >>> and >>>>> triaged them >>>>> https://issues.apache.org/jira/secure/Dashboard.jspa? >>> selectPageId=12327688 >>>>> note that about half of those are patch available, if you have some free >>>>> cycles please focus on these, here's the prioritized list: >>>>> https://issues.apache.org/jira/issues/?filter=12336872&; >>>>> jql=project%20%3D%20zookeeper%20AND%20fixVersion%20%3D%203. >>>>> 5.3%20and%20resolution%20%3D%20unresolved%20ORDER%20BY% >>> 20priority%20DESC >>>>> >>>>> I believe Rakesh (please confirm) is interested in releasing 3.4.10 once >>>>> ZOOKEEPER-1045 is committed. That patch has had extensive testing and >>>>> documentation (kudos Rakesh, et. al.) and is in final review -- unless >>>>> someone speaks up it will be committed soon, probably next week. Here's >>> the >>>>> prioritized list, not sure of those blockers really are blockers - >>> Flavio >>>>> do we still need to address the netty license issue: >>>>> https://issues.apache.org/jira/issues/?filter=12338391&; >>>>> jql=project%20%3D%20zookeeper%20AND%20fixVersion%20%3D%203. >>>>> 4.10%20and%20resolution%20%3D%20unresolved%20ORDER%20BY% >>> 20priority%20DESC >>>>> >>>>> Patrick >>>>> >>>>> >>> >>> >
