[pve-devel] [PATCH frr] frr: fix bit flag collision in patch

[Thomas Lamprecht]

On 13/03/2025 16:49, Gabriel Goller wrote:
> On 13.03.2025 16:16, Thomas Lamprecht wrote:
>> w.r.t. versioning I'd have bumped the pve1 part to pve2.
> 
> So '10.2.1-1+pve2'?

Exactly.

>>> +  * fix fabricd dummy_as_loopback flag collision
>>
>> collision with what? these entries should be telling for end users (not devs).
> 
> True, a simpler "fix fabricd dummy_as_loopback flag" would be enough.

No, my question was with what this collides, your correction does not answer
that at all and is equally "bad" compared to the original. Maybe something
along the lines of:

  * fix collision in fabricd for the option values of the recent dummy-as-loopback
    backport and a internal test mode, where enabling one would always enable the
    other.

As that tells admins actually what collided and what the basic effect was.

>>> +
>>> + -- Gabriel Goller <g.goller at proxmox.com>  Thu, 13 Mar 2025 13:33:46 +0100

I overlooked that above should be 'Proxmox Support Team <support at proxmox.com>'
dch uses the DEBEMAIL environment variable here, so you can add something like

export DEBEMAIL='Proxmox Support Team <support at proxmox.com>'

to your shell's rc file to get that correct, makes most sense if you primarily
develop on Proxmox projects on that host, e.g. I have a dedicated development VM
to contain all this stuff, otherwise adding an alias that sets this correctly
might be also an option.

> Stefan said the exact same thing :)
> This is done quite commonly in frr e.g.:
> https://git.proxmox.com/?p=mirror_frr.git;a=blob;f=bgpd/bgpd.h;h=9cb1d51088cfc456f344b17b8068f84d382e3751;hb=HEAD#l210.
> But I don't think it's that bad anyway :).

If they use it already, then fine, but lets not introduce this in any of our
(C) code.