> I already heard concerns from multiple folks expressing an opinion that > backport branch was all but decided in some meeting between interested > parties, even if the result of this conversation was brought back to the > mailing list. I want to take a moment to speak to this as I've had some very unpleasant and difficult direct conversations about this and continue to hear things 2nd and 3rd hand.
The "unofficial backport branch in public" was brought up and discussed at CoC in a room with 40+ people in it, many committers and PMC members, and I took an action item to follow up with the people who'd mentioned this shared pain to help them engage with the dev list. They're new contributors and didn't really know what the path looked like to constructively engage w/the community on the topic. I had no horse in that race other than I want to help people contribute and build skills around how to engage with the community. There was a follow up general unstructured working session that some contributors have to share tips, learnings, insights into what they run into rolling out new versions, etc, and I still hadn't gotten around to that todo item to bring that to the list. So naturally that topic came up since it wasn't addressed yet, people brainstormed, came up with they thought might work, and next blocking step was to bring it to the list to see what the community thought. Then it was brought to the list. No secret back-channel dealings. No "all but decided". The topic came up during the cassandra track and while unfortunately not everyone could be at the conference in person, nobody at any point suggested anything was decided or that any governance would change. It was an idea that people wanted to do enough work to feel comfortable bringing it to the broader dev community, and then I helped them do so. We need to be able to have discussions about ideas and proposals without the immediate reaction being suspicion, in-group out-group assumptions, and vitriol. People need to be able to brainstorm something and do enough work to test that their idea is solid enough to take up everyone else's time and attention with it. This is why we have the CEP process, to provide a path for people to explore technical ideas enough to then bring them to the community for consideration. The idea of a backport branch *was no different, *excepting it seems it's a topic that sparked a lot of emotion from various people on various sides and some less than professional engagement in the discussion. This: > concerns from multiple folks expressing an opinion that backport branch was > all but decided in some meeting between interested parties, even if the > result of this conversation was brought back to the mailing list. Directly intersects with what Mick has said: > Just because you disagree please don't try to shut down the discussion– > please be more generous to the exploration. > > For example, take this spin-off thread where Josh has tried to take a step > back and further explore the problem statement, but still this thread gets > hit with repeated objections from the original thread– that's not very > engaging or trusting of others' intent. And finally, the email I brought to the list about this topic was, I think, pretty clear it was just a proposal that was being opened for discussion: > The proposal we came up with: and > If you’re interested in helping curate or maintain this branch - or have > thoughts on the idea - please reply and voice your thoughts. If you don't like the idea of a backport branch: I get it. I don't prefer it either; I've tried to make clear in this thread the solution I personally think better balances the needs of the community. But I'm trying to keep an open mind, and I think either the backport branch idea, looser backports to latest GA, looser or more frequent exercising of our backport mechanisms, or tightening up quality of trunk and cutting trunk alphas *are all better than the status quo of people wasting time and energy on redundant drudge work they'd rather be investing in the community*. Hopefully the above does more good than harm; I don't think there's any villains here and I think everyone engaging on these threads genuinely wants the project to succeed and isn't actively trying to do that at anyone else's expense. We all need to work to explore how these ideas impact each others' workflows to try and figure out the best balance and compromise to move forward. Thus ends my TED talk. =/ On Fri, Oct 24, 2025, at 9:07 AM, Mick wrote: > > > > On 24 Oct 2025, at 11:44, Jeff Jirsa <[email protected]> wrote: > > > > There’s dozens of voices of dissent at varying levels of intensity > > > > Agree with Jeff here. > > I have not seen any hint or pretension of a consensus in either thread. > It's appreciated that a certain level of energy and progression in a > discussion can be conflated with consensus and seen as exclusive behaviour > (everyone should be conscious and proactive against that). > > What I have seen is folk bringing forward an idea that addresses real > problems, that is reversible in a pilot, a way to grow the dev community, and > a typical thing to do in open source projects. > > IMHO, it has been by-and-large brought forward and carried out in an > open-minded and explorative manner. > > Just because you disagree please don't try to shut down the discussion– > please be more generous to the exploration. > > For example, take this spin-off thread where Josh has tried to take a step > back and further explore the problem statement, but still this thread gets > hit with repeated objections from the original thread– that's not very > engaging or trusting of others' intent. > > > Scott, you make a statement that I both disagree with and feel might be > critical to moving the discussion forward (or at least putting aside concerns > to the original thread and allowing us to continue this one in better faith). > > > > There is a path forward for such backports to be contributed today, and > > it’s pretty well established. > > > I find that statement risks polarises the discussion– if, like me, you can't > see that practice alone addressing all the problems being raised in both > threads. I really do not wish to see certain features back ported into our > stable GA branches. > > Having said that, it is an entirely legitimate practice that solves many back > port possibilities, and if we do agree that the current need for a back port > branch remains only runtime jdk21 and cep-37, and we agree both can > comfortably fit in that existing practice, then there is no need today for a > back port branch and we can and should leave the discussion of creating such > a back port branch open and ongoing, without urgency. > > In this thread: that I hope we can seperate as it was intended; we should > continue to seek input from those running forks, to better understand them > and see what we could and might do to help them. Josh also raised solid > suggestions that had nothing to do with introducing a back port branch, let's > not hijack that please.
