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
