I'd like to update the package in stable releases to the latest version. The update is backwards-compatible in the sense that only new functionality was added. The package is hooked into the build process via rpm macros only in F41+, so it is a standalone leaf package in F<=40. Updating it will allow developers to test with the latest version of the code that supports pyc files properly, has additional features, and is faster.
Thus, I'm requesting a permanent exception for the updates policy.
Metadata Update from @zbyszek: - Issue tagged with: updates policy exception
This seems reasonable. +1
Since it doesn't introduce any user-facing changes in <F41 (because there is nothing user-facing at all) this is +1 from me too. Not sure if you technically even need an official exception here.
I don't know if it's a good idea to grant a permanent exception, since we don't have one for any buildroot-critical components right now, and updates can seriously break the build environment in F41+.
I am unconvinced of the value of a permanent exception, but I could be convinced of a one-time exception.
For this request, -1.
Metadata Update from @ngompa: - Issue tagged with: meeting
Not sure if you technically even need an official exception here.
I tried to follow the Policy. It says that the FESCo exception is needed in general, and doesn't provide any exception that'd match here, afaics.
we don't have one for any buildroot-critical components right now
The original post above explains why this package is different and why it's reasonable.
updates can seriously break the build environment in F41+
Well, if it's broken, then it'll be very quickly noticed and fixed. The problem would occur in rawhide first anyway, and there'd be plenty of time to prevent it from reaching stable via a (much slower) update in other releases.
That is not a sufficient reason to grant an exception. In fact, that sounds like a reason not to grant it. This strongly reminds me of the GCC plugin nightmare we used to have for years and years. There's no way I want to inflict more pain like this on the contributor community unless we have some kind of guard to prevent it from landing at all.
I agree that a permanent updates policy exception should only apply to stable branches where add-determinism is not part of the build pipeline. So for Fedora <41 that's fine (and I'm not sure an exception is actually needed since there are no user-facing changes), but for stable branches where add-determinism will be part of the pipeline, a permanent updates policy exception sounds like a recipe for disaster.
This was discussed in today's meeting:
Closing as rejected (for now) on the permanent exception.
Metadata Update from @jistone: - Issue close_status updated to: Rejected - Issue status updated to: Closed (was: Open)
Metadata Update from @jistone: - Issue untagged with: meeting
Log in to comment on this ticket.