+1 I also am very much on the *Test side. Now that Lucene and Solr are split, I don’t think theres much reason to base the Solr rule on Lucene’s.
- Houston On Wed, Jun 2, 2021 at 11:49 PM Atri Sharma <[email protected]> wrote: > +1. > > Either way is fine, as long as its enforced. > > On Thu, 3 Jun 2021, 05:12 Eric Pugh, <[email protected]> > 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 <[email protected]> wrote: >> >> Hi all, >> >> I am reviving this thread but perhaps it should be moved to >> [email protected] 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 <[email protected]> wrote: >> >>> Maybe simply apply the standard in both places? >>> >>> On Fri, Feb 26, 2021 at 9:04 AM Eric Pugh < >>> [email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 <[email protected]> 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 < >>>> [email protected]> wrote: >>>> >>>> >>>> Makes sense to me. >>>> >>>> >>>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <[email protected]> >>>> 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: [email protected] >>>> <[email protected]> >>>> For additional commands, e-mail: [email protected] >>>> <[email protected]> >>>> >>>> -- >>>> - Mark >>>> >>>> http://about.me/markrmiller >>>> >>>> >>>> -- >>>> - Mark >>>> >>>> http://about.me/markrmiller >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> <[email protected]> >>>> For additional commands, e-mail: [email protected] >>>> <[email protected]> >>>> >>>> >>>> _______________________ >>>> *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. >> >>
