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
