On May 7, 2011, at 6:30 AM, Michael McCandless wrote:
>
> Grant if I'm reading your response right, you agree with that freedom
> (others are free to refactor); you're just tempering in a good dose of
> reality ("refactoring is hard"), which I agree with.
That is exactly what I am saying. And
On Sat, May 7, 2011 at 1:02 PM, Michael McCandless
wrote:
> OK I opened:
>
> https://issues.apache.org/jira/browse/LUCENE-3079
awesome!
+1
>
> Mike
>
> http://blog.mikemccandless.com
>
> On Sat, May 7, 2011 at 6:46 AM, Michael McCandless
> wrote:
>> I agree! And I think you're saying the sam
OK I opened:
https://issues.apache.org/jira/browse/LUCENE-3079
Mike
http://blog.mikemccandless.com
On Sat, May 7, 2011 at 6:46 AM, Michael McCandless
wrote:
> I agree! And I think you're saying the same thing as Grant.
>
> Ie, others are fully free to refactor stuff, as long as they don't
I agree! And I think you're saying the same thing as Grant.
Ie, others are fully free to refactor stuff, as long as they don't
hurt Solr/Lucene (functionality, performance).
But you are tempering that with a nice dose of reality (successfully
factoring out faceting will be insanely hard).
I ver
On Sat, May 7, 2011 at 12:30 PM, Michael McCandless
wrote:
> I agree: refactoring is TONS of work. Even cases that seem cut and
> dry, from a distance, quickly prove to be hairy (just ask Robert about
> refactoring analyzers).
>
> However, I think "unproven gain" is too strong. EG, just a few da
I agree: refactoring is TONS of work. Even cases that seem cut and
dry, from a distance, quickly prove to be hairy (just ask Robert about
refactoring analyzers).
However, I think "unproven gain" is too strong. EG, just a few days
ago we had a user thread asking how to use auto-suggest outside of
+1, +1, +1, +1, +1, +1 - This is just what I've been trying (and seemingly
failing) to express.
On May 6, 2011, at 4:35 PM, Chris Hostetter wrote:
>
> : To me, the third camp is just saying the proof is in the pudding. If
> : you want to refactor, then go for it. Just make sure everything st
: To me, the third camp is just saying the proof is in the pudding. If
: you want to refactor, then go for it. Just make sure everything still
: works, which of course I know people will (but part of that means
: actually running Solr, IMO). Perhaps, more importantly don't get mad
: that if
+1 to Mike's proposal here. Each of these could easily be
patches/issues. The top ones would probably be the basics, eg,
faceting and schemas.
As the easiest short term solution for allowing other systems to use
Solr or it's features, it would be great if a 'committer' responded to
SOLR-1431. E
On May 5, 2011, at 11:03 AM, Simon Willnauer wrote:
> On Thu, May 5, 2011 at 4:41 PM, Mark Miller wrote:
>>
>> On May 5, 2011, at 10:25 AM, Grant Ingersoll wrote:
>>
>>> 3. Those who think most should be modularized, but realize it's a ton of
>>> work for an unproven gain (although most admi
On Thu, May 5, 2011 at 4:41 PM, Mark Miller wrote:
>
> On May 5, 2011, at 10:25 AM, Grant Ingersoll wrote:
>
>> 3. Those who think most should be modularized, but realize it's a ton of
>> work for an unproven gain (although most admit it is a highly likely gain)
>> and should be handled on a ca
On May 5, 2011, at 10:25 AM, Grant Ingersoll wrote:
> 3. Those who think most should be modularized, but realize it's a ton of
> work for an unproven gain (although most admit it is a highly likely gain)
> and should be handled on a case-by-case basis as people do the work. I
> don't have a
On May 5, 2011, at 4:15 AM, Simon Willnauer wrote:
> Hey folks
>
> On Tue, May 3, 2011 at 6:49 PM, Michael McCandless
> wrote:
>> Isn't our end goal here a bunch of well factored search modules? Ie,
>> fast forward a year or two and I think we should have modules like
>> these:
>
> I think we
Hey folks
On Tue, May 3, 2011 at 6:49 PM, Michael McCandless
wrote:
> Isn't our end goal here a bunch of well factored search modules? Ie,
> fast forward a year or two and I think we should have modules like
> these:
I think we have two camps here (10k feet view):
1. wants to move towards modu
On Wed, May 4, 2011 at 3:49 PM, Mark Miller wrote:
>
> On May 4, 2011, at 9:42 AM, Uwe Schindler wrote:
>
>> Solr has no performance testing framework, see the issue from today
>> (SOLR-2493).
>
> Come to Berlin Buzzwords!
I think I will come :)
simon
>
> (I know you already are :) )
>
> - Mark M
On May 4, 2011, at 9:42 AM, Uwe Schindler wrote:
> Solr has no performance testing framework, see the issue from today
> (SOLR-2493).
Come to Berlin Buzzwords!
(I know you already are :) )
- Mark Miller
lucidimagination.com
Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevol
> From: Robert Muir [mailto:rcm...@gmail.com]
> Sent: Wednesday, May 04, 2011 3:30 PM
> To: dev@lucene.apache.org
> Subject: Re: modularization discussion
>
> On Wed, May 4, 2011 at 9:11 AM, Mark Miller
> wrote:
> > Side note (plug): I have been playing with the bench
On Wed, May 4, 2011 at 9:11 AM, Mark Miller wrote:
> Side note (plug): I have been playing with the benchmark module (who did that
> module? I had missed it), and I've got some cool stuff to show at Berlin
> Buzzwords this year for my solr performance talk!
>
we svn move'd it here: https://issu
On May 4, 2011, at 8:25 AM, Michael McCandless wrote:
> Mark,
>
> Can you give some more details on your disagreement here...?
>
> Are there certain modules from my list that you don't think should be
> modules? The timeframe (1-2 years) is too optimistic/aggressive? Or
> you disagree that we
Mark,
Can you give some more details on your disagreement here...?
Are there certain modules from my list that you don't think should be
modules? The timeframe (1-2 years) is too optimistic/aggressive? Or
you disagree that we should poach from outside projects too...?
Or, more generally, you d
On May 3, 2011, at 1:29 PM, Shai Erera wrote:
> I don't like that approach. Two years from now, if indeed your vision becomes
> the reality (obviously, not everyone think like you), what would o.a.solr
> mean? Who will remember that 'suggest' (just picking an example) came from
> Solr? Who'd c
On Tue, May 3, 2011 at 1:11 PM, Mark Miller wrote:
>
> On May 3, 2011, at 12:49 PM, Michael McCandless wrote:
>
>> Isn't this the future we are working towards?
>
> No, not really. Others perhaps, but not me. I'm on board with some modules. I
> do think there are tradeoffs when considering them a
On the namespace, since Yonik seems concerned about it, and others
aren't (I think?), why don't we leave everything factored out of Solr
under the under org.apache.solr namespace?
Anyone object to that approach?
I don't like that approach. Two years from now, if indeed your vision
becomes the real
On May 3, 2011, at 12:49 PM, Michael McCandless wrote:
> Isn't this the future we are working towards?
No, not really. Others perhaps, but not me. I'm on board with some modules. I
do think there are tradeoffs when considering them and considering Lucene and
Solr. I'm happy to take everything
On the namespace, since Yonik seems concerned about it, and others
aren't (I think?), why don't we leave everything factored out of Solr
under the under org.apache.solr namespace?
Anyone object to that approach?
My only concern is that this sends the message that the module depends
on Solr bu
Isn't our end goal here a bunch of well factored search modules? Ie,
fast forward a year or two and I think we should have modules like
these:
* Faceting
* Highlighting
* Suggest (good patch is on LUCENE-2995)
* Schema
* Query impls
* Query parsers
* Analyzers (good progress h
On May 2, 2011, at 7:31 PM, Ryan McKinley wrote:
>
> In short, I believe people should still contribute where they see they can
> add the most value and according to their time schedules. Additionally,
> others who have more time or the ability to refactor for reusability should
> be free to
>
>
> In short, I believe people should still contribute where they see they can
> add the most value and according to their time schedules. Additionally,
> others who have more time or the ability to refactor for reusability should
> be free to do so as well.
>
I agree that people should be able
On Apr 27, 2011, at 11:45 PM, Greg Stein wrote:
> On Wed, Apr 27, 2011 at 09:25:14AM -0400, Yonik Seeley wrote:
>> ...
>> But as I said... it seems only fair to meet half way and use the solr
>> namespace
>> for some modules and the lucene namespace for others.
>
> Please explain this part to m
On Wed, Apr 27, 2011 at 09:25:14AM -0400, Yonik Seeley wrote:
>...
> But as I said... it seems only fair to meet half way and use the solr
> namespace
> for some modules and the lucene namespace for others.
Please explain this part to me... I really don't understand.
What does "fairness" have to
On Apr 26, 2011, at 11:12 PM, Chris Male wrote:
> > The two sides/takes seem to be (with some example reasons):
> > 1. pro: for example, modularization can expose features that were
> > traditionally in solr to lucene users.
>
> Some other Pros:
> Easier to test individual pieces. Easier to b
On Wed, Apr 27, 2011 at 11:49 AM, Michael McCandless
wrote:
> On Wed, Apr 27, 2011 at 9:25 AM, Yonik Seeley
> wrote:
>> On Wed, Apr 27, 2011 at 6:28 AM, Michael McCandless
>> wrote:
>>> Why impose namespace restrictions based on where code was originally
>>> committed? I think the namespace of
On Wed, Apr 27, 2011 at 9:25 AM, Yonik Seeley
wrote:
> On Wed, Apr 27, 2011 at 6:28 AM, Michael McCandless
> wrote:
>> Why impose namespace restrictions based on where code was originally
>> committed? I think the namespace of refactored code should reflect
>> the nature of the code, not its ori
On 4/27/2011 at 9:25 AM, Yonik wrote:
> it seems only fair to meet half way and use the solr namespace
> for some modules and the lucene namespace for others.
Let's eliminate a source of conflict, and make modules another product that is
neither Lucene nor Solr.
Steve
On Wed, Apr 27, 2011 at 6:28 AM, Michael McCandless
wrote:
> Why impose namespace restrictions based on where code was originally
> committed? I think the namespace of refactored code should reflect
> the nature of the code, not its original origins?
And if it's a very core part of solr that we'
> if its not stated as "this feature is going to Lucene"
It seems as though some people assume that since Lucene is a library, and Solr
is an application, that exposing Solr API *means* making it part of Lucene. It
ain't necessarily so, and it need not be a point of contention.
I want to reite
On Wed, Apr 27, 2011 at 8:13 AM, Mark Miller wrote:
> The problem is that Simon says things like, everything should be a module and
> solr should just be sugar on Lucene. That scares Yonik. Then Yonik makes
> comments questioning individual modules. That scares the other guys. Both
> sides ret
On Apr 27, 2011, at 12:14 AM, Robert Muir wrote:
> On Tue, Apr 26, 2011 at 11:41 PM, Grant Ingersoll wrote:
>> I think this needs a bit more explanation. AIUI, the primary cause for
>> concern is that by making something a module, you are taking a private,
>> internal API of Solr's and now ma
On Tue, Apr 26, 2011 at 11:41 PM, Grant Ingersoll wrote:
> I think this needs a bit more explanation. AIUI, the primary cause for
> concern is that by making something a module, you are taking a private,
> internal API of Solr's and now making it a public API that must be maintained
> (and ba
On Tue, Apr 26, 2011 at 11:34 PM, Yonik Seeley
wrote:
> On Tue, Apr 26, 2011 at 11:07 PM, Robert Muir wrote:
>> It appears there are some problems with modularization of the code,
>> especially between lucene and solr, so I would like for us to have a
>> discussion on this thread.
>
> The specifi
On Tue, Apr 26, 2011 at 11:41 PM, Grant Ingersoll wrote:
> I think this needs a bit more explanation. AIUI, the primary cause for
> concern is that by making something a module, you are taking a private,
> internal API of Solr's and now making it a public API that must be maintained
> (and bac
>
> > The two sides/takes seem to be (with some example reasons):
> > 1. pro: for example, modularization can expose features that were
> > traditionally in solr to lucene users.
>
> Some other Pros:
> Easier to test individual pieces. Easier to benchmark.
> More usage == more/better features/func
On Apr 26, 2011, at 10:07 PM, Robert Muir wrote:
> Hi,
>
> It appears there are some problems with modularization of the code,
> especially between lucene and solr, so I would like for us to have a
> discussion on this thread.
>
+1
> The two sides/takes seem to be (with some example reasons)
On Tue, Apr 26, 2011 at 11:07 PM, Robert Muir wrote:
> It appears there are some problems with modularization of the code,
> especially between lucene and solr, so I would like for us to have a
> discussion on this thread.
The specifics of each case matter of course.
As a general point, lucene a
44 matches
Mail list logo
