It was not my intention to hold up LUCENE-9434, I was worried that it could affect formatting. That should be easy to verify though, so feel free to continue with the patch!
Jan > 9. okt. 2020 kl. 18:52 skrev Cassandra Targett <[email protected]>: > > We discussed this before and agreed that could be removed. I made a patch to > remove it but my editor always removes trailing whitespace and Jan doesn’t > want that for some reason and I haven’t had time to go back to it. See > https://issues.apache.org/jira/browse/LUCENE-9434 > <https://issues.apache.org/jira/browse/LUCENE-9434>. > On Oct 9, 2020, 11:09 AM -0500, Jason Gerlowski <[email protected]>, > wrote: >> Small correction: I see now some pages for 8.4 and 8.6 in a different >> section of the wiki tree. But the overall point still stands I think >> - this hasn't been done consistently and it doesn't seem like that's >> caused any problems (as the pages are all stubs anyways). >> >> On Fri, Oct 9, 2020 at 12:05 PM Jason Gerlowski <[email protected]> >> wrote: >>> >>> The traditional (non-docker) part of the release should now be wrapped >>> up. Thanks everyone for the help and answering my questions here and >>> in Slack. One final question: >>> >>> The final releaseWizard.py step instructs: >>> >>> "The Solr WIKI has a page for every version which is often linked to >>> from WIKI pages to indicate differences between versions, example: >>> http://wiki.apache.org/solr/Solr4.3. Do the following: Update the page >>> for the released version with release date and link to release >>> statement. Create a new placeholder page for the "next" version, if it >>> does not exist" >>> >>> But looking at our wiki, the latest of these pages is 8.2 >>> (https://cwiki.apache.org/confluence/display/SOLR/Solr8.2). I've >>> created the pages as instructed for now. But if we're not following >>> this step regularly and it hasn't caused any issues maybe we should >>> remove it from the release process altogether? >>> >>> Jason >>> >>> On Thu, Oct 8, 2020 at 5:16 PM David Smiley <[email protected]> wrote: >>>> >>>> The way GitHub works for contributors is that you are expected to fork a >>>> repo and then push to your fork. At that point when you go to the PR area, >>>> you'll see a convenient yellow dialog to create a PR based on your pushed >>>> branch. >>>> >>>> ~ David Smiley >>>> Apache Lucene/Solr Search Developer >>>> http://www.linkedin.com/in/davidwsmiley >>>> >>>> >>>> On Thu, Oct 8, 2020 at 10:20 AM Chris Hostetter <[email protected]> >>>> wrote: >>>>> >>>>> >>>>> FWIW: I followed the docs to update the Dockerfiles + TAGS for 8.6.3, and >>>>> run tests; but since it's in a distinct github repo I don't think i can >>>>> push to it? >>>>> >>>>> so i creaed a GH issue w/patch... >>>>> >>>>> https://github.com/docker-solr/docker-solr/issues/349 >>>>> >>>>> >>>>> >>>>> : Date: Tue, 6 Oct 2020 11:33:15 -0400 >>>>> : From: Houston Putman <[email protected]> >>>>> : Reply-To: [email protected] >>>>> : To: Solr/Lucene Dev <[email protected]> >>>>> : Subject: Re: 8.6.3 Release >>>>> : >>>>> : That is correct. 8.x docker builds have not been affected in any way. >>>>> : >>>>> : On Tue, Oct 6, 2020 at 11:30 AM Cassandra Targett >>>>> <[email protected]> >>>>> : wrote: >>>>> : >>>>> : > I wanted to ask now that the 8.6.3 vote is underway - for the >>>>> docker-solr >>>>> : > image, are the update instructions in the docker-solr repo still the >>>>> same >>>>> : > for 8.x even though the build process has been moved to the main >>>>> project >>>>> : > for 9.0? Meaning, to release the 8.6.3 image there’s no change from >>>>> before, >>>>> : > right? >>>>> : > >>>>> : > I’m asking specifically about these instructions: >>>>> : > >>>>> : > https://github.com/docker-solr/docker-solr/blob/master/update.md >>>>> : > On Oct 1, 2020, 9:28 AM -0500, Jason Gerlowski >>>>> <[email protected]>, >>>>> : > wrote: >>>>> : > >>>>> : > I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can >>>>> : > someone please sanity check the summaries there when they get a >>>>> : > chance? Would appreciate the review. >>>>> : > >>>>> : > 8.6.3 is a bit interesting in that Lucene has no changes in this >>>>> : > bugfix release. As a result I had to omit the standard phrase in the >>>>> : > Solr release notes about there being additional changes at the Lucene >>>>> : > level, and change some of the wording in the Lucene announcement to >>>>> : > indicate the lack of changes. So that's something to pay particular >>>>> : > attention to, if someone can check my wording there. >>>>> : > >>>>> : > [1] >>>>> https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863 >>>>> : > [2] >>>>> : > >>>>> https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863 >>>>> : > >>>>> : > On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski >>>>> <[email protected]> >>>>> : > wrote: >>>>> : > >>>>> : > >>>>> : > The only one that was previously mentioned as a blocker was >>>>> : > SOLR-14835, but from the comments on the ticket it looks like it ended >>>>> : > up being purely a cosmetic issue. Andrzej left a comment there >>>>> : > suggesting that we "address" this with documentation for 8.6.3 but >>>>> : > otherwise leave it as-is. >>>>> : > >>>>> : > So it looks like we're unblocked on starting the release process. >>>>> : > Will begin the preliminary steps this afternoon. >>>>> : > >>>>> : > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett >>>>> <[email protected]> >>>>> : > wrote: >>>>> : > >>>>> : > >>>>> : > It looks to me like everything for 8.6.3 is resolved now ( >>>>> : > https://issues.apache.org/jira/projects/SOLR/versions/12348713), and >>>>> it >>>>> : > seems from comments in SOLR-14897 and SOLR-14898 that those fixes >>>>> make a >>>>> : > Jetty upgrade less compelling to try. >>>>> : > >>>>> : > Are there any other issues not currently marked for 8.6.3 we’re >>>>> waiting >>>>> : > for before starting the RC? >>>>> : > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski >>>>> <[email protected]>, >>>>> : > wrote: >>>>> : > >>>>> : > That said, if someone can use 8.6.3, what’s stopping them from going >>>>> to >>>>> : > 8.7 when it’e released? >>>>> : > >>>>> : > >>>>> : > The same things that always stop users from going directly to the >>>>> : > latest-and-greatest: fear of instability from new minor-release >>>>> : > features, reliance on behavior changed across minor versions, breaking >>>>> : > changes on Lucene elements that don't guarantee backcompat (e.g. >>>>> : > SOLR-14254), security issues in later versions (new libraries pulled >>>>> : > in with vulns), etc. There's lots of reasons a given user might want >>>>> : > to stick on 8.6.x rather than 8.7 (in the short/medium term). >>>>> : > >>>>> : > I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above >>>>> : > the worst of the Jetty issue should be mitigated by work on our end - >>>>> : > but I think there's a lot of reasons users might not upgrade as far as >>>>> : > we'd expect/like. >>>>> : > >>>>> : > >>>>> : > On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson >>>>> <[email protected]> >>>>> : > wrote: >>>>> : > >>>>> : > >>>>> : > For me, there’s a sharp distinction between changing a dependency in a >>>>> : > point release just because there’s a new version, and changing the >>>>> : > dependency because there’s a bug in it. That said, if someone can use >>>>> : > 8.6.3, what’s stopping them from going to 8.7 when it’e released? >>>>> Would it >>>>> : > make more sense to do the upgrades for 8.7 and get that out the door >>>>> rather >>>>> : > than backport? >>>>> : > >>>>> : > FWIW, >>>>> : > Erick >>>>> : > >>>>> : > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski <[email protected]> >>>>> : > wrote: >>>>> : > >>>>> : > Hey all, >>>>> : > >>>>> : > I wanted to add 2 more blocker tickets to the list: SOLR-14897 and >>>>> : > SOLR-14898. These tickets (while bad bugs in their own right) are >>>>> : > especially necessary because they work around a Jetty buffer-reuse bug >>>>> : > (see SOLR-14896) that causes sporadic request failures once triggered. >>>>> : > >>>>> : > So that brings the list of 8.6.3 blockers up to: SOLR-14850, >>>>> : > SOLR-14835, SOLR-14897, and SOLR-14898. (Thanks David for the quick >>>>> : > work on SOLR-14768!) >>>>> : > >>>>> : > Additionally, should we also consider a Jetty upgrade for 8.6.3 in >>>>> : > light of the issue mentioned above? I know it's atypical for bug-fix >>>>> : > releases to change deps, but here the bug is serious and tied directly >>>>> : > to the dep. SOLR-14897 and SOLR-14898 help greatly here, but the >>>>> : > Jetty bug is likely still a problem for users making requests that >>>>> : > match a specific (albeit rare) profile. Anyone have thoughts? >>>>> : > >>>>> : > Best, >>>>> : > >>>>> : > Jason >>>>> : > >>>>> : > On Fri, Sep 25, 2020 at 12:28 AM Houston Putman >>>>> <[email protected]> >>>>> : > wrote: >>>>> : > >>>>> : > >>>>> : > If I recall correctly, thats a step in the release wizard. >>>>> : > >>>>> : > After checking, I think this fits the bill: >>>>> : > >>>>> : > >>>>> https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/releaseWizard.yaml#L1435 >>>>> : > >>>>> : > - Houston >>>>> : > >>>>> : > On Fri, Sep 25, 2020 at 12:06 AM David Smiley <[email protected]> >>>>> wrote: >>>>> : > >>>>> : > >>>>> : > When moving changes from 8.7 to 8.6.3, must we (the mover of an >>>>> individual >>>>> : > change) move the CHANGES.txt entry on all branches -- master, >>>>> branch_8x, >>>>> : > branch_8_6? I expect the release branch but am unsure of the other >>>>> two. In >>>>> : > the past I have but it's annoying. Does the RM sync CHANGES.txt on the >>>>> : > other branches in one go? If not, I think it'd make sense for that to >>>>> : > happen. >>>>> : > >>>>> : > ~ David Smiley >>>>> : > Apache Lucene/Solr Search Developer >>>>> : > http://www.linkedin.com/in/davidwsmiley >>>>> : > >>>>> : > >>>>> : > On Thu, Sep 24, 2020 at 6:22 AM Atri Sharma <[email protected]> wrote: >>>>> : > >>>>> : > >>>>> : > I will push the 8.7 release by a week to give Jason enough headroom to >>>>> : > >>>>> : > >>>>> : > do the 8.6.3 release. >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > Jason, let me know if you need me to assist on the 8.6.3 release. >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > On Thu, Sep 24, 2020 at 3:23 PM Jason Gerlowski >>>>> <[email protected]> >>>>> : > wrote: >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > OK, in that case I'll try my best to keep the 8.6.3 process moving >>>>> : > >>>>> : > >>>>> : > >>>>> : > then, so Atri can stick as close to his proposed schedule as possible. >>>>> : > >>>>> : > >>>>> : > >>>>> : > My apologies - I didn't realize I'd be putting the brakes on 8.7 by >>>>> : > >>>>> : > >>>>> : > >>>>> : > proposing a bug-fix release. But the reasons make sense given what >>>>> : > >>>>> : > >>>>> : > >>>>> : > others mentioned above. >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > As branch_8_6 should be pretty stable by now I wonder if we really >>>>> need to >>>>> : > wait one week? >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > There's no special reason on my end. I suggested a week to give >>>>> : > >>>>> : > >>>>> : > >>>>> : > others time to backport anything they wanted included, but I'm happy >>>>> : > >>>>> : > >>>>> : > >>>>> : > to start the process as soon as all the expected changes land. >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > Best, >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > Jason >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > On Thu, Sep 24, 2020 at 1:48 AM Anshum Gupta <[email protected]> >>>>> : > wrote: >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > Simultaneous releases are also confusing for users, in addition to the >>>>> : > back-compat tests as our website chronologically lists our releases >>>>> and it >>>>> : > gets complicated for someone reading the 'News' page. >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > As 8.7 isn't a release that needs to be rushed, waiting until 8.6.3 is >>>>> : > released and back-compat indexes are pushed will make things easier >>>>> for the >>>>> : > RMs and community. >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > On Wed, Sep 23, 2020 at 1:43 PM David Smiley <[email protected]> >>>>> wrote: >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > Jason: Thanks for volunteering to do an 8.6.3! I recently fixed >>>>> : > SOLR-14768, multipart HTTP POST was broken in 8.6 (a regression I >>>>> : > introduced). If you can't do the release or need help, I will take >>>>> over. >>>>> : > It's the least I can offer in repentance for the regression. >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > ~ David Smiley >>>>> : > >>>>> : > >>>>> : > >>>>> : > Apache Lucene/Solr Search Developer >>>>> : > >>>>> : > >>>>> : > >>>>> : > http://www.linkedin.com/in/davidwsmiley >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > On Wed, Sep 23, 2020 at 10:07 AM Jason Gerlowski >>>>> <[email protected]> >>>>> : > wrote: >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > Hi all, >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > I ran into a query-parsing bug recently in SOLR-14859 that caused >>>>> : > >>>>> : > >>>>> : > >>>>> : > problems for some of my usecases. I wanted to volunteer as RM for an >>>>> : > >>>>> : > >>>>> : > >>>>> : > 8.6.3 to get a bugfix release out for users that aren't ready for some >>>>> : > >>>>> : > >>>>> : > >>>>> : > of the bigger changes in 8.7 >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > I was thinking of cutting the branch in a week's time to give others a >>>>> : > >>>>> : > >>>>> : > >>>>> : > chance to backport any bug-fixes they might want included, with an RC >>>>> : > >>>>> : > >>>>> : > >>>>> : > to follow shortly. Does anyone have any concerns with that plan, or >>>>> : > >>>>> : > >>>>> : > >>>>> : > have anything they'd like to fix or backport before an 8.6.3 goes out? >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > Best, >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > Jason >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > --------------------------------------------------------------------- >>>>> : > >>>>> : > >>>>> : > >>>>> : > To unsubscribe, e-mail: [email protected] >>>>> : > >>>>> : > >>>>> : > >>>>> : > For additional commands, e-mail: [email protected] >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > -- >>>>> : > >>>>> : > >>>>> : > >>>>> : > Anshum Gupta >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > --------------------------------------------------------------------- >>>>> : > >>>>> : > >>>>> : > >>>>> : > To unsubscribe, e-mail: [email protected] >>>>> : > >>>>> : > >>>>> : > >>>>> : > For additional commands, e-mail: [email protected] >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > -- >>>>> : > >>>>> : > >>>>> : > Regards, >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > Atri >>>>> : > >>>>> : > >>>>> : > Apache Concerted >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > --------------------------------------------------------------------- >>>>> : > >>>>> : > >>>>> : > To unsubscribe, e-mail: [email protected] >>>>> : > >>>>> : > >>>>> : > For additional commands, e-mail: [email protected] >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > >>>>> : > --------------------------------------------------------------------- >>>>> : > To unsubscribe, e-mail: [email protected] >>>>> : > For additional commands, e-mail: [email protected] >>>>> : > >>>>> : > >>>>> : > >>>>> : > --------------------------------------------------------------------- >>>>> : > To unsubscribe, e-mail: [email protected] >>>>> : > For additional commands, e-mail: [email protected] >>>>> : > >>>>> : > >>>>> : > --------------------------------------------------------------------- >>>>> : > To unsubscribe, e-mail: [email protected] >>>>> : > For additional commands, e-mail: [email protected] >>>>> : > >>>>> : > >>>>> : > --------------------------------------------------------------------- >>>>> : > To unsubscribe, e-mail: [email protected] >>>>> : > For additional commands, e-mail: [email protected] >>>>> : > >>>>> : > >>>>> : >>>>> >>>>> -Hoss >>>>> http://www.lucidworks.com/ >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >>
