From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 439FB1FF15F for ; Mon, 21 Oct 2024 18:06:15 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 44014385E6; Mon, 21 Oct 2024 18:06:52 +0200 (CEST) Message-ID: <22e250cd-25f2-4313-b848-be04bf1f565b@proxmox.com> Date: Mon, 21 Oct 2024 18:06:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox Backup Server development discussion References: <20241021125522.237273-1-c.ebner@proxmox.com> <1d54bdfe-5248-4815-b4ca-20497be1939e@proxmox.com> Content-Language: en-US, de-DE From: Christian Ebner In-Reply-To: <1d54bdfe-5248-4815-b4ca-20497be1939e@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.028 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup 0/3] backup client progress log interval X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Backup Server development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On 10/21/24 17:08, Thomas Lamprecht wrote: > 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? Okay, fine by me as well. To be honest I only followed trough with the variant in value approach since I did already implemented most of it on Friday before I did see your email regarding discouraging that approach. If going for two different optional parameters, one question remains however: how to handle the no logging case? Should a 0 value indicate that or do we want another explicit flag for that? > 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. Agreed! Thank you for your comments. _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel