fesco

#3584 Grant permanent updates exception for Mesa
Closed: Accepted by siosm. Opened by ngompa.

Closed: Accepted
Reopen Issue

We currently have a permanent exception for the Linux kernel but don't have a documented one for Mesa. Technically, Mesa updates are generally backward compatible so an exception isn't strictly needed, but occasionally behavioral changes occur either in response to hardware or Linux kernel changes. Even more rarely, sometimes libraries go away in Mesa, but we have mesa-compat to deal with those cases, so I don't think that's a big deal.

Rather than making this difficult to figure out, I'd like for us to just explicitly document that Mesa can be upgraded in stable releases just like the Linux kernel can. We gave an initial exception for the Mesa 26.0 upgrade in #3580, and I think we should also give a permanent one too.

Proposal: Mesa is explicitly allowed to upgrade to new versions in stable releases.

Needless to say, I think we should.

+1

I already gave my +1 for a permanent exception in that other ticket, so I'm still +1 here.

That is, assuming that the updates for stable branches are done responsibly, of course. I think it would make sense to either turn off autotime/autokarma for those updates entirely, or set them to sufficiently high values to allow for issues (like a +10 karma minimum) to be caught before the updates are pushed to stable.

+1

Agree with Fabio's suggestion as well around disabling auto-karma for "major" mesa updates.

+1

In practice for most packages that aren't Firefox, any karma requirement above +3 is indistinguishable from "disable karma push". I'm honestly 0 on requiring this, as the karma system has never been a particularly useful approach when dealing with low-level system functionality. (It works pretty well for applications, though.)

I mentioned this because mesa is actually one of the only (?) three packages, as far as I can tell, that gets a lot of karma votes (kernel and firefox being the other two). So I don't think it would be unreasonable, nor does a distinction between applications and "low-level" stuff make sense - because it's just not the case that it doesn't get +1 votes. I did not propose making the high limit or turning off autopush official though, just wanted to point out that it would need to be handled carefully.

EDIT:

For reference, the last three mesa updates for F43 (current latest stable) received +3, +11, and +10 karma, respectively, before being pushed to "stable":

  • https://bodhi.fedoraproject.org/updates/FEDORA-2026-03044a06da
  • https://bodhi.fedoraproject.org/updates/FEDORA-2026-6c4fe01324
  • https://bodhi.fedoraproject.org/updates/FEDORA-2026-811a7e5cf6
Edited by decathorpe

Mesa also already benefits from coordination with RPM Fusion (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XGVTPIDVH26DEX3SMK6U33OVNBIT4YRU/) so disabling auto-push for major releases is probably not a big ask.

+1

+1

+1

I think we don't need to specify a specific threshold, but given a lot of us express concern hopefully this is signal for the Mesa maintainers to treat Mesa upgrades in stable releases carefully.

+1

After 11 days:
APPROVED (+8, 0, 0)

Metadata Update from @siosm:
- Issue tagged with: document it, pending announcement

Announced in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3YHI3QNTXYWYW3J6FLQ5NQ2RWW36QV26/

Please make a PR to the docs.

Metadata Update from @siosm:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

Metadata Update from @siosm:
- Issue untagged with: pending announcement
Metadata
None

document it updates policy exception

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.