Re: Getting warnings out

[Erick Erickson]

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 the PR, here’s the URL: 
https://github.com/apache/lucene-solr/pull/1509

Erick

> On May 11, 2020, at 1:54 PM, Atri Sharma  wrote:
> 
> 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 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 to get a better feel for what it’ll take. I’ll 
>> probably post a PR for SOLR-10810 soon with what I’ve done so far, mainly 
>> getting auxiliary class warnings out of solr/core (which was something of a 
>> chore). Then on to Andras’ patches.
>> 
>> Gus:
>> 
>> The chunks are fairly big when it’s based on project. For instance solr/core 
>> or solrj/core or… I’m trying to get a clue how to break them up in to 
>> smaller chunks, directory-based would be best I think.
>> 
>> So here’s what I propose (I’ll take care of these steps):
>> 
>> 1> get the PR in place for what I've done so far for SOLR-10810 (warning, 
>> it’s bigger than it should be, in future I need to take smaller bites) and 
>> push that upstream when we’re satisfied.
>> 
>> 2> incorporate the changes Andras mentioned.
>> 
>> 3> start the process of suppressing warnings. I propose that we make a list 
>> of subtasks from SOLR-10778 and assign them to whoever takes them on. If you 
>> can’t assign something to yourself, raise a subtask and make a note in the 
>> description that you’re working on XYZ.
>> 
>> Again, the short-term goal is to get clean compilations, fixing safe/simple 
>> warnings that we fully understand and SuppressWarnings for the rest. From 
>> there we’ll start failing on warnings when a project is clean.
>> 
>> Thanks!
>> 
>> 
>>> On May 11, 2020, at 11:40 AM, Gus Heck  wrote:
>>> 
>>> @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 others.  Additionally, we can tweak the 
>>> linter settings per-module.  The final end state in the future is not to 
>>> have such linter customizations.
>>> 
>>> ~ David
>>> 
>>> 
>>> On Mon, May 11, 2020 at 11:22 AM Mike Drob  wrote:
>>> 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 warnings at the 
>>> same time seems more reasonable.
>>> 
>>> There are two umbrella jiras for that: 
>>> https://issues.apache.org/jira/browse/SOLR-10778 and 
>>> https://issues.apache.org/jira/browse/LUCENE-7907
>>> 
>>> I have two jiras in patch-available status:
>>> 
>>> https://issues.apache.org/jira/browse/LUCENE-9323
>>> https://issues.apache.org/jira/browse/SOLR-14266
>>> 
>>> Andras
>>> 
>>> On Mon, May 11, 2020 at 4:28 PM Erick Erickson  
>>> wrote:
>>> 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 person to have a hope of thinking 
>>> carefully about all of them, so my strategy is to stop adding to the 
>>> problem, raise awareness when it happens etc. I think to remove the 
>>> necessity for SuppressWarnings will require extensive work, best approached 
>>> over time, not in a huge wodge.
>>> 
>>> Best,
>>> Erick
>>> 
 On May 11, 2020, at 9:25 AM, Gus Heck  wrote:
 
 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 auto-solvable (things like redundant initializers for variables that 
 are already assigned before use), so the extra work is more than paid for 
 by the reduction in transition time. The key one to think carefully about 
 is the one that wants to minimize access, which is great 

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Atri Sharma]

My two cents:

As a Lucene heavy developer, I have several found maintaining Solr
dependencies while making large changes a bit cumbersome. I believe
Lucene and Solr should exist in a symbiotic relationship but not
tightly coupled with each other.


On Mon, May 11, 2020 at 7:22 PM Erik Hatcher  wrote:
>
> Without reading much or replying to any specific points made on this thread, 
> here's my raw thoughts on this age-old topic (finally  coming out of my 
> cocoon after taking things in for a bit)
>
> Solr is a search -server- with distributed capabilities, that leverages the 
> magic of Lucene underneath.  Solr depends on Lucene, is a consumer of it.  
> Lucene is a tight search -library- with little to no external dependencies.  
> Their purposes and end-users are different.
>
> I was never really for the grand unification of Lucene and Solr back in the 
> day because:
>
>   - Solr's developer experience would be greatly streamlined, faster, 
> cleaner, leaner, and focused
>   - Having Lucene change when Solr doesni't (yet) adapt to those changes 
> leads to confusion and inconsistency, loose wires hanging out of the wall 
> unconnected or duct taped together
>   - It simply makes sense to keep Lucene versioned and tightly controlled for 
> upgrades, various testing configurations varying Lucene versions, within Solr
>   - Solr could have a very concerted upgrade effort for Lucene capability 
> jumps, with a focused upgrade effort at the changed/improved/added touch 
> points just like other dependencies within Solr (like Tika and Jetty)
>
> Those points all kinda say the same thing Solr depends on "lucene.jar" 
> and I'm in the camp that thinks Solr and Lucene development, communities, and 
> end-users/consumers would all greatly benefit from a fancy new TLP and 
> focused community for solr.apache.org and a tight(er) relationship with the 
> Lucene community as an involved and vested consumer.
>
> Erik
>


-- 
Regards,

Atri
Apache Concerted

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

Re: Getting warnings out

[Atri Sharma]

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 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 to get a better feel for what it’ll take. I’ll 
> probably post a PR for SOLR-10810 soon with what I’ve done so far, mainly 
> getting auxiliary class warnings out of solr/core (which was something of a 
> chore). Then on to Andras’ patches.
>
> Gus:
>
> The chunks are fairly big when it’s based on project. For instance solr/core 
> or solrj/core or… I’m trying to get a clue how to break them up in to smaller 
> chunks, directory-based would be best I think.
>
> So here’s what I propose (I’ll take care of these steps):
>
> 1> get the PR in place for what I've done so far for SOLR-10810 (warning, 
> it’s bigger than it should be, in future I need to take smaller bites) and 
> push that upstream when we’re satisfied.
>
> 2> incorporate the changes Andras mentioned.
>
> 3> start the process of suppressing warnings. I propose that we make a list 
> of subtasks from SOLR-10778 and assign them to whoever takes them on. If you 
> can’t assign something to yourself, raise a subtask and make a note in the 
> description that you’re working on XYZ.
>
> Again, the short-term goal is to get clean compilations, fixing safe/simple 
> warnings that we fully understand and SuppressWarnings for the rest. From 
> there we’ll start failing on warnings when a project is clean.
>
> Thanks!
>
>
> > On May 11, 2020, at 11:40 AM, Gus Heck  wrote:
> >
> > @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 others.  Additionally, we can tweak the 
> > linter settings per-module.  The final end state in the future is not to 
> > have such linter customizations.
> >
> > ~ David
> >
> >
> > On Mon, May 11, 2020 at 11:22 AM Mike Drob  wrote:
> > 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 warnings at the 
> > same time seems more reasonable.
> >
> > There are two umbrella jiras for that: 
> > https://issues.apache.org/jira/browse/SOLR-10778 and 
> > https://issues.apache.org/jira/browse/LUCENE-7907
> >
> > I have two jiras in patch-available status:
> >
> > https://issues.apache.org/jira/browse/LUCENE-9323
> > https://issues.apache.org/jira/browse/SOLR-14266
> >
> > Andras
> >
> > On Mon, May 11, 2020 at 4:28 PM Erick Erickson  
> > wrote:
> > 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 person to have a hope of thinking 
> > carefully about all of them, so my strategy is to stop adding to the 
> > problem, raise awareness when it happens etc. I think to remove the 
> > necessity for SuppressWarnings will require extensive work, best approached 
> > over time, not in a huge wodge.
> >
> > Best,
> > Erick
> >
> > > On May 11, 2020, at 9:25 AM, Gus Heck  wrote:
> > >
> > > 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 auto-solvable (things like redundant initializers for variables that 
> > > are already assigned before use), so the extra work is more than paid for 
> > > by the reduction in transition time. The key one to think carefully about 
> > > is the one that wants to minimize access, which is great for new classes, 
> > > dangerous for released classes. Perhaps turn that warning off in 
> > > intellij...
> > >
> > > On Mon, May 11, 2020 at 8:14 AM Atri Sharma  wrote:
> > > +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. 

Re: Getting warnings out

[Erick Erickson]

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 to get a better feel for what it’ll take. I’ll probably post 
a PR for SOLR-10810 soon with what I’ve done so far, mainly getting auxiliary 
class warnings out of solr/core (which was something of a chore). Then on to 
Andras’ patches.

Gus:

The chunks are fairly big when it’s based on project. For instance solr/core or 
solrj/core or… I’m trying to get a clue how to break them up in to smaller 
chunks, directory-based would be best I think.

So here’s what I propose (I’ll take care of these steps):

1> get the PR in place for what I've done so far for SOLR-10810 (warning, it’s 
bigger than it should be, in future I need to take smaller bites) and push that 
upstream when we’re satisfied.

2> incorporate the changes Andras mentioned.

3> start the process of suppressing warnings. I propose that we make a list of 
subtasks from SOLR-10778 and assign them to whoever takes them on. If you can’t 
assign something to yourself, raise a subtask and make a note in the 
description that you’re working on XYZ.

Again, the short-term goal is to get clean compilations, fixing safe/simple 
warnings that we fully understand and SuppressWarnings for the rest. From there 
we’ll start failing on warnings when a project is clean.

Thanks!


> On May 11, 2020, at 11:40 AM, Gus Heck  wrote:
> 
> @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 others.  Additionally, we can tweak the linter 
> settings per-module.  The final end state in the future is not to have such 
> linter customizations.
> 
> ~ David
> 
> 
> On Mon, May 11, 2020 at 11:22 AM Mike Drob  wrote:
> 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 warnings at the 
> same time seems more reasonable.
> 
> There are two umbrella jiras for that: 
> https://issues.apache.org/jira/browse/SOLR-10778 and 
> https://issues.apache.org/jira/browse/LUCENE-7907
> 
> I have two jiras in patch-available status:
> 
> https://issues.apache.org/jira/browse/LUCENE-9323
> https://issues.apache.org/jira/browse/SOLR-14266
> 
> Andras
> 
> On Mon, May 11, 2020 at 4:28 PM Erick Erickson  
> wrote:
> 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 person to have a hope of thinking 
> carefully about all of them, so my strategy is to stop adding to the problem, 
> raise awareness when it happens etc. I think to remove the necessity for 
> SuppressWarnings will require extensive work, best approached over time, not 
> in a huge wodge.
> 
> Best,
> Erick
> 
> > On May 11, 2020, at 9:25 AM, Gus Heck  wrote:
> > 
> > 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 
> > auto-solvable (things like redundant initializers for variables that are 
> > already assigned before use), so the extra work is more than paid for by 
> > the reduction in transition time. The key one to think carefully about is 
> > the one that wants to minimize access, which is great for new classes, 
> > dangerous for released classes. Perhaps turn that warning off in 
> > intellij...  
> > 
> > On Mon, May 11, 2020 at 8:14 AM Atri Sharma  wrote:
> > +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 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 
> > explicitly declare:
> > 
> > protected NamedList values = new SimpleOrderedMap<>();
> > 
> > but then declare a method:
> > 
> > public 

Re: Getting warnings out

[Gus Heck]

@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 others.  Additionally, we can tweak the
> linter settings per-module.  The final end state in the future is not to
> have such linter customizations.
>
> ~ David
>
>
> On Mon, May 11, 2020 at 11:22 AM Mike Drob  wrote:
>
>> 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 <
>> andras.sala...@melda.info> 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 warnings at the
>>> same time seems more reasonable.
>>>
>>> There are two umbrella jiras for that:
>>> https://issues.apache.org/jira/browse/SOLR-10778 and
>>> https://issues.apache.org/jira/browse/LUCENE-7907
>>>
>>> I have two jiras in patch-available status:
>>>
>>> https://issues.apache.org/jira/browse/LUCENE-9323
>>> https://issues.apache.org/jira/browse/SOLR-14266
>>>
>>> Andras
>>>
>>> On Mon, May 11, 2020 at 4:28 PM Erick Erickson 
>>> wrote:
>>>
 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 person to have a hope of
 thinking carefully about all of them, so my strategy is to stop adding to
 the problem, raise awareness when it happens etc. I think to remove the
 necessity for SuppressWarnings will require extensive work, best approached
 over time, not in a huge wodge.

 Best,
 Erick

 > On May 11, 2020, at 9:25 AM, Gus Heck  wrote:
 >
 > 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
 auto-solvable (things like redundant initializers for variables that are
 already assigned before use), so the extra work is more than paid for by
 the reduction in transition time. The key one to think carefully about is
 the one that wants to minimize access, which is great for new classes,
 dangerous for released classes. Perhaps turn that warning off in
 intellij...
 >
 > On Mon, May 11, 2020 at 8:14 AM Atri Sharma  wrote:
 > +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 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
 explicitly declare:
 >
 > protected NamedList values = new SimpleOrderedMap<>();
 >
 > but then declare a method:
 >
 > public NamedList getValues() { return values; }
 >
 > This is just bad practice.
 >
 > I don’t mind the grunt work, keeps me from stupid surfing. I’m
 proposing that I fix what’s easy, and suppress the rest.
 >
 > It might have been clearer if I’d said “Then start failing builds on
 any new warnings of these types”.
 >
 > Oh, and I’m also thinking of changing my BadApple report to flag when
 new SuppressWarnings are introduced and then nag people about new ones.
 >
 >
 >
 > > On May 10, 2020, at 11:43 PM, David Smiley <
 david.w.smi...@gmail.com> wrote:
 > >
 > > 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 <
 erickerick...@gmail.com> wrote:
 > > I’m really struggling with what to do with compiler warnings,
 particularly all the rawtypes and unchecked warnings.
 > >
 > > On the one hand, the simple mechanical thing to do would be to
 SuppressWarnings on each one that exists presently. Frankly that feels
 pretty useless; that would preserve poor code forever.
 > >
 > > OTOH, actually _fixing_ the issues to not have, say, rawtypes is
 going to be time consuming and error-prone. 

Re: Getting warnings out

[David Smiley]

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 such linter customizations.

~ David


On Mon, May 11, 2020 at 11:22 AM Mike Drob  wrote:

> 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 warnings at the
>> same time seems more reasonable.
>>
>> There are two umbrella jiras for that:
>> https://issues.apache.org/jira/browse/SOLR-10778 and
>> https://issues.apache.org/jira/browse/LUCENE-7907
>>
>> I have two jiras in patch-available status:
>>
>> https://issues.apache.org/jira/browse/LUCENE-9323
>> https://issues.apache.org/jira/browse/SOLR-14266
>>
>> Andras
>>
>> On Mon, May 11, 2020 at 4:28 PM Erick Erickson 
>> wrote:
>>
>>> 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 person to have a hope of
>>> thinking carefully about all of them, so my strategy is to stop adding to
>>> the problem, raise awareness when it happens etc. I think to remove the
>>> necessity for SuppressWarnings will require extensive work, best approached
>>> over time, not in a huge wodge.
>>>
>>> Best,
>>> Erick
>>>
>>> > On May 11, 2020, at 9:25 AM, Gus Heck  wrote:
>>> >
>>> > 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
>>> auto-solvable (things like redundant initializers for variables that are
>>> already assigned before use), so the extra work is more than paid for by
>>> the reduction in transition time. The key one to think carefully about is
>>> the one that wants to minimize access, which is great for new classes,
>>> dangerous for released classes. Perhaps turn that warning off in
>>> intellij...
>>> >
>>> > On Mon, May 11, 2020 at 8:14 AM Atri Sharma  wrote:
>>> > +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 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
>>> explicitly declare:
>>> >
>>> > protected NamedList values = new SimpleOrderedMap<>();
>>> >
>>> > but then declare a method:
>>> >
>>> > public NamedList getValues() { return values; }
>>> >
>>> > This is just bad practice.
>>> >
>>> > I don’t mind the grunt work, keeps me from stupid surfing. I’m
>>> proposing that I fix what’s easy, and suppress the rest.
>>> >
>>> > It might have been clearer if I’d said “Then start failing builds on
>>> any new warnings of these types”.
>>> >
>>> > Oh, and I’m also thinking of changing my BadApple report to flag when
>>> new SuppressWarnings are introduced and then nag people about new ones.
>>> >
>>> >
>>> >
>>> > > On May 10, 2020, at 11:43 PM, David Smiley 
>>> wrote:
>>> > >
>>> > > 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 <
>>> erickerick...@gmail.com> wrote:
>>> > > I’m really struggling with what to do with compiler warnings,
>>> particularly all the rawtypes and unchecked warnings.
>>> > >
>>> > > On the one hand, the simple mechanical thing to do would be to
>>> SuppressWarnings on each one that exists presently. Frankly that feels
>>> pretty useless; that would preserve poor code forever.
>>> > >
>>> > > OTOH, actually _fixing_ the issues to not have, say, rawtypes is
>>> going to be time consuming and error-prone. Especially since I don’t really
>>> understand all the nuances yet and learning them one by one will introduce
>>> serious errors without doubt.
>>> > >
>>> > > So here’s what I propose. Even though it feels useless, just
>>> SuppressWarnings on anything that’s not a simple fix. Then start 

Re: Getting warnings out

[Mike Drob]

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 warnings at the
> same time seems more reasonable.
>
> There are two umbrella jiras for that:
> https://issues.apache.org/jira/browse/SOLR-10778 and
> https://issues.apache.org/jira/browse/LUCENE-7907
>
> I have two jiras in patch-available status:
>
> https://issues.apache.org/jira/browse/LUCENE-9323
> https://issues.apache.org/jira/browse/SOLR-14266
>
> Andras
>
> On Mon, May 11, 2020 at 4:28 PM Erick Erickson 
> wrote:
>
>> 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 person to have a hope of
>> thinking carefully about all of them, so my strategy is to stop adding to
>> the problem, raise awareness when it happens etc. I think to remove the
>> necessity for SuppressWarnings will require extensive work, best approached
>> over time, not in a huge wodge.
>>
>> Best,
>> Erick
>>
>> > On May 11, 2020, at 9:25 AM, Gus Heck  wrote:
>> >
>> > 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
>> auto-solvable (things like redundant initializers for variables that are
>> already assigned before use), so the extra work is more than paid for by
>> the reduction in transition time. The key one to think carefully about is
>> the one that wants to minimize access, which is great for new classes,
>> dangerous for released classes. Perhaps turn that warning off in
>> intellij...
>> >
>> > On Mon, May 11, 2020 at 8:14 AM Atri Sharma  wrote:
>> > +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 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
>> explicitly declare:
>> >
>> > protected NamedList values = new SimpleOrderedMap<>();
>> >
>> > but then declare a method:
>> >
>> > public NamedList getValues() { return values; }
>> >
>> > This is just bad practice.
>> >
>> > I don’t mind the grunt work, keeps me from stupid surfing. I’m
>> proposing that I fix what’s easy, and suppress the rest.
>> >
>> > It might have been clearer if I’d said “Then start failing builds on
>> any new warnings of these types”.
>> >
>> > Oh, and I’m also thinking of changing my BadApple report to flag when
>> new SuppressWarnings are introduced and then nag people about new ones.
>> >
>> >
>> >
>> > > On May 10, 2020, at 11:43 PM, David Smiley 
>> wrote:
>> > >
>> > > 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 <
>> erickerick...@gmail.com> wrote:
>> > > I’m really struggling with what to do with compiler warnings,
>> particularly all the rawtypes and unchecked warnings.
>> > >
>> > > On the one hand, the simple mechanical thing to do would be to
>> SuppressWarnings on each one that exists presently. Frankly that feels
>> pretty useless; that would preserve poor code forever.
>> > >
>> > > OTOH, actually _fixing_ the issues to not have, say, rawtypes is
>> going to be time consuming and error-prone. Especially since I don’t really
>> understand all the nuances yet and learning them one by one will introduce
>> serious errors without doubt.
>> > >
>> > > So here’s what I propose. Even though it feels useless, just
>> SuppressWarnings on anything that’s not a simple fix. Then start failing
>> builds on these warnings to catch any that come in in future. At least that
>> way there’ll be some incentive to keep the code from getting _worse_,
>> although people will still be able to just add SuppressWarnings to the mix
>> I suppose.
>> > >
>> > > The number of raw NamedList member variables we have is overwhelming
>> all by itself….
>> > >
>> > > Comments?
>> > >
>> > >
>> > > -
>> > > To unsubscribe, e-mail: 

Re: Getting warnings out

[Andras Salamon]

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
https://issues.apache.org/jira/browse/LUCENE-7907

I have two jiras in patch-available status:

https://issues.apache.org/jira/browse/LUCENE-9323
https://issues.apache.org/jira/browse/SOLR-14266

Andras

On Mon, May 11, 2020 at 4:28 PM Erick Erickson 
wrote:

> 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 person to have a hope of thinking
> carefully about all of them, so my strategy is to stop adding to the
> problem, raise awareness when it happens etc. I think to remove the
> necessity for SuppressWarnings will require extensive work, best approached
> over time, not in a huge wodge.
>
> Best,
> Erick
>
> > On May 11, 2020, at 9:25 AM, Gus Heck  wrote:
> >
> > 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
> auto-solvable (things like redundant initializers for variables that are
> already assigned before use), so the extra work is more than paid for by
> the reduction in transition time. The key one to think carefully about is
> the one that wants to minimize access, which is great for new classes,
> dangerous for released classes. Perhaps turn that warning off in
> intellij...
> >
> > On Mon, May 11, 2020 at 8:14 AM Atri Sharma  wrote:
> > +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 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
> explicitly declare:
> >
> > protected NamedList values = new SimpleOrderedMap<>();
> >
> > but then declare a method:
> >
> > public NamedList getValues() { return values; }
> >
> > This is just bad practice.
> >
> > I don’t mind the grunt work, keeps me from stupid surfing. I’m proposing
> that I fix what’s easy, and suppress the rest.
> >
> > It might have been clearer if I’d said “Then start failing builds on any
> new warnings of these types”.
> >
> > Oh, and I’m also thinking of changing my BadApple report to flag when
> new SuppressWarnings are introduced and then nag people about new ones.
> >
> >
> >
> > > On May 10, 2020, at 11:43 PM, David Smiley 
> wrote:
> > >
> > > 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 <
> erickerick...@gmail.com> wrote:
> > > I’m really struggling with what to do with compiler warnings,
> particularly all the rawtypes and unchecked warnings.
> > >
> > > On the one hand, the simple mechanical thing to do would be to
> SuppressWarnings on each one that exists presently. Frankly that feels
> pretty useless; that would preserve poor code forever.
> > >
> > > OTOH, actually _fixing_ the issues to not have, say, rawtypes is going
> to be time consuming and error-prone. Especially since I don’t really
> understand all the nuances yet and learning them one by one will introduce
> serious errors without doubt.
> > >
> > > So here’s what I propose. Even though it feels useless, just
> SuppressWarnings on anything that’s not a simple fix. Then start failing
> builds on these warnings to catch any that come in in future. At least that
> way there’ll be some incentive to keep the code from getting _worse_,
> although people will still be able to just add SuppressWarnings to the mix
> I suppose.
> > >
> > > The number of raw NamedList member variables we have is overwhelming
> all by itself….
> > >
> > > Comments?
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: 

BadApple report

[Erick Erickson]

Largely ignore the fact that weeks 0 and 1 had so many failures, that was due 
to Jenkins running out of space, which bled over into the week0 report.

This is the first one that reports the number of SuppressWarnings annotations 
that we can use as a baseline. If I start adding SuppressWarnings through the 
code as per my other e-mail, this number will increase drastically over the 
next while, but ignore it for now.

**

SuppressWarnings count: last week: 973, this week: 973, delta 0


Processing file (History bit 3): HOSS-2020-05-11.csv
Processing file (History bit 2): HOSS-2020-05-04.csv
Processing file (History bit 1): HOSS-2020-04-27.csv
Processing file (History bit 0): HOSS-2020-04-20.csv


Number of AwaitsFix: 42 Number of BadApples: 4



Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0  had  102 failures
Week: 1  had  343 failures
Week: 2  had  86 failures
Week: 3  had  78 failures


Failures in Hoss' reports for the last 4 rollups.

There were 484 unannotated tests that failed in Hoss' rollups. Ordered by the 
date I downloaded the rollup file, newest->oldest. See above for the dates the 
files were collected 
These tests were NOT BadApple'd or AwaitsFix'd

Failures in the last 4 reports..
   Report   Pct runsfails   test
 0123   0.5 1566 10  
ConnectionManagerTest.testReconnectWhenZkDisappeared
 0123   0.3 1556 10  ExecutePlanActionTest.testTaskTimeout
 0123   0.8 1360 20  MultiThreadedOCPTest.test
 0123   0.8 1566 10  RollingRestartTest.test
 0123   0.3 1567 11  SearchRateTriggerTest.testWaitForElapsed
 0123   0.5 1557 10  TestCryptoKeys.test
 0123   0.8 1474  8  TestInPlaceUpdatesDistrib.test
 0123   0.3 1582 13  
TestIndexWriterDelete.testDeleteAllNoDeadLock
 0123   0.5 1500 18  TestPackages.testPluginLoading


DO NOT ENABLE LIST:
MoveReplicaHDFSTest.testFailedMove
MoveReplicaHDFSTest.testNormalFailedMove
TestControlledRealTimeReopenThread.testCRTReopen
TestICUNormalizer2CharFilter.testRandomStrings
TestICUTokenizerCJK
TestImpersonationWithHadoopAuth.testForwarding
TestLTRReRankingPipeline.testDifferentTopN
TestRandomChains


DO NOT ANNOTATE LIST
CdcrBidirectionalTest.testBiDir
IndexSizeTriggerTest.testMergeIntegration
IndexSizeTriggerTest.testMixedBounds
IndexSizeTriggerTest.testSplitIntegration
IndexSizeTriggerTest.testTrigger
InfixSuggestersTest.testShutdownDuringBuild
ShardSplitTest.test
ShardSplitTest.testSplitMixedReplicaTypes
ShardSplitTest.testSplitWithChaosMonkey
Test2BPostings.test
TestLatLonShapeQueries.testRandomBig
TestPackedInts.testPackedLongValues
TestRandomChains.testRandomChainsWithLargeStrings
TestTriggerIntegration.testSearchRate

SuppressWarnings count: last week: 973, this week: 973, delta 0


Processing file (History bit 3): HOSS-2020-05-11.csv
Processing file (History bit 2): HOSS-2020-05-04.csv
Processing file (History bit 1): HOSS-2020-04-27.csv
Processing file (History bit 0): HOSS-2020-04-20.csv


Number of AwaitsFix: 42 Number of BadApples: 4


**Annotated tests that didn't fail in the last 4 weeks.

  **Tests removed from the next two lists because they were specified in 
'doNotEnable' in the properties file
 MoveReplicaHDFSTest.testNormalFailedMove

  **Annotations can be removed from the following tests because they haven't 
failed in the last 4 rollups.

  **Methods: 0


Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0  had  102 failures
Week: 1  had  343 failures
Week: 2  had  86 failures
Week: 3  had  78 failures


Failures in Hoss' reports for the last 4 rollups.

There were 484 unannotated tests that failed in Hoss' rollups. Ordered by the 
date I downloaded the rollup file, newest->oldest. See above for the dates the 
files were collected 
These tests were NOT BadApple'd or AwaitsFix'd

Failures in the last 4 reports..
   Report   Pct runsfails   test
 0123   0.5 1566 10  
ConnectionManagerTest.testReconnectWhenZkDisappeared
 0123   0.3 1556 10  ExecutePlanActionTest.testTaskTimeout
 0123   0.8 1360 20  MultiThreadedOCPTest.test
 0123   0.8 1566 10  RollingRestartTest.test
 0123   0.3 1567 11  SearchRateTriggerTest.testWaitForElapsed
 0123   0.5 1557 10  TestCryptoKeys.test
 0123   0.8 1474  8  TestInPlaceUpdatesDistrib.test
 0123   0.3 1582 13  
TestIndexWriterDelete.testDeleteAllNoDeadLock
 0123   0.5 1500 18  TestPackages.testPluginLoading


Failures over the last 4 weeks, but not every week. Ordered most-recent first:



 0120.3 1094  3  

Re: Getting warnings out

[Erick Erickson]

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 person to have a hope of thinking 
carefully about all of them, so my strategy is to stop adding to the problem, 
raise awareness when it happens etc. I think to remove the necessity for 
SuppressWarnings will require extensive work, best approached over time, not in 
a huge wodge.

Best,
Erick

> On May 11, 2020, at 9:25 AM, Gus Heck  wrote:
> 
> 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 auto-solvable 
> (things like redundant initializers for variables that are already assigned 
> before use), so the extra work is more than paid for by the reduction in 
> transition time. The key one to think carefully about is the one that wants 
> to minimize access, which is great for new classes, dangerous for released 
> classes. Perhaps turn that warning off in intellij...  
> 
> On Mon, May 11, 2020 at 8:14 AM Atri Sharma  wrote:
> +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 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 explicitly declare:
> 
> protected NamedList values = new SimpleOrderedMap<>();
> 
> but then declare a method:
> 
> public NamedList getValues() { return values; }
> 
> This is just bad practice.
> 
> I don’t mind the grunt work, keeps me from stupid surfing. I’m proposing that 
> I fix what’s easy, and suppress the rest.
> 
> It might have been clearer if I’d said “Then start failing builds on any new 
> warnings of these types”.
> 
> Oh, and I’m also thinking of changing my BadApple report to flag when new 
> SuppressWarnings are introduced and then nag people about new ones.
> 
> 
> 
> > On May 10, 2020, at 11:43 PM, David Smiley  wrote:
> > 
> > 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 do with compiler warnings, particularly 
> > all the rawtypes and unchecked warnings.
> > 
> > On the one hand, the simple mechanical thing to do would be to 
> > SuppressWarnings on each one that exists presently. Frankly that feels 
> > pretty useless; that would preserve poor code forever.
> > 
> > OTOH, actually _fixing_ the issues to not have, say, rawtypes is going to 
> > be time consuming and error-prone. Especially since I don’t really 
> > understand all the nuances yet and learning them one by one will introduce 
> > serious errors without doubt.
> > 
> > So here’s what I propose. Even though it feels useless, just 
> > SuppressWarnings on anything that’s not a simple fix. Then start failing 
> > builds on these warnings to catch any that come in in future. At least that 
> > way there’ll be some incentive to keep the code from getting _worse_, 
> > although people will still be able to just add SuppressWarnings to the mix 
> > I suppose.
> > 
> > The number of raw NamedList member variables we have is overwhelming all by 
> > itself….
> > 
> > Comments?
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> -- 
> Regards,
> 
> Atri
> Apache Concerted
> 
> 
> -- 
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)


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

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Erik Hatcher]

Without reading much or replying to any specific points made on this thread, 
here's my raw thoughts on this age-old topic (finally  coming out of my 
cocoon after taking things in for a bit)

Solr is a search -server- with distributed capabilities, that leverages the 
magic of Lucene underneath.  Solr depends on Lucene, is a consumer of it.  
Lucene is a tight search -library- with little to no external dependencies.  
Their purposes and end-users are different.

I was never really for the grand unification of Lucene and Solr back in the day 
because:

  - Solr's developer experience would be greatly streamlined, faster, cleaner, 
leaner, and focused
  - Having Lucene change when Solr doesni't (yet) adapt to those changes leads 
to confusion and inconsistency, loose wires hanging out of the wall unconnected 
or duct taped together
  - It simply makes sense to keep Lucene versioned and tightly controlled for 
upgrades, various testing configurations varying Lucene versions, within Solr
  - Solr could have a very concerted upgrade effort for Lucene capability 
jumps, with a focused upgrade effort at the changed/improved/added touch points 
just like other dependencies within Solr (like Tika and Jetty)

Those points all kinda say the same thing Solr depends on "lucene.jar" and 
I'm in the camp that thinks Solr and Lucene development, communities, and 
end-users/consumers would all greatly benefit from a fancy new TLP and focused 
community for solr.apache.org  and a tight(er) 
relationship with the Lucene community as an involved and vested consumer.

Erik

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Bram Van Dam]

On 11/05/2020 15:09, Dawid Weiss wrote:
>> Maybe I'm alone in this, but (better) Lucene compatibility is one of the
>> reasons why our company chose Solr over ElasticSearch.
> 
> I fail to see anything supporting superior Lucene
> compatibility of one vs. another.

Yeah you're right. It's since been pointed out to me that ES uses
vanilla Lucene these days. I hope Solr can remain in the same boat, it
would be a shame to fork Lucene and lose the benefits of compatibility.

 - Bram

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

Re: Getting warnings out

[Gus Heck]

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
auto-solvable (things like redundant initializers for variables that are
already assigned before use), so the extra work is more than paid for by
the reduction in transition time. The key one to think carefully about is
the one that wants to minimize access, which is great for new classes,
dangerous for released classes. Perhaps turn that warning off in
intellij...

On Mon, May 11, 2020 at 8:14 AM Atri Sharma  wrote:

> +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 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
>> explicitly declare:
>>
>> protected NamedList values = new SimpleOrderedMap<>();
>>
>> but then declare a method:
>>
>> public NamedList getValues() { return values; }
>>
>> This is just bad practice.
>>
>> I don’t mind the grunt work, keeps me from stupid surfing. I’m proposing
>> that I fix what’s easy, and suppress the rest.
>>
>> It might have been clearer if I’d said “Then start failing builds on any
>> new warnings of these types”.
>>
>> Oh, and I’m also thinking of changing my BadApple report to flag when new
>> SuppressWarnings are introduced and then nag people about new ones.
>>
>>
>>
>> > On May 10, 2020, at 11:43 PM, David Smiley 
>> wrote:
>> >
>> > 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 <
>> erickerick...@gmail.com> wrote:
>> > I’m really struggling with what to do with compiler warnings,
>> particularly all the rawtypes and unchecked warnings.
>> >
>> > On the one hand, the simple mechanical thing to do would be to
>> SuppressWarnings on each one that exists presently. Frankly that feels
>> pretty useless; that would preserve poor code forever.
>> >
>> > OTOH, actually _fixing_ the issues to not have, say, rawtypes is going
>> to be time consuming and error-prone. Especially since I don’t really
>> understand all the nuances yet and learning them one by one will introduce
>> serious errors without doubt.
>> >
>> > So here’s what I propose. Even though it feels useless, just
>> SuppressWarnings on anything that’s not a simple fix. Then start failing
>> builds on these warnings to catch any that come in in future. At least that
>> way there’ll be some incentive to keep the code from getting _worse_,
>> although people will still be able to just add SuppressWarnings to the mix
>> I suppose.
>> >
>> > The number of raw NamedList member variables we have is overwhelming
>> all by itself….
>> >
>> > Comments?
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
> Regards,
>
> Atri
> Apache Concerted
>


-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Dawid Weiss]

> Maybe I'm alone in this, but (better) Lucene compatibility is one of the
> reasons why our company chose Solr over ElasticSearch.

There are a number of Elasticsearch developers working on Lucene core
(or maybe rather Lucene developers working at Elasticsearch?). And
there are Solr developers working on Lucene features which cascade to
Elasticsearch functionality. Both projects follow Lucene snapshots
releases. I fail to see anything supporting superior Lucene
compatibility of one vs. another.

Dawid

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

Re: Getting warnings out

[Atri Sharma]

+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 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
> explicitly declare:
>
> protected NamedList values = new SimpleOrderedMap<>();
>
> but then declare a method:
>
> public NamedList getValues() { return values; }
>
> This is just bad practice.
>
> I don’t mind the grunt work, keeps me from stupid surfing. I’m proposing
> that I fix what’s easy, and suppress the rest.
>
> It might have been clearer if I’d said “Then start failing builds on any
> new warnings of these types”.
>
> Oh, and I’m also thinking of changing my BadApple report to flag when new
> SuppressWarnings are introduced and then nag people about new ones.
>
>
>
> > On May 10, 2020, at 11:43 PM, David Smiley 
> wrote:
> >
> > 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 do with compiler warnings,
> particularly all the rawtypes and unchecked warnings.
> >
> > On the one hand, the simple mechanical thing to do would be to
> SuppressWarnings on each one that exists presently. Frankly that feels
> pretty useless; that would preserve poor code forever.
> >
> > OTOH, actually _fixing_ the issues to not have, say, rawtypes is going
> to be time consuming and error-prone. Especially since I don’t really
> understand all the nuances yet and learning them one by one will introduce
> serious errors without doubt.
> >
> > So here’s what I propose. Even though it feels useless, just
> SuppressWarnings on anything that’s not a simple fix. Then start failing
> builds on these warnings to catch any that come in in future. At least that
> way there’ll be some incentive to keep the code from getting _worse_,
> although people will still be able to just add SuppressWarnings to the mix
> I suppose.
> >
> > The number of raw NamedList member variables we have is overwhelming all
> by itself….
> >
> > Comments?
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Regards,

Atri
Apache Concerted

Re: Getting warnings out

[Erick Erickson]

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 explicitly declare:

protected NamedList values = new SimpleOrderedMap<>();

but then declare a method:

public NamedList getValues() { return values; }

This is just bad practice.

I don’t mind the grunt work, keeps me from stupid surfing. I’m proposing that I 
fix what’s easy, and suppress the rest.

It might have been clearer if I’d said “Then start failing builds on any new 
warnings of these types”.

Oh, and I’m also thinking of changing my BadApple report to flag when new 
SuppressWarnings are introduced and then nag people about new ones.



> On May 10, 2020, at 11:43 PM, David Smiley  wrote:
> 
> 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 do with compiler warnings, particularly 
> all the rawtypes and unchecked warnings.
> 
> On the one hand, the simple mechanical thing to do would be to 
> SuppressWarnings on each one that exists presently. Frankly that feels pretty 
> useless; that would preserve poor code forever.
> 
> OTOH, actually _fixing_ the issues to not have, say, rawtypes is going to be 
> time consuming and error-prone. Especially since I don’t really understand 
> all the nuances yet and learning them one by one will introduce serious 
> errors without doubt.
> 
> So here’s what I propose. Even though it feels useless, just SuppressWarnings 
> on anything that’s not a simple fix. Then start failing builds on these 
> warnings to catch any that come in in future. At least that way there’ll be 
> some incentive to keep the code from getting _worse_, although people will 
> still be able to just add SuppressWarnings to the mix I suppose.
> 
> The number of raw NamedList member variables we have is overwhelming all by 
> itself….
> 
> Comments?
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Simon Willnauer]

On Sun, May 10, 2020 at 3:41 PM Bram Van Dam  wrote:
>
> On 10/05/2020 08:20, David Smiley wrote:
> > An idea just occurred to me that may help make a split nicer for Solr
> > than it is today.  Solr could use a branch of the Lucene project that's
> > used for the Solr project.
>
> Maybe I'm alone in this, but (better) Lucene compatibility is one of the
> reasons why our company chose Solr over ElasticSearch.

I though about this for a while and I do wonder if you could elaborate
on what makes Solr  have a better compatibility with Lucene. That's
certainly something elasticsearch would want to catch up on since it
sounds like a clear benefit for users. Maybe I just misunderstood what
you meant hence couldn't make much sense out of it.

simon

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

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

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Adrien Grand]

On Mon, May 11, 2020 at 1:17 AM Shawn Heisey  wrote:

> I think the presence of Solr in the codebase
> has diluted Lucene's releases, making them come far too quickly.  I
> would bet that without Solr, Lucene would probably be somewhere in 6.x,
> not 8.x.
>

Actually I think that Lucene would be on 8.x without Solr too. We did:
 - 5.0 to drop support for 3.x indices,
 - 6.0 to introduce points and require Java 8+,
 - 7.0 to introduce doc-value iterators and change how norms are encoded,
 - 8.0 for impacts / block-max WAND, which required breaking changes on the
Similarity API.

It would have been challenging to expose these changes with fewer major
releases without significantly delaying some very appealing features, which
has downsides too.

-- 
Adrien