Lucene or jetty, or anything else that touches the jakarta vs javax package switch mess.... any of those should be Jiras I think.
On the Jakarta/Javax topic: This is a MAJOR pain for one org I know, because they have solr code in their repo, and use our test framework, including the mini-cluster so, they can't move to anything with jakarta packages... and since they use dropwizard and hibernate validator among other things, that's a big deal. We need to get onto jakarta packages by 10.x (the tickets for jetty 11/12 will probably force this). -Gus On Thu, Oct 17, 2024 at 5:55 PM David Smiley <dsmi...@apache.org> wrote: > Indeed, please no JIRAs for these unless it's a bigger non-trivial upgrade > for some reason. Like for Lucene. > > On Thu, Oct 17, 2024 at 5:46 PM Jan Høydahl <jan....@cominvent.com> wrote: > > > I'm happy to just track the progress in each PR without additional JIRAs > > for each dependency. Perhaps an umbrella JIRA can be helpful though. > Also, > > no need for CHANGES entries for these, they get added to CHANGES during > > next release by a script, as long as SolrBot is the committer. You can > add > > yourself as "Co-authored-by: ". > > > > Some major-version-upgrades of dependencies require some more work or may > > be blocked by us lagging in Jetty version of other dependencies. Then we > > can convert the PR to draft with a comment. > > > > But feel free to arrange it however you wish. Appreciate any help. It is > > also a nice way to get aquainted with focused parts of the code and the > > build systme. > > > > Jan > > > > > 17. okt. 2024 kl. 16:07 skrev Christos Malliaridis < > > c.malliari...@gmail.com>: > > > > > > The main blocker based on the PR comments seems to be the JDK version > in > > > Solr that is too low to upgrade some of the dependencies. If Solr will > > use > > > JDK 21 in v10.0, it shouldn't be a problem updating these dependencies > > > before v10. > > > > > > I could create a JIRA ticket with subtasks for each dependency update + > > PR > > > that is available, so that we track the progress and document whether > > they > > > can and should be backported or not. Would that be helpful to get > things > > > started? > > > > > > Best, > > > Christos > > > > > > On Wed, Oct 16, 2024 at 12:06 PM Jan Høydahl <jan....@cominvent.com> > > wrote: > > > > > >> Hi, > > >> > > >> There are now 36 open SolrBot PRs, some of which are several months > old: > > >> > > >> https://github.com/apache/solr/pulls/solrbot > > >> > > >> Let's do a round of dependency upgrade merging to main + 9x prior to a > > 9.8 > > >> release. > > >> > > >> Not a committer? You can still help e.g. by triaging the PRs that > failed > > >> tests and making a comment in the PR on what you believe is the next > > >> action. Sometimes a rebase is required, and there's a checkbox in the > > >> description that can be checked to trigger a rebase on the next > solrbot > > run > > >> (every 4 hours). Sometimes tests fail unrelated to the upgrade, then > > that > > >> one test can be re-run to get to a green state. Sometimes new > transitive > > >> libraries are added by an upgrade, consider whether they are needed > (and > > >> must be added to licenses/ folder), or if they can be excluded. > > >> > > >> Here are some useful pointers: > > >> * > > >> > > > https://github.com/apache/solr/blob/main/dev-docs/dependency-upgrades.adoc > > >> * > > https://github.com/apache/solr/blob/main/dev-tools/scripts/cherrypick.sh > > >> can be useful for backporting (always run precommit before pushing > > though) > > >> > > >> Jan > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
