On Tue, Oct 6, 2020 at 10:45 PM Anshum Gupta wrote:
>
> I haven’t looked at the current ref branch recently, but the folks who
> have looked at it, if you think that this code can be merged into master
> even as big chunks, that’d be the most confidence building way forward.
>
>
+1 for
On Tue, Oct 6, 2020 at 7:45 PM Anshum Gupta wrote:
> Thanks for initiating this discussion, Ishan.
>
> For the sake of making sure that we are all on the same page, let me
> summarize my understanding and take on this thread.
>
> The current situation
> Mark has a reference branch, which the
Thanks for initiating this discussion, Ishan.
For the sake of making sure that we are all on the same page, let me
summarize my understanding and take on this thread.
The current situation
Mark has a reference branch, which the folks who have looked at the branch,
feel that it’s a much better,
No strong opinion from me. I think the back-compat concern is minor.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Oct 6, 2020 at 5:42 PM Noble Paul wrote:
> I think we should call that out in the changes.txt and make the changes
> right
I think we should call that out in the changes.txt and make the changes
right away.
On Wed, Oct 7, 2020, 8:20 AM Timothy Potter wrote:
> Just want to close the loop on this restlet issue. I've removed the
> restlet dependency in master (e879a52291ef7dcd0514e7419d811b6ff800bcce) but
> have not
Just want to close the loop on this restlet issue. I've removed the restlet
dependency in master (e879a52291ef7dcd0514e7419d811b6ff800bcce) but have
not backported that to 8.x yet.
I'm hesitant to backport because I had to change public function signatures
on ManagedResource, e.g.
Copying below Mark's posts from ASF Slack #solr-next-big-thing channel.
The Solr Reference Branch.
Document 1, a quick intro.
You can think of the Solr Reference Branch as a remaster of Solr. It
is not an attempt to redesign Solr or make it more fancy. The goal of
the Solr Reference Branch is to
> Let's say we cut 9x and now there is a new master taken from the
reference branch.
I never said “make a new master”, I said merge changes in ref branch into
master. If things are broken into pieces like Ishan is suggesting, those
changes can be merged into 9.x too. I only suggested this because
That is correct. 8.x docker builds have not been affected in any way.
On Tue, Oct 6, 2020 at 11:30 AM Cassandra Targett
wrote:
> I wanted to ask now that the 8.6.3 vote is underway - for the docker-solr
> image, are the update instructions in the docker-solr repo still the same
> for 8.x even
I wanted to ask now that the 8.6.3 vote is underway - for the docker-solr
image, are the update instructions in the docker-solr repo still the same for
8.x even though the build process has been moved to the main project for 9.0?
Meaning, to release the 8.6.3 image there’s no change from
Gone.
> On Oct 4, 2020, at 3:39 PM, Erick Erickson wrote:
>
> The "How to contribute" page here:
>
> https://cwiki.apache.org/confluence/display/solr/HowToContribute
>
> contains links to two obsolete pages for configuring Eclipse and IntelliJ:
>
>
> I think the danger is high to treat this branch as a black box (or an "all or
> nothing").
True Ilan. Ideally, I would like a few of us to study the code &
start pulling in changes we are confident of (even to 8x branch, why
not). We cannot burden a single developer to do everything.
This
I'm willing to help and I believe others will too if the amount of work for
contributing is reasonable (i.e. not a three months effort).
I looked into the possibility of doing so. To me, it seemed to be that it
is very hard to do so: possibly 1 year project for me. Problem is that it
is hard to
Another option to integrate this work into the main code line would be to
understand what changes have been made and where (Mark's descriptions in
Slack go in the right way but are still too high level), and then port or
even redo them in main, one by one.
I think the danger is high to treat this
> Docker is not a big requirement for large scale installations. Most of
them already have their own install scripts. Availability of docker is not
important for them. If a user is only encouraged to install Solr because of
a docker image , most likely they are not running a large enough cluster
Yes, A docker image will definitely help. I wasn't trying to downplay that
On Tue, Oct 6, 2020 at 6:55 PM Ishan Chattopadhyaya
wrote:
>
>
> > Docker is not a big requirement for large scale installations. Most of them
> > already have their own install scripts. Availability of docker is not
>
@Tomas Fernandez Lobbe
This is a very risky proposition. Let's say we cut 9x and now there is
a new master taken from the reference branch. That master is now
going to be 10.0.
* We never get it to the hands of the users anytime soon. We will
never be able to reconcile these 2 branches
* The
As I said, I'm *personally* not confident in putting such a big changeset
into master that wasn't vetted in a real user environment widely. I have,
in the past, done enough bad things to Solr (directly or indirectly), and I
don't want to repeat the same. Also, I'll be very uncomfortable if someone
+1 (binding)
SUCCESS! [1:05:14.591357]
On Mon, Oct 5, 2020 at 1:13 PM Anshum Gupta wrote:
> +1 (binding)
>
> SUCCESS! [1:00:37.423566]
>
> Tried basic indexing and search and ran the smoke tester.
>
> On Sat, Oct 3, 2020 at 6:53 PM Jason Gerlowski
> wrote:
>
>> Please vote for release
19 matches
Mail list logo
