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 <gerlowskija@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 <dsmiley@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.heck@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 <
> epugh@opensourceconnections.com> wrote:
> >>>
> >>> Makes sense to me.
> >>>
> >>>
> >>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan <marcuseagan@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
- Mark
http://about.me/markrmiller