SOLR-12765 has been committed now to master, branch_7x, branch_7_5 and branch_7_4. Thanks!
> On 17 Sep 2018, at 14:14, jim ferenczi <jim.feren...@gmail.com> wrote: > > Hi, > > Andrzej, there is another issue in the queue (LUCENE-8502) so I'll wait one > more day to build the first RC., please backport the fix for the JMX beans. > Cassandra, I backported the Tika version change in the docs, if SOLR-12771 is > merged today I'll include it in the RC tomorrow. > > Le lun. 17 sept. 2018 à 13:57, Andrzej Białecki <a...@getopt.org > <mailto:a...@getopt.org>> a écrit : > Hi Jim, > > I’d like to commit a fix for SOLR-12765 where a side-effect from other issue > changed the format of some JMX beans. > >> On 14 Sep 2018, at 23:25, jim ferenczi <jim.feren...@gmail.com >> <mailto:jim.feren...@gmail.com>> wrote: >> >> Sorry for the late reply. I built the first RC earlier today and had some >> issues to pass the smoke tests. Most of the issue were on my end but I had >> to open https://issues.apache.org/jira/browse/LUCENE-8500 >> <https://issues.apache.org/jira/browse/LUCENE-8500> to fix an actual bug. >> SCassandra, the issue is in the smoke tester so I don't know if we need a >> respin but I didn't send the artifacts so I can just rebuild RC1 with >> LUCENE-8500 when it's merged. In the meantime don't hesitate to merge the >> doc changes regarding Tika. Steve I can wait Tuesday to rebuild RC1 if you >> think it's worth waiting, otherwise if the smoke tests are fixed I'll >> proceed on Monday. >> >> Le ven. 14 sept. 2018 à 21:01, Steve Rowe <sar...@gmail.com >> <mailto:sar...@gmail.com>> a écrit : >> Hi Jim, >> >> I put the Solr ref guide edits Cassandra referred to in a patch on >> SOLR-12771, but as I mentioned in a comment there, I’d like to get Hoss’ss >> input before I commit, and he’s taking today off, so it’ll probably be >> Monday before he’ll have a chance to look at it. >> >> So in short, please don’t delay building the RC for SOLR-12771. >> >> -- >> Steve >> www.lucidworks.com <http://www.lucidworks.com/> >> >> > On Sep 14, 2018, at 8:40 AM, Cassandra Targett <casstarg...@gmail.com >> > <mailto:casstarg...@gmail.com>> wrote: >> > >> > Hi Jim, >> > >> > Are you working on the RC now? Overnight I discovered two really minor >> > things: first, there's an error in CHANGES.txt regarding the Tika version >> > that I mentioned in SOLR-12551 - Erick told me offline to go ahead and fix >> > it. Second, Steve has some edits he'd like to get in for the Solr Ref >> > Guide he also sent me offline. >> > >> > Neither have very much impact, but both could probably wait until/if there >> > is a respin of the RC - basically if you haven't started the RC yet I'll >> > push those through. But if you have started I'll wait. >> > >> > Thanks, >> > Cassandra >> > >> > On Thu, Sep 13, 2018 at 3:30 AM jim ferenczi <jim.feren...@gmail.com >> > <mailto:jim.feren...@gmail.com>> wrote: >> > Sure you can backport Tomás, the first RC is planned for tomorrow. >> > >> > Le jeu. 13 sept. 2018 à 00:10, Tomás Fernández Löbbe >> > <tomasflo...@gmail.com <mailto:tomasflo...@gmail.com>> a écrit : >> > Hi Jim, >> > I'd like to commit SOLR-12766 to 7.5. SOLR-11881 added retries for >> > internal requests, but the backoff time in cases with multiple updates can >> > become big, and cause clients to timeout. The change is minimal, just >> > backoff once for a retry batch instead of for every doc. >> > >> > I'm testing a patch and plan to commit later today, if there aren't any >> > issues or objections. >> > >> > On Wed, Sep 12, 2018 at 5:39 AM jim ferenczi <jim.feren...@gmail.com >> > <mailto:jim.feren...@gmail.com>> wrote: >> > Thanks ! >> > >> > Le mer. 12 sept. 2018 à 11:49, Adrien Grand <jpou...@gmail.com >> > <mailto:jpou...@gmail.com>> a écrit : >> > Hey Jim, >> > >> > I added you to the hudson-jobadmin group so that you can do it next time. >> > >> > Steve, thanks for taking care of setting up the builds! >> > >> > Le mar. 11 sept. 2018 à 17:32, jim ferenczi <jim.feren...@gmail.com >> > <mailto:jim.feren...@gmail.com>> a écrit : >> > No worries at all Cassandra. What do you think of building the first RC on >> > Friday and start the vote on Monday next week ? This will leave some >> > room to finish the missing bits. >> > Could someone help to setup the Jenkins releases build ? It seems that I >> > cannot create jobs with my account. >> > >> > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett <casstarg...@gmail.com >> > <mailto:casstarg...@gmail.com>> a écrit : >> > Sorry, Jim, I should have replied yesterday about the state of things with >> > the Ref Guide - it's close. I'm doing the last bit of big review I need to >> > do and am nearly done with that, then I have a couple more small things >> > done (including SOLR-12763 which I just created since I forgot to do it >> > earlier). My goal is to be done by the end of my day today so you could do >> > the RC tomorrow, but who knows what the day will bring work-wise, so I'll >> > send another mail at the end of the day my time to let you know for sure. >> > >> > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi <jim.feren...@gmail.com >> > <mailto:jim.feren...@gmail.com>> wrote: >> > I just fixed the invalid version (7.5.1) that I added in master and 7x. >> > The next version on these branches should be 7.6.0, sorry for the noise. >> > >> > Le lun. 10 sept. 2018 à 09:26, jim ferenczi <jim.feren...@gmail.com >> > <mailto:jim.feren...@gmail.com>> a écrit : >> > Hi, >> > >> > Feature freeze for 7.5 has started, I just created a branch_7_5.: >> > >> > * 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 "7.5" and priority "Blocker" will >> > delay a release candidate build. >> > >> > I'll create the first RC later this week depending on the status of the >> > Solr ref guide. Cassandra, can you update the status when you think that >> > the ref guide is ready (no rush just a reminder that we need to sync >> > during this release ;) ) ? >> > >> > Cheers, >> > Jim >> > >> > Le mer. 5 sept. 2018 à 17:57, Erick Erickson <erickerick...@gmail.com >> > <mailto:erickerick...@gmail.com>> a écrit : >> > Great, thanks! >> > On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi <jim.feren...@gmail.com >> > <mailto:jim.feren...@gmail.com>> wrote: >> > > >> > > Sure it can wait a few days. Let's cut the branch next Monday and we can >> > > sync with Cassandra to create the first RC when the ref guide is ready. >> > > >> > > Le mer. 5 sept. 2018 à 17:27, Erick Erickson <erickerick...@gmail.com >> > > <mailto:erickerick...@gmail.com>> a écrit : >> > >> >> > >> Jim: >> > >> >> > >> I know it's the 11th hour, but WDYT about cutting the branch next >> > >> Monday? We see a flurry of activity (announcing a release does >> > >> that....) and waiting to cut the branch might be easiest all 'round. >> > >> >> > >> Up to you of course, I can backport the test fixes I'd like for >> > >> instance and I'd like to get the upgraded ZooKeeper in 7.5. >> > >> >> > >> Erick >> > >> On Tue, Sep 4, 2018 at 1:04 PM Cassandra Targett <casstarg...@gmail.com >> > >> <mailto:casstarg...@gmail.com>> wrote: >> > >> > >> > >> > It's not so much the building of the RC as giving the content a >> > >> > detailed editorial review. >> > >> > >> > >> > The build/release process itself is well-documented and published >> > >> > with every Ref Guide: >> > >> > https://lucene.apache.org/solr/guide/how-to-contribute.html#building-publishing-the-guide >> > >> > >> > >> > <https://lucene.apache.org/solr/guide/how-to-contribute.html#building-publishing-the-guide>. >> > >> > It was designed from the artifact process, so it's nearly identical >> > >> > as a process. It's really barely a burden. >> > >> > >> > >> > In terms of preparing the content, there are a number of things I do: >> > >> > >> > >> > First, I try to ensure that every issue in CHANGES.txt that should be >> > >> > documented has been documented. That involves an intensive review of >> > >> > CHANGES.txt and a comparison with commits to find what might be >> > >> > missing, then chasing people down to see if they intend to make >> > >> > changes or not. Assuming the person responds, then it's waiting for >> > >> > them to get their stuff done. This is usually about 2-3 days of >> > >> > effort, before the waiting around for answers and/or commits. >> > >> > >> > >> > Then I review every commit and read it for clarity and correct >> > >> > English usage. Does it fit where someone put it? Does it explain what >> > >> > the author is hoping it explains? Also, many of our authors are not >> > >> > native English writers, and deserve the assistance of an editor to >> > >> > help put their work in the best possible light. In some cases, I feel >> > >> > I should extensively edit the contribution, which occasionally >> > >> > involves also immersing myself into the change itself. This is >> > >> > another 2-4 days of effort. >> > >> > >> > >> > Then there's this list of problems people commit all the time, many >> > >> > of which I can often resolve reasonably quickly with find/replace: >> > >> > >> > >> > - sentences that don't end in periods >> > >> > - inconsistency with instances of "i.e.," and "e.g.," (not "i.e.", >> > >> > "ie:", "IE", etc.) >> > >> > - no spaces between words and punctuation (commas, colons, periods), >> > >> > such as "here is :" or "word , word" >> > >> > - used sentence case for section titles instead of headline case >> > >> > - used abbreviations instead of the correct word ("ZK" instead of >> > >> > "ZooKeeper" being the biggest one here, but also "params" instead of >> > >> > "parameters" is quite common) >> > >> > - misspellings like "Zookeeper" instead of "ZooKeeper, or "solr" >> > >> > instead of "Solr" >> > >> > - config file names and parameter names/values not in monospace >> > >> > - lists of parameters are not properly formatted (should not be in >> > >> > tables) >> > >> > >> > >> > These are all to make the Ref Guide as consistent, cohesive, and easy >> > >> > to read as possible. It may be written by 30 people but it shouldn't >> > >> > read like it is. >> > >> > >> > >> > Should I do all this while the commits are coming through? Sure, but >> > >> > the reality is I can't. If we want to release the moment someone >> > >> > proposes a release, then most of my find/replace list above needs to >> > >> > go into precommit so these problems don't make it into the Guide to >> > >> > begin with. (Which might be onerous since we'd all get stalled >> > >> > waiting for someone to fix a typo...but really, precommit is meant in >> > >> > part to find your typos so why should this be different?) >> > >> > >> > >> > It would always still need editorial review, however, and that's not >> > >> > something we'll ever be able to fully automate. I'm more than happy >> > >> > to have a little help there, but assume since people aren't doing it >> > >> > today they don't have time, don't feel they have the skills, or don't >> > >> > want to bother. Or maybe I just kill myself for a level of quality no >> > >> > one else cares about...not sure I can stop doing it though if I'm the >> > >> > RM. >> > >> > >> > >> > (as a side note on that though, if we do merge the releases someday, >> > >> > then whoever RMs is going to have to wait for these editorial >> > >> > processes to be completed or the vote may fail because the Ref Guide >> > >> > reads like crap.) >> > >> > >> > >> > On Tue, Sep 4, 2018 at 11:33 AM jim ferenczi <jim.feren...@gmail.com >> > >> > <mailto:jim.feren...@gmail.com>> wrote: >> > >> >> >> > >> >> Thanks for explaining the situation Cassandra. I was planning to >> > >> >> build the first RC beginning of next week to give people a week to >> > >> >> discover blockers. I can certainly slow down things but I don't >> > >> >> think that the timing >> > >> >> differs from other releases. I am not aware of the operations that >> > >> >> are required for the Ref guide release process but what do you think >> > >> >> of sharing the tasks with the RM ? We could even merge the two >> > >> >> releases and make the RM responsible of both if the process is >> > >> >> documented. I'd be happy to experiment this for the 7.5 release if >> > >> >> you want. >> > >> >> >> > >> >> Le mar. 4 sept. 2018 à 17:55, Cassandra Targett >> > >> >> <casstarg...@gmail.com <mailto:casstarg...@gmail.com>> a écrit : >> > >> >>> >> > >> >>> I'm not objecting per se, but I feel like we used to propose a >> > >> >>> version and then give people a week before the branch was cut. >> > >> >>> Maybe that was just RM choice? From a personal perspective, I much >> > >> >>> prefer that model because the Ref Guide requires A LOT of my >> > >> >>> attention and my work there kicks into high gear as soon as a >> > >> >>> release is proposed. >> > >> >>> >> > >> >>> Even though the artifact and Ref Guide release processes are >> > >> >>> separate today, we want them to be a single process, so I need to >> > >> >>> act as though your timeframe for the RC is the deadline for Ref >> > >> >>> Guide edits to do an RC of the Ref Guide at the same time. That >> > >> >>> means I'm on your timetable, no matter what else I may have >> > >> >>> promised to my bosses and colleagues. It's stressful already to try >> > >> >>> to get it all done - I usually don't finish everything I want to do >> > >> >>> - and adding the burden of having to backport everything to 2 >> > >> >>> branches instead of 1 just makes it tedious as well. >> > >> >>> >> > >> >>> Also, yesterday was a major holiday in the US, and as of this >> > >> >>> moment it's not even noon on the East Coast, so there's a >> > >> >>> percentage of the community who may not even have seen your >> > >> >>> proposal yet. >> > >> >>> >> > >> >>> I greatly appreciate that you've volunteered to do the release and >> > >> >>> are energized to get it rolling, but is there a reason an RC has to >> > >> >>> be done by the beginning of next week? >> > >> >>> >> > >> >>> On Tue, Sep 4, 2018 at 10:36 AM Joel Bernstein <joels...@gmail.com >> > >> >>> <mailto:joels...@gmail.com>> wrote: >> > >> >>>> >> > >> >>>> +1, >> > >> >>>> >> > >> >>>> I'll likely be adding some Solr RefGuide changes later in the week >> > >> >>>> to the 7.5 branch but I'll make sure they don't effect the build. >> > >> >>>> >> > >> >>>> >> > >> >>>> Joel Bernstein >> > >> >>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/> >> > >> >>>> >> > >> >>>> >> > >> >>>> On Tue, Sep 4, 2018 at 10:52 AM jim ferenczi >> > >> >>>> <jim.feren...@gmail.com <mailto:jim.feren...@gmail.com>> wrote: >> > >> >>>>> >> > >> >>>>> Thanks all, >> > >> >>>>> since there are no objections I am planning to cut the branch for >> > >> >>>>> 7.5 tomorrow. I'll build the first RC early next week so there >> > >> >>>>> will be some room to merge important bug fixes later this week. >> > >> >>>>> All blockers except SOLR-12727 seem to be merged/resolved, I'll >> > >> >>>>> watch the remaining solr issue for updates. >> > >> >>>>> >> > >> >>>>> Le mar. 4 sept. 2018 à 10:21, jim ferenczi >> > >> >>>>> <jim.feren...@gmail.com <mailto:jim.feren...@gmail.com>> a écrit : >> > >> >>>>>> >> > >> >>>>>> Sure Jan, this is a nice cleanup, +1 to backport in 7x. >> > >> >>>>>> >> > >> >>>>>> Le mar. 4 sept. 2018 à 10:16, Jan Høydahl <jan....@cominvent.com >> > >> >>>>>> <mailto:jan....@cominvent.com>> a écrit : >> > >> >>>>>>> >> > >> >>>>>>> Jim, we have some release process improvements in LUCENE-5143. >> > >> >>>>>>> Basically, we'll only have one KEYS file instead of three plus >> > >> >>>>>>> those in the versioned folders that we have today. And the >> > >> >>>>>>> release py script will start checking that the RM's key is >> > >> >>>>>>> present in the KEYS file. Would you be ok with that being >> > >> >>>>>>> committed and you being the first RM to use it for 7.5.0? >> > >> >>>>>>> >> > >> >>>>>>> -- >> > >> >>>>>>> Jan Høydahl, search solution architect >> > >> >>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/> >> > >> >>>>>>> >> > >> >>>>>>> 3. sep. 2018 kl. 10:42 skrev jim ferenczi >> > >> >>>>>>> <jim.feren...@gmail.com <mailto:jim.feren...@gmail.com>>: >> > >> >>>>>>> >> > >> >>>>>>> Hi all, >> > >> >>>>>>> >> > >> >>>>>>> 7.4 has been released two months ago on June 29th and we have >> > >> >>>>>>> new features, enhancements and fixes that are not released yet >> > >> >>>>>>> so I'd like to start working on releasing Lucene/Solr 7.5.0. >> > >> >>>>>>> There's also a bad bug with index sorting that deletes the >> > >> >>>>>>> wrong documents when delete by query is used: >> > >> >>>>>>> https://issues.apache.org/jira/browse/LUCENE-8466 >> > >> >>>>>>> <https://issues.apache.org/jira/browse/LUCENE-8466> >> > >> >>>>>>> >> > >> >>>>>>> I can create the 7.5 branch later this week and build the first >> > >> >>>>>>> RC early next week if that works for everyone. Please let me >> > >> >>>>>>> know if there are bug fixes that needs to be fixed in 7.5 and >> > >> >>>>>>> might not be ready by then. >> > >> >>>>>>> >> > >> >>>>>>> Cheers, >> > >> >>>>>>> Jim >> > >> >>>>>>> >> > >> >>>>>>> >> > >> >> > >> --------------------------------------------------------------------- >> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > >> <mailto:dev-unsubscr...@lucene.apache.org> >> > >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> <mailto:dev-h...@lucene.apache.org> >> > >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > <mailto:dev-unsubscr...@lucene.apache.org> >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > <mailto:dev-h...@lucene.apache.org> >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> <mailto:dev-unsubscr...@lucene.apache.org> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> <mailto:dev-h...@lucene.apache.org> >> > > > > — > > Andrzej Białecki > — Andrzej Białecki
