I'm committing them, Thanks Ishan On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <romseyg...@gmail.com> wrote: > > Awesome, thank you Ishan! > > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ichattopadhy...@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 <romseyg...@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 <m...@apache.org> wrote: >> >> On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <m...@apache.org> wrote: >>> >>> Thank you, Alan. Give me an hour. >>> >>> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseyg...@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 <shalinman...@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 <romseyg...@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 <shalinman...@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 <romseyg...@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 <m...@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 <romseyg...@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 <casstarg...@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.smi...@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 <romseyg...@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 <gerlowsk...@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.feren...@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 >>>>>>>> >> <casstarg...@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 >>>>>>>> >>> <romseyg...@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 <romseyg...@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.smi...@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 >>>>>>>> >>> <romseyg...@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.smi...@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 <kris...@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 <jpou...@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 >>>>>>>> >>>>>> <nkn...@gmail.com> wrote: >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> - Nick >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi >>>>>>>> >>>>>>> <jim.feren...@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 >>>>>>>> >>>>>>>> <nkn...@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 <kris...@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.feren...@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.feren...@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.teof...@gmail.com> a écrit : >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> sure, thanks Jim! >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Tommaso >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi >>>>>>>> >>>>>>>>>>>>> <jim.feren...@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.teof...@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 >>>>>>>> >>>>>>>>>>>>>>> <jpou...@gmail.com> ha scritto: >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> Hi Noble, >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> No it hasn't created yet. >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul >>>>>>>> >>>>>>>>>>>>>>>> <noble.p...@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.smi...@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....@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 <tomasflo...@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.h...@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 >>>>>>>> >>>>>>>>>>>>>>>>>>>> <jpou...@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.h...@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 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>> <u...@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: u...@thetaphi.de >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jpou...@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.feren...@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 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> <romseyg...@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 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> <romseyg...@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 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> <u...@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: u...@thetaphi.de >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <romseyg...@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.smi...@gmail.com> >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January. >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> <sg.online.em...@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.smi...@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 <jpou...@gmail.com> >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Woodward >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <romseyg...@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 <casstarg...@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 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerick...@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.feren...@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.smi...@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 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <nkn...@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 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat...@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.feren...@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 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstarg...@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.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> 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> 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.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 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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> 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 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpou...@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 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <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%3DBlocke >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20 >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 10:36, jim ferenczi >>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <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> 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> 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> 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> 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
