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 <to...@muse.dev> 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 <to...@muse.dev> 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, 00:44 Tom DuBuisson <to...@muse.dev> ha > > scritto: > > > > > > > > > > > > > Zookeeper Developers, > > > > > > > > > > > > > > > > > > > > > > > > > > > > As part of our sponsorship of ApacheCon, our company MuseDev is > > > > doing a > > > > > > Bug > > > > > > > Bash for select Apache projects. We'll bring members of the > > > ApacheCon > > > > > > > community together to find and fix a range of security and > > > > performance > > > > > > bugs > > > > > > > during the conference, and gameify the experience with teams, a > > > > > > > leaderboard, and prizes. The bash is open to everyone whether > > > > attending > > > > > > the > > > > > > > conference or not, and our whole dev team will also be > > > participating > > > > to > > > > > > > help fix as many bugs as we can. > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're seeding the bug list with results from Muse, our code > > > analysis > > > > > > > platform, which runs as a Github App and comments on possible > > bugs > > > as > > > > > > part > > > > > > > of the pull request workflow. Here's an example of what it > looks > > > > like: > > > > > > > > > > > > > > > https://github.com/curl/curl/pull/5971#discussion_r490252196 > > > > > > > <https://github.com/curl/curl/pull/5971> > > > > > > > > > > > > > > > > > > > > > > > > > > > > We explored a number of Apache projects and are reaching out > > > because > > > > > our > > > > > > > analysis through Muse found some interesting bugs that could be > > > fixed > > > > > > > during the Bash. > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're writing to see if you'd be interested in having your > > project > > > > > > included > > > > > > > in the Bash. Everything is set up on our end, and if you're > > > > interested, > > > > > > we > > > > > > > would need you to say yes on this listserv, and we’ll work with > > the > > > > > > Apache > > > > > > > Infrastructure team to grant Muse access to your Github mirror. > > > > > > > > > > > > > > > > > > It is a public repo, which kind of access does it need? > > > > > > > > > > > > Enrico > > > > > > > > > > > > > > > > > > We'll then > > > > > > > make sure it's all set-up and ready for the Bash. And of > course, > > > > > everyone > > > > > > > on the project is most welcome to join the Bash and help us > smash > > > > some > > > > > > > bugs. > > > > > > > > > > > > > > > > > > > > > -Tom > > > > > > > > > > > > > > > > > > > > > > > > > > > >
