From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>,
Christian Ebner <c.ebner@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup 0/3] backup client progress log interval
Date: Mon, 21 Oct 2024 17:08:30 +0200 [thread overview]
Message-ID: <1d54bdfe-5248-4815-b4ca-20497be1939e@proxmox.com> (raw)
In-Reply-To: <20241021125522.237273-1-c.ebner@proxmox.com>
Am 21/10/2024 um 14:55 schrieb Christian Ebner:
> These patches allow to specify a time based or size based interval
> for progress log output as generated during `proxmox-backup-client
> backup` runs.
>
> The client is extended by an optional `progress-log-interval`
> parameter, which allows to set the interval as `TimeSpan` or
> `HumanByte` parsable input string, depending on the variant prefix.
> If set to `none` the progress log output is disabled, if no prefix is
> specified, a time based interval is assumed. Lastly, if the parameter
> is not given, the default 'time:1m' is used.
>
nice work but I'm a bit torn w.r.t. exposing the variant inside the
value, could be nicer to have it written out in the option name itself,
e.g.:
--progress-interval for time based, as intervals are very often time
based anyway, and it's probably what most user want by default.
--progress-size-interval for size based, albeit the option name is not
really _that_ good, but progress-interval-size, which would be nicer
for choosing between both via autocompletion as they share a longer
prefix, has an even worse ring to it IMO. That's why I'm torn, the
variant as value avoids this odd option naming, but still, multiplexing
option is juts not that great.
What do you think?
Oh, and in above examples I also dropped the "log" as while it certainly
doesn't hurt its IMO also not really required to be able to understand what
it's for.
_______________________________________________
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:[~2024-10-21 15:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 12:55 Christian Ebner
2024-10-21 12:55 ` [pbs-devel] [PATCH proxmox-backup 1/3] api-types: client: add type to specify " Christian Ebner
2024-10-21 12:55 ` [pbs-devel] [PATCH proxmox-backup 2/3] client: progress log: factor out log message generation Christian Ebner
2024-10-21 12:55 ` [pbs-devel] [PATCH proxmox-backup 3/3] client: progress log: allow to specify backup log interval Christian Ebner
2024-10-21 15:08 ` Thomas Lamprecht [this message]
2024-10-21 16:06 ` [pbs-devel] [PATCH proxmox-backup 0/3] backup client progress " Christian Ebner
2024-10-22 5:35 ` Thomas Lamprecht
2024-10-23 9:12 ` Christian Ebner
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=1d54bdfe-5248-4815-b4ca-20497be1939e@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=c.ebner@proxmox.com \
--cc=pbs-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