Hi,
there is no code for the build job, it is just a plain stupid Jenkins
job executing the follwoing command (see log output of last build):
[solr] $ /home/jenkins/tools/ant/apache-ant-1.8.4/bin/ant -file build.xml
-Dlucene.javadoc.url=https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-8.x/javadoc/
-Dsolr.javadoc.url=https://ci-builds.apache.org/job/Solr/job/Solr-Artifacts-8.11/javadoc/
-Dversion.suffix=15 prepare-release-no-sign
Most of the parameters are not needed, just do: "ant
prepare-release-no-sign" and the collect the artifacts from the solr
build dir.
Uwe
Am 19.01.2023 um 09:57 schrieb Tomasz Elendt:
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
backportinghttps://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
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:u...@thetaphi.de
