Mailing List Archive

Revisiting Standardized Test Names in Solr
Hi all,

Now that Lucene’s standardization is complete and I believe enforced,
should we discuss if we could bring the same consistency to Solr?

Best,

Marcus
--
Marcus Eagan
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
Makes sense to me.


> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>
> Hi all,
>
> Now that Lucene’s standardization is complete and I believe enforced, should we discuss if we could bring the same consistency to Solr?
>
> Best,
>
> Marcus
> --
> Marcus Eagan
>

_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
FWIW, I'm not really in favor of the convention Lucene adopted. I probably
lost track of the debate and failed to object which is on me, but I guess
it was because that was the lower number of changes there? It's
certainly much less legible in the IDE to have a wall of classes all
starting with T. Maybe given that the projects are splitting Solr can Stick
with FooTest not TestFoo? I think *Test suffix is more common in Solr...
(though I haven't attempted to quantify it)

On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <epugh@opensourceconnections.com>
wrote:

> Makes sense to me.
>
>
> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>
> Hi all,
>
> Now that Lucene’s standardization is complete and I believe enforced,
> should we discuss if we could bring the same consistency to Solr?
>
> Best,
>
> Marcus
> --
> Marcus Eagan
>
>
> _______________________
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
I look forward to a standardization on *something* but would prefer that we
not make a sweeping change like this until after Mark's "ref branch" is
reconciled. I don't want that to hang over the project indefinitely, but
we can wait; we've not had this standardization yet for many years, after
all.

That said, it would be good to choose the standard name now so that there
is less to change later. Can someone dig up the statistics on Solr's name
choice to see if there is a clear winner (e.g. >60%)? I don't have a
strong opinion on whatever the standard should be so long as there is a
standard :-)


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


On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <gus.heck@gmail.com> wrote:

> FWIW, I'm not really in favor of the convention Lucene adopted. I probably
> lost track of the debate and failed to object which is on me, but I guess
> it was because that was the lower number of changes there? It's
> certainly much less legible in the IDE to have a wall of classes all
> starting with T. Maybe given that the projects are splitting Solr can Stick
> with FooTest not TestFoo? I think *Test suffix is more common in Solr...
> (though I haven't attempted to quantify it)
>
> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <
> epugh@opensourceconnections.com> wrote:
>
>> Makes sense to me.
>>
>>
>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>>
>> Hi all,
>>
>> Now that Lucene’s standardization is complete and I believe enforced,
>> should we discuss if we could bring the same consistency to Solr?
>>
>> Best,
>>
>> Marcus
>> --
>> Marcus Eagan
>>
>>
>> _______________________
>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>> | http://www.opensourceconnections.com | My Free/Busy
>> <http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> This e-mail and all contents, including attachments, is considered to be
>> Company Confidential unless explicitly stated otherwise, regardless
>> of whether attachments are marked as such.
>>
>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
I'm fine with standardization, whichever convention we choose. I have
a slight preference for FooTest, for the same reason Gus mentioned,
but any standard is better than none here IMO.

> prefer that we not make a sweeping change like this until after Mark's "ref branch" is reconciled

Personally I disagree about the need to wait. It'd be one thing if
there was an agreed-upon plan or a timeframe for merging "ref-branch".
But since that's not the case today, I don't think it makes sense to
ignore concrete/mergeable improvements. It seems like a "bird in the
hand vs two in the bush" situation. Especially when there are
strategies for handling the conflicts that might arise with Mark's
"ref-branch" (e.g. do the test renames on both master and ref_impl).

Jason

On Sun, Feb 21, 2021 at 12:44 PM David Smiley <dsmiley@apache.org> wrote:
>
> I look forward to a standardization on *something* but would prefer that we not make a sweeping change like this until after Mark's "ref branch" is reconciled. I don't want that to hang over the project indefinitely, but we can wait; we've not had this standardization yet for many years, after all.
>
> That said, it would be good to choose the standard name now so that there is less to change later. Can someone dig up the statistics on Solr's name choice to see if there is a clear winner (e.g. >60%)? I don't have a strong opinion on whatever the standard should be so long as there is a standard :-)
>
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <gus.heck@gmail.com> wrote:
>>
>> FWIW, I'm not really in favor of the convention Lucene adopted. I probably lost track of the debate and failed to object which is on me, but I guess it was because that was the lower number of changes there? It's certainly much less legible in the IDE to have a wall of classes all starting with T. Maybe given that the projects are splitting Solr can Stick with FooTest not TestFoo? I think *Test suffix is more common in Solr... (though I haven't attempted to quantify it)
>>
>> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <epugh@opensourceconnections.com> wrote:
>>>
>>> Makes sense to me.
>>>
>>>
>>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> Now that Lucene’s standardization is complete and I believe enforced, should we discuss if we could bring the same consistency to Solr?
>>>
>>> Best,
>>>
>>> Marcus
>>> --
>>> Marcus Eagan
>>>
>>>
>>> _______________________
>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
There are already so many conflicts, you will cry and then realize there
are more. Even worse, some things have been changed due to their
cost/benefit failings, things that someone, somewhere, will cling to like a
life vest.

The ref branch waits for no man, and expects the same.

It lives on ridiculous speed and stability and throws mergability to the
crows.

It could not be merged into anything and survive, but it can absorb
anything, as long as it behaves like a boss or can be jostled into doing
so. So fear not for the fearless. You can’t let a specter freeze the
tireless day to day shifting and shuffling of names and rules and
locations. I swear, enough lucky shifts and this thing can rise to meet the
living. I’ve seen it see dead people.

End of the day, if the ref branch can’t survive even a large and lengthy
divergence, if that is the freeze in its tracks, it’s not at all what I’ve
said ive been working on and so does it even matter?


On Mon, Feb 22, 2021 at 9:39 AM Jason Gerlowski <gerlowskija@gmail.com>
wrote:

> I'm fine with standardization, whichever convention we choose. I have
> a slight preference for FooTest, for the same reason Gus mentioned,
> but any standard is better than none here IMO.
>
> > prefer that we not make a sweeping change like this until after Mark's
> "ref branch" is reconciled
>
> Personally I disagree about the need to wait. It'd be one thing if
> there was an agreed-upon plan or a timeframe for merging "ref-branch".
> But since that's not the case today, I don't think it makes sense to
> ignore concrete/mergeable improvements. It seems like a "bird in the
> hand vs two in the bush" situation. Especially when there are
> strategies for handling the conflicts that might arise with Mark's
> "ref-branch" (e.g. do the test renames on both master and ref_impl).
>
> Jason
>
> On Sun, Feb 21, 2021 at 12:44 PM David Smiley <dsmiley@apache.org> wrote:
> >
> > I look forward to a standardization on *something* but would prefer that
> we not make a sweeping change like this until after Mark's "ref branch" is
> reconciled. I don't want that to hang over the project indefinitely, but
> we can wait; we've not had this standardization yet for many years, after
> all.
> >
> > That said, it would be good to choose the standard name now so that
> there is less to change later. Can someone dig up the statistics on Solr's
> name choice to see if there is a clear winner (e.g. >60%)? I don't have a
> strong opinion on whatever the standard should be so long as there is a
> standard :-)
> >
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <gus.heck@gmail.com> wrote:
> >>
> >> FWIW, I'm not really in favor of the convention Lucene adopted. I
> probably lost track of the debate and failed to object which is on me, but
> I guess it was because that was the lower number of changes there? It's
> certainly much less legible in the IDE to have a wall of classes all
> starting with T. Maybe given that the projects are splitting Solr can Stick
> with FooTest not TestFoo? I think *Test suffix is more common in Solr...
> (though I haven't attempted to quantify it)
> >>
> >> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <
> epugh@opensourceconnections.com> wrote:
> >>>
> >>> Makes sense to me.
> >>>
> >>>
> >>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com>
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> Now that Lucene’s standardization is complete and I believe enforced,
> should we discuss if we could bring the same consistency to Solr?
> >>>
> >>> Best,
> >>>
> >>> Marcus
> >>> --
> >>> Marcus Eagan
> >>>
> >>>
> >>> _______________________
> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> >>> This e-mail and all contents, including attachments, is considered to
> be Company Confidential unless explicitly stated otherwise, regardless of
> whether attachments are marked as such.
> >>>
> >>
> >>
> >> --
> >> http://www.needhamsoftware.com (work)
> >> http://www.the111shift.com (play)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
- Mark

http://about.me/markrmiller
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
I hope that doesn’t sound too negative, “clinging” never sounds as positive
as I’d like and I do negative plenty well without doing it by accident. Not
a pessimistic statement though, I made it even better than I was planning
or remembering I could or however that works. Resistance is built into the
equation - this isn’t rock and roll, I’m a science bachelor. Though only a
small few liberal arts classes made me go, so I wouldn’t trust the cert
myself. Anyway, I learned from multiple Star Wars movies what to do here,
you have to setup an ambush on the trench run and then just make the thing
look like a huge black star.

On Fri, Feb 26, 2021 at 4:38 AM Mark Miller <markrmiller@gmail.com> wrote:

> There are already so many conflicts, you will cry and then realize there
> are more. Even worse, some things have been changed due to their
> cost/benefit failings, things that someone, somewhere, will cling to like a
> life vest.
>
> The ref branch waits for no man, and expects the same.
>
> It lives on ridiculous speed and stability and throws mergability to the
> crows.
>
> It could not be merged into anything and survive, but it can absorb
> anything, as long as it behaves like a boss or can be jostled into doing
> so. So fear not for the fearless. You can’t let a specter freeze the
> tireless day to day shifting and shuffling of names and rules and
> locations. I swear, enough lucky shifts and this thing can rise to meet the
> living. I’ve seen it see dead people.
>
> End of the day, if the ref branch can’t survive even a large and lengthy
> divergence, if that is the freeze in its tracks, it’s not at all what I’ve
> said ive been working on and so does it even matter?
>
>
> On Mon, Feb 22, 2021 at 9:39 AM Jason Gerlowski <gerlowskija@gmail.com>
> wrote:
>
>> I'm fine with standardization, whichever convention we choose. I have
>> a slight preference for FooTest, for the same reason Gus mentioned,
>> but any standard is better than none here IMO.
>>
>> > prefer that we not make a sweeping change like this until after Mark's
>> "ref branch" is reconciled
>>
>> Personally I disagree about the need to wait. It'd be one thing if
>> there was an agreed-upon plan or a timeframe for merging "ref-branch".
>> But since that's not the case today, I don't think it makes sense to
>> ignore concrete/mergeable improvements. It seems like a "bird in the
>> hand vs two in the bush" situation. Especially when there are
>> strategies for handling the conflicts that might arise with Mark's
>> "ref-branch" (e.g. do the test renames on both master and ref_impl).
>>
>> Jason
>>
>> On Sun, Feb 21, 2021 at 12:44 PM David Smiley <dsmiley@apache.org> wrote:
>> >
>> > I look forward to a standardization on *something* but would prefer
>> that we not make a sweeping change like this until after Mark's "ref
>> branch" is reconciled. I don't want that to hang over the project
>> indefinitely, but we can wait; we've not had this standardization yet for
>> many years, after all.
>> >
>> > That said, it would be good to choose the standard name now so that
>> there is less to change later. Can someone dig up the statistics on Solr's
>> name choice to see if there is a clear winner (e.g. >60%)? I don't have a
>> strong opinion on whatever the standard should be so long as there is a
>> standard :-)
>> >
>> >
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley
>> >
>> >
>> > On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <gus.heck@gmail.com> wrote:
>> >>
>> >> FWIW, I'm not really in favor of the convention Lucene adopted. I
>> probably lost track of the debate and failed to object which is on me, but
>> I guess it was because that was the lower number of changes there? It's
>> certainly much less legible in the IDE to have a wall of classes all
>> starting with T. Maybe given that the projects are splitting Solr can Stick
>> with FooTest not TestFoo? I think *Test suffix is more common in Solr...
>> (though I haven't attempted to quantify it)
>> >>
>> >> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <
>> epugh@opensourceconnections.com> wrote:
>> >>>
>> >>> Makes sense to me.
>> >>>
>> >>>
>> >>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com>
>> wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>> Now that Lucene’s standardization is complete and I believe enforced,
>> should we discuss if we could bring the same consistency to Solr?
>> >>>
>> >>> Best,
>> >>>
>> >>> Marcus
>> >>> --
>> >>> Marcus Eagan
>> >>>
>> >>>
>> >>> _______________________
>> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> >>> This e-mail and all contents, including attachments, is considered to
>> be Company Confidential unless explicitly stated otherwise, regardless of
>> whether attachments are marked as such.
>> >>>
>> >>
>> >>
>> >> --
>> >> http://www.needhamsoftware.com (work)
>> >> http://www.the111shift.com (play)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> --
> - Mark
>
> http://about.me/markrmiller
>
--
- Mark

http://about.me/markrmiller
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
> I hope that doesn’t sound too negative

Not to me. But I'm a little confused what your ultimate stand is on
these renames Marcus is proposing. I'm hearing different messages in
different sections of your email.

> There are already so many conflicts, you will cry and then realize there are more.

Sounds very much like you're saying that the test renames will cause
really painful merge-conflicts, and that renames should wait because
of the pain involved in reconciling ref_impl.

But...

> You can’t let a specter freeze the tireless day to day shifting and shuffling of names and rules and locations.

Sounds like you're saying that we shouldn't let fear of ref_impl
complications stop us from doing renames, file-moves, etc.

Sorry if I'm just being daft, but can you clarify please? Are you
saying that we should avoid big changes because of the ugly merges
with ref_impl? Or that we shouldn't let fear of ref_impl
complications stop us from anything on master? Or something else
altogether?

Best,

Jason

On Fri, Feb 26, 2021 at 7:50 AM Mark Miller <markrmiller@gmail.com> wrote:
>
> I hope that doesn’t sound too negative, “clinging” never sounds as positive as I’d like and I do negative plenty well without doing it by accident. Not a pessimistic statement though, I made it even better than I was planning or remembering I could or however that works. Resistance is built into the equation - this isn’t rock and roll, I’m a science bachelor. Though only a small few liberal arts classes made me go, so I wouldn’t trust the cert myself. Anyway, I learned from multiple Star Wars movies what to do here, you have to setup an ambush on the trench run and then just make the thing look like a huge black star.
>
> On Fri, Feb 26, 2021 at 4:38 AM Mark Miller <markrmiller@gmail.com> wrote:
>>
>> There are already so many conflicts, you will cry and then realize there are more. Even worse, some things have been changed due to their cost/benefit failings, things that someone, somewhere, will cling to like a life vest.
>>
>> The ref branch waits for no man, and expects the same.
>>
>> It lives on ridiculous speed and stability and throws mergability to the crows.
>>
>> It could not be merged into anything and survive, but it can absorb anything, as long as it behaves like a boss or can be jostled into doing so. So fear not for the fearless. You can’t let a specter freeze the tireless day to day shifting and shuffling of names and rules and locations. I swear, enough lucky shifts and this thing can rise to meet the living. I’ve seen it see dead people.
>>
>> End of the day, if the ref branch can’t survive even a large and lengthy divergence, if that is the freeze in its tracks, it’s not at all what I’ve said ive been working on and so does it even matter?
>>
>>
>> On Mon, Feb 22, 2021 at 9:39 AM Jason Gerlowski <gerlowskija@gmail.com> wrote:
>>>
>>> I'm fine with standardization, whichever convention we choose. I have
>>> a slight preference for FooTest, for the same reason Gus mentioned,
>>> but any standard is better than none here IMO.
>>>
>>> > prefer that we not make a sweeping change like this until after Mark's "ref branch" is reconciled
>>>
>>> Personally I disagree about the need to wait. It'd be one thing if
>>> there was an agreed-upon plan or a timeframe for merging "ref-branch".
>>> But since that's not the case today, I don't think it makes sense to
>>> ignore concrete/mergeable improvements. It seems like a "bird in the
>>> hand vs two in the bush" situation. Especially when there are
>>> strategies for handling the conflicts that might arise with Mark's
>>> "ref-branch" (e.g. do the test renames on both master and ref_impl).
>>>
>>> Jason
>>>
>>> On Sun, Feb 21, 2021 at 12:44 PM David Smiley <dsmiley@apache.org> wrote:
>>> >
>>> > I look forward to a standardization on *something* but would prefer that we not make a sweeping change like this until after Mark's "ref branch" is reconciled. I don't want that to hang over the project indefinitely, but we can wait; we've not had this standardization yet for many years, after all.
>>> >
>>> > That said, it would be good to choose the standard name now so that there is less to change later. Can someone dig up the statistics on Solr's name choice to see if there is a clear winner (e.g. >60%)? I don't have a strong opinion on whatever the standard should be so long as there is a standard :-)
>>> >
>>> >
>>> > ~ David Smiley
>>> > Apache Lucene/Solr Search Developer
>>> > http://www.linkedin.com/in/davidwsmiley
>>> >
>>> >
>>> > On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <gus.heck@gmail.com> wrote:
>>> >>
>>> >> FWIW, I'm not really in favor of the convention Lucene adopted. I probably lost track of the debate and failed to object which is on me, but I guess it was because that was the lower number of changes there? It's certainly much less legible in the IDE to have a wall of classes all starting with T. Maybe given that the projects are splitting Solr can Stick with FooTest not TestFoo? I think *Test suffix is more common in Solr... (though I haven't attempted to quantify it)
>>> >>
>>> >> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <epugh@opensourceconnections.com> wrote:
>>> >>>
>>> >>> Makes sense to me.
>>> >>>
>>> >>>
>>> >>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>>> >>>
>>> >>> Hi all,
>>> >>>
>>> >>> Now that Lucene’s standardization is complete and I believe enforced, should we discuss if we could bring the same consistency to Solr?
>>> >>>
>>> >>> Best,
>>> >>>
>>> >>> Marcus
>>> >>> --
>>> >>> Marcus Eagan
>>> >>>
>>> >>>
>>> >>> _______________________
>>> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> >>> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> http://www.needhamsoftware.com (work)
>>> >> http://www.the111shift.com (play)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>
> --
> - Mark
>
> http://about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
Mark 2.0 speaks in riddles, which I'm not great at interpreting.... but I
think you're implying that the so-called "ref-branch" is not going to be
merged into anything, which is depressing because I now care much less
about that branch. Markus, Jason -- lets get the standardization on with!

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


On Fri, Feb 26, 2021 at 7:50 AM Mark Miller <markrmiller@gmail.com> wrote:

> I hope that doesn’t sound too negative, “clinging” never sounds as
> positive as I’d like and I do negative plenty well without doing it by
> accident. Not a pessimistic statement though, I made it even better than I
> was planning or remembering I could or however that works. Resistance is
> built into the equation - this isn’t rock and roll, I’m a science bachelor.
> Though only a small few liberal arts classes made me go, so I wouldn’t
> trust the cert myself. Anyway, I learned from multiple Star Wars movies
> what to do here, you have to setup an ambush on the trench run and then
> just make the thing look like a huge black star.
>
> On Fri, Feb 26, 2021 at 4:38 AM Mark Miller <markrmiller@gmail.com> wrote:
>
>> There are already so many conflicts, you will cry and then realize there
>> are more. Even worse, some things have been changed due to their
>> cost/benefit failings, things that someone, somewhere, will cling to like a
>> life vest.
>>
>> The ref branch waits for no man, and expects the same.
>>
>> It lives on ridiculous speed and stability and throws mergability to the
>> crows.
>>
>> It could not be merged into anything and survive, but it can absorb
>> anything, as long as it behaves like a boss or can be jostled into doing
>> so. So fear not for the fearless. You can’t let a specter freeze the
>> tireless day to day shifting and shuffling of names and rules and
>> locations. I swear, enough lucky shifts and this thing can rise to meet the
>> living. I’ve seen it see dead people.
>>
>> End of the day, if the ref branch can’t survive even a large and lengthy
>> divergence, if that is the freeze in its tracks, it’s not at all what I’ve
>> said ive been working on and so does it even matter?
>>
>>
>> On Mon, Feb 22, 2021 at 9:39 AM Jason Gerlowski <gerlowskija@gmail.com>
>> wrote:
>>
>>> I'm fine with standardization, whichever convention we choose. I have
>>> a slight preference for FooTest, for the same reason Gus mentioned,
>>> but any standard is better than none here IMO.
>>>
>>> > prefer that we not make a sweeping change like this until after Mark's
>>> "ref branch" is reconciled
>>>
>>> Personally I disagree about the need to wait. It'd be one thing if
>>> there was an agreed-upon plan or a timeframe for merging "ref-branch".
>>> But since that's not the case today, I don't think it makes sense to
>>> ignore concrete/mergeable improvements. It seems like a "bird in the
>>> hand vs two in the bush" situation. Especially when there are
>>> strategies for handling the conflicts that might arise with Mark's
>>> "ref-branch" (e.g. do the test renames on both master and ref_impl).
>>>
>>> Jason
>>>
>>> On Sun, Feb 21, 2021 at 12:44 PM David Smiley <dsmiley@apache.org>
>>> wrote:
>>> >
>>> > I look forward to a standardization on *something* but would prefer
>>> that we not make a sweeping change like this until after Mark's "ref
>>> branch" is reconciled. I don't want that to hang over the project
>>> indefinitely, but we can wait; we've not had this standardization yet for
>>> many years, after all.
>>> >
>>> > That said, it would be good to choose the standard name now so that
>>> there is less to change later. Can someone dig up the statistics on Solr's
>>> name choice to see if there is a clear winner (e.g. >60%)? I don't have a
>>> strong opinion on whatever the standard should be so long as there is a
>>> standard :-)
>>> >
>>> >
>>> > ~ David Smiley
>>> > Apache Lucene/Solr Search Developer
>>> > http://www.linkedin.com/in/davidwsmiley
>>> >
>>> >
>>> > On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <gus.heck@gmail.com> wrote:
>>> >>
>>> >> FWIW, I'm not really in favor of the convention Lucene adopted. I
>>> probably lost track of the debate and failed to object which is on me, but
>>> I guess it was because that was the lower number of changes there? It's
>>> certainly much less legible in the IDE to have a wall of classes all
>>> starting with T. Maybe given that the projects are splitting Solr can Stick
>>> with FooTest not TestFoo? I think *Test suffix is more common in Solr...
>>> (though I haven't attempted to quantify it)
>>> >>
>>> >> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <
>>> epugh@opensourceconnections.com> wrote:
>>> >>>
>>> >>> Makes sense to me.
>>> >>>
>>> >>>
>>> >>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com>
>>> wrote:
>>> >>>
>>> >>> Hi all,
>>> >>>
>>> >>> Now that Lucene’s standardization is complete and I believe
>>> enforced, should we discuss if we could bring the same consistency to Solr?
>>> >>>
>>> >>> Best,
>>> >>>
>>> >>> Marcus
>>> >>> --
>>> >>> Marcus Eagan
>>> >>>
>>> >>>
>>> >>> _______________________
>>> >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>>> 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> >>> This e-mail and all contents, including attachments, is considered
>>> to be Company Confidential unless explicitly stated otherwise, regardless
>>> of whether attachments are marked as such.
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> http://www.needhamsoftware.com (work)
>>> >> http://www.the111shift.com (play)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
> --
> - Mark
>
> http://about.me/markrmiller
>
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
I interpreted Mark as saying, we should forge ahead with the things like standardizing test names, and when the reference branch is ready, we tackle it.

Having read most of the individual commits, all 1405 and counting, I think that bringing this code base in is going to be a major effort, and really isn’t going to be easy to bring in bit by bit. The changes are to everything, and I think unwinding the changes into “chunks” is going to be even more herculean…. The changes touch everything, and honestly, since it’s all about restoring speed and paying down accumulated tech debt, I totally get why it’s so intrusive. It’s a revolutionary change, not an evolutionary one.



> On Feb 26, 2021, at 8:26 AM, Jason Gerlowski <gerlowskija@gmail.com> wrote:
>
>> I hope that doesn’t sound too negative
>
> Not to me. But I'm a little confused what your ultimate stand is on
> these renames Marcus is proposing. I'm hearing different messages in
> different sections of your email.
>
>> There are already so many conflicts, you will cry and then realize there are more.
>
> Sounds very much like you're saying that the test renames will cause
> really painful merge-conflicts, and that renames should wait because
> of the pain involved in reconciling ref_impl.
>
> But...
>
>> You can’t let a specter freeze the tireless day to day shifting and shuffling of names and rules and locations.
>
> Sounds like you're saying that we shouldn't let fear of ref_impl
> complications stop us from doing renames, file-moves, etc.
>
> Sorry if I'm just being daft, but can you clarify please? Are you
> saying that we should avoid big changes because of the ugly merges
> with ref_impl? Or that we shouldn't let fear of ref_impl
> complications stop us from anything on master? Or something else
> altogether?
>
> Best,
>
> Jason
>
> On Fri, Feb 26, 2021 at 7:50 AM Mark Miller <markrmiller@gmail.com> wrote:
>>
>> I hope that doesn’t sound too negative, “clinging” never sounds as positive as I’d like and I do negative plenty well without doing it by accident. Not a pessimistic statement though, I made it even better than I was planning or remembering I could or however that works. Resistance is built into the equation - this isn’t rock and roll, I’m a science bachelor. Though only a small few liberal arts classes made me go, so I wouldn’t trust the cert myself. Anyway, I learned from multiple Star Wars movies what to do here, you have to setup an ambush on the trench run and then just make the thing look like a huge black star.
>>
>> On Fri, Feb 26, 2021 at 4:38 AM Mark Miller <markrmiller@gmail.com> wrote:
>>>
>>> There are already so many conflicts, you will cry and then realize there are more. Even worse, some things have been changed due to their cost/benefit failings, things that someone, somewhere, will cling to like a life vest.
>>>
>>> The ref branch waits for no man, and expects the same.
>>>
>>> It lives on ridiculous speed and stability and throws mergability to the crows.
>>>
>>> It could not be merged into anything and survive, but it can absorb anything, as long as it behaves like a boss or can be jostled into doing so. So fear not for the fearless. You can’t let a specter freeze the tireless day to day shifting and shuffling of names and rules and locations. I swear, enough lucky shifts and this thing can rise to meet the living. I’ve seen it see dead people.
>>>
>>> End of the day, if the ref branch can’t survive even a large and lengthy divergence, if that is the freeze in its tracks, it’s not at all what I’ve said ive been working on and so does it even matter?
>>>
>>>
>>> On Mon, Feb 22, 2021 at 9:39 AM Jason Gerlowski <gerlowskija@gmail.com> wrote:
>>>>
>>>> I'm fine with standardization, whichever convention we choose. I have
>>>> a slight preference for FooTest, for the same reason Gus mentioned,
>>>> but any standard is better than none here IMO.
>>>>
>>>>> prefer that we not make a sweeping change like this until after Mark's "ref branch" is reconciled
>>>>
>>>> Personally I disagree about the need to wait. It'd be one thing if
>>>> there was an agreed-upon plan or a timeframe for merging "ref-branch".
>>>> But since that's not the case today, I don't think it makes sense to
>>>> ignore concrete/mergeable improvements. It seems like a "bird in the
>>>> hand vs two in the bush" situation. Especially when there are
>>>> strategies for handling the conflicts that might arise with Mark's
>>>> "ref-branch" (e.g. do the test renames on both master and ref_impl).
>>>>
>>>> Jason
>>>>
>>>> On Sun, Feb 21, 2021 at 12:44 PM David Smiley <dsmiley@apache.org> wrote:
>>>>>
>>>>> I look forward to a standardization on *something* but would prefer that we not make a sweeping change like this until after Mark's "ref branch" is reconciled. I don't want that to hang over the project indefinitely, but we can wait; we've not had this standardization yet for many years, after all.
>>>>>
>>>>> That said, it would be good to choose the standard name now so that there is less to change later. Can someone dig up the statistics on Solr's name choice to see if there is a clear winner (e.g. >60%)? I don't have a strong opinion on whatever the standard should be so long as there is a standard :-)
>>>>>
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <gus.heck@gmail.com> wrote:
>>>>>>
>>>>>> FWIW, I'm not really in favor of the convention Lucene adopted. I probably lost track of the debate and failed to object which is on me, but I guess it was because that was the lower number of changes there? It's certainly much less legible in the IDE to have a wall of classes all starting with T. Maybe given that the projects are splitting Solr can Stick with FooTest not TestFoo? I think *Test suffix is more common in Solr... (though I haven't attempted to quantify it)
>>>>>>
>>>>>> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <epugh@opensourceconnections.com> wrote:
>>>>>>>
>>>>>>> Makes sense to me.
>>>>>>>
>>>>>>>
>>>>>>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Now that Lucene’s standardization is complete and I believe enforced, should we discuss if we could bring the same consistency to Solr?
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Marcus
>>>>>>> --
>>>>>>> Marcus Eagan
>>>>>>>
>>>>>>>
>>>>>>> _______________________
>>>>>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com | My Free/Busy
>>>>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>>>> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.needhamsoftware.com (work)
>>>>>> http://www.the111shift.com (play)
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>> --
>>> - Mark
>>>
>>> http://about.me/markrmiller
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
Maybe simply apply the standard in both places?

On Fri, Feb 26, 2021 at 9:04 AM Eric Pugh <epugh@opensourceconnections.com>
wrote:

> I interpreted Mark as saying, we should forge ahead with the things like
> standardizing test names, and when the reference branch is ready, we tackle
> it.
>
> Having read most of the individual commits, all 1405 and counting, I think
> that bringing this code base in is going to be a major effort, and really
> isn’t going to be easy to bring in bit by bit. The changes are to
> everything, and I think unwinding the changes into “chunks” is going to be
> even more herculean…. The changes touch everything, and honestly, since
> it’s all about restoring speed and paying down accumulated tech debt, I
> totally get why it’s so intrusive. It’s a revolutionary change, not an
> evolutionary one.
>
>
>
> On Feb 26, 2021, at 8:26 AM, Jason Gerlowski <gerlowskija@gmail.com>
> wrote:
>
> I hope that doesn’t sound too negative
>
>
> Not to me. But I'm a little confused what your ultimate stand is on
> these renames Marcus is proposing. I'm hearing different messages in
> different sections of your email.
>
> There are already so many conflicts, you will cry and then realize there
> are more.
>
>
> Sounds very much like you're saying that the test renames will cause
> really painful merge-conflicts, and that renames should wait because
> of the pain involved in reconciling ref_impl.
>
> But...
>
> You can’t let a specter freeze the tireless day to day shifting and
> shuffling of names and rules and locations.
>
>
> Sounds like you're saying that we shouldn't let fear of ref_impl
> complications stop us from doing renames, file-moves, etc.
>
> Sorry if I'm just being daft, but can you clarify please? Are you
> saying that we should avoid big changes because of the ugly merges
> with ref_impl? Or that we shouldn't let fear of ref_impl
> complications stop us from anything on master? Or something else
> altogether?
>
> Best,
>
> Jason
>
> On Fri, Feb 26, 2021 at 7:50 AM Mark Miller <markrmiller@gmail.com> wrote:
>
>
> I hope that doesn’t sound too negative, “clinging” never sounds as
> positive as I’d like and I do negative plenty well without doing it by
> accident. Not a pessimistic statement though, I made it even better than I
> was planning or remembering I could or however that works. Resistance is
> built into the equation - this isn’t rock and roll, I’m a science bachelor.
> Though only a small few liberal arts classes made me go, so I wouldn’t
> trust the cert myself. Anyway, I learned from multiple Star Wars movies
> what to do here, you have to setup an ambush on the trench run and then
> just make the thing look like a huge black star.
>
> On Fri, Feb 26, 2021 at 4:38 AM Mark Miller <markrmiller@gmail.com> wrote:
>
>
> There are already so many conflicts, you will cry and then realize there
> are more. Even worse, some things have been changed due to their
> cost/benefit failings, things that someone, somewhere, will cling to like a
> life vest.
>
> The ref branch waits for no man, and expects the same.
>
> It lives on ridiculous speed and stability and throws mergability to the
> crows.
>
> It could not be merged into anything and survive, but it can absorb
> anything, as long as it behaves like a boss or can be jostled into doing
> so. So fear not for the fearless. You can’t let a specter freeze the
> tireless day to day shifting and shuffling of names and rules and
> locations. I swear, enough lucky shifts and this thing can rise to meet the
> living. I’ve seen it see dead people.
>
> End of the day, if the ref branch can’t survive even a large and lengthy
> divergence, if that is the freeze in its tracks, it’s not at all what I’ve
> said ive been working on and so does it even matter?
>
>
> On Mon, Feb 22, 2021 at 9:39 AM Jason Gerlowski <gerlowskija@gmail.com>
> wrote:
>
>
> I'm fine with standardization, whichever convention we choose. I have
> a slight preference for FooTest, for the same reason Gus mentioned,
> but any standard is better than none here IMO.
>
> prefer that we not make a sweeping change like this until after Mark's
> "ref branch" is reconciled
>
>
> Personally I disagree about the need to wait. It'd be one thing if
> there was an agreed-upon plan or a timeframe for merging "ref-branch".
> But since that's not the case today, I don't think it makes sense to
> ignore concrete/mergeable improvements. It seems like a "bird in the
> hand vs two in the bush" situation. Especially when there are
> strategies for handling the conflicts that might arise with Mark's
> "ref-branch" (e.g. do the test renames on both master and ref_impl).
>
> Jason
>
> On Sun, Feb 21, 2021 at 12:44 PM David Smiley <dsmiley@apache.org> wrote:
>
>
> I look forward to a standardization on *something* but would prefer that
> we not make a sweeping change like this until after Mark's "ref branch" is
> reconciled. I don't want that to hang over the project indefinitely, but
> we can wait; we've not had this standardization yet for many years, after
> all.
>
> That said, it would be good to choose the standard name now so that there
> is less to change later. Can someone dig up the statistics on Solr's name
> choice to see if there is a clear winner (e.g. >60%)? I don't have a
> strong opinion on whatever the standard should be so long as there is a
> standard :-)
>
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <gus.heck@gmail.com> wrote:
>
>
> FWIW, I'm not really in favor of the convention Lucene adopted. I probably
> lost track of the debate and failed to object which is on me, but I guess
> it was because that was the lower number of changes there? It's certainly
> much less legible in the IDE to have a wall of classes all starting with T.
> Maybe given that the projects are splitting Solr can Stick with FooTest not
> TestFoo? I think *Test suffix is more common in Solr... (though I haven't
> attempted to quantify it)
>
> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <
> epugh@opensourceconnections.com> wrote:
>
>
> Makes sense to me.
>
>
> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>
> Hi all,
>
> Now that Lucene’s standardization is complete and I believe enforced,
> should we discuss if we could bring the same consistency to Solr?
>
> Best,
>
> Marcus
> --
> Marcus Eagan
>
>
> _______________________
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
> http://www.opensourceconnections.com | My Free/Busy
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless of
> whether attachments are marked as such.
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> <dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org
> <dev-help@lucene.apache.org>
>
> --
> - Mark
>
> http://about.me/markrmiller
>
>
> --
> - Mark
>
> http://about.me/markrmiller
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> <dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org
> <dev-help@lucene.apache.org>
>
>
> _______________________
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
Hi all,

I am reviving this thread but perhaps it should be moved to
dev@solr.apache.org given the project-level changes. Do people favor
standardizing Solr to match Lucene's convention or do you prefer *Test.java
as the convention?

There are many more files, and a few that don't follow either convention, I
bet.

Curious about people's thoughts:

Marcussorealheis:solr marcuseagan$ find . -name "Test*.java" | wc -l
493
Marcussorealheis:solr marcuseagan$ find . -name "*Test.java" | wc -l
753

On Fri, Feb 26, 2021 at 7:55 AM Gus Heck <gus.heck@gmail.com> wrote:

> Maybe simply apply the standard in both places?
>
> On Fri, Feb 26, 2021 at 9:04 AM Eric Pugh <epugh@opensourceconnections.com>
> wrote:
>
>> I interpreted Mark as saying, we should forge ahead with the things like
>> standardizing test names, and when the reference branch is ready, we tackle
>> it.
>>
>> Having read most of the individual commits, all 1405 and counting, I
>> think that bringing this code base in is going to be a major effort, and
>> really isn’t going to be easy to bring in bit by bit. The changes are to
>> everything, and I think unwinding the changes into “chunks” is going to be
>> even more herculean…. The changes touch everything, and honestly, since
>> it’s all about restoring speed and paying down accumulated tech debt, I
>> totally get why it’s so intrusive. It’s a revolutionary change, not an
>> evolutionary one.
>>
>>
>>
>> On Feb 26, 2021, at 8:26 AM, Jason Gerlowski <gerlowskija@gmail.com>
>> wrote:
>>
>> I hope that doesn’t sound too negative
>>
>>
>> Not to me. But I'm a little confused what your ultimate stand is on
>> these renames Marcus is proposing. I'm hearing different messages in
>> different sections of your email.
>>
>> There are already so many conflicts, you will cry and then realize there
>> are more.
>>
>>
>> Sounds very much like you're saying that the test renames will cause
>> really painful merge-conflicts, and that renames should wait because
>> of the pain involved in reconciling ref_impl.
>>
>> But...
>>
>> You can’t let a specter freeze the tireless day to day shifting and
>> shuffling of names and rules and locations.
>>
>>
>> Sounds like you're saying that we shouldn't let fear of ref_impl
>> complications stop us from doing renames, file-moves, etc.
>>
>> Sorry if I'm just being daft, but can you clarify please? Are you
>> saying that we should avoid big changes because of the ugly merges
>> with ref_impl? Or that we shouldn't let fear of ref_impl
>> complications stop us from anything on master? Or something else
>> altogether?
>>
>> Best,
>>
>> Jason
>>
>> On Fri, Feb 26, 2021 at 7:50 AM Mark Miller <markrmiller@gmail.com>
>> wrote:
>>
>>
>> I hope that doesn’t sound too negative, “clinging” never sounds as
>> positive as I’d like and I do negative plenty well without doing it by
>> accident. Not a pessimistic statement though, I made it even better than I
>> was planning or remembering I could or however that works. Resistance is
>> built into the equation - this isn’t rock and roll, I’m a science bachelor.
>> Though only a small few liberal arts classes made me go, so I wouldn’t
>> trust the cert myself. Anyway, I learned from multiple Star Wars movies
>> what to do here, you have to setup an ambush on the trench run and then
>> just make the thing look like a huge black star.
>>
>> On Fri, Feb 26, 2021 at 4:38 AM Mark Miller <markrmiller@gmail.com>
>> wrote:
>>
>>
>> There are already so many conflicts, you will cry and then realize there
>> are more. Even worse, some things have been changed due to their
>> cost/benefit failings, things that someone, somewhere, will cling to like a
>> life vest.
>>
>> The ref branch waits for no man, and expects the same.
>>
>> It lives on ridiculous speed and stability and throws mergability to the
>> crows.
>>
>> It could not be merged into anything and survive, but it can absorb
>> anything, as long as it behaves like a boss or can be jostled into doing
>> so. So fear not for the fearless. You can’t let a specter freeze the
>> tireless day to day shifting and shuffling of names and rules and
>> locations. I swear, enough lucky shifts and this thing can rise to meet the
>> living. I’ve seen it see dead people.
>>
>> End of the day, if the ref branch can’t survive even a large and lengthy
>> divergence, if that is the freeze in its tracks, it’s not at all what I’ve
>> said ive been working on and so does it even matter?
>>
>>
>> On Mon, Feb 22, 2021 at 9:39 AM Jason Gerlowski <gerlowskija@gmail.com>
>> wrote:
>>
>>
>> I'm fine with standardization, whichever convention we choose. I have
>> a slight preference for FooTest, for the same reason Gus mentioned,
>> but any standard is better than none here IMO.
>>
>> prefer that we not make a sweeping change like this until after Mark's
>> "ref branch" is reconciled
>>
>>
>> Personally I disagree about the need to wait. It'd be one thing if
>> there was an agreed-upon plan or a timeframe for merging "ref-branch".
>> But since that's not the case today, I don't think it makes sense to
>> ignore concrete/mergeable improvements. It seems like a "bird in the
>> hand vs two in the bush" situation. Especially when there are
>> strategies for handling the conflicts that might arise with Mark's
>> "ref-branch" (e.g. do the test renames on both master and ref_impl).
>>
>> Jason
>>
>> On Sun, Feb 21, 2021 at 12:44 PM David Smiley <dsmiley@apache.org> wrote:
>>
>>
>> I look forward to a standardization on *something* but would prefer that
>> we not make a sweeping change like this until after Mark's "ref branch" is
>> reconciled. I don't want that to hang over the project indefinitely, but
>> we can wait; we've not had this standardization yet for many years, after
>> all.
>>
>> That said, it would be good to choose the standard name now so that there
>> is less to change later. Can someone dig up the statistics on Solr's name
>> choice to see if there is a clear winner (e.g. >60%)? I don't have a
>> strong opinion on whatever the standard should be so long as there is a
>> standard :-)
>>
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <gus.heck@gmail.com> wrote:
>>
>>
>> FWIW, I'm not really in favor of the convention Lucene adopted. I
>> probably lost track of the debate and failed to object which is on me, but
>> I guess it was because that was the lower number of changes there? It's
>> certainly much less legible in the IDE to have a wall of classes all
>> starting with T. Maybe given that the projects are splitting Solr can Stick
>> with FooTest not TestFoo? I think *Test suffix is more common in Solr...
>> (though I haven't attempted to quantify it)
>>
>> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <
>> epugh@opensourceconnections.com> wrote:
>>
>>
>> Makes sense to me.
>>
>>
>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>>
>> Hi all,
>>
>> Now that Lucene’s standardization is complete and I believe enforced,
>> should we discuss if we could bring the same consistency to Solr?
>>
>> Best,
>>
>> Marcus
>> --
>> Marcus Eagan
>>
>>
>> _______________________
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
>> http://www.opensourceconnections.com | My Free/Busy
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> This e-mail and all contents, including attachments, is considered to be
>> Company Confidential unless explicitly stated otherwise, regardless of
>> whether attachments are marked as such.
>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> <dev-unsubscribe@lucene.apache.org>
>> For additional commands, e-mail: dev-help@lucene.apache.org
>> <dev-help@lucene.apache.org>
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> <dev-unsubscribe@lucene.apache.org>
>> For additional commands, e-mail: dev-help@lucene.apache.org
>> <dev-help@lucene.apache.org>
>>
>>
>> _______________________
>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>> | http://www.opensourceconnections.com | My Free/Busy
>> <http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> This e-mail and all contents, including attachments, is considered to be
>> Company Confidential unless explicitly stated otherwise, regardless
>> of whether attachments are marked as such.
>>
>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>


--
Marcus Eagan
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
I’m in the *Test.java camp, but primarily care about any consistent pattern!


> On Jun 2, 2021, at 7:29 PM, Marcus Eagan <marcuseagan@gmail.com <mailto:marcuseagan@gmail.com>> wrote:
>
> Hi all,
>
> I am reviving this thread but perhaps it should be moved to dev@solr.apache.org <mailto:dev@solr.apache.org> given the project-level changes. Do people favor standardizing Solr to match Lucene's convention or do you prefer *Test.java as the convention?
>
> There are many more files, and a few that don't follow either convention, I bet.
>
> Curious about people's thoughts:
>
> Marcussorealheis:solr marcuseagan$ find . -name "Test*.java" | wc -l
> 493
> Marcussorealheis:solr marcuseagan$ find . -name "*Test.java" | wc -l
> 753
>
> On Fri, Feb 26, 2021 at 7:55 AM Gus Heck <gus.heck@gmail.com <mailto:gus.heck@gmail.com>> wrote:
> Maybe simply apply the standard in both places?
>
> On Fri, Feb 26, 2021 at 9:04 AM Eric Pugh <epugh@opensourceconnections.com <mailto:epugh@opensourceconnections.com>> wrote:
> I interpreted Mark as saying, we should forge ahead with the things like standardizing test names, and when the reference branch is ready, we tackle it.
>
> Having read most of the individual commits, all 1405 and counting, I think that bringing this code base in is going to be a major effort, and really isn’t going to be easy to bring in bit by bit. The changes are to everything, and I think unwinding the changes into “chunks” is going to be even more herculean…. The changes touch everything, and honestly, since it’s all about restoring speed and paying down accumulated tech debt, I totally get why it’s so intrusive. It’s a revolutionary change, not an evolutionary one.
>
>
>
>> On Feb 26, 2021, at 8:26 AM, Jason Gerlowski <gerlowskija@gmail.com <mailto:gerlowskija@gmail.com>> wrote:
>>
>>> I hope that doesn’t sound too negative
>>
>> Not to me. But I'm a little confused what your ultimate stand is on
>> these renames Marcus is proposing. I'm hearing different messages in
>> different sections of your email.
>>
>>> There are already so many conflicts, you will cry and then realize there are more.
>>
>> Sounds very much like you're saying that the test renames will cause
>> really painful merge-conflicts, and that renames should wait because
>> of the pain involved in reconciling ref_impl.
>>
>> But...
>>
>>> You can’t let a specter freeze the tireless day to day shifting and shuffling of names and rules and locations.
>>
>> Sounds like you're saying that we shouldn't let fear of ref_impl
>> complications stop us from doing renames, file-moves, etc.
>>
>> Sorry if I'm just being daft, but can you clarify please? Are you
>> saying that we should avoid big changes because of the ugly merges
>> with ref_impl? Or that we shouldn't let fear of ref_impl
>> complications stop us from anything on master? Or something else
>> altogether?
>>
>> Best,
>>
>> Jason
>>
>> On Fri, Feb 26, 2021 at 7:50 AM Mark Miller <markrmiller@gmail.com <mailto:markrmiller@gmail.com>> wrote:
>>>
>>> I hope that doesn’t sound too negative, “clinging” never sounds as positive as I’d like and I do negative plenty well without doing it by accident. Not a pessimistic statement though, I made it even better than I was planning or remembering I could or however that works. Resistance is built into the equation - this isn’t rock and roll, I’m a science bachelor. Though only a small few liberal arts classes made me go, so I wouldn’t trust the cert myself. Anyway, I learned from multiple Star Wars movies what to do here, you have to setup an ambush on the trench run and then just make the thing look like a huge black star.
>>>
>>> On Fri, Feb 26, 2021 at 4:38 AM Mark Miller <markrmiller@gmail.com <mailto:markrmiller@gmail.com>> wrote:
>>>>
>>>> There are already so many conflicts, you will cry and then realize there are more. Even worse, some things have been changed due to their cost/benefit failings, things that someone, somewhere, will cling to like a life vest.
>>>>
>>>> The ref branch waits for no man, and expects the same.
>>>>
>>>> It lives on ridiculous speed and stability and throws mergability to the crows.
>>>>
>>>> It could not be merged into anything and survive, but it can absorb anything, as long as it behaves like a boss or can be jostled into doing so. So fear not for the fearless. You can’t let a specter freeze the tireless day to day shifting and shuffling of names and rules and locations. I swear, enough lucky shifts and this thing can rise to meet the living. I’ve seen it see dead people.
>>>>
>>>> End of the day, if the ref branch can’t survive even a large and lengthy divergence, if that is the freeze in its tracks, it’s not at all what I’ve said ive been working on and so does it even matter?
>>>>
>>>>
>>>> On Mon, Feb 22, 2021 at 9:39 AM Jason Gerlowski <gerlowskija@gmail.com <mailto:gerlowskija@gmail.com>> wrote:
>>>>>
>>>>> I'm fine with standardization, whichever convention we choose. I have
>>>>> a slight preference for FooTest, for the same reason Gus mentioned,
>>>>> but any standard is better than none here IMO.
>>>>>
>>>>>> prefer that we not make a sweeping change like this until after Mark's "ref branch" is reconciled
>>>>>
>>>>> Personally I disagree about the need to wait. It'd be one thing if
>>>>> there was an agreed-upon plan or a timeframe for merging "ref-branch".
>>>>> But since that's not the case today, I don't think it makes sense to
>>>>> ignore concrete/mergeable improvements. It seems like a "bird in the
>>>>> hand vs two in the bush" situation. Especially when there are
>>>>> strategies for handling the conflicts that might arise with Mark's
>>>>> "ref-branch" (e.g. do the test renames on both master and ref_impl).
>>>>>
>>>>> Jason
>>>>>
>>>>> On Sun, Feb 21, 2021 at 12:44 PM David Smiley <dsmiley@apache.org <mailto:dsmiley@apache.org>> wrote:
>>>>>>
>>>>>> I look forward to a standardization on *something* but would prefer that we not make a sweeping change like this until after Mark's "ref branch" is reconciled. I don't want that to hang over the project indefinitely, but we can wait; we've not had this standardization yet for many years, after all.
>>>>>>
>>>>>> That said, it would be good to choose the standard name now so that there is less to change later. Can someone dig up the statistics on Solr's name choice to see if there is a clear winner (e.g. >60%)? I don't have a strong opinion on whatever the standard should be so long as there is a standard :-)
>>>>>>
>>>>>>
>>>>>> ~ David Smiley
>>>>>> Apache Lucene/Solr Search Developer
>>>>>> http://www.linkedin.com/in/davidwsmiley <http://www.linkedin.com/in/davidwsmiley>
>>>>>>
>>>>>>
>>>>>> On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <gus.heck@gmail.com <mailto:gus.heck@gmail.com>> wrote:
>>>>>>>
>>>>>>> FWIW, I'm not really in favor of the convention Lucene adopted. I probably lost track of the debate and failed to object which is on me, but I guess it was because that was the lower number of changes there? It's certainly much less legible in the IDE to have a wall of classes all starting with T. Maybe given that the projects are splitting Solr can Stick with FooTest not TestFoo? I think *Test suffix is more common in Solr... (though I haven't attempted to quantify it)
>>>>>>>
>>>>>>> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <epugh@opensourceconnections.com <mailto:epugh@opensourceconnections.com>> wrote:
>>>>>>>>
>>>>>>>> Makes sense to me.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com <mailto:marcuseagan@gmail.com>> wrote:
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Now that Lucene’s standardization is complete and I believe enforced, should we discuss if we could bring the same consistency to Solr?
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Marcus
>>>>>>>> --
>>>>>>>> Marcus Eagan
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________
>>>>>>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy
>>>>>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>>>>>> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work)
>>>>>>> http://www.the111shift.com <http://www.the111shift.com/> (play)
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>>>>>
>>>> --
>>>> - Mark
>>>>
>>>> http://about.me/markrmiller <http://about.me/markrmiller>
>>>
>>> --
>>> - Mark
>>>
>>> http://about.me/markrmiller <http://about.me/markrmiller>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>>
>
> _______________________
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
>
>
>
> --
> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work)
> http://www.the111shift.com <http://www.the111shift.com/> (play)
>
>
> --
> Marcus Eagan
>

_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
Re: Revisiting Standardized Test Names in Solr [ In reply to ]
+1.

Either way is fine, as long as its enforced.

On Thu, 3 Jun 2021, 05:12 Eric Pugh, <epugh@opensourceconnections.com>
wrote:

> I’m in the *Test.java camp, but primarily care about any consistent
> pattern!
>
>
> On Jun 2, 2021, at 7:29 PM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>
> Hi all,
>
> I am reviving this thread but perhaps it should be moved to
> dev@solr.apache.org given the project-level changes. Do people favor
> standardizing Solr to match Lucene's convention or do you prefer *Test.java
> as the convention?
>
> There are many more files, and a few that don't follow either convention,
> I bet.
>
> Curious about people's thoughts:
>
> Marcussorealheis:solr marcuseagan$ find . -name "Test*.java" | wc -l
> 493
> Marcussorealheis:solr marcuseagan$ find . -name "*Test.java" | wc -l
> 753
>
> On Fri, Feb 26, 2021 at 7:55 AM Gus Heck <gus.heck@gmail.com> wrote:
>
>> Maybe simply apply the standard in both places?
>>
>> On Fri, Feb 26, 2021 at 9:04 AM Eric Pugh <
>> epugh@opensourceconnections.com> wrote:
>>
>>> I interpreted Mark as saying, we should forge ahead with the things like
>>> standardizing test names, and when the reference branch is ready, we tackle
>>> it.
>>>
>>> Having read most of the individual commits, all 1405 and counting, I
>>> think that bringing this code base in is going to be a major effort, and
>>> really isn’t going to be easy to bring in bit by bit. The changes are to
>>> everything, and I think unwinding the changes into “chunks” is going to be
>>> even more herculean…. The changes touch everything, and honestly, since
>>> it’s all about restoring speed and paying down accumulated tech debt, I
>>> totally get why it’s so intrusive. It’s a revolutionary change, not an
>>> evolutionary one.
>>>
>>>
>>>
>>> On Feb 26, 2021, at 8:26 AM, Jason Gerlowski <gerlowskija@gmail.com>
>>> wrote:
>>>
>>> I hope that doesn’t sound too negative
>>>
>>>
>>> Not to me. But I'm a little confused what your ultimate stand is on
>>> these renames Marcus is proposing. I'm hearing different messages in
>>> different sections of your email.
>>>
>>> There are already so many conflicts, you will cry and then realize there
>>> are more.
>>>
>>>
>>> Sounds very much like you're saying that the test renames will cause
>>> really painful merge-conflicts, and that renames should wait because
>>> of the pain involved in reconciling ref_impl.
>>>
>>> But...
>>>
>>> You can’t let a specter freeze the tireless day to day shifting and
>>> shuffling of names and rules and locations.
>>>
>>>
>>> Sounds like you're saying that we shouldn't let fear of ref_impl
>>> complications stop us from doing renames, file-moves, etc.
>>>
>>> Sorry if I'm just being daft, but can you clarify please? Are you
>>> saying that we should avoid big changes because of the ugly merges
>>> with ref_impl? Or that we shouldn't let fear of ref_impl
>>> complications stop us from anything on master? Or something else
>>> altogether?
>>>
>>> Best,
>>>
>>> Jason
>>>
>>> On Fri, Feb 26, 2021 at 7:50 AM Mark Miller <markrmiller@gmail.com>
>>> wrote:
>>>
>>>
>>> I hope that doesn’t sound too negative, “clinging” never sounds as
>>> positive as I’d like and I do negative plenty well without doing it by
>>> accident. Not a pessimistic statement though, I made it even better than I
>>> was planning or remembering I could or however that works. Resistance is
>>> built into the equation - this isn’t rock and roll, I’m a science bachelor.
>>> Though only a small few liberal arts classes made me go, so I wouldn’t
>>> trust the cert myself. Anyway, I learned from multiple Star Wars movies
>>> what to do here, you have to setup an ambush on the trench run and then
>>> just make the thing look like a huge black star.
>>>
>>> On Fri, Feb 26, 2021 at 4:38 AM Mark Miller <markrmiller@gmail.com>
>>> wrote:
>>>
>>>
>>> There are already so many conflicts, you will cry and then realize there
>>> are more. Even worse, some things have been changed due to their
>>> cost/benefit failings, things that someone, somewhere, will cling to like a
>>> life vest.
>>>
>>> The ref branch waits for no man, and expects the same.
>>>
>>> It lives on ridiculous speed and stability and throws mergability to the
>>> crows.
>>>
>>> It could not be merged into anything and survive, but it can absorb
>>> anything, as long as it behaves like a boss or can be jostled into doing
>>> so. So fear not for the fearless. You can’t let a specter freeze the
>>> tireless day to day shifting and shuffling of names and rules and
>>> locations. I swear, enough lucky shifts and this thing can rise to meet the
>>> living. I’ve seen it see dead people.
>>>
>>> End of the day, if the ref branch can’t survive even a large and lengthy
>>> divergence, if that is the freeze in its tracks, it’s not at all what I’ve
>>> said ive been working on and so does it even matter?
>>>
>>>
>>> On Mon, Feb 22, 2021 at 9:39 AM Jason Gerlowski <gerlowskija@gmail.com>
>>> wrote:
>>>
>>>
>>> I'm fine with standardization, whichever convention we choose. I have
>>> a slight preference for FooTest, for the same reason Gus mentioned,
>>> but any standard is better than none here IMO.
>>>
>>> prefer that we not make a sweeping change like this until after Mark's
>>> "ref branch" is reconciled
>>>
>>>
>>> Personally I disagree about the need to wait. It'd be one thing if
>>> there was an agreed-upon plan or a timeframe for merging "ref-branch".
>>> But since that's not the case today, I don't think it makes sense to
>>> ignore concrete/mergeable improvements. It seems like a "bird in the
>>> hand vs two in the bush" situation. Especially when there are
>>> strategies for handling the conflicts that might arise with Mark's
>>> "ref-branch" (e.g. do the test renames on both master and ref_impl).
>>>
>>> Jason
>>>
>>> On Sun, Feb 21, 2021 at 12:44 PM David Smiley <dsmiley@apache.org>
>>> wrote:
>>>
>>>
>>> I look forward to a standardization on *something* but would prefer that
>>> we not make a sweeping change like this until after Mark's "ref branch" is
>>> reconciled. I don't want that to hang over the project indefinitely, but
>>> we can wait; we've not had this standardization yet for many years, after
>>> all.
>>>
>>> That said, it would be good to choose the standard name now so that
>>> there is less to change later. Can someone dig up the statistics on Solr's
>>> name choice to see if there is a clear winner (e.g. >60%)? I don't have a
>>> strong opinion on whatever the standard should be so long as there is a
>>> standard :-)
>>>
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <gus.heck@gmail.com> wrote:
>>>
>>>
>>> FWIW, I'm not really in favor of the convention Lucene adopted. I
>>> probably lost track of the debate and failed to object which is on me, but
>>> I guess it was because that was the lower number of changes there? It's
>>> certainly much less legible in the IDE to have a wall of classes all
>>> starting with T. Maybe given that the projects are splitting Solr can Stick
>>> with FooTest not TestFoo? I think *Test suffix is more common in Solr...
>>> (though I haven't attempted to quantify it)
>>>
>>> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <
>>> epugh@opensourceconnections.com> wrote:
>>>
>>>
>>> Makes sense to me.
>>>
>>>
>>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> Now that Lucene’s standardization is complete and I believe enforced,
>>> should we discuss if we could bring the same consistency to Solr?
>>>
>>> Best,
>>>
>>> Marcus
>>> --
>>> Marcus Eagan
>>>
>>>
>>> _______________________
>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
>>> http://www.opensourceconnections.com | My Free/Busy
>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> This e-mail and all contents, including attachments, is considered to be
>>> Company Confidential unless explicitly stated otherwise, regardless of
>>> whether attachments are marked as such.
>>>
>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> <dev-unsubscribe@lucene.apache.org>
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> <dev-help@lucene.apache.org>
>>>
>>> --
>>> - Mark
>>>
>>> http://about.me/markrmiller
>>>
>>>
>>> --
>>> - Mark
>>>
>>> http://about.me/markrmiller
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> <dev-unsubscribe@lucene.apache.org>
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> <dev-help@lucene.apache.org>
>>>
>>>
>>> _______________________
>>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>>> | http://www.opensourceconnections.com | My Free/Busy
>>> <http://tinyurl.com/eric-cal>
>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>> This e-mail and all contents, including attachments, is considered to be
>>> Company Confidential unless explicitly stated otherwise, regardless
>>> of whether attachments are marked as such.
>>>
>>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>
>
> --
> Marcus Eagan
>
>
> _______________________
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>