From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id D622A1FF394 for ; Mon, 3 Jun 2024 14:21:38 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 6189DE2E; Mon, 3 Jun 2024 14:22:06 +0200 (CEST) Date: Mon, 03 Jun 2024 14:21:30 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Dietmar Maurer , Proxmox Backup Server development discussion References: <20240529095502.938695-1-dietmar@proxmox.com> <103715843.2056.1716978171391@webmail.proxmox.com> <1449403995.2265.1716986655072@webmail.proxmox.com> In-Reply-To: <1449403995.2265.1716986655072@webmail.proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1717417048.g0ke3iroho.astroid@yuna.none> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.059 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pbs-devel] [PATCH proxmox v2] sys: pass create options as reference 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On May 29, 2024 2:44 pm, Dietmar Maurer wrote: >> I guess we could make a note for the next proxmox-sys bump we do for other reasons, but bumping half the world just for this seems a lot of work for little gain? > > This is just a cleanup, so it is not really required. But if we delay all cleanups, cleanup will take a long time (or will never happen ...) we don't need to delay all cleanups (and I hope we don't :)), but for those that contain breaking changes that cause a lot of churn, we need to decide whether the churn *now* is worth it. and most of the time, that decision will incorporate the benefits of the change (if it is mostly cosmetic, then the scales will tip towards "let's put it on a list of things to do when we have unavoidable/important breaking changes"). improving our processes so we don't forget to incorporate such small cleanups when the next good opportunity arrives would also be good - because we definitely don't want to end up with them never happening! > But yes, we want to split this crate anyways, so lets wait for that. ack. issues like this are definitely an argument for crates with limited scope and clear boundaries ;) _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel