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