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 >>>> >>>>
