You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Tomasz Elendt <to...@gmail.com> on 2023/01/18 16:25:55 UTC
Backporting changes to 8.11 and 8.11.3 release
Hey,
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Backporting changes to 8.11 and 8.11.3 release
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
+1 to any and all changes to be back ported. Please feel free to open PRs
where backporting isn't straight forward.
On Wed, 18 Jan, 2023, 9:56 pm Tomasz Elendt, <to...@gmail.com>
wrote:
> Hey,
>
> 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Backporting changes to 8.11 and 8.11.3 release
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
I tried building 8.11.x recently via solr-bench and found that restlet
dependency wasn't available. In case that was not a temporary thing and you
run into that issue, please open a JIRA issue about it.
On Thu, 19 Jan, 2023, 2:29 pm Tomasz Elendt, <to...@gmail.com>
wrote:
> Thank you for explanation and for backporting this change :)
>
> > On 18. Jan 2023, at 18:15, Kevin Risden <kr...@apache.org> 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 <ap...@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-unsubscribe@solr.apache.org
> >> For additional commands, e-mail: dev-help@solr.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Backporting changes to 8.11 and 8.11.3 release
Posted by Tomasz Elendt <to...@gmail.com>.
Thank you for explanation and for backporting this change :)
> On 18. Jan 2023, at 18:15, Kevin Risden <kr...@apache.org> 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 <ap...@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-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Backporting changes to 8.11 and 8.11.3 release
Posted by Kevin Risden <kr...@apache.org>.
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 <ap...@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-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Backporting changes to 8.11 and 8.11.3 release
Posted by Uwe Schindler <uw...@thetaphi.de>.
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<ap...@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-unsubscribe@solr.apache.org
>> For additional commands, e-mail:dev-help@solr.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:dev-unsubscribe@solr.apache.org
> For additional commands, e-mail:dev-help@solr.apache.org
>
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:uwe@thetaphi.de
Re: Backporting changes to 8.11 and 8.11.3 release
Posted by Tomasz Elendt <to...@gmail.com>.
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 <ap...@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-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Backporting changes to 8.11 and 8.11.3 release
Posted by Shawn Heisey <ap...@elyograg.org>.
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-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org