|Robert Muir||Apr 26, 2011 8:07 pm|
|Yonik Seeley||Apr 26, 2011 8:34 pm|
|Grant Ingersoll||Apr 26, 2011 8:41 pm|
|Chris Male||Apr 26, 2011 9:12 pm|
|Robert Muir||Apr 26, 2011 9:14 pm|
|Michael McCandless||Apr 27, 2011 3:27 am|
|Michael McCandless||Apr 27, 2011 3:36 am|
|Mark Miller||Apr 27, 2011 5:12 am|
|Robert Muir||Apr 27, 2011 5:33 am|
|Steven A Rowe||Apr 27, 2011 6:18 am|
|Yonik Seeley||Apr 27, 2011 6:24 am|
|Steven A Rowe||Apr 27, 2011 6:48 am|
|Michael McCandless||Apr 27, 2011 8:49 am|
|Grant Ingersoll||Apr 27, 2011 5:50 pm|
|Yonik Seeley||Apr 27, 2011 6:23 pm|
|Greg Stein||Apr 27, 2011 8:44 pm|
|Grant Ingersoll||May 2, 2011 3:11 pm|
|Ryan McKinley||May 2, 2011 4:31 pm|
|Mark Miller||May 2, 2011 7:27 pm|
|Michael McCandless||May 3, 2011 9:49 am|
|Michael McCandless||May 3, 2011 9:55 am|
|Mark Miller||May 3, 2011 10:11 am|
|Shai Erera||May 3, 2011 10:29 am|
|Ryan McKinley||May 3, 2011 10:31 am|
|Mark Miller||May 3, 2011 10:46 am|
|Michael McCandless||May 4, 2011 5:25 am|
|Mark Miller||May 4, 2011 6:10 am|
|Robert Muir||May 4, 2011 6:29 am|
|Uwe Schindler||May 4, 2011 6:41 am|
|Mark Miller||May 4, 2011 6:49 am|
|Simon Willnauer||May 4, 2011 7:01 am|
|Simon Willnauer||May 5, 2011 1:15 am|
|Grant Ingersoll||May 5, 2011 7:25 am|
|Mark Miller||May 5, 2011 7:40 am|
|Simon Willnauer||May 5, 2011 8:03 am|
|Grant Ingersoll||May 5, 2011 8:34 am|
|Jason Rutherglen||May 5, 2011 9:58 am|
|Chris Hostetter||May 6, 2011 1:35 pm|
|Mark Miller||May 6, 2011 1:44 pm|
|Michael McCandless||May 7, 2011 3:30 am|
|Simon Willnauer||May 7, 2011 3:34 am|
|Michael McCandless||May 7, 2011 3:45 am|
|Michael McCandless||May 7, 2011 4:01 am|
|Simon Willnauer||May 7, 2011 4:10 am|
|Grant Ingersoll||May 7, 2011 5:20 am|
|Subject:||Re: modularization discussion|
|From:||Michael McCandless (luc...@mikemccandless.com)|
|Date:||May 3, 2011 9:55:18 am|
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.... but, this turns into a non-issue once Solr is well factored into modules, because by the time we arrive at that future, "depending on Solr" just means "depending on Solr modules", which resolves my concern!
On Mon, May 2, 2011 at 6:11 PM, Grant Ingersoll <gsin...@apache.org> wrote:
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 me... I really don't understand.
At the risk of speaking for someone else, I think it has to do w/ wanting to
maintain brand awareness for Solr. We, as the PMC, currently produce two
products: Apache Lucene and Apache Solr. I believe Yonik's concern is that if
everything is just labeled Lucene, then Solr is just seen as a very thin shell
around Lucene (which, IMO, would still not be the case, since wiring together a
server app like Solr is non-trivial, but that is my opinion and I'm not sure if
Yonik share's it). Solr has never been a thin shell around Lucene and never
will be. However, In some ways, this gets at why I believe Yonik was
interested in a Solr TLP: so that Solr could stand on it's own as a brand and as
a first class Apache product steered by a PMC that is aligned solely w/
producing the Solr (i.e. as a TLP) product as opposed to the two products we
produce now. (Note, my vote on such a TLP was -1, so please don't confuse me as
arguing for the point, I'm just trying to, hopefully, explain it)
That being said, 99% of consumers of Solr never even know what is in the
underlying namespace b/c they only ever interact w/ Solr via HTTP (which has
solr in the namespace by default) at the server API level, so at least in my
mind, I don't care what the namespace used underneath is. Call it lusolr for
all I care.
What does "fairness" have to do with the codebase?
I can't speak to this, but perhaps it's just the wrong choice of words and would
have been better said: please don't take this as a reason to gut Solr and call
Isn't the whole point of the Lucene project to create the best code possible, for the benefit of our worldwide users?
It is. We do that primarily through the release of two products: Lucene and
Solr. Lucene is a Java class library. A good deal of programming is required
to create anything meaningful in terms of a production ready search server.
Solr is a server that takes and makes most things that are programming tasks in
Lucene configuration tasks as well as adds a fair bit of functionality
(distributed search, replication, faceting, auto-suggest, etc.) and is thus that
much easier to put in production (I've seen people be in production on Solr in a
matter of days/weeks, I've never seen that in Lucene) The crux of this debate
is whether these additional pieces are better served as modules (I think they
are) or tightly coupled inside of Solr (which does have a few benefits from a
dev. point of view, even though I firmly believe they are outweighed by the
positives of modularization.) And, while I think most of us agree that
modularization makes sense, that doesn't mean there aren't reasons against it.
I also believe we need to take it on a case by case basis. I also don't think
every patch has to be in it's final place on first commit. As Otis so often
says, it's just software. If it doesn't work, change it. Thus, if people
contribute and it lands in Solr, the committer who commits it need not
immediately move it (although, hopefully they will) or ask the contributor to do
so, as that will likely dampen contributions. Likewise for Lucene. Along with
that, if and when others wish to refactor, then they should by all means be
allowed to do so assuming of course, all tests across both products still pass.
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 don't know what the outcome of this thread should be, so I guess we need to
just move forward and keep coding away and working to make things better. Do
others see anything broader here? A vote? That would be symbolic, I guess, but
doesn't force anyone to do anything since there isn't a specific issue at hand
other than a broad concept that is seen as "good".