That's understandable. Thank you. I guess I would need to build it myself anyway (the other alternative is to wait for some critical vulnerability fix that would trigger a new release I guess). I would gladly grab a -SNAPSHOT build/nightly release but you don't seem to provide those for 8.x, right?
That job seems to be disabled: https://ci-builds.apache.org/job/Solr/job/Solr-Artifacts-8.11/ That's not a big deal, I can build it myself. Do you happen to have CI job code open-source? I did some searching but I couldn't find it. Best, Tomasz > On 18. Jan 2023, at 17:59, Shawn Heisey <apa...@elyograg.org> wrote: > > On 1/18/23 09:25, Tomasz Elendt wrote: >> I have a question about backporting fixes to 8.11. As I understand there are >> no new features being developed for 8.x but certain bug fixes are being >> backported. At least I see a bunch of them done by Kevin Risden ([1]). My >> question is: how does it work? How are the changes selected and applied? The >> technical aspect is also interesting as Solr 8.x has a different project >> structure. Are these changes applied manually? >> Would you folks agree on backporting >> https://issues.apache.org/jira/browse/SOLR-13219 there? If it needs to be >> done manually I can do it (I can prepare a new GitHub MR). >> The reason I'm interested in backporting it to 8.x is that we have an issue >> with upgrading to Solr 9 (descried by my colleague in this thread [2]) and >> we would like to avoid maintaining custom fork of 8.x ourselves. >> [1] like this one: https://github.com/apache/lucene-solr/pull/2670 >> [2] https://www.mail-archive.com/users@solr.apache.org/msg04714.html > > The bar is pretty high for backporting a fix to a branch in maintenance mode, > which is where 8.x is. > > Normally it only happens in these instances: > > 1) It fixes a vulnerability that has no workaround. > 2) The change is VERY trivial, so not likely to cause new problems, but has > big benefits for most users. > > The bar is slightly higher for triggering an actual new release on the > branch. Even if someone thinks the change is minor enough for backporting, I > don't think it is enough to trigger a new release. > > Without a new release, you're building Solr from source either way. If it > were me, I would maintain my own patched git repo and not expect that > upstream will include it. And I would keep a copy of the minimal patch > necessary so I could always create the patched repo from scratch. > > The problems you're having with 9.x are very strange. Would you be able to > get a thread dump from a problem server while trying a reload that times out? > Maybe we can figure out what's holding it up. Is it happening on all cores > for the collection or a subset that might consist only of one core? > > Thanks, > Shawn > > --------------------------------------------------------------------- > 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
