On Mon, Jan 10, 2022 at 12:57 AM Jan Høydahl <[email protected]> wrote: > > Hi, > > This is quite simple. > - The 9.0 release is on-going - now on branch_9_0 > - The normal feature feeze rules apply. Anything explicitly approved as > blocker gets in > > We can still consider adding features to the branch if the benfit/risk ratio > is high enough. Having a long stabilization period also helps. But please ask > before merging. > > The discussion whether we have "enough features" is i.m.o. silly, that's not > how it works, we release as often as possible, and major versions annually. > But this time around we wanted to wait for Lucene 9 which was also delayed. > Now, after almost 2 years on 8.x we have Java11, Lucene 9, gradle build, > embedded Docker image and tons of litle improvements for devs as well as > users. 8x is in bugfix mode so no new feature releases there. We are > currenlty blocked from getting ANY new feature into our users hands. > > Wrt node roles, it was not ok to knowingly sabotage the feature freeze, but > I'm not going to revert your commit. I'll put the incident on the > branch-confusion account. The feature appears to be backward compat and high > benefit, but it touches lots of core code paths, so I'd say there is a > medium/high risk of introducing new bugs. If you do not intend to revert, > please follow test failures and other feedback wrt that feature closely. I'd > also wish the Admin UI would show roles in some way. You can see the > properties in dashboard, but can you see the resolved roles for nodes > explicitly anywhere? I'm also surprised not to find an explicit NODE_ROLES > variable in solr.in.sh for a prominent feature like this - it would be so > much easier for e.g. solr-operator to configure roles for a node if it was > contained in a single env-var. > > Wrt vector search, it may go in if it is ready soon-ish, guess the code is > isolated enough to be low-risk, it can also be called out as experimental. > But i'm not willing to delay the release another month or more (March-April?) > just to wait for yet another feature.
I agree with you Jan. If it's a few days away, we should accommodate it. Definitely not a month. > > I'm excited to get 9.0 into the hands of users. Let's make this happen! > > Jan > > > 9. jan. 2022 kl. 08:16 skrev Ishan Chattopadhyaya <[email protected]>: > > > Ishan: What warrants a release is subjective, but noone can accuse the Solr > > project of RUSHING with the 9.0 release. Have a look at the Major Changes > > in Solr 9 page if you need a reminder of what we have been keeping from our > > users (and developers not the least) for too long. > > Apache Solr is a search engine. In that list, except for the UI page for SQL, > I don't see a new *search* related feature. A major release without any > compelling feature will keep users from upgrading. I don't understand the > hurry now when the vector search support is just around the corner. Why can't > we make an exception for that particular feature and include it in the > release, if it gets ready before the release? > > On Sun, Jan 9, 2022 at 11:35 AM Ishan Chattopadhyaya > <[email protected]> wrote: >> >> > Ishan, that also means that you only need to revert SOLR-15694 on >> > branch_9_0 >> >> In Apache Solr, committers don't tell other committers to revert commits >> without a proper technical justification. You were late in cutting the >> release branch for 9.0, and now "need" me to revert my commit because you're >> not comfortable with the commit making it to the release? >> >> This is very demoralizing. When contributors work for months on a feature, >> they hope to see a released version of Solr with that feature. In the case >> of SOLR-15694, we took several extra steps to ensure broader community >> participation. If you still demand of me to revert the commit, I'll comply >> since I don't want to hold up this release. In that case, I'll backport to a >> 8.12 release so that users can use the feature sooner than waiting another >> 2-3 months for a 9.1 release. >> >> On Sun, Jan 9, 2022 at 11:05 AM Noble Paul <[email protected]> wrote: >>> >>> The New feature list for 9.0 is >>> >>> * Replica placement plugins >>> * Rate limiting and task management >>> * Certificate Auth Plugin >>> * SQL Query interface in UI >>> >>> None of these are compelling search features which will motivate >>> anyone to upgrade OTOH , vector search is a very attractive feature >>> and even if it we release that as "experimental" users are likely to >>> upgrade >>> >>> So, please consider including that >>> >>> >>> On Sun, Jan 9, 2022 at 11:35 AM Jan Høydahl <[email protected]> wrote: >>> > >>> > IMPORTANT >>> > >>> > Just created branch_9_0 off of branch_9x, and bumped version on branch_9x >>> > to 9.1. >>> > >>> > This means that everything is back to normal branch structure, and the >>> > feature freeze is now only on branch_9_0. >>> > >>> > Ishan, that also means that you only need to revert SOLR-15694 on >>> > branch_9_0, and let it remain on branch_9x, while you let it bake. >>> > >>> > I also added these Jenkins jobs: >>> > - Solr-Artifacts-9x >>> > - Solr-Check-9.x >>> > - Solr-reference-guide-9.x >>> > - Solr-Artifacts-9.0 >>> > - Solr-Check-9.0 >>> > - Solr-reference-guide-9.0 >>> > >>> > Jan >>> > >>> > 9. jan. 2022 kl. 01:04 skrev Jan Høydahl <[email protected]>: >>> > >>> > Hi, >>> > >>> > This is indeed a deliberate deviation from established branch process, as >>> > debated and decided in the "Solr 9.0.0 release in February" thread >>> > https://lists.apache.org/thread/pzqvmcxcjhkrj2xb31sj3pwzrn6x9vd3 and >>> > repeated on this very thread, so this is far from some SNEAKY attempt to >>> > trick you all :) However, the intent of minimizing number of backports in >>> > a period where the project is in 9.0 release focus (there will be tons of >>> > commits) seemd brilliant just a week ago, but I can see that we also need >>> > a place to land 9.1 features now and not wait until February. >>> > >>> > As several committers are in support of freeing branch_9x for feature >>> > development for 9.1, I'll go ahead and create the branch_9_0 branch now. >>> > >>> > Ishan: What warrants a release is subjective, but noone can accuse the >>> > Solr project of RUSHING with the 9.0 release. Have a look at the Major >>> > Changes in Solr 9 page if you need a reminder of what we have been >>> > keeping from our users (and developers not the least) for too long. >>> > Someone will always have a "killer feature" around the corner. Fine, then >>> > 9.1 will also get a nice killer feature. Or 9.2. More champagne! But lack >>> > of a brand new feature is never a blocker for any release. >>> > >>> > Jan >>> > >>> > 8. jan. 2022 kl. 02:45 skrev Ishan Chattopadhyaya >>> > <[email protected]>: >>> > >>> > > branch_9x is in feature freeze! We want to stabilize >>> > >>> > Feature freeze is meant for the release branches. There is no precedent >>> > for having a feature freeze on the stable branch. I urge you to follow >>> > well established processes and not invent new processes on the fly and >>> > hold the project hostage to those new processes. If you have concerns >>> > about the stability of the commit, we can consider reverting from the >>> > stable branch. >>> > >>> > On Sat, Jan 8, 2022 at 7:11 AM Ishan Chattopadhyaya >>> > <[email protected]> wrote: >>> >> >>> >> > What do we think about a "beta" release, to give users (including >>> >> > *ourselves* in many cases) more time to try out 9.0 to report issues? >>> >> +1 >>> >> >>> >> > It would be a shame to release Solr 9 without support for the vector >>> >> > based index in Lucene 9. Thankfully there's a JIRA issue with a PR! >>> >> > https://issues.apache.org/jira/browse/SOLR-15880 . It's as much about >>> >> > optics as anything. I think many users are probably more at a >>> >> > curiosity / exploratory stage with this topic but still -- Solr 9 >>> >> > without the ability to explore this is disappointing, leaving them to >>> >> > consider other options to scratch that itch. >>> >> >>> >> Fully agree with the sentiment here, David. Without the vector search >>> >> feature, I see no other important enough feature in a 9.0 release to >>> >> capture users' excitement. Commentators are already writing off Solr as >>> >> legacy search [0], and such a milestone release should address some of >>> >> the areas in which we're falling behind. >>> >> >>> >> If that feature is just a few weeks out, what is the need for this >>> >> artificial rush to get 9.0 out now? >>> >> >>> >> [0] - https://twitter.com/jobergum/status/1476657317768749062 >>> >> >>> >> >>> >> On Sat, Jan 8, 2022 at 5:15 AM Jan Høydahl <[email protected]> wrote: >>> >>> >>> >>> branch_9x is in feature freeze! We want to stabilize, fix bugs and >>> >>> remove blockers on that branch, not add features - unless they are >>> >>> agreed as a blocker for the release. >>> >>> If everyone starts pushing all kinds of new features to 9x now, it will >>> >>> never stabilize. >>> >>> >>> >>>>>>>> >>> Q: But my feature is almost ready and low-risk, I can surely >>> >>>>>>>> >>> put it on branch_9x ? >>> >>>>>>>> >>> A: No, only blockers and bugfixes please. You can argue on >>> >>>>>>>> >>> dev@ that your feature is a blocker >>> >>> >>> >>> >>> >>> I think it all looks a bit messy and rushed. SOLR-15694 is open, PR is >>> >>> open, with no approvals from any of the reviwers? >>> >>> >>> >>> Please revert on branch_9x and then "argue on dev@ that your feature is >>> >>> a blocker". >>> >>> >>> >>> Jan >>> >>> >>> >>> 7. jan. 2022 kl. 20:09 skrev Ishan Chattopadhyaya >>> >>> <[email protected]>: >>> >>> >>> >>> Since a 9.0 release branch has not been cut, I backported the >>> >>> SOLR-15694 to branch_9x. If there are any concerns, we can discuss >>> >>> reverting it from branch_9_0 later. >>> >>> Thanks and regards. >>> >>> >>> >>> On Fri, Jan 7, 2022 at 10:34 PM Ishan Chattopadhyaya >>> >>> <[email protected]> wrote: >>> >>>> >>> >>>> > let it bake in main (10.0) for some time, letting more devs try it >>> >>>> > out >>> >>>> >>> >>>> Please define "some time". Is 3 weeks until the 9.0 release not enough? >>> >>>> >>> >>>> On Fri, Jan 7, 2022 at 10:26 PM Jan Høydahl <[email protected]> >>> >>>> wrote: >>> >>>>> >>> >>>>> I think it is premature to add it to branch_9x yet. First get +1 from >>> >>>>> key stakeholders on the PR, then let it bake in main (10.0) for some >>> >>>>> time, letting more devs try it out. If all looks good at that point, >>> >>>>> we may consider it, especially if the default behaviour is === 8.x. >>> >>>>> >>> >>>>> What do others think? >>> >>>>> >>> >>>>> Jan >>> >>>>> >>> >>>>> 7. jan. 2022 kl. 11:26 skrev Ishan Chattopadhyaya >>> >>>>> <[email protected]>: >>> >>>>> >>> >>>>> > Btw - does Solr have any benchmarks published yet, that we can >>> >>>>> > compare 8.11 with 9.0? Would be very useful. >>> >>>>> >>> >>>>> I can work on it over the weekend. I have some suites ready with me, >>> >>>>> but not automated yet. >>> >>>>> >>> >>>>> > Today: Cut branch_9x and enter feature freeze on that branch >>> >>>>> >>> >>>>> I'd like to include SOLR-15694 (node roles) in 9.0, if that's okay >>> >>>>> with you. It is dev complete, we're just running the tests to make >>> >>>>> sure the failing tests are not due to our changes (and unrelated); we >>> >>>>> can commit it over the weekend. >>> >>>>> >>> >>>>> On Fri, Jan 7, 2022 at 3:13 AM Jan Høydahl <[email protected]> >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> I don't think we are allowed by Apache policy to broadly announce >>> >>>>>> non-official releases like nightlies. >>> >>>>>> >>> >>>>>> There should be more than enough in 9.0 to warrant a major release. >>> >>>>>> Most users will be reluctant to jump on a X.0.0 release, so we can >>> >>>>>> mature a lot in 9.0.x. >>> >>>>>> >>> >>>>>> Perhaps if we start authoring the Release Notes (any volunteers?), >>> >>>>>> we'll see more clearly what we are about to relase. >>> >>>>>> And if we can have new sexy features in 9.1 and 9.2 that even >>> >>>>>> warrants blog posts and twitter bragging, even better :) >>> >>>>>> >>> >>>>>> Let's keep this release train rolling and force ourselves into >>> >>>>>> getting this out there sooner rather than later. We're not releasing >>> >>>>>> the reference-branch or anything, so I think a beta is not >>> >>>>>> necessary, unless the release phase ends up in endless RCs due to >>> >>>>>> tons of bugs and regressions. >>> >>>>>> >>> >>>>>> Btw - does Solr have any benchmarks published yet, that we can >>> >>>>>> compare 8.11 with 9.0? Would be very useful. >>> >>>>>> >>> >>>>>> Jan >>> >>>>>> >>> >>>>>> 6. jan. 2022 kl. 22:24 skrev David Smiley <[email protected]>: >>> >>>>>> >>> >>>>>> What do we think about a "beta" release, to give users (including >>> >>>>>> *ourselves* in many cases) more time to try out 9.0 to report >>> >>>>>> issues? I don't think a beta release would necessitate a typical >>> >>>>>> feature freeze. If we ultimately decline on a beta release, a >>> >>>>>> counter-proposal would be to promote our nightly docker images >>> >>>>>> everywhere (solr-users list, twitter, Slack) to solicit feedback. >>> >>>>>> >>> >>>>>> It would be a shame to release Solr 9 without support for the vector >>> >>>>>> based index in Lucene 9. Thankfully there's a JIRA issue with a PR! >>> >>>>>> https://issues.apache.org/jira/browse/SOLR-15880 . It's as much >>> >>>>>> about optics as anything. I think many users are probably more at a >>> >>>>>> curiosity / exploratory stage with this topic but still -- Solr 9 >>> >>>>>> without the ability to explore this is disappointing, leaving them >>> >>>>>> to consider other options to scratch that itch. >>> >>>>>> >>> >>>>>> ~ David Smiley >>> >>>>>> Apache Lucene/Solr Search Developer >>> >>>>>> http://www.linkedin.com/in/davidwsmiley >>> >>>>>> >>> >>>>>> >>> >>>>>> On Thu, Jan 6, 2022 at 2:11 PM Timothy Potter <[email protected]> >>> >>>>>> wrote: >>> >>>>>>> >>> >>>>>>> thanks Jan, PR looks good now! 😀 >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> On Thu, Jan 6, 2022 at 11:52 AM Jan Høydahl <[email protected]> >>> >>>>>>> wrote: >>> >>>>>>>> >>> >>>>>>>> False alarm, I had a dirty checkout. >>> >>>>>>>> Please see if your PR passes precommit. >>> >>>>>>>> >>> >>>>>>>> Jan >>> >>>>>>>> >>> >>>>>>>> > 6. jan. 2022 kl. 19:49 skrev Jan Høydahl <[email protected]>: >>> >>>>>>>> > >>> >>>>>>>> > Tim, I pushed a change to gradle that now uses hardcoded 9.0.0 >>> >>>>>>>> > for tests.luceneMatchVersion. That's a stop-gap, will make it >>> >>>>>>>> > dynamically follow the current lucene-version, but somehow my >>> >>>>>>>> > gradle project picked up an old version of >>> >>>>>>>> > org.apache.lucene.utils.Version class... >>> >>>>>>>> > >>> >>>>>>>> > Now I get a new error >>> >>>>>>>> > >>> >>>>>>>> > * What went wrong: >>> >>>>>>>> > Execution failed for task ':validateSourcePatterns'. >>> >>>>>>>> >> Found 10 violations in source files (@author javadoc tag, svn >>> >>>>>>>> >> keyword, tabs instead spaces). >>> >>>>>>>> > >>> >>>>>>>> > Jan >>> >>>>>>>> > >>> >>>>>>>> >> 6. jan. 2022 kl. 17:53 skrev Timothy Potter >>> >>>>>>>> >> <[email protected]>: >>> >>>>>>>> >> >>> >>>>>>>> >> Thanks for the update Jan! >>> >>>>>>>> >> >>> >>>>>>>> >> One of my PRs (sync'd with main) is now failing precommit with: >>> >>>>>>>> >> >>> >>>>>>>> >> 105 actionable tasks: 103 executed, 2 up-to-date >>> >>>>>>>> >> 201FAILURE: Build failed with an exception. >>> >>>>>>>> >> 202 >>> >>>>>>>> >> 203* Where: >>> >>>>>>>> >> 204Script >>> >>>>>>>> >> '/home/runner/work/solr/solr/gradle/validation/solr.config-file-sanity.gradle' >>> >>>>>>>> >> line: 40 >>> >>>>>>>> >> 205 >>> >>>>>>>> >> 206* What went wrong: >>> >>>>>>>> >> 207Execution failed for task ':solr:validateConfigFileSanity'. >>> >>>>>>>> >> 208> Configset does not refer to the correct luceneMatchVersion >>> >>>>>>>> >> (10.0.0): >>> >>>>>>>> >> /home/runner/work/solr/solr/solr/server/solr/configsets/_default/conf/solrconfig.xml >>> >>>>>>>> >> 209 >>> >>>>>>>> >> >>> >>>>>>>> >> Any ideas what's wrong there? >>> >>>>>>>> >> >>> >>>>>>>> >> On Thu, Jan 6, 2022 at 9:40 AM Jan Høydahl >>> >>>>>>>> >> <[email protected]> wrote: >>> >>>>>>>> >>> >>> >>>>>>>> >>> NOTICE: >>> >>>>>>>> >>> >>> >>>>>>>> >>> Branch branch_9_x has been cut and versions updated to 10.0 on >>> >>>>>>>> >>> 'main' branch. >>> >>>>>>>> >>> >>> >>>>>>>> >>> This follows the plan from previous notice about 9.0 release >>> >>>>>>>> >>> [1]. Here is what will happen: >>> >>>>>>>> >>> >>> >>>>>>>> >>> Today: Cut branch_9x and enter feature freeze on that branch >>> >>>>>>>> >>> Next few weeks: Remove blockers, prepare build & release >>> >>>>>>>> >>> machinery >>> >>>>>>>> >>> February: Cut branch_9_0 and build RC1 >>> >>>>>>>> >>> >>> >>>>>>>> >>> This is how we'll use the branches until we cut the branch_9_0 >>> >>>>>>>> >>> release-branch: >>> >>>>>>>> >>> >>> >>>>>>>> >>> main: All new features and bug fixes (as today) >>> >>>>>>>> >>> branch_9x: Only backport of bugfixes and blockers for the 9.0 >>> >>>>>>>> >>> release. >>> >>>>>>>> >>> >>> >>>>>>>> >>> >>> >>>>>>>> >>> FAQ: >>> >>>>>>>> >>> ------ >>> >>>>>>>> >>> Q: Where do I put a feature intended for 9.1? >>> >>>>>>>> >>> A: On main branch. Then in February, bulk backport to branch_9x >>> >>>>>>>> >>> >>> >>>>>>>> >>> Q: Can we go to Java17 on main branch now? >>> >>>>>>>> >>> A: Not yet, let's keep main branch as-is until branch_9_0 is >>> >>>>>>>> >>> cut, to easen backporting >>> >>>>>>>> >>> >>> >>>>>>>> >>> Q: But my feature is almost ready and low-risk, I can surely >>> >>>>>>>> >>> put it on branch_9x ? >>> >>>>>>>> >>> A: No, only blockers and bugfixes please. You can argue on >>> >>>>>>>> >>> dev@ that your feature is a blocker >>> >>>>>>>> >>> >>> >>>>>>>> >>> Q: How can I help with the 9.0 release? >>> >>>>>>>> >>> A: You can check out the JIRA for blockers [2] and help fix >>> >>>>>>>> >>> those >>> >>>>>>>> >>> >>> >>>>>>>> >>> Q: Why do we need to wait until February with cutting the >>> >>>>>>>> >>> release branch? >>> >>>>>>>> >>> A: We don't - if blockers are resolved and we feel close to >>> >>>>>>>> >>> RC1 before then... >>> >>>>>>>> >>> >>> >>>>>>>> >>> >>> >>>>>>>> >>> [1] >>> >>>>>>>> >>> https://lists.apache.org/thread/qv9n2b7jkmzr26ov5p50lc3h2dy7htzo >>> >>>>>>>> >>> [2] https://issues.apache.org/jira/issues/?filter=12351219 >>> >>>>>>>> >> >>> >>>>>>>> >> --------------------------------------------------------------------- >>> >>>>>>>> >> 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] >>> >>>>>>>> >>> >>>>>> >>> >>>>> >>> >>> >>> > >>> > >>> >>> >>> -- >>> ----------------------------------------------------- >>> Noble Paul >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> > -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
