I have some mixed feelings because on one side I can understand the will to simplify our life but on the other hand I find it a bit selfish to ignore the other Jamm users.
Le jeu. 8 janv. 2026 à 19:28, Josh McKenzie <[email protected]> a écrit : > We can expect jamm changes to be mostly about supporting new JDK's given > the trajectory of the past half decade or so. Given our intent to allow > running on the latest LTS JDK across all GA branches, that means we can > expect to need to backport jamm changes to all branches to support a new > JDK. > > To Aleksey's point, however, this is something we're used to. And with > jamm the scale of the changes should be modest and the frequency of these > changes low. > > I think having the code in-tree per-branch gives us an optimal balance of > ease-of-use with our build ecosystem that we use daily at the expense of > slightly more toil on modifying jamm very infrequently. > > On Thu, Jan 8, 2026, at 11:23 AM, Aleksey Yeshchenko wrote: > > Sure, but that is true about absolute majority of C* codebase. Most of our > utility classes are the same in most branches, without changing that much. > It’s not a reason enough to pull everything into a submodule. > > At the end of the day I would rather deal with plain old C* repo branches, > then the combination of jamm repo branches, plus a submodule, plus pointers > to different jamm branches in C* branches. > > Forward merging and backward-porting code is something we are pretty good > at. > > On 7 Jan 2026, at 20:16, Doug Rohrer <[email protected]> wrote: > > The last part here is a really good point. Given it'll be something that > we need in multiple branches, using a submodule may well be the better > option. > > Copy/paste of changes across several Cassandra branches is, as we all > know, pretty painful. > > Doug > > On Jan 7, 2026, at 7:38 AM, Mick <[email protected]> wrote: > > > > On 6 Jan 2026, at 18:12, Josh McKenzie <[email protected]> wrote: > > While your solution is the easiest one, undeniably, of course, it > seems to disregard the existing user base. Some of them are other > Apache projects too. I think that we are beyond this and we want to > have it re-usable by other projects too. > > > Right now we're a pure consumer of the lib. If we brought it in-tree and > published artifacts from our source, we'd be becoming maintainers of the > lib which is a Big Change. > > I don't think we're ready to sign up for that tbh and I'm weakly against > it. > > So that leaves a) copying code in-tree, or b) submodule. > > > > > Right, if we're not taking over jamm then we're not needing to maintain it > as a separate code repo. (I didn't realise this was the intention either.) > > Aside from that, a git submodule does have a benefit due to how we can > change the branch of it we use and how we need to do that we it comes time > to back-porting jdk support to earlier versions. I don't have an opinion > here, it's just another point of consideration. > > >
