: 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 
<jim.feren...@gmail.com <mailto:jim.feren...@gmail.com>> 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 
<casstarg...@gmail.com <mailto:casstarg...@gmail.com>> 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 
<erickerick...@gmail.com <mailto:erickerick...@gmail.com>> 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 
<david.w.smi...@gmail.com <mailto:david.w.smi...@gmail.com>> 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 
<jim.feren...@gmail.com <mailto:jim.feren...@gmail.com>> 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 
<jpou...@gmail.com <mailto:jpou...@gmail.com>> 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 
<jpou...@gmail.com <mailto:jpou...@gmail.com>> 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 
<jim.feren...@gmail.com <mailto:jim.feren...@gmail.com>> 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 
<erickerick...@gmail.com <mailto:erickerick...@gmail.com>> 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 
<caomanhdat...@gmail.com <mailto:caomanhdat...@gmail.com>> 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 
<jim.feren...@gmail.com <mailto:jim.feren...@gmail.com>> 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 
<david.w.smi...@gmail.com <mailto:david.w.smi...@gmail.com>> 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 
<jpou...@gmail.com <mailto:jpou...@gmail.com>> 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 
<rcm...@gmail.com <mailto:rcm...@gmail.com>> 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 
<jpou...@gmail.com <mailto:jpou...@gmail.com>> 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 
<jpou...@gmail.com <mailto:jpou...@gmail.com>> 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 
<rcm...@gmail.com <mailto:rcm...@gmail.com>> 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 
<jpou...@gmail.com <mailto:jpou...@gmail.com>> 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: 
dev-unsubscr...@lucene.apache.org <mailto:dev-unsubscr...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: 
dev-h...@lucene.apache.org <mailto:dev-h...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>> >>>>> >>>
: > >> >>>>>>>>> >>>>>> >>>>> >
: > >> >>>>>>>>> >>>>>> >>>>>
: > >> >>>>>>>>> >>>>>> >>>>> 
---------------------------------------------------------------------
: > >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org <mailto:dev-unsubscr...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: 
dev-h...@lucene.apache.org <mailto:dev-h...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>> >>>>>
: > >> >>>>>>>>> >>>>>> >>> --
: > >> >>>>>>>>> >>>>>> >>> 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: 
dev-unsubscr...@lucene.apache.org <mailto:dev-unsubscr...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>> For additional commands, e-mail: 
dev-h...@lucene.apache.org <mailto:dev-h...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>>
: > >> >>>>>>>>> > --
: > >> >>>>>>>>> > 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: dev-unsubscr...@lucene.apache.org 
<mailto:dev-unsubscr...@lucene.apache.org>
: > >> >>>>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org 
<mailto:dev-h...@lucene.apache.org>
: > >> >>>>>>>>>
: > >> >>> --
: > >> >>>
: > >> >>> Nicholas Knize, Ph.D., GISP
: > >> >>> Geospatial Software Guy  |  Elasticsearch
: > >> >>> Apache Lucene Committer
: > >> >>> nkn...@apache.org <mailto:nkn...@apache.org>
: > >> >>
: > >> >> --
: > >> >> 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: dev-unsubscr...@lucene.apache.org 
<mailto:dev-unsubscr...@lucene.apache.org>
: > >> For additional commands, e-mail: dev-h...@lucene.apache.org 
<mailto:dev-h...@lucene.apache.org>
: > >>
: > >
: > 
: > 
: > -- 
: > Adrien
: > 
: > ---------------------------------------------------------------------
: > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
<mailto:dev-unsubscr...@lucene.apache.org>
: > For additional commands, e-mail: dev-h...@lucene.apache.org 
<mailto:dev-h...@lucene.apache.org>
: > 
: > -- 
: > 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to