Hi all,
I am reviving this thread but perhaps it should be moved to
d...@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.h...@gmail.com> wrote:
> Maybe simply apply the standard in both places?
>
> On Fri, Feb 26, 2021 at 9:04 AM Eric Pugh <ep...@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 <gerlowsk...@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 <markrmil...@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 <markrmil...@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 <gerlowsk...@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 <dsmi...@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.h...@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 <
>> ep...@opensourceconnections.com> wrote:
>>
>>
>> Makes sense to me.
>>
>>
>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcusea...@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-unsubscr...@lucene.apache.org
>> <dev-unsubscr...@lucene.apache.org>
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> <dev-h...@lucene.apache.org>
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> <dev-unsubscr...@lucene.apache.org>
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> <dev-h...@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
