<div dir="ltr"><div>Hi,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 7, 2024 at 11:47 AM Enrico Weigelt, metux IT consult <<a href="mailto:info@metux.net">info@metux.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 07.02.24 00:59, Peter Hutterer wrote:<br>

>> Closes: xorg/xserver#1631<br>
><br>
> It supports that too, but afaik the use of Fixes is more common in the<br>
> xorg repo. In (some?) gnome OTOH repos Closes refers to an issue anf<br>
> Fixes usually to a commit.<br>
<br>
Okay, so settle to "Fixes:" ?<br></blockquote><div><br></div><div>As Peter explained, "Fixes" refers to a commit in particular (like a regression was introduced, then fixed with a later commit, that later commit "fixes" the first commit) - That is useful for example when backporting between branches, because those can be squashed together, if caught on time before the first commit gets backported.</div><div></div><div>e.g.: <a href="https://gitlab.freedesktop.org/xorg/xserver/-/commit/133e0d6">https://gitlab.freedesktop.org/xorg/xserver/-/commit/133e0d6</a></div><div><br></div><div>"Closes" refers to the issue in gitlab that that particular commit addresses:<br></div><div>e.g.: <a href="https://gitlab.freedesktop.org/xorg/xserver/-/commit/e622466">https://gitlab.freedesktop.org/xorg/xserver/-/commit/e622466</a></div><div></div><div><br></div><div>Also, please note that both can be used in the same commit:<br></div><div>e.g.: <a href="https://gitlab.freedesktop.org/xorg/xserver/-/commit/3ddb81b">https://gitlab.freedesktop.org/xorg/xserver/-/commit/3ddb81b</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Perhaps it's time to write some little document about that.<br>
<br>
We already have some things in the Wiki, but seems to be a bit outdated.<br>
I'd prefer having such docs within the source tree.<br>
<br>
>> By the way: how to do we handle fixes that might go to several branches ?<br>
><br>
> merge it into master, then `git cherry-pick -x` to the branch, file a<br>
> merge request for that particular branch. The gitlab closed merge<br>
> request page will have examples of those, usually prefixed with the<br>
> branch they're supposed to be merged in to make them easier to identify.<br>
<br>
Yes, that's the technical side, but I've been wondering about a formal<br>
process on how to decide which stuff should be backported, especially<br>
for bugfixes. Some projects (e.g. Linux kernel) extract them (semi-)<br>
automatically by git headers.<br>
<br>
Or maybe have some tags that one can set if one *thinks* something<br>
might be worth backporting (or moving to another branch like Xwayland),<br>
so the corresponding maintainer could be notified and decide on his<br>
own ?<br></blockquote><div><br></div><div>Just a note to clarify, xwayland is just like any other stable branch of the xserver, fixes are not /moved/ to xwayland, they get merged first into master and then get backported into the stable xwayland branch(es) as necessary.</div><div><br></div><div>This is something I do on a regular basis as a maintainer of Xwayland, it's a manual process indeed.<br></div><div><br></div><div>Cheers,</div><div>Olivier<br></div></div></div>