OK, I just put up a PR for SOLR-10810 with what I have so far for solr/core. I
suspect it overlaps with some of the changes from the JIRAs people have pointed
out. Please feel free to comment.
Meanwhile I’ll start looking at the other JIRAs and (eventually) reconcile them.
In case I messed up
Erick,
Please assign me a medium sized directory as well (in the Lucene JIRA).
Atri
On Mon, May 11, 2020 at 11:21 PM Erick Erickson wrote:
>
> Andras:
>
> Yep, I saw a couple of those, I’m looking at how to incorporate. It may take
> another week or so, depending… Apologies for them sitting
Andras:
Yep, I saw a couple of those, I’m looking at how to incorporate. It may take
another week or so, depending… Apologies for them sitting on the shelf for so
long.
David: Noted.
Mike:
Well, I’ve got some ready to look at more closely, I often tear into something
for a while mostly
@Erick assign me a (not too large) dir... I'll help.
On Mon, May 11, 2020 at 11:33 AM David Smiley
wrote:
> My proposal to disregard entire classes of warnings was intended to be a
> short term strategy and not long term. It allows you to fix some problems
> completely before moving onto
My proposal to disregard entire classes of warnings was intended to be a
short term strategy and not long term. It allows you to fix some problems
completely before moving onto others. Additionally, we can tweak the
linter settings per-module. The final end state in the future is not to
have
I agree with the one warning at a time approach. That one seems most
feasible to take piecemeal
On Mon, May 11, 2020 at 10:19 AM Andras Salamon
wrote:
> Hi,
>
> We have quite a few warnings, it would be difficult to fix them at once.
> Checking one directory (or warning type) and handling 10-20
Hi,
We have quite a few warnings, it would be difficult to fix them at once.
Checking one directory (or warning type) and handling 10-20 warnings at the
same time seems more reasonable.
There are two umbrella jiras for that:
https://issues.apache.org/jira/browse/SOLR-10778 and
Gus:
When it comes to actually removing the necessity of suppresswarnings IntelliJ
makes a lot of this much easier. The issue is that it’s too much work for any
one person to have a hope of doing in any reasonable period without introducing
errors.
There are just too many warnings for one
I typically battle warnings by conquering one file/directory at a time...
And letting Intellij take me from warning to warning with F2 key really
really really speeds things up. This is a wider set than compiler warnings,
but you can customize it, and many of the additional warnings are
+1 to Erick’s proposal.
I hate the number of warnings we get — we should still be formulating some
sort of a strategy to fix them.
Atri
On Mon, 11 May 2020 at 17:09, Erick Erickson
wrote:
> Just disabling the warning globally nothing to prevent more being added.
> Take raw types. They’re a
Just disabling the warning globally nothing to prevent more being added. Take
raw types. They’re a compromise allowed by the java compiler explicitly to be
able to continue to use older binaries written before (or without) generics.
But take a look at SolrQueryResponse for instance. We
Can't we customize the linting to disregard entire categories of certain
warnings for now? This makes your task manageable.
https://discuss.gradle.org/t/recompile-with-xlint-parameters/25279
~ David
On Sun, May 10, 2020 at 10:41 PM Erick Erickson
wrote:
> I’m really struggling with what to
12 matches
Mail list logo
