Thank you for explanation and for backporting this change :) > On 18. Jan 2023, at 18:15, Kevin Risden <[email protected]> wrote: > > Since I backported a bunch of stuff - there are only a handful of changes > on branch_8_11 for 8.11.3 > https://github.com/apache/lucene-solr/blob/branch_8_11/solr/CHANGES.txt: > > Some general notes: > * If it is a dependency upgrade - those are the hardest between > main/branch_9x and branch_8_11 - the build tool changed and is completely > different to how dependencies get upgraded. > * Most simple bug fixes are relatively easy to backport - the biggest > difference here is formatting changes since main/branch_9x has spotless > formatting > * Make sure not to break backwards compatibility or introduce issues on > branch_8_11 since 8.11.3 would just be a bug fix release. > * There is no guarantee that 8.11.3 will ever be released > > There are a bunch of old PRs - https://github.com/apache/lucene-solr/pulls > - that most likely never go migrated to https://github.com/apache/solr > > Regarding https://issues.apache.org/jira/browse/SOLR-13219 - seems like > something reasonable to backport and relatively self contained. > > Kevin Risden > > > On Wed, Jan 18, 2023 at 12:00 PM Shawn Heisey <[email protected]> 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/[email protected]/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: [email protected] >> For additional commands, e-mail: [email protected] >> >>
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
