I'm also confused slightly on the branch strategy here. main got converted to 10.x that's fine... but I would think ALL 9.x branches should descend from branch_9x, including 9.0... why wouldn't we have made branch_9x and branch_9_0 immediately? Where was noble supposed to check in for a feature that wasn't meant for 10.x?
On Fri, Jan 7, 2022 at 8:45 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > > 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 < > ichattopadhy...@gmail.com> 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 <jan....@cominvent.com> 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 >>> <https://issues.apache.org/jira/browse/SOLR-15694> is open, PR >>> <https://github.com/apache/solr/pull/403> 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 < >>> ichattopadhy...@gmail.com>: >>> >>> 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 < >>> ichattopadhy...@gmail.com> 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 <jan....@cominvent.com> >>>> 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 < >>>>> ichattopadhy...@gmail.com>: >>>>> >>>>> > 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 <jan....@cominvent.com> >>>>> 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 <dsmi...@apache.org>: >>>>>> >>>>>> 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 <thelabd...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> thanks Jan, PR looks good now! 😀 >>>>>>> >>>>>>> >>>>>>> On Thu, Jan 6, 2022 at 11:52 AM Jan Høydahl <jan....@cominvent.com> >>>>>>> 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 <jan....@cominvent.com>: >>>>>>>> > >>>>>>>> > 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 < >>>>>>>> thelabd...@gmail.com>: >>>>>>>> >> >>>>>>>> >> 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 < >>>>>>>> jan....@cominvent.com> 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: dev-unsubscr...@solr.apache.org >>>>>>>> >> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>>>> >> >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>>>> >>>>>>>> >>>>>> >>>>> >>> -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
