Mesa has one of the best collaborative, multi-vendor, in-depth testing system found in the
open source world. It has prevented countless regressions and increased the quality of the
project to the point that it ships to millions of gamers through distributions or the Steam Deck.
Let's take some time to reflect on what makes the project successful, its pain points for users
and developers, and how it could be applied to other components of the graphics stack such as
the Linux DRM subsystem, DXVK/VKD3D, IGT, ...
Proposed topics of conversation
- Reducing the amount of environment variables that are passed around to increase re-usability of containers and ease local execution
- Reducing the duplication of efforts between the containers and the rootfs: use the container as a base? run the container directly?
- Reducing the number of instances of "CI took too long" by prioritizing jobs coming from Marge
- Making running on bare metal as easy as running in the cloud runners. This would make other projects easier to get into the CI train: No visible spring boards in Mesa's code by moving the code to custom Gitlab Executors?
- Making it easier to create new CI test farms, or for developers to share access to their test machines: Speccing up a kit, instructions to set things up, and making it easy to maintain/updates like in valve-infra.
|Code of Conduct
|For which conference do you send the proposal?
|X.Org Developers Conference 2022
|GSoC, EVoC or Outreachy
|In-person or virtual presentation