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] >>>> For additional commands, e-mail: [email protected] >>>> >>> -- >>> - Mark >>> >>> http://about.me/markrmiller >> >> -- >> - Mark >> >> http://about.me/markrmiller > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [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.
