Perfect, thanks Cassandra ! Le mar. 11 sept. 2018 à 22:35, Cassandra Targett <casstarg...@gmail.com> a écrit :
> Jim, your suggestion of Friday for the RC & vote on Monday sounds great. > > I'm done with my major reviews/edits. I still have the smaller typos I > look for to do - I can skip those if I have to, but realistically I can > probably get them done tomorrow. > > Cassandra > > On Tue, Sep 11, 2018 at 3:16 PM jim ferenczi <jim.feren...@gmail.com> > wrote: > >> Sorry but this was just committed to master and branch_7x and I see some >> discussions regarding the implication of this change. Is it really safe to >> include it in 7.5 ? >> >> Le mar. 11 sept. 2018 à 21:43, Varun Thacker <va...@vthacker.in> a >> écrit : >> >>> Hi Jim, >>> >>> I'd like to backport SOLR-11836 if that's okay with you. It's a trivial >>> fix which I committed to master and branch_7x a little while ago. >>> >>> On Tue, Sep 11, 2018 at 9:09 AM jim ferenczi <jim.feren...@gmail.com> >>> wrote: >>> >>>> Thanks Steve! >>>> >>>> Le mar. 11 sept. 2018 à 18:02, Steve Rowe <sar...@gmail.com> a écrit : >>>> >>>>> Hi Jim, >>>>> >>>>> > On Sep 11, 2018, at 11:32 AM, jim ferenczi <jim.feren...@gmail.com> >>>>> wrote: >>>>> > >>>>> > Could someone help to setup the Jenkins releases build ? It seems >>>>> that I cannot create jobs with my account. >>>>> >>>>> >>>>> Each project's PMC Chair is responsible for granting job >>>>> creation/modification permissions on Jenkins: >>>>> https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount >>>>> >>>>> I’ll go create the 7.5 jobs now. >>>>> >>>>> -- >>>>> Steve >>>>> www.lucidworks.com >>>>> >>>>> > On Sep 11, 2018, at 11:32 AM, jim ferenczi <jim.feren...@gmail.com> >>>>> wrote: >>>>> > >>>>> > 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 >>>>> >>>>>
