xserver release process

[Hans de Goede]

Hi,

On 08-10-2019 18:28, Adam Jackson wrote:

<snip>

> 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 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.

2. Send out a notice that a new release will happen in say 4 weeks
from date of sending with a request for testing + getting any pending
*fixes* upstream asao, maybe together with some "beta" or "rc" tarbals,
but that is optional.

My main reason for suggesting either one is that I personally am aware
of at least 2 issues (both related to secondary USB GPUs handling) which
are only present in master and not in the 1.20 branch and which I really
would like to see fixed before a new release. I have taking a look at
these on my to do list, but not at the top of it (yet).

Having 1. would help in tracking such known issues, I doubt I'm the only
one who has a couple of "I need to look into this and fix it" items on
their TODO, so being able to track these would be good.

Having 2. would help me bump up these TODOs in priority to try and get
them fixed before the release :)

Regards,

Hans