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 <jpou...@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 <romseyg...@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.p...@gmail.com> wrote: > > > > 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 > > > > > > > -- > Adrien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
