Here it is.
gt;>>> tremendous
>>>>> time and effort in order to improve the project in a pretty thankless
>>>> way.
>>>>>
>>>>> Anyways happy to entertain further discussion on the topic, but I think
>>>> the
>>>>>
;>
> >>> On Sat, Jul 30, 2022 at 4:38 PM Ishan Chattopadhyaya <
> >>> ichattopadhy...@gmail.com> wrote:
> >>>
> >>>>> I ask that you please suspend sweeping changes because they are a
> real
> >>>> impediment to o
at you please suspend sweeping changes because they are a real
>>>> impediment to other branches/PRs that move lots of files. This is
>>>> happening right now: https://github.com/apache/solr/pull/943 (for
>> SolrJ)
>>>>
>>>> +1, I don't feel the
)
> <
> >> cpoersc...@bloomberg.net> wrote:
> >>
> >>> PR 916 was a subset of PR 912 and I've just resolved its conflicts.
> >>>
> >>> Also https://issues.apache.org/jira/browse/SOLR-16318 started, in case
> >>> that helps.
&g
t> wrote:
>>
>>> PR 916 was a subset of PR 912 and I've just resolved its conflicts.
>>>
>>> Also https://issues.apache.org/jira/browse/SOLR-16318 started, in case
>>> that helps.
>>>
>>> Christine
>>>
>>> From: dev
om: dev@solr.apache.org At: 07/26/22 15:10:03 UTC+1:00To:
> > dev@solr.apache.org
> > Subject: Re: Cleaning up IntelliJ warnings in code base
> >
> > Not sure about https://github.com/apache/solr/pull/916 but
> > https://github.com/apache/solr/pull/912 conflicts in a ton
gt; Christine
>
> From: dev@solr.apache.org At: 07/26/22 15:10:03 UTC+1:00To:
> dev@solr.apache.org
> Subject: Re: Cleaning up IntelliJ warnings in code base
>
> Not sure about https://github.com/apache/solr/pull/916 but
> https://github.com/apache/solr/pull/912 conflicts in
PR 916 was a subset of PR 912 and I've just resolved its conflicts.
Also https://issues.apache.org/jira/browse/SOLR-16318 started, in case that
helps.
Christine
From: dev@solr.apache.org At: 07/26/22 15:10:03 UTC+1:00To: dev@solr.apache.org
Subject: Re: Cleaning up IntelliJ warnings in code
Sure!
I wonder if there is a better way to organize these types of changes in the
future…..? I would love to get the rest of the warnings dealt with at some
point.
Eric
> On Jul 26, 2022, at 2:34 PM, David Smiley wrote:
>
> I ask that you please suspend sweeping changes because they
Not sure about https://github.com/apache/solr/pull/916 but
https://github.com/apache/solr/pull/912 conflicts in a ton of places and
haven't looked at updating it.
Kevin Risden
On Tue, Jul 26, 2022 at 9:51 AM Eric Pugh
wrote:
> Hi all…. Are there any updates to the two PR’s related to WIP
While sitting in the car from Virginia to Missouri I have been fixing up
typos and grammar.
https://github.com/apache/solr/pull/900
Tomorrow on the way to Kansas I will finish up the last few tests.
I would love to get some review my thought is if any of the changes I
made don’t seem
Thanks Mike for fixing my backport issue……
So, I’ve wended my way through 84 files focusing on grammar and typos:
https://github.com/apache/solr/pull/900
One thing I wanted to highlight, the AffinityPlacementFactory.java
Okay, I merged the other day….
Firstly, in terms of a workflow, I looked at the Solr-NightlyTests-main Jenkins
test, and in fact the one that ran after my commit has two tests that failed
that look like normal build failures…. Versus what I committed:
+1 to "Squash and Merge"
On Wed, Jun 1, 2022 at 10:00 AM Houston Putman wrote:
> 100%, in my opinion
>
> On Wed, Jun 1, 2022 at 8:11 AM Eric Pugh
> wrote:
>
>> One last question…. “Squash and Merge” right? We don’t care about all
>> my interim commits….
>>
>>
>> On May 31, 2022, at 6:37 PM,
100%, in my opinion
On Wed, Jun 1, 2022 at 8:11 AM Eric Pugh
wrote:
> One last question…. “Squash and Merge” right? We don’t care about all my
> interim commits….
>
>
> On May 31, 2022, at 6:37 PM, Eric Pugh
> wrote:
>
> Cool.
>
> So here is an example of what I’ll merge in a day or so:
>
One last question…. “Squash and Merge” right? We don’t care about all my
interim commits….
> On May 31, 2022, at 6:37 PM, Eric Pugh
> wrote:
>
> Cool.
>
> So here is an example of what I’ll merge in a day or so:
> https://github.com/apache/solr/pull/885
>
Cool.
So here is an example of what I’ll merge in a day or so:
https://github.com/apache/solr/pull/885
And I’m going to start on a new PR for
https://issues.apache.org/jira/browse/SOLR-16224 that is about looking at how
fields are defined in the tests.
> On May 31, 2022, at 12:41 PM,
>
> What about back porting, would you want these back ported to 8 and 9? Or
> just 9?
>
I would say just main and branch_9x
On Tue, May 31, 2022 at 12:39 PM Eric Pugh
wrote:
> Thanks for the response Mike…
>
> So I finished up going through the test code, and yeah, wow…. Doing it
> one
Thanks for the response Mike…
So I finished up going through the test code, and yeah, wow…. Doing it one
file at a time was educational at least ;-).
https://github.com/apache/solr/compare/main...epugh:intellij_inspired_cleanups?expand=1
In terms of a workflow, should I open up a single JIRA
Declaring an unused thrown exception in tests isn't the most critical
change, but cleaning this up might help us discover accidental API
signature changes in the future. If a test throws an exception then JUnit
will figure it out and fail the test anyway, which is probably what we want
to do
So, going through and cleaning up unused throwing of exceptions, I’ve touched
all these files listed below. I was thinking I would do ONE commit for all of
the “remove unused Exception”…. Before I keep going, wanted to make sure that
makes sense…..
modified:
IntelliJ is produced by a company and I have no idea how they go about
selecting what the default inspections (what IntelliJ calls these) are.
Maybe it was one person there, maybe it was arbitrary by whoever wrote
the inspection, or maybe they had some more thoughtful approach that looked
at
On 5/27/2022 8:24 AM, Eric Pugh wrote:
Hey all, was poking around at a unit test while watching TV and
noticed lots of warnings from IntelliJ, little stuff like exceptions
being thrown that don’t need to be thrown, unused variables, or typos.
In eclipse, there are THOUSANDS of warnings. And
Yeah I'm certainly for cleaning up warnings, but I agree it should be in
small chunks, and considered. In some cases "cleanup" will be
//noinspection or @SuppressWarnings...
Getting to a green check mark is quite beneficial, making it easier to
notice when you've added something that's (possibly)
I have a vague recollection of having seen intellij warnings that
really _shouldn't_ be "fixed". Unfortunately I'm not sure I'll be able
to recall exactly what, but I thought I'd mention it as a word of
caution, and in case it spurs anyone else's curiosity. Splitting any
such PRs up by warning
Also, I guess I need to be careful to run spotless after I make changes to the
tests per package.
> On May 27, 2022, at 10:58 AM, Eric Pugh
> wrote:
>
> Here is what I did the other night:
>
> https://github.com/apache/solr/compare/main...epugh:intellij_suggested_fixes
>
Here is what I did the other night:
https://github.com/apache/solr/compare/main...epugh:intellij_suggested_fixes
I could just work on package by package, pushing them up, and if there is
debate, I can just revert a commit on a package by package basis??
Thoughts?
Eric
> On May 27, 2022, at
I would try to handle them in several small PRs either grouped by module or
by warning type.
On Fri, May 27, 2022 at 9:24 AM Eric Pugh
wrote:
> Hey all, was poking around at a unit test while watching TV and noticed
> lots of warnings from IntelliJ, little stuff like exceptions being thrown
>
Hey all, was poking around at a unit test while watching TV and noticed lots of
warnings from IntelliJ, little stuff like exceptions being thrown that don’t
need to be thrown, unused variables, or typos.
I was thinking about going through and fixing those, just to get the long list
of
30 matches
Mail list logo
