New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mesa: 20.0.2 -> 20.0.7 #89105
mesa: 20.0.2 -> 20.0.7 #89105
Conversation
version = "20.0.2"; | ||
# Release calendar: https://www.mesa3d.org/release-calendar.html | ||
# Release frequency: https://www.mesa3d.org/releasing.html#schedule | ||
version = "20.0.7"; # Update only to the final (last planned) release (i.e. X.Y.MAX)? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vcunat what do you think of the idea to only update to the final (last planned) release of a X.Y series?
This isn't ideal, but since we currently lack the capacity to update mesa
~every two weeks, our channels are usually delayed by a few days anyway, and this causes lots of rebuilds that sounded like an idea that might be worth a try. My hope is that the last/final release a a series would be the most bug free / well tested.
Gentoo might do this as well (https://packages.gentoo.org/packages/media-libs/mesa) but most distributions seem to package the most recent stable release.
But of course this wouldn't have to be a strict rule (sometimes we might e.g. require an update to fix other packages that run into bugs or require new features).
New features releases (new X.Y series) are available approx. every 3 months so that wouldn't be a problem for us, but it's unfortunately also a bit long.
Alternatives:
- We could follow all stable updates if testing from
@GrahamcOfBorg
would be sufficient (the build time might e.g. be sufficient for aglxgears
test if that runs with software drivers - haven't looked into that yet). - We keep the "random" updates (currently done) - i.e. someone updates
mesa
whenever they feel like the package is too outdated - We create a team for
mesa
and rotate for each update
Edit: Maybe I should also create an issue for this question?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the non-feature bumps I expect we could go without manual testing (into staging), in which case the update is quite easy to do. I also had some ideas about reducing the rebuild amounts significantly, at the very least on non-feature bumps (I could try to recover the ideas). But perhaps there's no real demand for frequent updates anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, the rebuild ideas are here: #44831
I'll assign |
OK, at least this time I'd wait if .8 comes out in the next few days. We probably won't have a EDIT: still not available, as of June 7. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's stage this now; I can't see any benefit in waiting so long.
https://lists.freedesktop.org/archives/mesa-dev/2020-June/224501.html /cc PR #89105; this is indeed announced to be the last 20.0 version.
Motivation for this change
Note: It's probably best to wait for 20.0.8 with is the last planned release for 20.0 as it should be released very soon (was scheduled for yesterday).
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)