Re: xserver release process
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. Milestones: https://gitlab.freedesktop.org/xorg/xserver/-/milestones - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xserver release process
On 10/8/19 1:19 PM, 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 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: https://gitlab.freedesktop.org/xorg/xserver/-/milestones -- Aaron 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 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xserver release process
On 2019-10-08 6:28 p.m., Adam Jackson wrote: I gave a brief lightning talk about this at XDC Montreal [1], and nobody seemed to object, but here's a recap for those who weren't present or have other ideas or preferences. In short, releases need to happen, and we have CI, so let's just pop a release out on scheduled dates assuming CI passes. Six months seems to be a pretty reasonable cadence for xserver major releases as new feature development has tailed off a bit. Likewise for stable branches, if there's been changes to the branch and it's been (say) two weeks since the last release on that branch, and CI passes, automatically do a new release. I intend to make this _entirely_ automatic, with a robot doing the actual commits and release uploads. I like the idea of doing automatic release snapshots / candidates, but I think that's a bit too aggressive for actual releases at this point, at least on the stable branch. E.g. the recent 32-bit ABI breakage on the 1.20 branch would likely have made it into a 1.20.y release with this scheme. Also, let's adopt the Mesa "last two digits of the year" version scheme, it makes it easy to see how old your software is at a glance. We'll need to be slightly careful about this to ensure we don't make the (protocol) release number go crazy, so the scheme looks something like this (underscores for clarity): - xserver 1.20.5 → 1_20_05_000 - xserver 19.0.0 → 1_20_19_000 - xserver 19.0.1 → 1_20_19_001 - xserver 19.1.0 → 1_20_19_100 - xserver 20.0.0 → 1_20_20_000 And then 1_21_*_* as of 21.x.y? Either way, sounds good. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xserver release process
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 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 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xserver release process
Adam Jackson writes: > In short, releases need to happen, and we have CI, so let's just pop a > release out on scheduled dates assuming CI passes. WFM -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
xserver release process
I gave a brief lightning talk about this at XDC Montreal [1], and nobody seemed to object, but here's a recap for those who weren't present or have other ideas or preferences. In short, releases need to happen, and we have CI, so let's just pop a release out on scheduled dates assuming CI passes. Six months seems to be a pretty reasonable cadence for xserver major releases as new feature development has tailed off a bit. Likewise for stable branches, if there's been changes to the branch and it's been (say) two weeks since the last release on that branch, and CI passes, automatically do a new release. I intend to make this _entirely_ automatic, with a robot doing the actual commits and release uploads. Also, let's adopt the Mesa "last two digits of the year" version scheme, it makes it easy to see how old your software is at a glance. We'll need to be slightly careful about this to ensure we don't make the (protocol) release number go crazy, so the scheme looks something like this (underscores for clarity): - xserver 1.20.5 → 1_20_05_000 - xserver 19.0.0 → 1_20_19_000 - xserver 19.0.1 → 1_20_19_001 - xserver 19.1.0 → 1_20_19_100 - xserver 20.0.0 → 1_20_20_000 Suggestions and comments are welcome, with the understanding that anything much more complicated or too different than this implies that you're volunteering to do all the work. (Not that that's a problem, just letting you know what you're signing up for.) [1] Starting approximately here: https://youtu.be/JIry8jpbPUY?t=32790 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
xserver release process and gitlab
I was asked off-list what tasks are involved in releasing a new X server, since eventually people are probably going to want one. And that's a good question! The unfortunate answer is that the process has been informal and has varied over time. We have often used tracking bugs in bugzilla to define the set of remaining issues to address within a release, but we're not using bugzilla anymore. So I think it's probably a good idea to start with the processes available to us in gitlab. From what I can tell, "milestones" are the best fit for this. I've created a starter milestone to track 1.21: https://gitlab.freedesktop.org/xorg/xserver/milestones/1 Anyone with "developer" access or higher to the xserver project should be able to edit this milestone, but the release manager (whoever that ends up being) should have final editorial control. If you think an issue should be added to this milestone, comment on the issue or find a developer who can nominate it for you. I'll take a pass through the issue list in the next few days and nominate some likely bugs. In general, candidate issues for a major release include crash fixes, regressions, and major feature work. The release manager should ensure all such issues have assignees, and check in on their progress regularly. Establishing a release schedule should itself be one of the issues resolved for a given release (since you can't comment on a milestone proper, only on issues attached to it). So let's do that here: https://gitlab.freedesktop.org/xorg/xserver/issues/688 We don't currently have formal acceptance criteria for a release, though an obvious minimum would be to have 'ninja -C build test' pass on all major platforms in CI. We should document this testing process, as well as define criteria for adding additional acceptance criteria. Vaguely related to all this is that we badly need to get our documentation moved from the old wiki to gitlab. There's an open issue for this, but it's a few months inactive: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/80 If any of this sounds too crazy, or if there are other things we need to address, please let us know so we can address them. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
