You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Mark Miller <ma...@gmail.com> on 2021/07/08 04:18:14 UTC

Re: Solr Alpha (EA) release of Reference Branch

I will be pulling stuff over as I can and have been working towards making
it easier for others to do some comparisons and maybe take an interest in
some of the changes.

I’m also working on getting an up to date branch with my latest changes
available. There are a few outstanding items I need to get time for.

The number of changes ended up being astronomical though. Many of the
things done are 100% my direction. An amazing number of the changes and
fixes are deeply interconnected.

The only dream to even consume it would have been a new Solr branch with
mass buy in and mass effort on a major, updates likely not supported
release. That would have to happen in parallel with the current stable,
upgradable release element.

The buy in effort, agreement, directions, resources, etc, etc is just
beyond my abilities even if I went full at it. It’s not impossible, but
ridiculously improbable and with an uncertain outcome.

Ive still got in one way or another, everything I got out of it.

And almost all of it that applied in 2020-2021 applied in 2019 and in 2017.

So I’m not really worried about losing any of it via time in any real way.

Extracting some of the best things is something I’ll probably mull around
for a long time. The total efficiency and performance of tests. That’s just
insane time and effort and tied into production stuff heavily. Even getting
it on a stable commit with insane hours really required I owned the branch
and could move as fast as I wanted.

That only begins to describe the difficulty in getting some of the stuff
that is central to what I wanted.

I’m also blown out from at all that work when it comes to some of it. Some
of it was just a ridiculous amount of effort, and I can’t maintain that
effort currently, nor would anyone want me to.

So right now I’m pulling things over as they make sense for what I’m after.

I have some of the items i mentioned I’m working towards. I don’t see a
sell by date on what I got/get out of the branch.

So it’s not unfortunately, coming as was always a nice pipe dream. But
things are coming from it.

MRM

On Mon, Jun 28, 2021 at 3:32 AM Jan Høydahl <ja...@cominvent.com> wrote:

> On our last committers meeting it was made clear that "Reference Branch"
> is never going to be "merged" (oh, how simple this sounds), but mays serve
> as inspiration for incremental improvement, please see Meeting Notes:
> https://cwiki.apache.org/confluence/display/SOLR/2021-06+Committer+Meeting+notes
>
> Jan
>
> > 27. jun. 2021 kl. 03:30 skrev Shawn Heisey <ap...@elyograg.org>:
> >
> > On 10/3/2020 1:42 PM, Ishan Chattopadhyaya wrote:
> >> As you might be aware, the reference_impl branch has a lot of
> improvements that we want to see in Solr master. However, it is currently a
> large deviation from master and hence the stability and reliability (though
> improved in certain aspects) remains to be tested in real production
> environments before we gain confidence in bringing those changes to master.
> >> I propose that we do a one off preview release from that branch, say
> Solr 10 alpha (early access) or any other name that someone suggests, so
> that users could try it out and report regressions or improvements etc.
> >
> > (Original message was on dev@lucene, so this will seem out of the
> blue.  I wrote most of this last year, just hadn't sent it yet!  It's been
> sitting in my drafts forever.  Sending to dev@solr now.)
> >
> > How to handle this seems to come down to the answers to a couple of
> questions:
> >
> > * Is this new code stable enough to work in the wild?
> > * Do we want to release 9.0 before we merge Mark's work to main, or
> after?
> >
> > Can someone who was involved when 4.0-ALPHA and 4.0-BETA were released
> tell me whether those releases actually did what was intended and made
> 4.0.0 a better release?  If they did, then a special release for this new
> implementation before merging to main would probably also be helpful.  If
> there was no real benefit gained, then maybe we're better off just going
> ahead with the merge.
> >
> > If the general feeling is that this new release is looking very solid,
> then I think we should merge to main soon, probably just before branch_9x
> is created.  If we think it needs more work, then maybe we should hold on
> merging until *after* branch_9x is created, so the new implementation will
> release with 10.0 and there will be more time to work on it.
> >
> > My current impression, which I will admit is made with almost zero
> actual information about the code or its stability, is that we should plan
> on stabilizing the new implementation for the 9.0 release.  There's going
> to be pain no matter how we handle this, so diving in now seems like a good
> idea.
> >
> > A tangent:  How robust is our testing?  I know they take a long time to
> run, but do we think there's enough being tested?  There has been some
> discussion in the past about benchmarks for Solr.  Benchmarks would be
> cool, but I'm more interested in making sure that our tests will catch
> problems before they get out into the wild.
> >
> > Thanks,
> > Shawn
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
> --
- Mark

http://about.me/markrmiller