Mailing List Archive: Apache Bug Bash

Apache Bug Bash

Sep 23, 2020, 8:56 AM

Post #1 of 8 (442 views)

Lucene 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

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. If this sounds familiar it's because I've been talking a
bit on this mailing list about Muse already. There has already been a bug
fix based on the tool findings, a prior conversation "Code Analysis during
CI?", and a PR adding configuration information for the GitHub App.

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 while we're already
working with the infrastructure team to get lucene-solr added (with the PR
and other conversation as evidence of support) it would help if you say yes
on this listserv as a clear signal to the Apache Infrastructure team to
grant Muse access to your Github mirror.

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

Re: Apache Bug Bash [ In reply to ]

arafalov at gmail

Sep 23, 2020, 9:10 AM

Post #2 of 8 (442 views)

Permalink

I just tested this on my personal tiny Java project and it is
(committer) +1 from me. Did not test it as part of a PR process,
though would be super excited if I could retroactively graft it on my
current one somehow: https://github.com/apache/lucene-solr/pull/1863

I've also signed up for the ApacheCon code bash and confirmed as
mentor availability. How much time I will actually have is a question,
but I will try. Hopefully, I will end up on a Solr team, there was no
way to indicate that (Tom!).

I would be super-curious to see how well it would be able to support
Solr's gradle build with all the dark magic we seem to have in it.

Regards,
Alex.
P.s. I suspect the full analysis of the code base would still be
rather noisy, but since that's not a default flow of
MuseDev, that should be fine.
P.p.s. Medium term, I would love to write a custom check that
complains about missing @since Javadoc tags for anything that is
pluggable/module like, including Analyzers, UpdateRequestProcessors,
Stream Components, etc. Knowing when each individual module is
introduced is super useful for those on older versions and my previous
attempts at fixing this required standalone code that even I cannot
get to run again easily now.

On Wed, 23 Sep 2020 at 11:56, Tom DuBuisson <tommd@muse.dev> wrote:
>
> Lucene 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
>
> 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. If this sounds familiar it's because I've been talking a bit on this mailing list about Muse already. There has already been a bug fix based on the tool findings, a prior conversation "Code Analysis during CI?", and a PR adding configuration information for the GitHub App.
>
> 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 while we're already working with the infrastructure team to get lucene-solr added (with the PR and other conversation as evidence of support) it would help if you say yes on this listserv as a clear signal to the Apache Infrastructure team to grant Muse access to your Github mirror.
>
> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Apache Bug Bash [ In reply to ]

dsmiley at apache

Sep 23, 2020, 1:39 PM

Post #3 of 8 (442 views)

Permalink

Sounds great! I'll try and be more responsive to any bugs reported through
the bash.
+1 (PMC)

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

On Wed, Sep 23, 2020 at 11:56 AM Tom DuBuisson <tommd@muse.dev> wrote:

> Lucene 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
>
> 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. If this sounds familiar it's because I've been talking a
> bit on this mailing list about Muse already. There has already been a bug
> fix based on the tool findings, a prior conversation "Code Analysis during
> CI?", and a PR adding configuration information for the GitHub App.
>
> 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 while we're
> already working with the infrastructure team to get lucene-solr added (with
> the PR and other conversation as evidence of support) it would help if you
> say yes on this listserv as a clear signal to the Apache Infrastructure
> team to grant Muse access to your Github mirror.
>
> 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
>

Re: Apache Bug Bash [ In reply to ]

tommd at muse

Sep 23, 2020, 3:56 PM

Post #4 of 8 (442 views)

Permalink

On Wed, Sep 23, 2020 at 9:11 AM Alexandre Rafalovitch <arafalov@gmail.com>
wrote:

> I just tested this on my personal tiny Java project and it is
> (committer) +1 from me. Did not test it as part of a PR process,
> though would be super excited if I could retroactively graft it on my
> current one somehow: https://github.com/apache/lucene-solr/pull/1863

I have a script or two that helps with this sort of test, it's a bit manual
so I ran and am awaiting results:
https://staging.muse.dev/result/TomMD/lucene-solr/01EJYJ8VRS8K52P95RKFBQAE1Y?tab=logs

> Hopefully, I will end up on a Solr team, there was no
> way to indicate that (Tom!).
>

Victoria (CCed) can make this a fact, not a hope! There are only so many
options we wanted to present to people in the signup. Anything can be
changed, we'll be here the whole time.

> I would be super-curious to see how well it would be able to support
> Solr's gradle build with all the dark magic we seem to have in it.
>

Perhaps I should keep it a secret and ratchet up the suspense, but I'm not
much of a showman.

The Infer and FSB tools ran on Solr seemingly fine (
https://console.muse.dev/result/TomMD/lucene-solr/01EG97PRSVXT35Z1E9T3SKA9V2?search=solr&tab=results)
but with the noise level you expect on a large project with subtle
invariants. The error prone results are lacking so I'll investigate.

> P.p.s. Medium term, I would love to write a custom check that
> complains about missing @since Javadoc tags for anything that is
> pluggable/module like, including Analyzers, UpdateRequestProcessors,
> Stream Components, etc. Knowing when each individual module is
> introduced is super useful for those on older versions and my previous
> attempts at fixing this required standalone code that even I cannot
> get to run again easily now.
>

I know we tweeted about this, but to bring that conversation to the ML: The
fastest way to write such a check is probably with an Error Prone plugin.
There isn't any support yet for ErrorProne plugins inside of Muse, but this
has been on our minds for a while. If someone beats me ot making an error
prone pass then I'll gladly make a way to run it.

>
> On Wed, 23 Sep 2020 at 11:56, Tom DuBuisson <tommd@muse.dev> wrote:
> >
> > Lucene 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
> >
> > 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. If this sounds familiar it's because I've been talking a
> bit on this mailing list about Muse already. There has already been a bug
> fix based on the tool findings, a prior conversation "Code Analysis during
> CI?", and a PR adding configuration information for the GitHub App.
> >
> > 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 while we're
> already working with the infrastructure team to get lucene-solr added (with
> the PR and other conversation as evidence of support) it would help if you
> say yes on this listserv as a clear signal to the Apache Infrastructure
> team to grant Muse access to your Github mirror.
> >
> > 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Apache Bug Bash [ In reply to ]

arafalov at gmail

Sep 23, 2020, 4:13 PM

Post #5 of 8 (442 views)

Permalink

On Wed, 23 Sep 2020 at 18:56, Tom DuBuisson <tommd@muse.dev> wrote:
> On Wed, Sep 23, 2020 at 9:11 AM Alexandre Rafalovitch <arafalov@gmail.com> wrote:
>> I would be super-curious to see how well it would be able to support
>> Solr's gradle build with all the dark magic we seem to have in it.
>
>
> Perhaps I should keep it a secret and ratchet up the suspense, but I'm not much of a showman.
>
> The Infer and FSB tools ran on Solr seemingly fine (https://console.muse.dev/result/TomMD/lucene-solr/01EG97PRSVXT35Z1E9T3SKA9V2?search=solr&tab=results) but with the noise level you expect on a large project with subtle invariants. The error prone results are lacking so I'll investigate.
>
The results are long enough that they could benefit from faceted
search by source, file, error type, etc. I wish there was an
open-source product you could leverage for such custom structured
search :-) (Yes, I realize your primary interface is PR with much less
noise)

>>
>> P.p.s. Medium term, I would love to write a custom check that
>> complains about missing @since Javadoc tags for anything that is
>> pluggable/module like, including Analyzers, UpdateRequestProcessors,
>> Stream Components, etc. Knowing when each individual module is
>> introduced is super useful for those on older versions and my previous
>> attempts at fixing this required standalone code that even I cannot
>> get to run again easily now.
>
>
> I know we tweeted about this, but to bring that conversation to the ML: The fastest way to write such a check is probably with an Error Prone plugin. There isn't any support yet for ErrorProne plugins inside of Muse, but this has been on our minds for a while. If someone beats me ot making an error prone pass then I'll gladly make a way to run it.

I have given error-prone a quick go. It works nicely when I installed
IntelliJ plugin linked from their website.

But for custom plugin..... Let's just say I got lost between
annotation processing during plugin compilation, annotation processing
including plugin, module/project dependencies and IntelliJ Idea's
options to make it work. So, I could not get a trivial example end to
end in Idea's default project setup.

But.... they have an example that I could import into IntelliJ idea
and get it to work with Gradle setup:
https://github.com/google/error-prone/tree/master/examples/plugin/gradle
(clone whole repo, point IntelliJ at just that directory as a project,
let it recognize Gradle, etc).

So, theoretically, if you take that custom plugin and manage to figure
out how to apply it to a custom project, I can keep beating my head on
my own specialized needs in parallel.

Anyway, the rest of this thread is probably not lucene-dev worthy. At
least not until there is something to show.

Regards,
Alex.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Apache Bug Bash [ In reply to ]

mdrob at apache

Sep 23, 2020, 6:04 PM

Post #6 of 8 (442 views)

Permalink

Note that error prone is part of our standard compilation already.

On Wed, Sep 23, 2020 at 6:14 PM Alexandre Rafalovitch <arafalov@gmail.com>
wrote:

> On Wed, 23 Sep 2020 at 18:56, Tom DuBuisson <tommd@muse.dev> wrote:
>
> > On Wed, Sep 23, 2020 at 9:11 AM Alexandre Rafalovitch <
> arafalov@gmail.com> wrote:
>
> >> I would be super-curious to see how well it would be able to support
>
> >> Solr's gradle build with all the dark magic we seem to have in it.
>
> >
>
> >
>
> > Perhaps I should keep it a secret and ratchet up the suspense, but I'm
> not much of a showman.
>
> >
>
> > The Infer and FSB tools ran on Solr seemingly fine (
> https://console.muse.dev/result/TomMD/lucene-solr/01EG97PRSVXT35Z1E9T3SKA9V2?search=solr&tab=results)
> but with the noise level you expect on a large project with subtle
> invariants. The error prone results are lacking so I'll investigate.
>
> >
>
> The results are long enough that they could benefit from faceted
>
> search by source, file, error type, etc. I wish there was an
>
> open-source product you could leverage for such custom structured
>
> search :-) (Yes, I realize your primary interface is PR with much less
>
> noise)
>
>
>
> >>
>
> >> P.p.s. Medium term, I would love to write a custom check that
>
> >> complains about missing @since Javadoc tags for anything that is
>
> >> pluggable/module like, including Analyzers, UpdateRequestProcessors,
>
> >> Stream Components, etc. Knowing when each individual module is
>
> >> introduced is super useful for those on older versions and my previous
>
> >> attempts at fixing this required standalone code that even I cannot
>
> >> get to run again easily now.
>
> >
>
> >
>
> > I know we tweeted about this, but to bring that conversation to the ML:
> The fastest way to write such a check is probably with an Error Prone
> plugin. There isn't any support yet for ErrorProne plugins inside of Muse,
> but this has been on our minds for a while. If someone beats me ot making
> an error prone pass then I'll gladly make a way to run it.
>
>
>
> I have given error-prone a quick go. It works nicely when I installed
>
> IntelliJ plugin linked from their website.
>
>
>
> But for custom plugin..... Let's just say I got lost between
>
> annotation processing during plugin compilation, annotation processing
>
> including plugin, module/project dependencies and IntelliJ Idea's
>
> options to make it work. So, I could not get a trivial example end to
>
> end in Idea's default project setup.
>
>
>
> But.... they have an example that I could import into IntelliJ idea
>
> and get it to work with Gradle setup:
>
> https://github.com/google/error-prone/tree/master/examples/plugin/gradle
>
> (clone whole repo, point IntelliJ at just that directory as a project,
>
> let it recognize Gradle, etc).
>
>
>
> So, theoretically, if you take that custom plugin and manage to figure
>
> out how to apply it to a custom project, I can keep beating my head on
>
> my own specialized needs in parallel.
>
>
>
> Anyway, the rest of this thread is probably not lucene-dev worthy. At
>
> least not until there is something to show.
>
>
>
> Regards,
>
> Alex.
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
>

Re: Apache Bug Bash [ In reply to ]

arafalov at gmail

Sep 24, 2020, 5:59 AM

Post #7 of 8 (442 views)

Permalink

That's interesting. I did track LUCENE-9497 from your comment and
gradle/validation/error-prone.gradle

But it seems all the flags are disabled for now. So, is it actually
running on pre-commit (check)?

Because, for example, we also introduced a custom Doclet to check ?
cross-references recently. But error-prone supports JavaDoc analysis
as well. So, maybe these things should be consolidated.

I am guessing this is a separate discussion from MuseDev's approach as
they will primarily run the checks on PRs and show changed warnings
only (and with more tools). But it is somewhat connected at the same
time in terms of using a static analysis approach.

Regards,
Alex.
P.s. It also means that maybe writing my own error-prone plugin and
integrating it into the project is less difficult than I estimated.

On Wed, 23 Sep 2020 at 21:04, Mike Drob <mdrob@apache.org> wrote:
>
> Note that error prone is part of our standard compilation already.
>
> On Wed, Sep 23, 2020 at 6:14 PM Alexandre Rafalovitch <arafalov@gmail.com> wrote:
>>
>> On Wed, 23 Sep 2020 at 18:56, Tom DuBuisson <tommd@muse.dev> wrote:
>>
>> > On Wed, Sep 23, 2020 at 9:11 AM Alexandre Rafalovitch <arafalov@gmail.com> wrote:
>>
>> >> I would be super-curious to see how well it would be able to support
>>
>> >> Solr's gradle build with all the dark magic we seem to have in it.
>>
>> >
>>
>> >
>>
>> > Perhaps I should keep it a secret and ratchet up the suspense, but I'm not much of a showman.
>>
>> >
>>
>> > The Infer and FSB tools ran on Solr seemingly fine (https://console.muse.dev/result/TomMD/lucene-solr/01EG97PRSVXT35Z1E9T3SKA9V2?search=solr&tab=results) but with the noise level you expect on a large project with subtle invariants. The error prone results are lacking so I'll investigate.
>>
>> >
>>
>> The results are long enough that they could benefit from faceted
>>
>> search by source, file, error type, etc. I wish there was an
>>
>> open-source product you could leverage for such custom structured
>>
>> search :-) (Yes, I realize your primary interface is PR with much less
>>
>> noise)
>>
>>
>>
>> >>
>>
>> >> P.p.s. Medium term, I would love to write a custom check that
>>
>> >> complains about missing @since Javadoc tags for anything that is
>>
>> >> pluggable/module like, including Analyzers, UpdateRequestProcessors,
>>
>> >> Stream Components, etc. Knowing when each individual module is
>>
>> >> introduced is super useful for those on older versions and my previous
>>
>> >> attempts at fixing this required standalone code that even I cannot
>>
>> >> get to run again easily now.
>>
>> >
>>
>> >
>>
>> > I know we tweeted about this, but to bring that conversation to the ML: The fastest way to write such a check is probably with an Error Prone plugin. There isn't any support yet for ErrorProne plugins inside of Muse, but this has been on our minds for a while. If someone beats me ot making an error prone pass then I'll gladly make a way to run it.
>>
>>
>>
>> I have given error-prone a quick go. It works nicely when I installed
>>
>> IntelliJ plugin linked from their website.
>>
>>
>>
>> But for custom plugin..... Let's just say I got lost between
>>
>> annotation processing during plugin compilation, annotation processing
>>
>> including plugin, module/project dependencies and IntelliJ Idea's
>>
>> options to make it work. So, I could not get a trivial example end to
>>
>> end in Idea's default project setup.
>>
>>
>>
>> But.... they have an example that I could import into IntelliJ idea
>>
>> and get it to work with Gradle setup:
>>
>> https://github.com/google/error-prone/tree/master/examples/plugin/gradle
>>
>> (clone whole repo, point IntelliJ at just that directory as a project,
>>
>> let it recognize Gradle, etc).
>>
>>
>>
>> So, theoretically, if you take that custom plugin and manage to figure
>>
>> out how to apply it to a custom project, I can keep beating my head on
>>
>> my own specialized needs in parallel.
>>
>>
>>
>> Anyway, the rest of this thread is probably not lucene-dev worthy. At
>>
>> least not until there is something to show.
>>
>>
>>
>> Regards,
>>
>> Alex.
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Apache Bug Bash [ In reply to ]

tommd at muse

Sep 28, 2020, 4:11 PM

Post #8 of 8 (440 views)

Permalink

Lucene, Solr,
We have Muse set-up and enabled on your project and it’s ready for the bug
bash during ApacheCon. For anyone interested in participating, we’d love
to have you, and you can register via our eventbrite link.
https://www.eventbrite.com/e/muse-presents-apachecon-bug-bash-2020-tickets-122229739441

-Tom

On Wed, Sep 23, 2020 at 8:56 AM Tom DuBuisson <tommd@muse.dev> wrote:

> Lucene 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
>
> 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. If this sounds familiar it's because I've been talking a
> bit on this mailing list about Muse already. There has already been a bug
> fix based on the tool findings, a prior conversation "Code Analysis during
> CI?", and a PR adding configuration information for the GitHub App.
>
> 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 while we're
> already working with the infrastructure team to get lucene-solr added (with
> the PR and other conversation as evidence of support) it would help if you
> say yes on this listserv as a clear signal to the Apache Infrastructure
> team to grant Muse access to your Github mirror.
>
> 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
>