[prev in list] [next in list] [prev in thread] [next in thread]
List: lucene-dev
Subject: Re: 8.6.3 Release
From: David Smiley <dsmiley () apache ! org>
Date: 2020-10-23 0:17:19
Message-ID: CABEwPvHDJHeqp98AJ_Z4n40OvFqaz4Kam_PgN9M0PFq6Qpa1Pw () mail ! gmail ! com
[Download RAW message or body]
I don't think the status of any page should be in the name of the page --
it breaks links when it changes. The status can be at the top of the
content.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Oct 22, 2020 at 10:55 AM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:
> I guess some convention due to MoinMoin?
>
> On Thu, 22 Oct, 2020, 7:25 pm Jason Gerlowski, <gerlowskija@gmail.com>
> wrote:
>
>> On the topic - is there a particular reason behind the convention of
>> having the page titles be named without spaces or periods? As is they
>> look more like Java classnames than page titles. e.g.
>> "ReleaseNote852" vs "Release Notes: 8.5.2" vs. "8.5.2 Release Notes"
>>
>> On Thu, Oct 22, 2020 at 9:50 AM Jason Gerlowski <gerlowskija@gmail.com>
>> wrote:
>> >
>> > I added that "DRAFT-" prefix mostly for the reason Atri mentioned: to
>> > indicate that the page was a WIP. I thought it might also have the
>> > side benefit of catching the eye of any committers who had Confluence
>> > open and a few minutes to review the content. The page still has
>> > "DRAFT-" because, as Cassandra suspected, I forgot to update it once
>> > the release was finished. Fixing now.
>> >
>> > On Thu, Oct 22, 2020 at 9:47 AM Atri Sharma <atri@apache.org> wrote:
>> > >
>> > > Fair point -- I have changed accordingly.
>> > >
>> > > On Thu, Oct 22, 2020 at 7:09 PM Cassandra Targett <
>> casstargett@gmail.com> wrote:
>> > > >
>> > > > That's a fair thing to consider, but does it really matter if
>> someone looks at the draft notes pre-release? What would be the harm if
>> users happen across them before they're done?
>> > > >
>> > > > (And to David's point, it's not in the RM steps to fix the page
>> name after release, so it's pretty easy to forget to do it.)
>> > > > On Oct 22, 2020, 8:31 AM -0500, Atri Sharma <atri@apache.org>,
>> wrote:
>> > > >
>> > > > I added it since it looked a safe way to indicate that the draft
>> notes
>> > > > are in progress and should not be referred to in case somebody is
>> > > > surfing the release notes.
>> > > >
>> > > > Atri
>> > > >
>> > > > On Thu, Oct 22, 2020 at 6:23 PM David Smiley <dsmiley@apache.org>
>> wrote:
>> > > >
>> > > >
>> > > > Jason: This is the first time I recall seeing release note pages in
>> Confluence with a "DRAFT-" prefix. And I also see that Atri has follow-ed
>> suit (following your lead, no doubt) for 8.6. Why? Looking at the page
>> navigation, it's clearly an oddity -- a change. And it's still DRAFT
>> despite it being released.
>> > > >
>> > > > ~ David Smiley
>> > > > Apache Lucene/Solr Search Developer
>> > > > http://www.linkedin.com/in/davidwsmiley
>> > > >
>> > > >
>> > > > On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski <
>> gerlowskija@gmail.com> 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 <
>> gerlowskija@gmail.com> 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 <
>> casstargett@gmail.com> 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 <
>> gerlowskija@gmail.com>, 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 <
>> erickerickson@gmail.com> 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 <gerlowskija@gmail.com>
>> 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 <
>> houstonputman@gmail.com> 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 <dsmiley@apache.org>
>> 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 <atri@apache.org>
>> 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 <
>> gerlowskija@gmail.com> 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 <
>> anshum@anshumgupta.net> 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 <dsmiley@apache.org>
>> 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 <
>> gerlowskija@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>> > > >
>> > > >
>> > > >
>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > >
>> > > >
>> > > >
>> > > > Anshum Gupta
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > >
>> > > >
>> > > >
>> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >
>> > > >
>> > > >
>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > >
>> > > >
>> > > > Regards,
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > Atri
>> > > >
>> > > >
>> > > > Apache Concerted
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > >
>> > > >
>> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >
>> > > >
>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Regards,
>> > > >
>> > > > Atri
>> > > > Apache Concerted
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >
>> > >
>> > >
>> > > --
>> > > Regards,
>> > >
>> > > Atri
>> > > Apache Concerted
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
[Attachment #3 (text/html)]
<div dir="ltr">I don't think the status of any page should be in the name of the \
page -- it breaks links when it changes. The status can be at the top of the \
content.<div><br clear="all"><div><div dir="ltr" class="gmail_signature" \
data-smartmail="gmail_signature"><div dir="ltr">~ David Smiley<div>Apache Lucene/Solr \
Search Developer</div><div><a href="http://www.linkedin.com/in/davidwsmiley" \
target="_blank">http://www.linkedin.com/in/davidwsmiley</a></div></div></div></div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 22, 2020 at 10:55 \
AM Ishan Chattopadhyaya <<a \
href="mailto:ichattopadhyaya@gmail.com">ichattopadhyaya@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
dir="auto">I guess some convention due to MoinMoin?</div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 22 Oct, 2020, 7:25 pm \
Jason Gerlowski, <<a href="mailto:gerlowskija@gmail.com" \
target="_blank">gerlowskija@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On \
the topic - is there a particular reason behind the convention of<br> having the page \
titles be named without spaces or periods? As is they<br> look more like Java \
classnames than page titles. e.g.<br> "ReleaseNote852" vs "Release \
Notes: 8.5.2" vs. "8.5.2 Release Notes"<br> <br>
On Thu, Oct 22, 2020 at 9:50 AM Jason Gerlowski <<a \
href="mailto:gerlowskija@gmail.com" rel="noreferrer" \
target="_blank">gerlowskija@gmail.com</a>> wrote:<br> ><br>
> I added that "DRAFT-" prefix mostly for the reason Atri mentioned: \
to<br> > indicate that the page was a WIP. I thought it might also have the<br>
> side benefit of catching the eye of any committers who had Confluence<br>
> open and a few minutes to review the content. The page still has<br>
> "DRAFT-" because, as Cassandra suspected, I forgot to update it \
once<br> > the release was finished. Fixing now.<br>
><br>
> On Thu, Oct 22, 2020 at 9:47 AM Atri Sharma <<a href="mailto:atri@apache.org" \
rel="noreferrer" target="_blank">atri@apache.org</a>> wrote:<br> > ><br>
> > Fair point -- I have changed accordingly.<br>
> ><br>
> > On Thu, Oct 22, 2020 at 7:09 PM Cassandra Targett <<a \
href="mailto:casstargett@gmail.com" rel="noreferrer" \
target="_blank">casstargett@gmail.com</a>> wrote:<br> > > ><br>
> > > That's a fair thing to consider, but does it really matter if someone \
looks at the draft notes pre-release? What would be the harm if users happen across \
them before they're done?<br> > > ><br>
> > > (And to David's point, it's not in the RM steps to fix the page name \
after release, so it's pretty easy to forget to do it.)<br> > > > On Oct 22, \
2020, 8:31 AM -0500, Atri Sharma <<a href="mailto:atri@apache.org" \
rel="noreferrer" target="_blank">atri@apache.org</a>>, wrote:<br> > > \
><br> > > > I added it since it looked a safe way to indicate that the \
draft notes<br> > > > are in progress and should not be referred to in case \
somebody is<br> > > > surfing the release notes.<br>
> > ><br>
> > > Atri<br>
> > ><br>
> > > On Thu, Oct 22, 2020 at 6:23 PM David Smiley <<a \
href="mailto:dsmiley@apache.org" rel="noreferrer" \
target="_blank">dsmiley@apache.org</a>> wrote:<br> > > ><br>
> > ><br>
> > > Jason: This is the first time I recall seeing release note pages in \
Confluence with a "DRAFT-" prefix. And I also see that Atri has follow-ed \
suit (following your lead, no doubt) for 8.6. Why? Looking at the page navigation, \
it's clearly an oddity -- a change. And it's still DRAFT despite it being \
released.<br> > > ><br>
> > > ~ David Smiley<br>
> > > Apache Lucene/Solr Search Developer<br>
> > > <a href="http://www.linkedin.com/in/davidwsmiley" rel="noreferrer \
noreferrer" target="_blank">http://www.linkedin.com/in/davidwsmiley</a><br> > > \
><br> > > ><br>
> > > On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski <<a \
href="mailto:gerlowskija@gmail.com" rel="noreferrer" \
target="_blank">gerlowskija@gmail.com</a>> wrote:<br> > > ><br>
> > ><br>
> > > I've put together draft Release Notes for 8.6.3 here. [1] [2]. \
Can<br> > > > someone please sanity check the summaries there when they get \
a<br> > > > chance? Would appreciate the review.<br>
> > ><br>
> > > 8.6.3 is a bit interesting in that Lucene has no changes in this<br>
> > > bugfix release. As a result I had to omit the standard phrase in \
the<br> > > > Solr release notes about there being additional changes at the \
Lucene<br> > > > level, and change some of the wording in the Lucene \
announcement to<br> > > > indicate the lack of changes. So that's \
something to pay particular<br> > > > attention to, if someone can check my \
wording there.<br> > > ><br>
> > > [1] <a \
href="https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863" \
rel="noreferrer noreferrer" \
target="_blank">https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863</a><br>
> > > [2] <a \
href="https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863" \
rel="noreferrer noreferrer" \
target="_blank">https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863</a><br>
> > ><br>
> > > On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski <<a \
href="mailto:gerlowskija@gmail.com" rel="noreferrer" \
target="_blank">gerlowskija@gmail.com</a>> wrote:<br> > > ><br>
> > ><br>
> > > The only one that was previously mentioned as a blocker was<br>
> > > SOLR-14835, but from the comments on the ticket it looks like it \
ended<br> > > > up being purely a cosmetic issue. Andrzej left a comment \
there<br> > > > suggesting that we "address" this with \
documentation for 8.6.3 but<br> > > > otherwise leave it as-is.<br>
> > ><br>
> > > So it looks like we're unblocked on starting the release \
process.<br> > > > Will begin the preliminary steps this afternoon.<br>
> > ><br>
> > > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett <<a \
href="mailto:casstargett@gmail.com" rel="noreferrer" \
target="_blank">casstargett@gmail.com</a>> wrote:<br> > > ><br>
> > ><br>
> > > It looks to me like everything for 8.6.3 is resolved now (<a \
href="https://issues.apache.org/jira/projects/SOLR/versions/12348713" rel="noreferrer \
noreferrer" target="_blank">https://issues.apache.org/jira/projects/SOLR/versions/12348713</a>), \
and it seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a Jetty \
upgrade less compelling to try.<br> > > ><br>
> > > Are there any other issues not currently marked for 8.6.3 we're \
waiting for before starting the RC?<br> > > > On Sep 29, 2020, 12:04 PM \
-0500, Jason Gerlowski <<a href="mailto:gerlowskija@gmail.com" rel="noreferrer" \
target="_blank">gerlowskija@gmail.com</a>>, wrote:<br> > > ><br>
> > > That said, if someone can use 8.6.3, what's stopping them from going \
to 8.7 when it'e released?<br> > > ><br>
> > ><br>
> > > The same things that always stop users from going directly to the<br>
> > > latest-and-greatest: fear of instability from new minor-release<br>
> > > features, reliance on behavior changed across minor versions, \
breaking<br> > > > changes on Lucene elements that don't guarantee \
backcompat (e.g.<br> > > > SOLR-14254), security issues in later versions \
(new libraries pulled<br> > > > in with vulns), etc. There's lots of \
reasons a given user might want<br> > > > to stick on 8.6.x rather than 8.7 \
(in the short/medium term).<br> > > ><br>
> > > I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said \
above<br> > > > the worst of the Jetty issue should be mitigated by work on \
our end -<br> > > > but I think there's a lot of reasons users might not \
upgrade as far as<br> > > > we'd expect/like.<br>
> > ><br>
> > ><br>
> > > On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson <<a \
href="mailto:erickerickson@gmail.com" rel="noreferrer" \
target="_blank">erickerickson@gmail.com</a>> wrote:<br> > > ><br>
> > ><br>
> > > 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?<br> > > ><br>
> > > FWIW,<br>
> > > Erick<br>
> > ><br>
> > > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski <<a \
href="mailto:gerlowskija@gmail.com" rel="noreferrer" \
target="_blank">gerlowskija@gmail.com</a>> wrote:<br> > > ><br>
> > > Hey all,<br>
> > ><br>
> > > I wanted to add 2 more blocker tickets to the list: SOLR-14897 and<br>
> > > SOLR-14898. These tickets (while bad bugs in their own right) are<br>
> > > especially necessary because they work around a Jetty buffer-reuse \
bug<br> > > > (see SOLR-14896) that causes sporadic request failures once \
triggered.<br> > > ><br>
> > > So that brings the list of 8.6.3 blockers up to: SOLR-14850,<br>
> > > SOLR-14835, SOLR-14897, and SOLR-14898. (Thanks David for the \
quick<br> > > > work on SOLR-14768!)<br>
> > ><br>
> > > Additionally, should we also consider a Jetty upgrade for 8.6.3 in<br>
> > > light of the issue mentioned above? I know it's atypical for \
bug-fix<br> > > > releases to change deps, but here the bug is serious and \
tied directly<br> > > > to the dep. SOLR-14897 and SOLR-14898 help greatly \
here, but the<br> > > > Jetty bug is likely still a problem for users making \
requests that<br> > > > match a specific (albeit rare) profile. Anyone have \
thoughts?<br> > > ><br>
> > > Best,<br>
> > ><br>
> > > Jason<br>
> > ><br>
> > > On Fri, Sep 25, 2020 at 12:28 AM Houston Putman <<a \
href="mailto:houstonputman@gmail.com" rel="noreferrer" \
target="_blank">houstonputman@gmail.com</a>> wrote:<br> > > ><br>
> > ><br>
> > > If I recall correctly, thats a step in the release wizard.<br>
> > ><br>
> > > After checking, I think this fits the bill:<br>
> > > <a href="https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/releaseWizard.yaml#L1435" \
rel="noreferrer noreferrer" \
target="_blank">https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/releaseWizard.yaml#L1435</a><br>
> > ><br>
> > > - Houston<br>
> > ><br>
> > > On Fri, Sep 25, 2020 at 12:06 AM David Smiley <<a \
href="mailto:dsmiley@apache.org" rel="noreferrer" \
target="_blank">dsmiley@apache.org</a>> wrote:<br> > > ><br>
> > ><br>
> > > 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.<br> > > ><br>
> > > ~ David Smiley<br>
> > > Apache Lucene/Solr Search Developer<br>
> > > <a href="http://www.linkedin.com/in/davidwsmiley" rel="noreferrer \
noreferrer" target="_blank">http://www.linkedin.com/in/davidwsmiley</a><br> > > \
><br> > > ><br>
> > > On Thu, Sep 24, 2020 at 6:22 AM Atri Sharma <<a \
href="mailto:atri@apache.org" rel="noreferrer" \
target="_blank">atri@apache.org</a>> wrote:<br> > > ><br>
> > ><br>
> > > I will push the 8.7 release by a week to give Jason enough headroom \
to<br> > > ><br>
> > ><br>
> > > do the 8.6.3 release.<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Jason, let me know if you need me to assist on the 8.6.3 release.<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > On Thu, Sep 24, 2020 at 3:23 PM Jason Gerlowski <<a \
href="mailto:gerlowskija@gmail.com" rel="noreferrer" \
target="_blank">gerlowskija@gmail.com</a>> wrote:<br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > OK, in that case I'll try my best to keep the 8.6.3 process \
moving<br> > > ><br>
> > ><br>
> > ><br>
> > > then, so Atri can stick as close to his proposed schedule as \
possible.<br> > > ><br>
> > ><br>
> > ><br>
> > > My apologies - I didn't realize I'd be putting the brakes on \
8.7 by<br> > > ><br>
> > ><br>
> > ><br>
> > > proposing a bug-fix release. But the reasons make sense given what<br>
> > ><br>
> > ><br>
> > ><br>
> > > others mentioned above.<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > As branch_8_6 should be pretty stable by now I wonder if we really \
need to wait one week?<br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > There's no special reason on my end. I suggested a week to \
give<br> > > ><br>
> > ><br>
> > ><br>
> > > others time to backport anything they wanted included, but I'm \
happy<br> > > ><br>
> > ><br>
> > ><br>
> > > to start the process as soon as all the expected changes land.<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Best,<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Jason<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > On Thu, Sep 24, 2020 at 1:48 AM Anshum Gupta <<a \
href="mailto:anshum@anshumgupta.net" rel="noreferrer" \
target="_blank">anshum@anshumgupta.net</a>> wrote:<br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > 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.<br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > 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.<br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > On Wed, Sep 23, 2020 at 1:43 PM David Smiley <<a \
href="mailto:dsmiley@apache.org" rel="noreferrer" \
target="_blank">dsmiley@apache.org</a>> wrote:<br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > 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.<br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > ~ David Smiley<br>
> > ><br>
> > ><br>
> > ><br>
> > > Apache Lucene/Solr Search Developer<br>
> > ><br>
> > ><br>
> > ><br>
> > > <a href="http://www.linkedin.com/in/davidwsmiley" rel="noreferrer \
noreferrer" target="_blank">http://www.linkedin.com/in/davidwsmiley</a><br> > > \
><br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > On Wed, Sep 23, 2020 at 10:07 AM Jason Gerlowski <<a \
href="mailto:gerlowskija@gmail.com" rel="noreferrer" \
target="_blank">gerlowskija@gmail.com</a>> wrote:<br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Hi all,<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > I ran into a query-parsing bug recently in SOLR-14859 that caused<br>
> > ><br>
> > ><br>
> > ><br>
> > > problems for some of my usecases. I wanted to volunteer as RM for \
an<br> > > ><br>
> > ><br>
> > ><br>
> > > 8.6.3 to get a bugfix release out for users that aren't ready for \
some<br> > > ><br>
> > ><br>
> > ><br>
> > > of the bigger changes in 8.7<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > I was thinking of cutting the branch in a week's time to give \
others a<br> > > ><br>
> > ><br>
> > ><br>
> > > chance to backport any bug-fixes they might want included, with an \
RC<br> > > ><br>
> > ><br>
> > ><br>
> > > to follow shortly. Does anyone have any concerns with that plan, \
or<br> > > ><br>
> > ><br>
> > ><br>
> > > have anything they'd like to fix or backport before an 8.6.3 goes \
out?<br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Best,<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Jason<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > ---------------------------------------------------------------------<br>
> > ><br>
> > ><br>
> > ><br>
> > > To unsubscribe, e-mail: <a \
href="mailto:dev-unsubscribe@lucene.apache.org" rel="noreferrer" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> > > ><br>
> > ><br>
> > ><br>
> > > For additional commands, e-mail: <a \
href="mailto:dev-help@lucene.apache.org" rel="noreferrer" \
target="_blank">dev-help@lucene.apache.org</a><br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > --<br>
> > ><br>
> > ><br>
> > ><br>
> > > Anshum Gupta<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > ---------------------------------------------------------------------<br>
> > ><br>
> > ><br>
> > ><br>
> > > To unsubscribe, e-mail: <a \
href="mailto:dev-unsubscribe@lucene.apache.org" rel="noreferrer" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> > > ><br>
> > ><br>
> > ><br>
> > > For additional commands, e-mail: <a \
href="mailto:dev-help@lucene.apache.org" rel="noreferrer" \
target="_blank">dev-help@lucene.apache.org</a><br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > --<br>
> > ><br>
> > ><br>
> > > Regards,<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Atri<br>
> > ><br>
> > ><br>
> > > Apache Concerted<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > ---------------------------------------------------------------------<br>
> > ><br>
> > ><br>
> > > To unsubscribe, e-mail: <a \
href="mailto:dev-unsubscribe@lucene.apache.org" rel="noreferrer" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> > > ><br>
> > ><br>
> > > For additional commands, e-mail: <a \
href="mailto:dev-help@lucene.apache.org" rel="noreferrer" \
target="_blank">dev-help@lucene.apache.org</a><br> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > ---------------------------------------------------------------------<br>
> > > To unsubscribe, e-mail: <a \
href="mailto:dev-unsubscribe@lucene.apache.org" rel="noreferrer" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> > > > For \
additional commands, e-mail: <a href="mailto:dev-help@lucene.apache.org" \
rel="noreferrer" target="_blank">dev-help@lucene.apache.org</a><br> > > \
><br> > > ><br>
> > ><br>
> > > ---------------------------------------------------------------------<br>
> > > To unsubscribe, e-mail: <a \
href="mailto:dev-unsubscribe@lucene.apache.org" rel="noreferrer" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> > > > For \
additional commands, e-mail: <a href="mailto:dev-help@lucene.apache.org" \
rel="noreferrer" target="_blank">dev-help@lucene.apache.org</a><br> > > \
><br> > > ><br>
> > > ---------------------------------------------------------------------<br>
> > > To unsubscribe, e-mail: <a \
href="mailto:dev-unsubscribe@lucene.apache.org" rel="noreferrer" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> > > > For \
additional commands, e-mail: <a href="mailto:dev-help@lucene.apache.org" \
rel="noreferrer" target="_blank">dev-help@lucene.apache.org</a><br> > > \
><br> > > ><br>
> > > ---------------------------------------------------------------------<br>
> > > To unsubscribe, e-mail: <a \
href="mailto:dev-unsubscribe@lucene.apache.org" rel="noreferrer" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> > > > For \
additional commands, e-mail: <a href="mailto:dev-help@lucene.apache.org" \
rel="noreferrer" target="_blank">dev-help@lucene.apache.org</a><br> > > \
><br> > > ><br>
> > ><br>
> > > --<br>
> > > Regards,<br>
> > ><br>
> > > Atri<br>
> > > Apache Concerted<br>
> > ><br>
> > > ---------------------------------------------------------------------<br>
> > > To unsubscribe, e-mail: <a \
href="mailto:dev-unsubscribe@lucene.apache.org" rel="noreferrer" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> > > > For \
additional commands, e-mail: <a href="mailto:dev-help@lucene.apache.org" \
rel="noreferrer" target="_blank">dev-help@lucene.apache.org</a><br> > > \
><br> > ><br>
> ><br>
> > --<br>
> > Regards,<br>
> ><br>
> > Atri<br>
> > Apache Concerted<br>
> ><br>
> > ---------------------------------------------------------------------<br>
> > To unsubscribe, e-mail: <a href="mailto:dev-unsubscribe@lucene.apache.org" \
rel="noreferrer" target="_blank">dev-unsubscribe@lucene.apache.org</a><br> > > \
For additional commands, e-mail: <a href="mailto:dev-help@lucene.apache.org" \
rel="noreferrer" target="_blank">dev-help@lucene.apache.org</a><br> > ><br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe, e-mail: <a href="mailto:dev-unsubscribe@lucene.apache.org" \
rel="noreferrer" target="_blank">dev-unsubscribe@lucene.apache.org</a><br> For \
additional commands, e-mail: <a href="mailto:dev-help@lucene.apache.org" \
rel="noreferrer" target="_blank">dev-help@lucene.apache.org</a><br> <br>
</blockquote></div>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic