I agree with Doug that the burden of proof is on keeping the codebases
together instead of the reverse. I liken it to a marriage; it has to work
well for both parties.It seems to be mostly beneficial for Solr but
much less so for Lucene.
BTW an even better example than the huge FuzzyQuery
On Sun, May 10, 2020 at 8:20 AM David Smiley
wrote:
> I wonder if ElasticSearch tries to do this on their side too; does it?
>
Yes, Elasticsearch regularly upgrades to new snapshots of Lucene[1][2],
often multiple times per minor version. It helps give Lucene more test and
performance coverage,
On 10/05/2020 08:20, David Smiley wrote:
> An idea just occurred to me that may help make a split nicer for Solr
> than it is today. Solr could use a branch of the Lucene project that's
> used for the Solr project.
Maybe I'm alone in this, but (better) Lucene compatibility is one of the
reasons
Solr maintaining a fork of Lucene sounds like exactly the situation that
let to the original merge, where there are two sets of divergent development
On Sun, May 10, 2020 at 1:20 AM David Smiley
wrote:
> I agree with Doug that the burden of proof is on keeping the codebases
> together instead
On 5/10/2020 3:41 PM, Michael McCandless wrote:
I think the costs (I agree: they are high) are a one-time thing, while
the benefits are long term, and accrue/multiply with time. We should
make decisions like this with the long-term benefits in mind.
I expect Lucene and Solr to have long
On Thu, May 7, 2020 at 1:07 PM Bram Van Dam wrote:
> The big question is this: “Is this the right time to split Solr and
> > Lucene into two independent projects?”.
>
> Sounds like there are quite a few tasks to complete to get this done.
> Splitting the build and codebase. Presumably a bunch of
On Wed, May 6, 2020 at 4:24 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
Offtopic: Gus, I'm looking at Vespa core for Solr someday
>
+1, Vespa looks really fascinating! Plus it is released under ASL 2 as
well. And the world clearly needs more open-source search engines.
Mike
On Tue, May 5, 2020 at 4:59 PM Tomás Fernández Löbbe
wrote:
On Tue, May 5, 2020 at 12:37 PM Dawid Weiss wrote:
>
>> > I read “promotion to TLP” as if this was some achievement that needs to
>> be celebrated now.
>>
>> I honestly believe it is an achievement for a project to receive
>> top-level
Better stick to Lucene snapshot versions. Commit the Lucene change first, then
solr. If the Lucene change is not mature enough to commit to Lucene, it is
probably not mature enough for Solr either. Avoid hacks or forks, spend some
longer time to get it right.
If things get removed from Lucene
On Sun, May 10, 2020 at 11:55 AM Mike Drob wrote:
> Solr maintaining a fork of Lucene sounds like exactly the situation that
> let to the original merge, where there are two sets of divergent development
>
Exactly
I’m really struggling with what to do with compiler warnings, particularly all
the rawtypes and unchecked warnings.
On the one hand, the simple mechanical thing to do would be to SuppressWarnings
on each one that exists presently. Frankly that feels pretty useless; that
would preserve poor
Can't we customize the linting to disregard entire categories of certain
warnings for now? This makes your task manageable.
https://discuss.gradle.org/t/recompile-with-xlint-parameters/25279
~ David
On Sun, May 10, 2020 at 10:41 PM Erick Erickson
wrote:
> I’m really struggling with what to
12 matches
Mail list logo
