Necro-thread powers activate! Since I'm on the topic (cassandra-ecosystem thread, CEP to draft on that front) I figured I'd poke my head back in to this thread. I think we have a general consensus here (i.e. supermajority, not unanimous, but no binding -1's) on bringing this in-tree and locking / deprecating the other jamm repo.
To put a bow on it - does this track? Anyone had a change of heart since we last talked through this? On Wed, Jan 14, 2026, at 8:14 AM, Štefan Miklošovič wrote: > Realistically speaking if we just copy it and let the original library > there sitting still it will just die, it is dead pretty much already. > It is just that we are the ones who happen to have the biggest urge to > do something about that and have enough manpower to pull it off. I can > hardly imagine other people forking it / resurrecting it, if that was > true it would have happened already. > > On Wed, Jan 14, 2026 at 8:47 AM Benjamin Lerer <[email protected]> wrote: > > > > 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. > >> > >> >
