On Wed, Sep 23, 2020 at 9:11 AM Alexandre Rafalovitch <arafa...@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 <to...@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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
