> 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 >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> -- >> - Mark >> >> http://about.me/markrmiller > > -- > - Mark > > http://about.me/markrmiller --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
