public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH frr] frr: fix bit flag collision in patch
Date: Fri, 14 Mar 2025 10:33:23 +0100	[thread overview]
Message-ID: <aa092130-7d45-44e3-9936-ff621cd656c9@proxmox.com> (raw)
In-Reply-To: <zjcd5mtjczr4fltdi6tal5lbr6jtnsf2b4f35e734ik2s42nxf@kgaphbcyxizo>

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@proxmox.com>  Thu, 13 Mar 2025 13:33:46 +0100

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

export DEBEMAIL='Proxmox Support Team <support@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.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


  reply	other threads:[~2025-03-14  9:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 12:49 Gabriel Goller
2025-03-13 15:16 ` Thomas Lamprecht
2025-03-13 15:49   ` Gabriel Goller
2025-03-14  9:33     ` Thomas Lamprecht [this message]
2025-03-14  9:48       ` Gabriel Goller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aa092130-7d45-44e3-9936-ff621cd656c9@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal