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 < [email protected]> wrote: > 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] >> >>
