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] > <mailto:[email protected]>> wrote: > > Hi all, > > I am reviving this thread but perhaps it should be moved to > [email protected] <mailto:[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] > <mailto:[email protected]>> wrote: > Maybe simply apply the standard in both places? > > On Fri, Feb 26, 2021 at 9:04 AM Eric Pugh <[email protected] > <mailto:[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] >> <mailto:[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] >> <mailto:[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] >>> <mailto:[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] >>>> <mailto:[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] >>>>> <mailto:[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 >>>>>> <http://www.linkedin.com/in/davidwsmiley> >>>>>> >>>>>> >>>>>> On Sun, Feb 21, 2021 at 12:18 PM Gus Heck <[email protected] >>>>>> <mailto:[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] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> Makes sense to me. >>>>>>>> >>>>>>>> >>>>>>>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <[email protected] >>>>>>>> <mailto:[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 >>>>>>>> <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: [email protected] >>>>> <mailto:[email protected]> >>>>> For additional commands, e-mail: [email protected] >>>>> <mailto:[email protected]> >>>>> >>>> -- >>>> - Mark >>>> >>>> http://about.me/markrmiller <http://about.me/markrmiller> >>> >>> -- >>> - Mark >>> >>> http://about.me/markrmiller <http://about.me/markrmiller> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> For additional commands, e-mail: [email protected] >> <mailto:[email protected]> >> > > _______________________ > 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.
