Re: ZooKeeper 3.6.2 release procedure finished - time to drop 3.4 from dist ?

2020-09-28 Thread Enrico Olivelli
This is the PR for the website
https://github.com/apache/zookeeper/pull/1468

please anyone merge
IMO there is no need for a JIRA

Enrico

Il giorno lun 21 set 2020 alle ore 16:56 Enrico Olivelli <
eolive...@gmail.com> ha scritto:

> Andor,
> sorry for the late reply.
>
> I am hesitating because we should also update the website and we have to
> coordinate a bit
> https://zookeeper.apache.org/releases.html
>
> I am going to fix the website as first step, then when I see that the
> website is updated (no more links in the download page)
> I will remove the files from "dist".
>
> Then we can make the announcement.
>
> If anyone objects please chime in immediately
>
> Enrico
>
>
> Il giorno ven 11 set 2020 alle ore 21:44 Andor Molnar 
> ha scritto:
>
>> Hi Enrico,
>>
>> Sounds like a good plan for me.
>> Go ahead please and drop 3.4 from the dist folder.
>>
>> Do we want to make an official announcement (again) about the EOL of 3.4?
>> We already passed the official date and there was an announcement already
>> in the past, so I’m not keen on doing it.
>>
>> Andor
>>
>>
>>
>> > On 2020. Sep 11., at 8:12, Enrico Olivelli  wrote:
>> >
>> > Tamaas
>> >
>> > Il giorno gio 10 set 2020 alle ore 12:59 Tamas Penzes
>> >  ha scritto:
>> >
>> >> Congrats team.
>> >>
>> >> May I ask you when do you plan to move the stable pointer from 3.5.x to
>> >> 3.6.x?
>> >>
>> >
>> > As far as I can remember there is no written policy.
>> > We had users running with 3.5 "BETA" for years, now we see that users
>> start
>> > using 3.6 (and we see bug reports and we already cut 2 point releases)
>> >
>> > I am switching to 3.6 in all of the projects I am contributing to.
>> >
>> > Probably we will switch the 'stable' label to 3.6.x when we release
>> 3.7.0
>> > then 3.5 will be far away from the current development branch (it will
>> be
>> > 3.8 or even 4.0...)
>> >
>> >
>> > Enrico
>> >
>> >
>> >>
>> >> Thanks, Tamaas
>> >>
>> >> On Thu, Sep 10, 2020 at 12:50 PM Enrico Olivelli 
>> >> wrote:
>> >>
>> >>> Hi,
>> >>> I have completed the release procedure for 3.6.2.
>> >>> We have to drop stuff from non active branches from the dist area
>> >>> according to ASF rules.
>> >>>
>> >>> Do we have to remove 3.4.x from the "dist" area ?
>> >>> https://dist.apache.org/repos/dist/release/zookeeper/
>> >>>
>> >>> IIRC we decided to sent it to EOL On June 2020
>> >>>
>> >>> My proposal is to drop it
>> >>>
>> >>> Thoughts ?
>> >>>
>> >>> Enrico
>> >>>
>> >>
>>
>>


Re: ApacheCon Bug Bash

2020-09-28 Thread Tom DuBuisson
Enrico,
That sounds great.  We'll get the repo activated.

Tom


On Sun, Sep 27, 2020, 11:11 PM Enrico Olivelli  wrote:

> Tom
> Overall I think that we can move forward.
>
> This thread has been around for a while, there are no objections, every
> question has been answered.
>
> Thank you very much
>
> I hope this activity will help in growing Zookeeper project both in code
> quality and with more contributions, that is to help the community to grow.
>
> Best regards
>
> Enrico
>
> Il Lun 28 Set 2020, 01:27 Tom DuBuisson  ha scritto:
>
> > Norbert,
> >
> > Yes, you understand that correctly.  And those analyzers are FindSecBugs,
> > Error Prone and Infer.  All open source and in moderate to wide use
> > already.  Only find sec bugs is security specific - Infer and Error Prone
> > might find security bugs but they are more general purpose in nature.
> >
> > -Tom
> >
> > On Sun, Sep 27, 2020 at 3:43 PM Norbert Kalmar
> > 
> > wrote:
> >
> > > Hello Tom,
> > >
> > > +1 on the initiative, thanks for bringing this to our attention.
> > >
> > > If I understand correctly, there will be no disclosed security issues
> > which
> > > cannot be found with open source static analyzers.
> > >
> > > Regards,
> > > Norbert
> > >
> > >
> > > On Sun, Sep 27, 2020 at 8:23 AM Szalay-Bekő Máté <
> > > szalay.beko.m...@gmail.com>
> > > wrote:
> > >
> > > > Hello Guys,
> > > >
> > > > In general I like the idea, but unfortunately I can not really
> > > participate
> > > > (either in the coding or in the review) as I have a few important
> > > projects
> > > > close to deadline at the moment.
> > > >
> > > > My only concern is with the security bugs, which I don't like to be
> > > openly
> > > > reported before publishing a release with the fix. But for any other
> > kind
> > > > of bugfixes / improvements, I am very positive with the initiative.
> > > >
> > > >
> > > > Best regards,
> > > > Mate
> > > >
> > > > On Sun, Sep 27, 2020, 07:06 Tom DuBuisson  wrote:
> > > >
> > > > > Enrico et al,
> > > > >
> > > > > Are there other thoughts on this?  It would be great to get setup
> > > before
> > > > > the bash actually begins.  Enrico, lacking other voices would you
> > like
> > > to
> > > > > make a final call?
> > > > >
> > > > > -Tom
> > > > >
> > > > > On Thu, Sep 24, 2020 at 3:30 AM Enrico Olivelli <
> eolive...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Tom,
> > > > > > Personally I am +1 with this proposal. Thanks for your
> > > clarifications.
> > > > > >
> > > > > > But we should ear opinions from other people in this list
> > > > > >
> > > > > >
> > > > > > Enrico
> > > > > >
> > > > > > Il giorno mer 23 set 2020 alle ore 23:51 Tom DuBuisson <
> > > to...@muse.dev
> > > > >
> > > > > ha
> > > > > > scritto:
> > > > > >
> > > > > > > Enrico,
> > > > > > >
> > > > > > > On the topic security issues and reporting:  Muse's default
> > > > > configuration
> > > > > > > is open source tools and here it is run on open source
> projects.
> > > The
> > > > > > > results are thus already available publicly (in this case from
> > FSB,
> > > > > > Infer,
> > > > > > > and Error Prone).  Muse doesn't post anything to GitHub except
> in
> > > the
> > > > > > case
> > > > > > > of pull requests and then only if the bug is deemed to have
> been
> > > > > > > "introduced" as part of the PR - meaning it shouldn't be a
> > > > > vulnerability
> > > > > > in
> > > > > > > currently shipped software.
> > > > > > >
> > > > > > > If there are desires or proposals about more control over bug
> > > reports
> > > > > in
> > > > > > a
> > > > > > > convenient, configurable, manner then we'd really like to dig
> in
> > > and
> > > > > hear
> > > > > > > how to help.  In case there is more discussion on this point
> I'm
> > > > CCing
> > > > > > > Andrew who leads Muse's product design.
> > > > > > >
> > > > > > > -Tom
> > > > > > >
> > > > > > > On Wed, Sep 23, 2020 at 1:09 PM Enrico Olivelli <
> > > eolive...@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Il Mer 23 Set 2020, 19:02 Tom DuBuisson  ha
> > > > scritto:
> > > > > > > >
> > > > > > > > > Enrico,
> > > > > > > > >
> > > > > > > > > The Muse App requires two main abilities.  First is events,
> > > such
> > > > as
> > > > > > > > > notification when pull requests are opened or updated.
> > Second
> > > is
> > > > > > > > > permission to post comments (which is always possible for
> > > humans
> > > > > but
> > > > > > > more
> > > > > > > > > tightly controlled when the poster authenticates as a
> github
> > > > > > > > application).
> > > > > > > > > The repository being public has allowed us to run the app
> and
> > > > > observe
> > > > > > > > > ErrorProne, Infer, and FindSecBugs all run out of the box
> and
> > > > > without
> > > > > > > > > custom configuration.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Makes sense.
> > > > > > > >
> > > > > > > > One last question from my side
> > > > > > > > What about security issues?
> > > > > > > > 

Re: ApacheCon Bug Bash

2020-09-28 Thread Flavio Junqueira
It does sound like a good initiative, thanks for including us. I still have the 
concern that others have expressed below around exposing security issues. We 
have guidelines to follow and shouldn't be exposing them openly. I see that Tom 
said:

>> All open source and in moderate to wide use already.  Only find sec
>> bugs is security specific - Infer and Error Prone might find security
>> bugs but they are more general purpose in nature.

But I'm unsure about what this is saying. Otherwise, I'm good with bug bashing.

-Flavio


> On 28 Sep 2020, at 08:11, Enrico Olivelli  wrote:
> 
> Tom
> Overall I think that we can move forward.
> 
> This thread has been around for a while, there are no objections, every
> question has been answered.
> 
> Thank you very much
> 
> I hope this activity will help in growing Zookeeper project both in code
> quality and with more contributions, that is to help the community to grow.
> 
> Best regards
> 
> Enrico
> 
> Il Lun 28 Set 2020, 01:27 Tom DuBuisson  ha scritto:
> 
>> Norbert,
>> 
>> Yes, you understand that correctly.  And those analyzers are FindSecBugs,
>> Error Prone and Infer.  All open source and in moderate to wide use
>> already.  Only find sec bugs is security specific - Infer and Error Prone
>> might find security bugs but they are more general purpose in nature.
>> 
>> -Tom
>> 
>> On Sun, Sep 27, 2020 at 3:43 PM Norbert Kalmar
>> 
>> wrote:
>> 
>>> Hello Tom,
>>> 
>>> +1 on the initiative, thanks for bringing this to our attention.
>>> 
>>> If I understand correctly, there will be no disclosed security issues
>> which
>>> cannot be found with open source static analyzers.
>>> 
>>> Regards,
>>> Norbert
>>> 
>>> 
>>> On Sun, Sep 27, 2020 at 8:23 AM Szalay-Bekő Máté <
>>> szalay.beko.m...@gmail.com>
>>> wrote:
>>> 
 Hello Guys,
 
 In general I like the idea, but unfortunately I can not really
>>> participate
 (either in the coding or in the review) as I have a few important
>>> projects
 close to deadline at the moment.
 
 My only concern is with the security bugs, which I don't like to be
>>> openly
 reported before publishing a release with the fix. But for any other
>> kind
 of bugfixes / improvements, I am very positive with the initiative.
 
 
 Best regards,
 Mate
 
 On Sun, Sep 27, 2020, 07:06 Tom DuBuisson  wrote:
 
> Enrico et al,
> 
> Are there other thoughts on this?  It would be great to get setup
>>> before
> the bash actually begins.  Enrico, lacking other voices would you
>> like
>>> to
> make a final call?
> 
> -Tom
> 
> On Thu, Sep 24, 2020 at 3:30 AM Enrico Olivelli >> 
> wrote:
> 
>> Tom,
>> Personally I am +1 with this proposal. Thanks for your
>>> clarifications.
>> 
>> But we should ear opinions from other people in this list
>> 
>> 
>> Enrico
>> 
>> Il giorno mer 23 set 2020 alle ore 23:51 Tom DuBuisson <
>>> to...@muse.dev
> 
> ha
>> scritto:
>> 
>>> Enrico,
>>> 
>>> On the topic security issues and reporting:  Muse's default
> configuration
>>> is open source tools and here it is run on open source projects.
>>> The
>>> results are thus already available publicly (in this case from
>> FSB,
>> Infer,
>>> and Error Prone).  Muse doesn't post anything to GitHub except in
>>> the
>> case
>>> of pull requests and then only if the bug is deemed to have been
>>> "introduced" as part of the PR - meaning it shouldn't be a
> vulnerability
>> in
>>> currently shipped software.
>>> 
>>> If there are desires or proposals about more control over bug
>>> reports
> in
>> a
>>> convenient, configurable, manner then we'd really like to dig in
>>> and
> hear
>>> how to help.  In case there is more discussion on this point I'm
 CCing
>>> Andrew who leads Muse's product design.
>>> 
>>> -Tom
>>> 
>>> On Wed, Sep 23, 2020 at 1:09 PM Enrico Olivelli <
>>> eolive...@gmail.com
> 
>>> wrote:
>>> 
 Il Mer 23 Set 2020, 19:02 Tom DuBuisson  ha
 scritto:
 
> Enrico,
> 
> The Muse App requires two main abilities.  First is events,
>>> such
 as
> notification when pull requests are opened or updated.
>> Second
>>> is
> permission to post comments (which is always possible for
>>> humans
> but
>>> more
> tightly controlled when the poster authenticates as a github
 application).
> The repository being public has allowed us to run the app and
> observe
> ErrorProne, Infer, and FindSecBugs all run out of the box and
> without
> custom configuration.
> 
 
 Makes sense.
 
 One last question from my side
 What about security issues?
 Our policy is to have them reported to
 secur...@zookeeper.apache.org
 before

ApacheCon is going to start

2020-09-28 Thread Enrico Olivelli
Hi ZooKeeper community,

Probably you already know that ApacheCon@Home is going to take place this
week.

Even if it will be a "virtual" conference this time, it will also be a
great chance to meet and see each other.

This is the list of Tracks and a link to Camille's keynote
https://apachecon.com/acah2020/tracks/keynotes.html#W1515
https://apachecon.com/acah2020/tracks/

As you can there are going to be talks about cool projects from people in
our community.

This is the link to the Slack workspace of the event
http://s.apache.org/apachecon-slack

Don't miss this chance of being part of this great ASF community event !

Attending to the event is free
https://hopin.to/events/apachecon-home#schedule

See you at ApacheCon@Home !

Enrico


Re: ApacheCon Bug Bash

2020-09-28 Thread Enrico Olivelli
Tom
Overall I think that we can move forward.

This thread has been around for a while, there are no objections, every
question has been answered.

Thank you very much

I hope this activity will help in growing Zookeeper project both in code
quality and with more contributions, that is to help the community to grow.

Best regards

Enrico

Il Lun 28 Set 2020, 01:27 Tom DuBuisson  ha scritto:

> Norbert,
>
> Yes, you understand that correctly.  And those analyzers are FindSecBugs,
> Error Prone and Infer.  All open source and in moderate to wide use
> already.  Only find sec bugs is security specific - Infer and Error Prone
> might find security bugs but they are more general purpose in nature.
>
> -Tom
>
> On Sun, Sep 27, 2020 at 3:43 PM Norbert Kalmar
> 
> wrote:
>
> > Hello Tom,
> >
> > +1 on the initiative, thanks for bringing this to our attention.
> >
> > If I understand correctly, there will be no disclosed security issues
> which
> > cannot be found with open source static analyzers.
> >
> > Regards,
> > Norbert
> >
> >
> > On Sun, Sep 27, 2020 at 8:23 AM Szalay-Bekő Máté <
> > szalay.beko.m...@gmail.com>
> > wrote:
> >
> > > Hello Guys,
> > >
> > > In general I like the idea, but unfortunately I can not really
> > participate
> > > (either in the coding or in the review) as I have a few important
> > projects
> > > close to deadline at the moment.
> > >
> > > My only concern is with the security bugs, which I don't like to be
> > openly
> > > reported before publishing a release with the fix. But for any other
> kind
> > > of bugfixes / improvements, I am very positive with the initiative.
> > >
> > >
> > > Best regards,
> > > Mate
> > >
> > > On Sun, Sep 27, 2020, 07:06 Tom DuBuisson  wrote:
> > >
> > > > Enrico et al,
> > > >
> > > > Are there other thoughts on this?  It would be great to get setup
> > before
> > > > the bash actually begins.  Enrico, lacking other voices would you
> like
> > to
> > > > make a final call?
> > > >
> > > > -Tom
> > > >
> > > > On Thu, Sep 24, 2020 at 3:30 AM Enrico Olivelli  >
> > > > wrote:
> > > >
> > > > > Tom,
> > > > > Personally I am +1 with this proposal. Thanks for your
> > clarifications.
> > > > >
> > > > > But we should ear opinions from other people in this list
> > > > >
> > > > >
> > > > > Enrico
> > > > >
> > > > > Il giorno mer 23 set 2020 alle ore 23:51 Tom DuBuisson <
> > to...@muse.dev
> > > >
> > > > ha
> > > > > scritto:
> > > > >
> > > > > > Enrico,
> > > > > >
> > > > > > On the topic security issues and reporting:  Muse's default
> > > > configuration
> > > > > > is open source tools and here it is run on open source projects.
> > The
> > > > > > results are thus already available publicly (in this case from
> FSB,
> > > > > Infer,
> > > > > > and Error Prone).  Muse doesn't post anything to GitHub except in
> > the
> > > > > case
> > > > > > of pull requests and then only if the bug is deemed to have been
> > > > > > "introduced" as part of the PR - meaning it shouldn't be a
> > > > vulnerability
> > > > > in
> > > > > > currently shipped software.
> > > > > >
> > > > > > If there are desires or proposals about more control over bug
> > reports
> > > > in
> > > > > a
> > > > > > convenient, configurable, manner then we'd really like to dig in
> > and
> > > > hear
> > > > > > how to help.  In case there is more discussion on this point I'm
> > > CCing
> > > > > > Andrew who leads Muse's product design.
> > > > > >
> > > > > > -Tom
> > > > > >
> > > > > > On Wed, Sep 23, 2020 at 1:09 PM Enrico Olivelli <
> > eolive...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Il Mer 23 Set 2020, 19:02 Tom DuBuisson  ha
> > > scritto:
> > > > > > >
> > > > > > > > Enrico,
> > > > > > > >
> > > > > > > > The Muse App requires two main abilities.  First is events,
> > such
> > > as
> > > > > > > > notification when pull requests are opened or updated.
> Second
> > is
> > > > > > > > permission to post comments (which is always possible for
> > humans
> > > > but
> > > > > > more
> > > > > > > > tightly controlled when the poster authenticates as a github
> > > > > > > application).
> > > > > > > > The repository being public has allowed us to run the app and
> > > > observe
> > > > > > > > ErrorProne, Infer, and FindSecBugs all run out of the box and
> > > > without
> > > > > > > > custom configuration.
> > > > > > > >
> > > > > > >
> > > > > > > Makes sense.
> > > > > > >
> > > > > > > One last question from my side
> > > > > > > What about security issues?
> > > > > > > Our policy is to have them reported to
> > > secur...@zookeeper.apache.org
> > > > > > > before
> > > > > > > public disclosure
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Enrico
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Tom
> > > > > > > >
> > > > > > > > On Wed, Sep 23, 2020 at 6:35 AM Enrico Olivelli <
> > > > eolive...@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Il Mer 23 Set 2020,