I guess some convention due to MoinMoin? On Thu, 22 Oct, 2020, 7:25 pm Jason Gerlowski, <[email protected]> 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 <[email protected]> > 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 <[email protected]> wrote: > > > > > > Fair point -- I have changed accordingly. > > > > > > On Thu, Oct 22, 2020 at 7:09 PM Cassandra Targett < > [email protected]> 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 <[email protected]>, > 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 <[email protected]> > 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 < > [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] > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > > > > > Atri > > > > Apache Concerted > > > > > > > > --------------------------------------------------------------------- > > > > 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] > >
