Re: Upcoming 3.4/3.5 releases.

[Patrick Hunt <ph...@apache.org>]

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 <fp...@apache.org> 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 <ph...@apache.org> 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 <ph...@apache.org> 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
> >>
> >>
>
>

Re: Upcoming 3.4/3.5 releases.

[Flavio Junqueira <fp...@apache.org>]

I personally don't mind supporting changes that satisfy the requirements of the broad community, even if they deviate from the original plan. Changes to ZooKeeper clearly affect Curator users, so we should care and I believe we do.

I can't agree with the argument that because the feature has taken long to stabilize, folks are free to ignore the recommendation of the community. The recommendation was to treat the reconfiguration feature as experimental because there could be changes to the API. My expectation was that anyone using it would either keep in mind that such changes could come or bring any concern to the community. If we were not handling the stabilization of the 3.5 branch in a way that satisfied users, the discussion should have been brought to the list, possibly accompanied of a recommendation if not a plan of execution.

To insist on my position, I'm fine with the suggestion of deprecating the old calls rather than remove them. If it doesn't break anything and users are happier this way, then why not? I'm not fine with the argument that we have to take it because the community has taken long to complete it, though.

-Flavio

> On 11 Dec 2016, at 16:52, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
> 
>> 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 <fp...@apache.org> 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 <ph...@apache.org> 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 <fp...@apache.org> 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 <ph...@apache.org> 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 <ph...@apache.org> 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
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
> 

Re: Upcoming 3.4/3.5 releases.

[Jordan Zimmerman <jo...@jordanzimmerman.com>]

> 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 <fp...@apache.org> 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 <ph...@apache.org> 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 <fp...@apache.org> 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 <ph...@apache.org> 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 <ph...@apache.org> 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
>>>>> 
>>>>> 
>>> 
>>> 
> 

Re: Upcoming 3.4/3.5 releases.

[Flavio Junqueira <fp...@apache.org>]

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 <ph...@apache.org> 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 <fp...@apache.org> 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 <ph...@apache.org> 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 <ph...@apache.org> 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
>>>> 
>>>> 
>> 
>>