xserver release process

Adam Jackson ajax at nwnk.net
Wed Oct 9 16:56:25 UTC 2019

On Tue, 2019-10-08 at 22:19 +0200, Hans de Goede wrote:
> Hi,
> On 08-10-2019 18:28, Adam Jackson wrote:
> > In short, releases need to happen, and we have CI, so let's just pop a
> > release out on scheduled dates assuming CI passes.
> Given that the Xorg xserver has a lot of hw interaction, we are
> never going to catch everything with CI, so this seems a bit
> over-simplified.

I mean, yes, it's over-simplified. The alternative is not doing
releases, apparently. The idea here is that we keep adding more
coverage to CI, and we fake hardware coverage if we need to by writing
more tooling around vkms and friends. This may mean that any given
point-zero release is less stable than we might like, but that's not
exactly new, and having cheap-and-frequent stable releases should help
mitigate that.

> I think it would be good to have 2 things:
> 1. A way to track potential blocker bugs. Note I'm not advocating some
> process heavy approach here. The blocker bugs can just be gitlab issues
> with a special tag I guess. The idea is that the release-coordinator
> at least can get a list of known issues and then decide if those are bad
> enough to delay a release or not.



- ajax

More information about the xorg-devel mailing list