Thanks for doing this Alan. I'll handle RAMDirectory* removals from the new master (LUCENE-8474)
D. On Tue, Jan 8, 2019 at 10:11 AM Alan Woodward <[email protected]> wrote: > > > It looks like someone renamed the "master (8.0)" version of SOLR & LUCENE > > in Jira to "master (9.0)" but IIUC that's definitely *NOT* correct ... > > because it means all the stuff that's been committed to origin/master over > > the past X months won't be listed as "fixed in '8.0'" when people look > > at jira in the future. > > That would be me… I’ll clean it up, thanks for pointing it out Hoss. > > > On 7 Jan 2019, at 23:45, Chris Hostetter <[email protected]> wrote: > > > > : OK, Christmas caught up with me a bit… I’ve just created a branch for 8x > > : from master, and am in the process of updating the master branch to > > : version 9. New commits that should be included in the 8.0 release > > : should also be back-ported to branch_8x from master. > > > > It looks like someone renamed the "master (8.0)" version of SOLR & LUCENE > > in Jira to "master (9.0)" but IIUC that's definitely *NOT* correct ... > > because it means all the stuff that's been committed to origin/master over > > the past X months won't be listed as "fixed in '8.0'" when people look > > at jira in the future. > > > > I'm pretty sure "master (8.0)" should have been renamed "8.0" and a > > completely > > new version (with a new internal ID in jira) should have been added for > > "master (9.0)" > > > > Right? > > > > (In the meantime, it seems folks have already added new "8.0" > > versions for SOLR/LUCENE to Jira, which have a handful of issues mapped to > > them, that will need cleaned up) > > > > > > > > : > >> >>>>>> > > : > >> >>>>>> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi > > <[email protected] <mailto:[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] <mailto:[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] <mailto:[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 > > > > <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] <mailto:[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 > > <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] <mailto:[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 > > > > <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] <mailto:[email protected]>> a écrit : > > : > >> >>>>>>>>> >>> > > : > >> >>>>>>>>> >>> Đạt, is > > https://issues.apache.org/jira/browse/SOLR-12639 > > <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] <mailto:[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 > > > > <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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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 > > <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] <mailto:[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 > > <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 > > <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] <mailto:[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] <mailto:[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 > > <https://issues.apache.org/jira/browse/LUCENE-8116> > > : > >> >>>>>>>>> >>>>>> >>>>> >>> > [2] > > https://issues.apache.org/jira/browse/LUCENE-8020 > > <https://issues.apache.org/jira/browse/LUCENE-8020> > > : > >> >>>>>>>>> >>>>>> >>>>> >>> > [3] > > https://issues.apache.org/jira/browse/LUCENE-8007 > > <https://issues.apache.org/jira/browse/LUCENE-8007> > > : > >> >>>>>>>>> >>>>>> >>>>> >>> > [4] > > https://issues.apache.org/jira/browse/LUCENE-4198 > > <https://issues.apache.org/jira/browse/LUCENE-4198> > > : > >> >>>>>>>>> >>>>>> >>>>> >>> > [5] > > https://issues.apache.org/jira/browse/LUCENE-8135 > > <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 > > <https://issues.apache.org/jira/browse/LUCENE-8031> > > : > >> >>>>>>>>> >>>>>> >>>>> >>> > [7] > > https://issues.apache.org/jira/browse/LUCENE-8134 > > <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] <mailto:[email protected]> > > : > >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: > > [email protected] <mailto:[email protected]> > > : > >> >>>>>>>>> >>>>>> >>>>> >>> > > : > >> >>>>>>>>> >>>>>> >>>>> > > > : > >> >>>>>>>>> >>>>>> >>>>> > > : > >> >>>>>>>>> >>>>>> >>>>> > > --------------------------------------------------------------------- > > : > >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: > > [email protected] <mailto:[email protected]> > > : > >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: > > [email protected] <mailto:[email protected]> > > : > >> >>>>>>>>> >>>>>> >>>>> > > : > >> >>>>>>>>> >>>>>> >>> -- > > : > >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, > > Developer, Author, Speaker > > : > >> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley > > <http://linkedin.com/in/davidwsmiley> | Book: > > http://www.solrenterprisesearchserver.com > > <http://www.solrenterprisesearchserver.com/> > > : > >> >>>>>>>>> >>>>>> > > : > >> >>>>>>>>> >>>>>> > > --------------------------------------------------------------------- > > : > >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: > > [email protected] <mailto:[email protected]> > > : > >> >>>>>>>>> >>>>>> For additional commands, e-mail: > > [email protected] <mailto:[email protected]> > > : > >> >>>>>>>>> >>>>>> > > : > >> >>>>>>>>> > -- > > : > >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, > > Author, Speaker > > : > >> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley > > <http://linkedin.com/in/davidwsmiley> | Book: > > http://www.solrenterprisesearchserver.com > > <http://www.solrenterprisesearchserver.com/> > > : > >> >>>>>>>>> > > : > >> >>>>>>>>> > > --------------------------------------------------------------------- > > : > >> >>>>>>>>> To unsubscribe, e-mail: [email protected] > > <mailto:[email protected]> > > : > >> >>>>>>>>> For additional commands, e-mail: > > [email protected] <mailto:[email protected]> > > : > >> >>>>>>>>> > > : > >> >>> -- > > : > >> >>> > > : > >> >>> Nicholas Knize, Ph.D., GISP > > : > >> >>> Geospatial Software Guy | Elasticsearch > > : > >> >>> Apache Lucene Committer > > : > >> >>> [email protected] <mailto:[email protected]> > > : > >> >> > > : > >> >> -- > > : > >> >> Lucene/Solr Search Committer, Consultant, Developer, Author, > > Speaker > > : > >> >> LinkedIn: http://linkedin.com/in/davidwsmiley > > <http://linkedin.com/in/davidwsmiley> | Book: > > http://www.solrenterprisesearchserver.com > > <http://www.solrenterprisesearchserver.com/> > > : > >> > > : > >> --------------------------------------------------------------------- > > : > >> To unsubscribe, e-mail: [email protected] > > <mailto:[email protected]> > > : > >> For additional commands, e-mail: [email protected] > > <mailto:[email protected]> > > : > >> > > : > > > > : > > > : > > > : > -- > > : > Adrien > > : > > > : > --------------------------------------------------------------------- > > : > To unsubscribe, e-mail: [email protected] > > <mailto:[email protected]> > > : > For additional commands, e-mail: [email protected] > > <mailto:[email protected]> > > : > > > : > -- > > : > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker > > : > LinkedIn: http://linkedin.com/in/davidwsmiley > > <http://linkedin.com/in/davidwsmiley> | Book: > > http://www.solrenterprisesearchserver.com > > <http://www.solrenterprisesearchserver.com/>-- > > : > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker > > : > LinkedIn: http://linkedin.com/in/davidwsmiley > > <http://linkedin.com/in/davidwsmiley> | Book: > > http://www.solrenterprisesearchserver.com > > <http://www.solrenterprisesearchserver.com/> > > : > > > > -Hoss > > http://www.lucidworks.com/ > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
