Re: issues and merge requests

[Enrico Weigelt, metux IT consult]

On 07.02.24 12:20, Olivier Fourdan wrote:

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.
e.g.: https://gitlab.freedesktop.org/xorg/xserver/-/commit/133e0d6


"Closes" refers to the issue in gitlab that that particular commit
addresses:
e.g.: https://gitlab.freedesktop.org/xorg/xserver/-/commit/e622466


Also, please note that both can be used in the same commit:
e.g.: https://gitlab.freedesktop.org/xorg/xserver/-/commit/3ddb81b



thanks, fixed the contributing.md (mr #1276)


Or maybe have some tags that one can set if one *thinks* something
might be worth backporting (or moving to another branch like Xwayland),
so the corresponding maintainer could be notified and decide on his
own ?

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.


That's what I meant by "moving" (in best case cherry-pick), maybe my
wording wasn't precise enought ;-)


This is something I do on a regular basis as a maintainer of Xwayland,
it's a manual process indeed.


Ok. How do you learn of potentially interesting commits ? Do you monitor
everything happening on master or shall we CC you, if we think something
should also land in xwayland ?


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: issues and merge requests

[Olivier Fourdan]

Hi,

On Wed, Feb 7, 2024 at 11:47 AM Enrico Weigelt, metux IT consult <
i...@metux.net> wrote:

> On 07.02.24 00:59, Peter Hutterer wrote:
> >> Closes: xorg/xserver#1631
> >
> > It supports that too, but afaik the use of Fixes is more common in the
> > xorg repo. In (some?) gnome OTOH repos Closes refers to an issue anf
> > Fixes usually to a commit.
>
> Okay, so settle to "Fixes:" ?
>

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.
e.g.: https://gitlab.freedesktop.org/xorg/xserver/-/commit/133e0d6

"Closes" refers to the issue in gitlab that that particular commit
addresses:
e.g.: https://gitlab.freedesktop.org/xorg/xserver/-/commit/e622466

Also, please note that both can be used in the same commit:
e.g.: https://gitlab.freedesktop.org/xorg/xserver/-/commit/3ddb81b

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

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.

This is something I do on a regular basis as a maintainer of Xwayland, it's
a manual process indeed.

Cheers,
Olivier

Re: issues and merge requests

[Enrico Weigelt, metux IT consult]

On 07.02.24 00:59, Peter Hutterer wrote:

Hi,


Closes: xorg/xserver#1631


It supports that too, but afaik the use of Fixes is more common in the
xorg repo. In (some?) gnome OTOH repos Closes refers to an issue anf
Fixes usually to a commit.


Okay, so settle to "Fixes:" ?

Perhaps it's time to write some little document about that.

We already have some things in the Wiki, but seems to be a bit outdated.
I'd prefer having such docs within the source tree.


By the way: how to do we handle fixes that might go to several branches ?


merge it into master, then `git cherry-pick -x` to the branch, file a
merge request for that particular branch. The gitlab closed merge
request page will have examples of those, usually prefixed with the
branch they're supposed to be merged in to make them easier to identify.


Yes, that's the technical side, but I've been wondering about a formal
process on how to decide which stuff should be backported, especially
for bugfixes. Some projects (e.g. Linux kernel) extract them (semi-)
automatically by git headers.

Or maybe have some tags that one can set if one *thinks* something
might be worth backporting (or moving to another branch like Xwayland),
so the corresponding maintainer could be notified and decide on his
own ?


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: issues and merge requests

[Enrico Weigelt, metux IT consult]

On 05.02.24 22:56, Peter Hutterer wrote:


Best approach is to add a line "Fixes #123" into the commit message
and/or the merge request and gitlab will automatically link to to issue
123 in the same repo and close it when merged.


I believe gitlab reacts on "Closes:", like this:

Closes: xorg/xserver#1631


By the way: how to do we handle fixes that might go to several branches ?

For example, we might have have things that should go to 21.x branch
as well as master, as well as xwayland branch.


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: issues and merge requests

[Peter Hutterer]

On Tue, Feb 06, 2024 at 11:41:06AM +0100, Enrico Weigelt, metux IT consult 
wrote:
> On 05.02.24 22:56, Peter Hutterer wrote:
> 
> > Best approach is to add a line "Fixes #123" into the commit message
> > and/or the merge request and gitlab will automatically link to to issue
> > 123 in the same repo and close it when merged.
> 
> I believe gitlab reacts on "Closes:", like this:
> 
> Closes: xorg/xserver#1631

It supports that too, but afaik the use of Fixes is more common in the
xorg repo. In (some?) gnome OTOH repos Closes refers to an issue anf
Fixes usually to a commit.

> By the way: how to do we handle fixes that might go to several branches ?

merge it into master, then `git cherry-pick -x` to the branch, file a
merge request for that particular branch. The gitlab closed merge
request page will have examples of those, usually prefixed with the
branch they're supposed to be merged in to make them easier to identify.

Cheers,
  Peter

> 
> For example, we might have have things that should go to 21.x branch
> as well as master, as well as xwayland branch.
> 
> 
> --mtx
> 
> --
> ---
> Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
> werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
> GPG/PGP-Schlüssel zu.
> ---
> Enrico Weigelt, metux IT consult
> Free software and Linux embedded engineering
> i...@metux.net -- +49-151-27565287

Re: issues and merge requests

[tlaronde]

On Tue, Feb 06, 2024 at 07:56:16AM +1000, Peter Hutterer wrote:
> On Mon, Feb 05, 2024 at 09:52:50PM +0100, tlaro...@kergis.com wrote:
> > Alan Coopersmith has applied the merge request for libXau---thanks!
> > 
> > I had written 2 issues, related, against libXau, that the patches
> > address, so I have closed the issues after the merge.
> > 
> > It seems to me that writing issues against a module; providing patches
> > via a merge request; then closing the issues when the merge has been
> > approved and applied by a developer has the advantage of providing an
> > history.
> > 
> > Are there guidelines set concerning this?
> 
> Best approach is to add a line "Fixes #123" into the commit message
> and/or the merge request and gitlab will automatically link to to issue
> 123 in the same repo and close it when merged.
> 
> Otherwise and if on the same instance, you can also link to other
> projects using the full path including namespace, e.g.
> xorg/lib/libX11!10 is merge request 10 in libX11.
> 
> Note that a "Fixes #123" in a commit message will link from the issue to
> the commit every time you push. If you're easily embarrassed about your
> development flow it's best to leave that off and add it before the final
> push before filing a merge request ;)
> 

OK. I will follow this pattern for further patches.

Cheers,
-- 
Thierry Laronde 
 http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: issues and merge requests

[Peter Hutterer]

On Mon, Feb 05, 2024 at 09:52:50PM +0100, tlaro...@kergis.com wrote:
> Alan Coopersmith has applied the merge request for libXau---thanks!
> 
> I had written 2 issues, related, against libXau, that the patches
> address, so I have closed the issues after the merge.
> 
> It seems to me that writing issues against a module; providing patches
> via a merge request; then closing the issues when the merge has been
> approved and applied by a developer has the advantage of providing an
> history.
> 
> Are there guidelines set concerning this?

Best approach is to add a line "Fixes #123" into the commit message
and/or the merge request and gitlab will automatically link to to issue
123 in the same repo and close it when merged.

Otherwise and if on the same instance, you can also link to other
projects using the full path including namespace, e.g.
xorg/lib/libX11!10 is merge request 10 in libX11.

Note that a "Fixes #123" in a commit message will link from the issue to
the commit every time you push. If you're easily embarrassed about your
development flow it's best to leave that off and add it before the final
push before filing a merge request ;)

Cheers,
  Peter

issues and merge requests

[tlaronde]

Alan Coopersmith has applied the merge request for libXau---thanks!

I had written 2 issues, related, against libXau, that the patches
address, so I have closed the issues after the merge.

It seems to me that writing issues against a module; providing patches
via a merge request; then closing the issues when the merge has been
approved and applied by a developer has the advantage of providing an
history.

Are there guidelines set concerning this?
-- 
Thierry Laronde 
 http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C