lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Đạt Cao Mạnh <caomanhdat...@gmail.com>
Subject Re: Fwd: Lucene/Solr 8.0
Date Fri, 03 May 2019 14:41:49 GMT
Hi David,

I agree with Cassandra about using ref-guide for expressing our idea and
our plan for a major version. But I also make some minor change to the wiki
page about what we are gainning on switching to HTTP/2.

On Thu, May 2, 2019 at 10:04 PM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> What should be done to get 8.0 version added to Docker Hub [0]?
> Would this need to be done by Martijn Koster at Lucidworks? If so, can
> someone please request him to take a look?
> Or is this something that even we (@ Apache) can do too?
>
> [0] - https://hub.docker.com/_/solr/
>
> On Tue, Apr 30, 2019 at 9:44 PM Ishan Chattopadhyaya
> <ichattopadhyaya@gmail.com> wrote:
> >
> > On a different note, I realized 2 days back that the solr:latest on
> > docker hub points to 7.7.1. What do we need to do to get 8.0 docker
> > image on docker hub?
> >
> > On Tue, Apr 30, 2019 at 6:57 PM Cassandra Targett <casstargett@gmail.com>
> wrote:
> > >
> > > I have a number of changes in a local branch for the 8.0 Ref Guide
> page “Major Changes in Solr 8” about HTTP/2 which might help. I hadn’t
> intended to push my branch, but I could if it helps. I also have a bunch of
> unfinished content I started about nested documents, but tearing apart the
> CHANGES.txt to figure out what is new and how that impacts upgrades is
> incredibly painful and time-consuming, and I don’t have a ton of time these
> days. This is why the 8.0 Ref Guide isn’t out yet.
> > >
> > > Tangentially, I feel like we need to work something else out about
> Wiki release notes (and, remember, wiki.apache.org is going away really
> soon now) and the Ref Guide. It’s odd to me that one person decides how to
> present what’s new in the Wiki release notes, and someone else decides how
> to present a whole other set of content about the same set of features for
> the Ref Guide. Usually I skip the what’s new part for the minor releases,
> but for major ones, there needs to be a comprehensive “here’s what’s new
> and what’s changed” - we’ve done it for 5->6 and 6->7, it’s part of the
> major version process now.
> > >
> > > Anyway, let me know if you want to see what I have so far, and I’ll
> try to find some time to push it or make a patch.
> > > On Apr 30, 2019, 8:00 AM -0500, David Smiley <david.w.smiley@gmail.com>,
> wrote:
> > >
> > > Hi Dat,
> > >
> > > I plan to update Solr's release notes for 8.0 retroactively.
> https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs;
> I wrote this well over a month ago.  Can you please enhance the part on
> HTTP2 to be more informative?  For example... what *benefit* does HTTP2
> bring to internode communication?  I know you benchmarked things.  Maybe
> mention the road to full HTTP2 continues into 8.x?
> > >
> > > I'm sending this to the dev list so really anyone else can help like
> list other major features... though I think maybe it's just these two.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > > ---------- Forwarded message ---------
> > > From: David Smiley <david.w.smiley@gmail.com>
> > > Date: Thu, Mar 14, 2019 at 9:34 AM
> > > Subject: Re: Lucene/Solr 8.0
> > > To: Solr/Lucene Dev <dev@lucene.apache.org>
> > >
> > >
> > > The Solr highlights section of the announcement is severely incomplete
> as to appear embarrassing.
> > > In the absence of time/effort to fix it should have simply been
> omitted; the CHANGES.txt has details.
> > > That would not have been embarrassing.
> > > Maybe next time we could have a call to action about the release
> highlights that coincides with the creation of the release branch;
> > > that is a juncture in which the features are frozen and there's plenty
> of time to update.
> > > Last night I saw the call to action but it was woefully too late for
> me to help.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > >
> > > On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jpountz@gmail.com>
> wrote:
> > >>
> > >> I organized existing items of the Lucene release notes into sections
> > >> and added a new item about FeatureField,
> > >> LongPoint#newDistanceFeatureQuery and
> > >> LatLonPoint#newDistanceFeatureQuery.
> > >>
> > >> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <romseygeek@gmail.com>
> wrote:
> > >> >
> > >> > Jim and I have created wiki pages for the 8.0 release highlights
> here:
> > >> > https://wiki.apache.org/solr/ReleaseNote80
> > >> > https://wiki.apache.org/lucene-java/ReleaseNote80
> > >> >
> > >> > Feel free to edit and improve them - the Solr one in particular
> could do with some beefing up.
> > >> >
> > >> >
> > >> > On 20 Feb 2019, at 11:37, Noble Paul <noble.paul@gmail.com> wrote:
> > >> >
> > >> > I'm committing them,
> > >> > Thanks Ishan
> > >> >
> > >> > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <romseygeek@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Awesome, thank you Ishan!
> > >> >
> > >> > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> > >> >
> > >> > Would anyone like to volunteer to be release manager for 7.7.1?
> > >> >
> > >> > I can volunteer for 7.7.1. I'll start as soon as both these issues
> are committed.
> > >> >
> > >> > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <romseygeek@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > We have two Solr issues that are serious enough to warrant a 7.7.1
> release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility
> guarantees, we should do this release before we restart the 8.0.0 process.
> > >> >
> > >> > Would anyone like to volunteer to be release manager for 7.7.1?
> Ideally we would get this done quickly so that I can continue releasing
> 8.0.0.
> > >> >
> > >> > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mkhl@apache.org> wrote:
> > >> >
> > >> > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mkhl@apache.org>
> wrote:
> > >> >
> > >> >
> > >> > Thank you, Alan. Give me an hour.
> > >> >
> > >> > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
> > >> >
> > >> >
> > >> > OK, let’s do an RC2.  When do you think you can have a fix in?
> > >> >
> > >> > Mikhail, will you be able to get your fix in soon as well?
> > >> >
> > >> >
> > >> >
> > >> > Nope. Don't wait for SOLR-13126, it turns to be more complicated.
> > >> >
> > >> >
> > >> >
> > >> > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <
> shalinmangar@gmail.com> wrote:
> > >> >
> > >> > Hi Alan,
> > >> >
> > >> > There is a work-around which is to change the default to using
> legacy assignment using cluster properties. But I don't like the idea of
> releasing something that we know is broken and asking everyone to set a
> cluster property to workaround it. I'd rather just rollback the commits
> that caused the problem and then release 8.0
> > >> >
> > >> > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <romseygeek@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Hi Shalin,
> > >> >
> > >> > I'm not familiar with this bit of code - is there a workaround
> available?  ie a way of using a different replica placement strategy when
> creating a collection?  If there is, I'd be tempted to continue with the
> vote as is and then do an immediate 8.0.1 release once you have things
> fixed, particularly if we’re going to require a 7.7.1 as well.
> > >> >
> > >> > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <
> shalinmangar@gmail.com> wrote:
> > >> >
> > >> > Hi Alan,
> > >> >
> > >> > I opened SOLR-13248 a few minutes ago. It is a bad bug that should
> be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In
> the interest of time, I propose rolling back SOLR-12739 which caused these
> issues. We can re-introduce it with proper fixes for the related issues in
> 8.1.
> > >> >
> > >> > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <romseygeek@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > The release candidate has already been built and voting is in
> progress, so it’s missed the boat unless there’s a respin.  It does look
> like a nasty bug though, so if you have a fix then feel free too commit it
> to the 8_0 branch in case we do an 8.0.1 release.
> > >> >
> > >> > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mkhl@apache.org> wrote:
> > >> >
> > >> > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
> > >> >
> > >> > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I have no problem with bug-fixes and ref-guide changes on the 8_0
> branch.
> > >> >
> > >> > On 13 Feb 2019, at 22:25, Cassandra Targett <casstargett@gmail.com>
> wrote:
> > >> >
> > >> > I’ll let Alan reply definitively, but IMO if branch_8_0 is closed
> even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at
> all since there’s a lot of editing yet to be done for it.
> > >> >
> > >> > Cassandra
> > >> > On Feb 13, 2019, 4:20 PM -0600, David Smiley <
> david.w.smiley@gmail.com>, wrote:
> > >> >
> > >> > I've been shepherding
> https://issues.apache.org/jira/browse/SOLR-13129 which only touches the
> Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's
> committed after the 8.0 for the code?  I could avoid touching CHANGES.txt
> if that helps (it'd be of dubious value to users browsing the change list
> any way).
> > >> >
> > >> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Thanks for letting me know Jason.  Your commit will have missed the
> cut, yes, but I don’t think it matters that much.  It will get picked up in
> a respin or in any subsequent bug-fix release, and if RC1 passes the vote
> then we can just alter CHANGES.txt
> > >> >
> > >> >
> > >> > On 13 Feb 2019, at 16:27, Jason Gerlowski <gerlowskija@gmail.com>
> wrote:
> > >> >
> > >> > Hey Alan,
> > >> >
> > >> > I just committed a minor inconsequential bugfix
> > >> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> > >> > realize I was cutting it so close to your work on cutting RC1, but
> > >> > from commits I see you made this morning preparing for the RC I
> > >> > suspect I cut things _very_ close and just missed it.
> > >> >
> > >> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
> > >> > problems for you on the release end.  I'm happy to do whatever's
> > >> > easiest for you regarding that commit.  It'd be nice to have it
> > >> > included in 8.0, but it's not imperative by any means if I've
> already
> > >> > missed the first RC, or it's easier for you to omit from potential
> > >> > subsequent RCs.  Let me know if there's anything you'd like me to do
> > >> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> > >> > go back and update CHANGES.txt I think.
> > >> >
> > >> > Sorry again for the potential complication.  I hate to be "that
> guy".
> > >> > Thanks for stepping up and handling the release.
> > >> >
> > >> > Best,
> > >> >
> > >> > Jason
> > >> >
> > >> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Thanks for fixing Cassandra and sorry for the noise. I did this too
> many times in the past so I just mechanically changed the redirect without
> thinking of when or if the ref guide was also released.
> > >> > I'll be more careful next time ;).
> > >> >
> > >> > On another note, now that 7.7 is out and that we're preparing the
> release for 8.0 what do you think of removing/nuking the 7x branch. This
> was already discussed some time ago
> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
> reached a consensus and we have maybe new options with the move to gitbox.
> One option discussed in the thread was to remove all files and add a README
> that says that this branch is dead. I don't know if it's possible but we
> could also make the branch protected in gitbox in order to avoid new
> commits. What do you think ? Should we keep this branch and just consider
> new commits as useless or should we try to "clean up" all Nx branches that
> are not active anymore (5x, 6x, 7x) ?
> > >> >
> > >> > Jim
> > >> >
> > >> > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <
> casstargett@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > I’d like to remind RMs that when finishing up a release, we can’t
> just do a blanket find/replace in .htaccess to update the version. If we’re
> not going to coordinate binary releases with Ref Guide releases, we need to
> be careful not to change the redirects unless that version’s Ref Guide
> release is also imminent.
> > >> >
> > >> > This is noted in the ReleaseToDo (
> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
> but I’ve seen it occur a little too soon for the past few releases…in those
> cases, the Ref Guide release was pretty close so it didn’t matter that much.
> > >> >
> > >> > In this case, though, I haven’t had time to do a 7.7 Ref Guide so
> it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone
> else needs to maybe take care of it), but all non-version specific Ref
> Guide link is now being routed to a non-existent 7.7 path. It’s easy to
> fix, but we have an easy way to avoid routing people to dead links.
> > >> >
> > >> > Cassandra
> > >> > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <romseygeek@gmail.com>,
> wrote:
> > >> >
> > >> > Once 7.7 is out the door, we should get on with releasing 8.0.  I
> volunteer to be the manager for this round.  My current plan is to build a
> release candidate early next week, as soon as the 7.7 release has been
> announced.
> > >> >
> > >> > On 8 Feb 2019, at 09:07, Alan Woodward <romseygeek@gmail.com>
> wrote:
> > >> >
> > >> > It is a shame, I agree, but some of this stuff has been deprecated
> since 3.6, so another release cycle won’t hurt :). We should prioritise
> cleaning this stuff up once 8.0 is out of the door though.
> > >> >
> > >> > On 8 Feb 2019, at 07:27, David Smiley <david.w.smiley@gmail.com>
> wrote:
> > >> >
> > >> > Okay.  I suppose the issue is that it's simply too late in the 8.0
> cycle to remove things that have been deprecated in previous releases?
> solr.LatLonType is one example.  It's a shame to keep around such things
> further.
> > >> >
> > >> > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseygeek@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Not quite - the plan is to remove things entirely in 9.0, but we
> may need to back port some extra deprecations to 8x.  We don’t necessarily
> need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without
> any problems.  I opened the issues to ensure that we didn’t keep carrying
> deprecated code through any further releases.
> > >> >
> > >> >
> > >> > On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com>
> wrote:
> > >> >
> > >> > I want to ensure people are aware of two issues "Remove deprecated
> code in master" that Alan filed:
> > >> >
> > >> > https://issues.apache.org/jira/browse/SOLR-13138
> > >> > https://issues.apache.org/jira/browse/LUCENE-8638
> > >> > There's a "master-deprecations" branch as well.
> > >> >
> > >> > Although both issues are marked "master (9.0)", I think the intent
> is actually 8.0 so that we are finally rid of the deprecated code?
> > >> >
> > >> > ~ David
> > >> >
> > >> > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <krisden@apache.org>
> wrote:
> > >> >
> > >> >
> > >> > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> > >> > I'm keeping any eye on the builds this weekend but all indications
> are
> > >> > no issues so far.
> > >> >
> > >> > Kevin Risden
> > >> >
> > >> > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpountz@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Nick, this change seems to be causing test failures. Can you have a
> look?
> > >> >
> > >> > See eg.
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> > >> >
> > >> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nknize@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Thank you Jim. LUCENE-8669 has been merged.
> > >> >
> > >> > - Nick
> > >> >
> > >> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Sure Nick, I am not aware of other blockers for 7.7 so I'll start
> the first RC when your patch is merged.
> > >> > Kevin, this looks like a big change so I am not sure if it's a good
> idea to rush this in for 8.0. Would it be safer to target another version
> in order to take some time to ensure that it's not breaking anything ? I
> guess that your concern is that a change like this should happen in a major
> version but I wonder if it's worth the risk. I don't know this part of the
> code and the implications of such a change so I let you decide what we
> should do here but let's not delay the release if we realize that this
> change requires more than a few days to be merged.
> > >> >
> > >> > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nknize@gmail.com> a
> écrit :
> > >> >
> > >> >
> > >> > Hey Jim,
> > >> >
> > >> > I just added https://issues.apache.org/jira/browse/LUCENE-8669
> along with a pretty straightforward patch. This is a critical one that I
> think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> > >> >
> > >> > On Wed, Jan 30, 2019 at 1:07 PM
> > >> >
> > >> > Kevin Risden <krisden@apache.org> wrote:
> > >> >
> > >> >
> > >> > Jim,
> > >> >
> > >> > Since 7.7 needs to be released before 8.0 does that leave time to
> get
> > >> > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> > >> > currently under review.
> > >> >
> > >> > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if
> others
> > >> > feel this should make it into 8.0 or not.
> > >> >
> > >> > Kevin Risden
> > >> >
> > >> > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I had to revert the version bump for 8.0 (8.1) on branch_8x because
> we don't handle two concurrent releases in our tests (
> https://issues.apache.org/jira/browse/LUCENE-8665).
> > >> > Since we want to release 7.7 first I created the Jenkins job for
> this version only and will build the first candidate for this version later
> this week if there are no objection.
> > >> > I'll restore the version bump for 8.0 when 7.7 is out.
> > >> >
> > >> >
> > >> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.ferenczi@gmail.com>
> a écrit :
> > >> >
> > >> >
> > >> > Hi,
> > >> > Hearing no objection I created the branches for 8.0 and 7.7. I'll
> now create the Jenkins tasks for these versions, Uwe can you also add them
> to the Policeman's Jenkins job ?
> > >> > This also means that the feature freeze phase has started for both
> versions (7.7 and 8.0):
> > >> >
> > >> > No new features may be committed to the branch.
> > >> > Documentation patches, build patches and serious bug fixes may be
> committed to the branch. However, you should submit all patches you want to
> commit to Jira first to give others the chance to review and possibly vote
> against the patch. Keep in mind that it is our main intention to keep the
> branch as stable as possible.
> > >> > All patches that are intended for the branch should first be
> committed to the unstable branch, merged into the stable branch, and then
> into the current release branch.
> > >> > Normal unstable and stable branch development may continue as
> usual. However, if you plan to commit a big change to the unstable branch
> while the branch feature freeze is in effect, think twice: can't the
> addition wait a couple more days? Merges of bug fixes into the branch may
> become more difficult.
> > >> > Only Jira issues with Fix version "X.Y" and priority "Blocker" will
> delay a release candidate build.
> > >> >
> > >> >
> > >> > Thanks,
> > >> > Jim
> > >> >
> > >> >
> > >> > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > sure, thanks Jim!
> > >> >
> > >> > Tommaso
> > >> >
> > >> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > >> > <jim.ferenczi@gmail.com> ha scritto:
> > >> >
> > >> >
> > >> > Go ahead Tommaso the branch is not created yet.
> > >> > The plan is to create the branches (7.7 and 8.0)  tomorrow or
> wednesday and to announce the feature freeze the same day.
> > >> > For blocker issues that are still open this leaves another week to
> work on a patch and we can update the status at the end of the week in
> order to decide if we can start the first build candidate
> > >> > early next week. Would that work for you ?
> > >> >
> > >> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > I'd like to backport
> https://issues.apache.org/jira/browse/LUCENE-8659
> > >> > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> > >> >
> > >> > Regards,
> > >> > Tommaso
> > >> >
> > >> > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > >> > <jpountz@gmail.com> ha scritto:
> > >> >
> > >> >
> > >> > Hi Noble,
> > >> >
> > >> > No it hasn't created yet.
> > >> >
> > >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.paul@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Is the branch already cut for 8.0? which is it?
> > >> >
> > >> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
> david.w.smiley@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I finally have a patch up for
> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
> blocker) that I feel pretty good about.  This provides a key part of the
> nested document support.
> > >> > I will work on some documentation for it this week -- SOLR-13129
> > >> >
> > >> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan.asf@cominvent.com>
> wrote:
> > >> >
> > >> >
> > >> > I don't think it is critical for this to be a blocker for 8.0. If
> it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > >> > I think we should simply remove the buffering feature in the UI and
> replace it with an error message popup or something.
> > >> > I'll try to take a look next week.
> > >> >
> > >> > --
> > >> > Jan Høydahl, search solution architect
> > >> > Cominvent AS - www.cominvent.com
> > >> >
> > >> > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
> tomasflobbe@gmail.com>:
> > >> >
> > >> > I think the UI is an important Solr feature. As long as there is a
> reasonable time horizon for the issue being resolved I'm +1 on making it a
> blocker. I'm not familiar enough with the UI code to help either
> unfortunately.
> > >> >
> > >> > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > It looks like someone tried to make it a blocker once before... And
> it's actually a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it rather than browsing away or closing the
> window, not knowing that it's silently pumping out requests after showing
> an error... would completely hose a node, and until they tracked down the
> source of the requests, (hope he didn't go home) it would be impossible to
> resolve...
> > >> >
> > >> > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Releasing a new major is very challenging on its own, I'd rather not
> > >> > call it a blocker and delay the release for it since this isn't a
> new
> > >> > regression in 8.0: it looks like a problem that has affected Solr
> > >> > since at least 6.3? I'm not familiar with the UI code at all, but
> > >> > maybe this is something that could get fixed before we build a RC?
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> > >> >
> > >> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de>
> wrote:
> > >> >
> > >> >
> > >> > Cool,
> > >> >
> > >> > I am working on giving my best release time guess as possible on
> the FOSDEM conference!
> > >> >
> > >> > Uwe
> > >> >
> > >> > -----
> > >> > Uwe Schindler
> > >> > Achterdiek 19, D-28357 Bremen
> > >> > http://www.thetaphi.de
> > >> > eMail: uwe@thetaphi.de
> > >> >
> > >> > -----Original Message-----
> > >> > From: Adrien Grand <jpountz@gmail.com>
> > >> > Sent: Thursday, January 24, 2019 5:33 PM
> > >> > To: Lucene Dev <dev@lucene.apache.org>
> > >> > Subject: Re: Lucene/Solr 8.0
> > >> >
> > >> > +1 to release 7.7 and 8.0 in a row starting on the week of February
> 4th.
> > >> >
> > >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
> jim.ferenczi@gmail.com>
> > >> > wrote:
> > >> >
> > >> >
> > >> > Hi,
> > >> > As we agreed some time ago I'd like to start on releasing 8.0. The
> branch is
> > >> >
> > >> > already created so we can start the process anytime now. Unless
> there are
> > >> > objections I'd like to start the feature freeze next week in order
> to build the
> > >> > first candidate the week after.
> > >> >
> > >> > We'll also need a 7.7 release but I think we can handle both with
> Alan so
> > >> >
> > >> > the question now is whether we are ok to start the release process
> or if there
> > >> > are any blockers left ;).
> > >> >
> > >> >
> > >> >
> > >> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com>
> > >> >
> > >> > a écrit :
> > >> >
> > >> >
> > >> > I’ve started to work through the various deprecations on the new
> master
> > >> >
> > >> > branch.  There are a lot of them, and I’m going to need some
> assistance for
> > >> > several of them, as it’s not entirely clear what to do.
> > >> >
> > >> >
> > >> > I’ll open two overarching issues in JIRA, one for lucene and one
> for Solr,
> > >> >
> > >> > with lists of the deprecations that need to be removed in each
> one.  I’ll create
> > >> > a shared branch on gitbox to work against, and push the changes
> I’ve already
> > >> > done there.  We can then create individual JIRA issues for any
> changes that
> > >> > are more involved than just deleting code.
> > >> >
> > >> >
> > >> > All assistance gratefully received, particularly for the Solr
> deprecations
> > >> >
> > >> > where there’s a lot of code I’m unfamiliar with.
> > >> >
> > >> >
> > >> > On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > I think the current plan is to do a 7.7 release at the same time as
> 8.0, to
> > >> >
> > >> > handle any last-minute deprecations etc.  So let’s keep those jobs
> enabled
> > >> > for now.
> > >> >
> > >> >
> > >> > On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > I will start and add the branch_8x jobs to Jenkins once I have some
> time
> > >> >
> > >> > later today.
> > >> >
> > >> >
> > >> > The question: How to proceed with branch_7x? Should we stop using it
> > >> >
> > >> > and release 7.6.x only (so we would use branch_7_6 only for
> bugfixes), or
> > >> > are we planning to one more Lucene/Solr 7.7? In the latter case I
> would keep
> > >> > the jenkins jobs enabled for a while.
> > >> >
> > >> >
> > >> > Uwe
> > >> >
> > >> > -----
> > >> > Uwe Schindler
> > >> > Achterdiek 19, D-28357 Bremen
> > >> > http://www.thetaphi.de
> > >> > eMail: uwe@thetaphi.de
> > >> >
> > >> > From: Alan Woodward <romseygeek@gmail.com>
> > >> > Sent: Monday, January 7, 2019 11:30 AM
> > >> > To: dev@lucene.apache.org
> > >> > Subject: Re: Lucene/Solr 8.0
> > >> >
> > >> > 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.
> > >> >
> > >> >
> > >> > This is not intended as a feature freeze, as I know there are still
> some
> > >> >
> > >> > things being worked on for 8.0; however, it should let us clean up
> master by
> > >> > removing as much deprecated code as possible, and give us an idea
> of any
> > >> > replacement work that needs to be done.
> > >> >
> > >> >
> > >> >
> > >> > On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > January.
> > >> >
> > >> > On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > It would be nice to see Solr 8 in January soon as there is an
> enhancement
> > >> >
> > >> > on nested-documents we are waiting to get our hands on.
> > >> >
> > >> > Any idea when Solr 8 would be out ?
> > >> >
> > >> > Thx
> > >> > SG
> > >> >
> > >> > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > >> >
> > >> > <david.w.smiley@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I see 10 JIRA issues matching this filter:   project in (SOLR,
> LUCENE) AND
> > >> >
> > >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> > >> >
> > >> >  click here:
> > >> >
> > >> >
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > >> >
> > >> >
> > >> > Thru the end of the month, I intend to work on those issues not yet
> > >> >
> > >> > assigned.
> > >> >
> > >> >
> > >> > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > +1
> > >> >
> > >> > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > >> >
> > >> > <romseygeek@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Hi all,
> > >> >
> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> > >> >
> > >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to
> create the
> > >> > branch this week - say Wednesday?  Then we should have some time to
> > >> > clean up the master branch and uncover anything that still needs to
> be done
> > >> > on 8.0 before we start the release process next year.
> > >> >
> > >> >
> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > I'm a bit delayed, but +1 on the 7.6 and 8.0 plan from me too.
> > >> >
> > >> > On Fri, Oct 19, 2018 at 7:18 AM Erick Erickson
> > >> >
> > >> > <erickerickson@gmail.com> wrote:
> > >> >
> > >> >
> > >> > +1, this gives us all a chance to prioritize getting the blockers
> out
> > >> > of the way in a careful manner.
> > >> > On Fri, Oct 19, 2018 at 7:56 AM jim ferenczi <
> jim.ferenczi@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > +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
> > >> >
> > >> > <david.w.smiley@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > +1 to a 7.6 —lots of stuff in there
> > >> > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > >> >
> > >> > <nknize@gmail.com> 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 and selective indexing
> work
> > >> > done in LUCENE-8496. Any objections or thoughts?
> > >> >
> > >> >
> > >> > - Nick
> > >> >
> > >> >
> > >> > On Thu, Oct 18, 2018 at 5:32 AM Đạt Cao Mạnh
> > >> >
> > >> > <caomanhdat317@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Thanks Cassandra and Jim,
> > >> >
> > >> > I created a blocker issue for Solr 8.0 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
> > >> >
> > >> > <jim.ferenczi@gmail.com> 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
> > >> >
> > >> > <casstargett@gmail.com> 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
> > >> >
> > >> > <jim.ferenczi@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
> > >> >
> > >> > <casstargett@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
> > >> >
> > >> > <erickerickson@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
> > >> >
> > >> >
> > >> > 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.smiley@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 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.ferenczi@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%3DBlocke
> > >> > r%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
> > >> >
> > >> > <jpountz@gmail.com> 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
> > >> >
> > >> > <jpountz@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%3DBlocke
> > >> > r%20and%20resolution%20%3D%20Unresolved%20
> > >> >
> > >> >
> > >> > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> > >> >
> > >> > <jim.ferenczi@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
> > >> >
> > >> > <erickerickson@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
> > >> >
> > >> > <caomanhdat317@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.ferenczi@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.smiley@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 --
> > >> >
> > >> > &g
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Sincerely yours
> > >> > Mikhail Khludnev
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > -----------------------------------------------------
> > >> > Noble Paul
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> > For additional commands, e-mail: dev-help@lucene.apache.org
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Adrien
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>
>


-- 
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat317@gmail.com
<caomanhdat317@gmail.com>*

Mime
View raw message