xserver release process
aplattner at nvidia.com
Wed Oct 9 15:01:22 UTC 2019
On 10/8/19 1:19 PM, Hans de Goede wrote:
> 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
> 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.
If you have issues or merge requests that need to block a release,
please tag them with the appropriate GitLab milestone:
> 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 :)
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
More information about the xorg-devel