Hi, I am + 1 for it too.
Kind Regards, Furkan KAMACI On 3 Jun 2021 Thu at 06:55 Houston Putman <hous...@apache.org> wrote: > +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 <a...@apache.org> wrote: > >> +1. >> >> Either way is fine, as long as its enforced. >> >> On Thu, 3 Jun 2021, 05:12 Eric Pugh, <ep...@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 <marcusea...@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.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 >>> >>> >>> _______________________ >>> *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. >>> >>>
