+1 too. With this new perspective we could create the branch just after the 7.6 release and target the 8.0 release for January 2019 which gives almost 3 month to finish the blockers ?
Le jeu. 18 oct. 2018 à 23:56, David Smiley <[email protected]> a écrit : > +1 to a 7.6 —lots of stuff in there > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <[email protected]> wrote: > >> If we're planning to postpone cutting an 8.0 branch until a few weeks >> from now then I'd like to propose (and volunteer to RM) a 7.6 release >> targeted for late November or early December (following the typical 2 month >> release pattern). It feels like this might give a little breathing room for >> finishing up 8.0 blockers? And looking at the change log there appear to be >> a healthy list of features, bug fixes, and improvements to both Solr and >> Lucene that warrant a 7.6 release? Personally I wouldn't mind releasing the >> LatLonShape encoding changes in LUCENE-8521 >> <https://issues.apache.org/jira/browse/LUCENE-8521> and selective >> indexing work done in LUCENE-8496 >> <https://issues.apache.org/jira/browse/LUCENE-8496>. Any objections or >> thoughts? >> >> - Nick >> >> >> On Thu, Oct 18, 2018 at 5:32 AM Đạt Cao Mạnh <[email protected]> >> wrote: >> >>> Thanks Cassandra and Jim, >>> >>> I created a blocker issue for Solr 8.0 SOLR-12883 >>> <https://issues.apache.org/jira/browse/SOLR-12883>, currently in >>> jira/http2 branch there are a draft-unmature implementation of SPNEGO >>> authentication which enough to makes the test pass, this implementation >>> will be removed when SOLR-12883 gets resolved . Therefore I don't see any >>> problem on merging jira/http2 to master branch in the next week. >>> >>> On Thu, Oct 18, 2018 at 2:33 AM jim ferenczi <[email protected]> >>> wrote: >>> >>>> > But if you're working with a different assumption - that just the >>>> existence of the branch does not stop Dat from still merging his work and >>>> the work being included in 8.0 - then I agree, waiting for him to merge >>>> doesn't need to stop the creation of the branch. >>>> >>>> Yes that's my reasoning. This issue is a blocker so we won't release >>>> without it but we can work on the branch in the meantime and let other >>>> people work on new features that are not targeted to 8. >>>> >>>> Le mer. 17 oct. 2018 à 20:51, Cassandra Targett <[email protected]> >>>> a écrit : >>>> >>>>> OK - I was making an assumption that the timeline for the first 8.0 RC >>>>> would be ASAP after the branch is created. >>>>> >>>>> It's a common perception that making a branch freezes adding new >>>>> features to the release, perhaps in an unofficial way (more of a courtesy >>>>> rather than a rule). But if you're working with a different assumption - >>>>> that just the existence of the branch does not stop Dat from still merging >>>>> his work and the work being included in 8.0 - then I agree, waiting for >>>>> him >>>>> to merge doesn't need to stop the creation of the branch. >>>>> >>>>> If, however, once the branch is there people object to Dat merging his >>>>> work because it's "too late", then the branch shouldn't be created yet >>>>> because we want to really try to clear that blocker for 8.0. >>>>> >>>>> Cassandra >>>>> >>>>> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi <[email protected]> >>>>> wrote: >>>>> >>>>>> Ok thanks for answering. >>>>>> >>>>>> > - I think Solr needs a couple more weeks since the work Dat is >>>>>> doing isn't quite done yet. >>>>>> >>>>>> We can wait a few more weeks to create the branch but I don't think >>>>>> that one action (creating the branch) prevents the other (the work Dat is >>>>>> doing). >>>>>> HTTP/2 is one of the blocker for the release but it can be done in >>>>>> master and backported to the appropriate branch as any other feature ? We >>>>>> just need an issue with the blocker label to ensure that >>>>>> we don't miss it ;). Creating the branch early would also help in >>>>>> case you don't want to release all the work at once in 8.0.0. >>>>>> Next week was just a proposal, what I meant was soon because we >>>>>> target a release in a few months. >>>>>> >>>>>> >>>>>> Le mer. 17 oct. 2018 à 17:52, Cassandra Targett < >>>>>> [email protected]> a écrit : >>>>>> >>>>>>> IMO next week is a bit too soon for the branch - I think Solr needs >>>>>>> a couple more weeks since the work Dat is doing isn't quite done yet. >>>>>>> >>>>>>> Solr needs the HTTP/2 work Dat has been doing, and he told me >>>>>>> yesterday he feels it is nearly ready to be merged into master. >>>>>>> However, it >>>>>>> does require a new release of Jetty to Solr is able to retain Kerberos >>>>>>> authentication support (Dat has been working with that team to help test >>>>>>> the changes Jetty needs to support Kerberos with HTTP/2). They should >>>>>>> get >>>>>>> that release out soon, but we are dependent on them a little bit. >>>>>>> >>>>>>> He can hopefully reply with more details on his status and what else >>>>>>> needs to be done. >>>>>>> >>>>>>> Once Dat merges his work, IMO we should leave it in master for a >>>>>>> little bit. While he has been beasting and testing with Jenkins as he >>>>>>> goes >>>>>>> along, I think it would be good to have all the regular master builds >>>>>>> work >>>>>>> on it for a little bit also. >>>>>>> >>>>>>> Of the other blockers, the only other large-ish one is to fully >>>>>>> remove Trie* fields, which some of us also discussed yesterday and it >>>>>>> seemed we concluded that Solr isn't really ready to do that. The >>>>>>> performance issues with single value lookups are a major obstacle. It >>>>>>> would >>>>>>> be nice if someone with a bit more experience with that could comment in >>>>>>> the issue (SOLR-12632) and/or unmark it as a blocker. >>>>>>> >>>>>>> Cassandra >>>>>>> >>>>>>> On Wed, Oct 17, 2018 at 8:38 AM Erick Erickson < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I find 9 open blockers for 8.0: >>>>>>>> >>>>>>>> >>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20status%20%3D%20OPEN >>>>>>>> >>>>>>>> As David mentioned, many of the SOlr committers are at Activate, >>>>>>>> which >>>>>>>> ends Thursday so feedback (and work) may be a bit delayed. >>>>>>>> On Wed, Oct 17, 2018 at 8:11 AM David Smiley < >>>>>>>> [email protected]> wrote: >>>>>>>> > >>>>>>>> > Hi, >>>>>>>> > >>>>>>>> > Thanks for volunteering to do the 8.0 release Jim! >>>>>>>> > >>>>>>>> > Many of us are at the Activate Conference in Montreal. We had a >>>>>>>> committers meeting where we discussed some of the blockers. I think >>>>>>>> only a >>>>>>>> couple items were raised. I'll leave Dat to discuss the one on HTTP2. >>>>>>>> On >>>>>>>> the Solr nested docs front, I articulated one and we mostly came to a >>>>>>>> decision on how to do it. It's not "hard" just a matter of how to >>>>>>>> hook in >>>>>>>> some functionality so that it's user-friendly. I'll file an issue for >>>>>>>> this. Inexplicably I'm sheepish about marking issues "blocker" but I >>>>>>>> shouldn't be. I'll file that issue and look at another issue or two >>>>>>>> that >>>>>>>> ought to be blockers. Nothing is "hard" or tons of work that is in my >>>>>>>> sphere of work. >>>>>>>> > >>>>>>>> > On the Lucene side, I will commit >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-7875 RE MultiFields >>>>>>>> either late tonight or tomorrow when I have time. It's ready to be >>>>>>>> committed; just sitting there. It's a minor thing but important to >>>>>>>> make >>>>>>>> this change now before 8.0. >>>>>>>> > >>>>>>>> > I personally plan to spend more time on the upcoming weeks on a >>>>>>>> few of these 8.0 things. >>>>>>>> > >>>>>>>> > ~ David >>>>>>>> > >>>>>>>> > >>>>>>>> > On Wed, Oct 17, 2018 at 4:21 AM jim ferenczi < >>>>>>>> [email protected]> wrote: >>>>>>>> >> >>>>>>>> >> Hi, >>>>>>>> >> We still have two blockers for the Lucene 8 release: >>>>>>>> >> >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-7075?jql=(project%3D%22Lucene%20-%20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocker%20and%20resolution%20%3D%20Unresolved%20 >>>>>>>> >> We're planning to work on these issues in the coming days, are >>>>>>>> there any other blockers (not in the list) on Solr side. >>>>>>>> >> Now that Lucene 7.5 is released I'd like to create a Lucene 8 >>>>>>>> branch soon (next week for instance ? ). There are some work to do to >>>>>>>> make >>>>>>>> sure that all tests pass, add the new version... >>>>>>>> >> I can take care of it if there are no objections. Creating the >>>>>>>> branch in advance would help to stabilize this version (people can >>>>>>>> continue >>>>>>>> to work on new features that are not targeted for 8.0) and >>>>>>>> >> we can discuss the best date for the release when all blockers >>>>>>>> are resolved. What do you think ? >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> Le mar. 18 sept. 2018 à 11:32, Adrien Grand <[email protected]> >>>>>>>> a écrit : >>>>>>>> >>> >>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR-12639 the >>>>>>>> right issue for HTTP/2 support? Should we make it a blocker for 8.0? >>>>>>>> >>> >>>>>>>> >>> Le lun. 3 sept. 2018 à 23:37, Adrien Grand <[email protected]> >>>>>>>> a écrit : >>>>>>>> >>>> >>>>>>>> >>>> For the record here is the JIRA query for blockers that Erick >>>>>>>> referred to: >>>>>>>> https://issues.apache.org/jira/browse/SOLR-12720?jql=(project%3D%22Lucene%20-%20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocker%20and%20resolution%20%3D%20Unresolved%20 >>>>>>>> >>>> >>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi < >>>>>>>> [email protected]> a écrit : >>>>>>>> >>>>> >>>>>>>> >>>>> Ok thanks Đạt and Erick. I'll follow the blockers on Jira. >>>>>>>> Đạt do you have an issue opened for the HTTP/2 support ? >>>>>>>> >>>>> >>>>>>>> >>>>> Le ven. 31 août 2018 à 16:40, Erick Erickson < >>>>>>>> [email protected]> a écrit : >>>>>>>> >>>>>> >>>>>>>> >>>>>> There's also the issue of what to do as far as removing >>>>>>>> Trie* support. >>>>>>>> >>>>>> I think there's a blocker JIRA. >>>>>>>> >>>>>> >>>>>>>> >>>>>> project = SOLR AND priority = Blocker AND resolution = >>>>>>>> Unresolved >>>>>>>> >>>>>> >>>>>>>> >>>>>> Shows 6 blockers >>>>>>>> >>>>>> On Fri, Aug 31, 2018 at 4:12 AM Đạt Cao Mạnh < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>> > >>>>>>>> >>>>>> > Hi Jim, >>>>>>>> >>>>>> > >>>>>>>> >>>>>> > I really want to introduce the support of HTTP/2 into Solr >>>>>>>> 8.0 (currently cooked in jira/http2 branch). The changes of that >>>>>>>> branch are >>>>>>>> less than Star Burst effort and closer to be merged into master branch. >>>>>>>> >>>>>> > >>>>>>>> >>>>>> > Thanks! >>>>>>>> >>>>>> > >>>>>>>> >>>>>> > On Fri, Aug 31, 2018 at 3:55 PM jim ferenczi < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>> >> >>>>>>>> >>>>>> >> Hi all, >>>>>>>> >>>>>> >> I'd like to get some feedback regarding the upcoming >>>>>>>> Lucene/Solr 8 release. There are still some cleanups and docs to add >>>>>>>> on the >>>>>>>> Lucene side but it seems that all blockers are resolved. >>>>>>>> >>>>>> >> From a Solr perspective are there any important changes >>>>>>>> that need to be done or are we still good with the October target for >>>>>>>> the >>>>>>>> release ? Adrien mentioned the Star Burst effort some time ago, is it >>>>>>>> something that is planned for 8 ? >>>>>>>> >>>>>> >> >>>>>>>> >>>>>> >> Cheers, >>>>>>>> >>>>>> >> Jim >>>>>>>> >>>>>> >> >>>>>>>> >>>>>> >> Le mer. 1 août 2018 à 19:02, David Smiley < >>>>>>>> [email protected]> a écrit : >>>>>>>> >>>>>> >>> >>>>>>>> >>>>>> >>> Yes, that new BKD/Points based code is definitely >>>>>>>> something we want in 8 or 7.5 -- it's a big deal. I think it would >>>>>>>> also be >>>>>>>> awesome if we had highlighter that could use the Weight.matches() API >>>>>>>> -- >>>>>>>> again for either 7.5 or 8. I'm working on this on the >>>>>>>> UnifiedHighlighter >>>>>>>> front and Alan from other aspects. >>>>>>>> >>>>>> >>> ~ David >>>>>>>> >>>>>> >>> >>>>>>>> >>>>>> >>> On Wed, Aug 1, 2018 at 12:51 PM Adrien Grand < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>> >>>> >>>>>>>> >>>>>> >>>> I was hoping that we would release some bits of this >>>>>>>> new support for geo shapes in 7.5 already. We are already very close to >>>>>>>> being able to index points, lines and polygons and query for >>>>>>>> intersection >>>>>>>> with an envelope. It would be nice to add support for other relations >>>>>>>> (eg. >>>>>>>> disjoint) and queries (eg. polygon) but the current work looks already >>>>>>>> useful to me. >>>>>>>> >>>>>> >>>> >>>>>>>> >>>>>> >>>> Le mer. 1 août 2018 à 17:00, Robert Muir < >>>>>>>> [email protected]> a écrit : >>>>>>>> >>>>>> >>>>> >>>>>>>> >>>>>> >>>>> My only other suggestion is we may want to get Nick's >>>>>>>> shape stuff into >>>>>>>> >>>>>> >>>>> the sandbox module at least for 8.0 so that it can be >>>>>>>> tested out. I >>>>>>>> >>>>>> >>>>> think it looks like that wouldn't delay any October >>>>>>>> target though? >>>>>>>> >>>>>> >>>>> >>>>>>>> >>>>>> >>>>> On Wed, Aug 1, 2018 at 9:51 AM, Adrien Grand < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>> >>>>> > I'd like to revive this thread now that these new >>>>>>>> optimizations for >>>>>>>> >>>>>> >>>>> > collection of top docs are more usable and enabled >>>>>>>> by default in >>>>>>>> >>>>>> >>>>> > IndexSearcher ( >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8060). Any >>>>>>>> >>>>>> >>>>> > feedback about starting to work towards releasing >>>>>>>> 8.0 and targeting October >>>>>>>> >>>>>> >>>>> > 2018? >>>>>>>> >>>>>> >>>>> > >>>>>>>> >>>>>> >>>>> > >>>>>>>> >>>>>> >>>>> > Le jeu. 21 juin 2018 à 09:31, Adrien Grand < >>>>>>>> [email protected]> a écrit : >>>>>>>> >>>>>> >>>>> >> >>>>>>>> >>>>>> >>>>> >> Hi Robert, >>>>>>>> >>>>>> >>>>> >> >>>>>>>> >>>>>> >>>>> >> I agree we need to make it more usable before 8.0. >>>>>>>> I would also like to >>>>>>>> >>>>>> >>>>> >> improve ReqOptSumScorer ( >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8204) >>>>>>>> >>>>>> >>>>> >> to leverage impacts so that queries that >>>>>>>> incorporate queries on feature >>>>>>>> >>>>>> >>>>> >> fields ( >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8197) in an optional >>>>>>>> >>>>>> >>>>> >> clause are also fast. >>>>>>>> >>>>>> >>>>> >> >>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir < >>>>>>>> [email protected]> a écrit : >>>>>>>> >>>>>> >>>>> >>> >>>>>>>> >>>>>> >>>>> >>> How can the end user actually use the biggest new >>>>>>>> feature: impacts and >>>>>>>> >>>>>> >>>>> >>> BMW? As far as I can tell, the issue to actually >>>>>>>> implement the >>>>>>>> >>>>>> >>>>> >>> necessary API changes (IndexSearcher/TopDocs/etc) >>>>>>>> is still open and >>>>>>>> >>>>>> >>>>> >>> unresolved, although there are some interesting >>>>>>>> ideas on it. This >>>>>>>> >>>>>> >>>>> >>> seems like a really big missing piece, without a >>>>>>>> proper API, the stuff >>>>>>>> >>>>>> >>>>> >>> is not really usable. I also can't imagine a >>>>>>>> situation where the API >>>>>>>> >>>>>> >>>>> >>> could be introduced in a followup minor release >>>>>>>> because it would be >>>>>>>> >>>>>> >>>>> >>> too invasive. >>>>>>>> >>>>>> >>>>> >>> >>>>>>>> >>>>>> >>>>> >>> On Mon, Jun 18, 2018 at 1:19 PM, Adrien Grand < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>> >>>>> >>> > Hi all, >>>>>>>> >>>>>> >>>>> >>> > >>>>>>>> >>>>>> >>>>> >>> > I would like to start discussing releasing >>>>>>>> Lucene/Solr 8.0. Lucene 8 >>>>>>>> >>>>>> >>>>> >>> > already >>>>>>>> >>>>>> >>>>> >>> > has some good changes around scoring, notably >>>>>>>> cleanups to >>>>>>>> >>>>>> >>>>> >>> > similarities[1][2][3], indexing of impacts[4], >>>>>>>> and an implementation of >>>>>>>> >>>>>> >>>>> >>> > Block-Max WAND[5] which, once combined, allow to >>>>>>>> run queries faster >>>>>>>> >>>>>> >>>>> >>> > when >>>>>>>> >>>>>> >>>>> >>> > total hit counts are not requested. >>>>>>>> >>>>>> >>>>> >>> > >>>>>>>> >>>>>> >>>>> >>> > [1] >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8116 >>>>>>>> >>>>>> >>>>> >>> > [2] >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8020 >>>>>>>> >>>>>> >>>>> >>> > [3] >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8007 >>>>>>>> >>>>>> >>>>> >>> > [4] >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-4198 >>>>>>>> >>>>>> >>>>> >>> > [5] >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8135 >>>>>>>> >>>>>> >>>>> >>> > >>>>>>>> >>>>>> >>>>> >>> > In terms of bug fixes, there is also a bad >>>>>>>> relevancy bug[6] which is >>>>>>>> >>>>>> >>>>> >>> > only in >>>>>>>> >>>>>> >>>>> >>> > 8.0 because it required a breaking change[7] to >>>>>>>> be implemented. >>>>>>>> >>>>>> >>>>> >>> > >>>>>>>> >>>>>> >>>>> >>> > [6] >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8031 >>>>>>>> >>>>>> >>>>> >>> > [7] >>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8134 >>>>>>>> >>>>>> >>>>> >>> > >>>>>>>> >>>>>> >>>>> >>> > As usual, doing a new major release will also >>>>>>>> help age out old codecs, >>>>>>>> >>>>>> >>>>> >>> > which >>>>>>>> >>>>>> >>>>> >>> > in-turn make maintenance easier: 8.0 will no >>>>>>>> longer need to care about >>>>>>>> >>>>>> >>>>> >>> > the >>>>>>>> >>>>>> >>>>> >>> > fact that some codecs were initially implemented >>>>>>>> with a random-access >>>>>>>> >>>>>> >>>>> >>> > API >>>>>>>> >>>>>> >>>>> >>> > for doc values, that pre-7.0 indices encoded >>>>>>>> norms differently, or that >>>>>>>> >>>>>> >>>>> >>> > pre-6.2 indices could not record an index sort. >>>>>>>> >>>>>> >>>>> >>> > >>>>>>>> >>>>>> >>>>> >>> > I also expect that we will come up with ideas of >>>>>>>> things to do for 8.0 >>>>>>>> >>>>>> >>>>> >>> > as we >>>>>>>> >>>>>> >>>>> >>> > feel that the next major is getting closer. In >>>>>>>> terms of planning, I was >>>>>>>> >>>>>> >>>>> >>> > thinking that we could target something like >>>>>>>> october 2018, which would >>>>>>>> >>>>>> >>>>> >>> > be >>>>>>>> >>>>>> >>>>> >>> > 12-13 months after 7.0 and 3-4 months from now. >>>>>>>> >>>>>> >>>>> >>> > >>>>>>>> >>>>>> >>>>> >>> > From a Solr perspective, the main change I'm >>>>>>>> aware of that would be >>>>>>>> >>>>>> >>>>> >>> > worth >>>>>>>> >>>>>> >>>>> >>> > releasing a new major is the Star Burst effort. >>>>>>>> Is it something we want >>>>>>>> >>>>>> >>>>> >>> > to >>>>>>>> >>>>>> >>>>> >>> > get in for 8.0? >>>>>>>> >>>>>> >>>>> >>> > >>>>>>>> >>>>>> >>>>> >>> > Adrien >>>>>>>> >>>>>> >>>>> >>> >>>>>>>> >>>>>> >>>>> >>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>> >>>>> >>> To unsubscribe, e-mail: >>>>>>>> [email protected] >>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: >>>>>>>> [email protected] >>>>>>>> >>>>>> >>>>> >>> >>>>>>>> >>>>>> >>>>> > >>>>>>>> >>>>>> >>>>> >>>>>>>> >>>>>> >>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: >>>>>>>> [email protected] >>>>>>>> >>>>>> >>>>> For additional commands, e-mail: >>>>>>>> [email protected] >>>>>>>> >>>>>> >>>>> >>>>>>>> >>>>>> >>> -- >>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, Developer, >>>>>>>> Author, Speaker >>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >>>>>>>> http://www.solrenterprisesearchserver.com >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>> >>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>> >>>>>>>> > -- >>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, Author, >>>>>>>> Speaker >>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >>>>>>>> http://www.solrenterprisesearchserver.com >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> -- >> >> Nicholas Knize, Ph.D., GISP >> Geospatial Software Guy | Elasticsearch >> Apache Lucene Committer >> [email protected] >> > -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > http://www.solrenterprisesearchserver.com >
