From: "Laurențiu Leahu-Vlăducu" <l.leahu-vladucu@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] applied: [PATCH proxmox-backup v3 1/1] proxy/parallel_handler: Improved panic errors with formatted strings
Date: Tue, 28 Jan 2025 09:03:22 +0100 [thread overview]
Message-ID: <40a0d777-2627-436c-a879-ffab776e5452@proxmox.com> (raw)
In-Reply-To: <54c6eab0-fe33-4792-a74c-b9f80e247324@proxmox.com>
I fully agree with you on all points - thanks for the info! :)
On 27.01.25 16:57, Thomas Lamprecht wrote:
> Am 24.01.25 um 16:29 schrieb Laurențiu Leahu-Vlăducu:
>> * Improved errors when panics occur and the panic message is a
>> formatted (not static) string. This worked already for &str literals,
>> but not for Strings.
>>
>> Downcasting to both &str and String is also done by the Rust Standard
>> Library in the default panic handler. See:
>> https://github.com/rust-lang/rust/blob/b605c65b6eb5fa71783f8e26df69975f9f1680ee/library/std/src/panicking.rs#L777
>>
>> * Switched from eprintln! to tracing::error when logging panics in the
>> task scheduler.
>
> This describes what happens but not why and which visible changes this
> has, or not has, like I asked in my review for v2.
>
> Background reasoning is important for commit messages, as while a
> summary about "what" changes can be quite nice to have it can almost
> always reconstructed relatively easy from checking the diff. The
> semantic change that affects users and or devs OTOH is harder to
> reconstruct, sometimes even impossible (besides that brains tend to
> forget details, staff is not always around to be able to ask them).
> And while one won't need that information for all commits, one cannot
> really predict for which, so adding a rationale for every non-trivial
> commit–with a rather narrow definition of trivial–is the only way to
> ensure that this information is there when needed; short of time-travel
> ;) Note that one does not need a ton of text, one or two sentences can
> often be enough, sometimes a few short paragraphs tend to help though;
> I'm also fine with always going for relatively long commit messages, a
> short summary at the top would be helpful then though.
>
> Oh and FWIW, for this change it would have been fine to switch over to
> tracing::error in a separate patch, as it's not directly related to
> better relaying errors from panics.
>
> The first part above I mentioned on v2, that's on you so to say, the
> latter I did not mention when reviewing on v2, so that's on me, as it's
> not a big change and I did not want to delay it further I now applied
> the patches as is.
>
> And the reason I went for a relatively big explanation here, which
> actually applies to all devs not just you, is mostly because first,
> you're relatively new at Proxmox thus a bit stricter review with more
> rationale is warranted and second, doing so safes, among others, the
> people writing changelogs and tracking down bugs a ton of time, and I
> tend to do both quite often and know the pain about having to retrace
> all relations and background reasoning from a fresh starts because the
> author did not bother with any commit message, and while it was
> self-explanatory or obvious back then for them, they "interestingly"
> often do not remember when asking about the background in persona; which
> _is_ relatable, as said making errors and forgetting things is human,
> but as the fix is so easy, i.e. just write an actual commit message with
> some actual background, it's nonetheless not a good excuse. Another
> benefit of writing short summarize is that one needs to reflect on the
> work on a higher level, just like rubber duck programming that can help
> to improve things without another's person's review or sometimes also
> surface some flaws.
>
> anyhow: applied, thanks!
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
next prev parent reply other threads:[~2025-01-28 8:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-24 15:29 [pbs-devel] [PATCH proxmox/proxmox-backup v3 0/1] " Laurențiu Leahu-Vlăducu
2025-01-24 15:29 ` [pbs-devel] [PATCH proxmox-backup v3 1/1] proxy/parallel_handler: " Laurențiu Leahu-Vlăducu
2025-01-27 15:57 ` [pbs-devel] applied: " Thomas Lamprecht
2025-01-28 8:03 ` Laurențiu Leahu-Vlăducu [this message]
2025-01-24 15:29 ` [pbs-devel] [PATCH proxmox v3 1/1] rest-server: " Laurențiu Leahu-Vlăducu
2025-01-27 18:22 ` [pbs-devel] applied: " Thomas Lamprecht
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=40a0d777-2627-436c-a879-ffab776e5452@proxmox.com \
--to=l.leahu-vladucu@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=t.lamprecht@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