> On Oct 13, 2025, at 7:02 AM, Josh McKenzie <[email protected]> wrote:
>
> To respond to some of the other points and throw my perspective into the mix:
>
>> Release engineering for a branch is nearly a full-time job.
> While release management is a burden (and one we've had a hard time
> resourcing for years), I don't see it as being nearly a full-time job per
> branch. We also have contributors willing to step forward and take on this
> extra work and plenty of opportunity for automation on both release
> preparation and validation that would lower that burden further.
>
>> Unofficial branches will miss correctness and compatibility fixes unless
>> their maintenance is made a burden for all committers.
> Both proposals (backport to 5.0, support a 5.1 that accepts backport) would
> be considered official during the pilot. Bugfixes that are 5.0 or older would
> have 1 more branch they needed to apply to and merge through.
>
I see the word unofficial used too many times. There’s no such thing as
unofficial. If it’s merged by committers and voted on for release by the PMC,
it’s official. If it’s not, it doesn’t belong in the ASF repos.
>
>> – Backports branches don’t solve the “some people run forks” problem.
> I see this a bit differently; it doesn't "solve" the problem (I don't
> personally see this as a problem to be solved fwiw), but it does bring those
> forks much closer to upstream and move engineering effort that would
> otherwise be on private forks into the public space benefiting everyone.
I think you’ve seen at least a few reasons in this thread why the goal and
proposal may not align. What one team considers ready and low risk, another
team begs not to be included. I suspect if there was really, truly a shared
understanding of “this is back port ready, low risk, ready to run”, we could
just put it into the existing branches (with a “yes this is a feature, but it’s
a feature we all trust” discussion)?
