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 85E9C1FF191 for ; Tue, 7 Oct 2025 17:05:40 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id DE7A41BCA6; Tue, 7 Oct 2025 17:05:44 +0200 (CEST) Message-ID: <343ef141-571c-454a-9be0-987945adca4a@proxmox.com> Date: Tue, 7 Oct 2025 17:05:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Wolfgang Bumiller References: <20251003085045.1346864-1-d.csapak@proxmox.com> <20251003085045.1346864-8-d.csapak@proxmox.com> <897f41d8-2337-423d-a128-0252056b936b@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1759849511019 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.025 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 Subject: Re: [pbs-devel] [PATCH proxmox-backup 6/6] api: admin: datastore: implement streaming content api call 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 Cc: 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" Am 07.10.25 um 16:31 schrieb Wolfgang Bumiller: > Module level sounds nice in theory, and *could* look fine. Great, so we agree on the essentials. > I'd definitely love undo the export mess we have, but as it is now, > module level imports_granularity would be an *absolute nightmare* for > our code base, while for Item level it wouldn't matter, it would produce > the least friction with git merges. With about 100 to 1k of use statement lines at the top of a lot of files though. FWIW, for better merge conflict handling one can also use language aware tooling like mergiraf [0] as git merge driver. Getting a more organized module export has more benefits than just being able to use the module import level granularity in rustfmt (once it's stable). So if mergiraf delivers what it promises, I'd that as better stop-gap until we get around to start an organized effort to cleanup that export mess we currently got. [0]: https://mergiraf.org/ _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel