LUCENE-8502 is in and backported On Mon, Sep 17, 2018 at 2:14 PM 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> 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> 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 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> 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 >>> >>> > On Sep 14, 2018, at 8:40 AM, Cassandra Targett <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> >>> 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> 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> >>> wrote: >>> > Thanks ! >>> > >>> > Le mer. 12 sept. 2018 à 11:49, Adrien Grand <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> >>> 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> 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> >>> 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> >>> 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> >>> a écrit : >>> > Great, thanks! >>> > On Wed, Sep 5, 2018 at 8:44 AM jim ferenczi <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> 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> 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. >>> 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> 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> 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> 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/ >>> > >> >>>> >>> > >> >>>> >>> > >> >>>> On Tue, Sep 4, 2018 at 10:52 AM jim ferenczi < >>> 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> 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> 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 >>> > >> >>>>>>> >>> > >> >>>>>>> 3. sep. 2018 kl. 10:42 skrev jim ferenczi < >>> 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 >>> > >> >>>>>>> >>> > >> >>>>>>> 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 >>> > >> For additional commands, e-mail: dev-h...@lucene.apache.org >>> > >> >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>> > >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >> >> >> — >> >> Andrzej Białecki >> >>
