From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC PATCH http-server 1/2] add error message into http body
Date: Wed, 29 Jan 2025 18:51:50 +0100 [thread overview]
Message-ID: <cd2194a4-6af0-4c62-ac57-87dcad803647@proxmox.com> (raw)
In-Reply-To: <25098460-cb5f-4a09-9b0b-a34da57ce0ef@proxmox.com>
Am 28.01.25 um 15:46 schrieb Dominik Csapak:
> (short question: is going from rfc -> v2 alright with you? or should i do
> rfc -> v1 -> v2 in the future? looking at my past series i did both, but would
> like to do that consistently. maybe it's even a thing to write in the dev docs?)
Good question!
We do not have this pattern that often so I do not have some specific and well
thought out opinion for our use case, but I can say this:
- most developers on other projects using our development (mailing list based) flow,
like e.g. Linux Kernel or QEMU, reset the revision when switching from an RFC to
a PATCH. FWIW though, as this is what I observed subjectively, I did not collect
some unbiased statistic.
- I can see benefits for keep bumping the revision like you did, as one is
indirectly made aware that there was something before the first submission of a
series after switching from RFC to PATCH.
The "changes from rfc" wording you used for the changelog also made this quite
clear.
- OTOH that could be also addressed by linking at the previous submission(s),
something that seems also quite popular for aforementioned projects.
For now, I'm fine with either variant, no strong preference either way, albeit
being able to extract the information from a submission that a switch happened,
be it through a good changelog title like you used and/or a link to the previous
submission, would be definitively really good to have–to not say a must-have.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-01-29 17:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 8:45 [pve-devel] [RFC PATCH http-server 0/2] improve error handling on api errors Dominik Csapak
2025-01-08 8:45 ` [pve-devel] [RFC PATCH http-server 1/2] add error message into http body Dominik Csapak
2025-01-15 16:08 ` Thomas Lamprecht
2025-01-16 7:31 ` Dominik Csapak
2025-01-27 12:44 ` Dominik Csapak
2025-01-28 14:24 ` Thomas Lamprecht
2025-01-28 14:46 ` Dominik Csapak
2025-01-29 17:51 ` Thomas Lamprecht [this message]
2025-01-08 8:45 ` [pve-devel] [RFC PATCH http-server 2/2] use HTTP_INTERNAL_SERVER_ERROR were appropriate instead of '501' Dominik Csapak
2025-01-15 16:19 ` Thomas Lamprecht
2025-01-16 7:36 ` Dominik Csapak
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=cd2194a4-6af0-4c62-ac57-87dcad803647@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@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