From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <w.bumiller@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 5DE9B9F8EA for <pbs-devel@lists.proxmox.com>; Tue, 7 Nov 2023 09:26:51 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 374C21EE58 for <pbs-devel@lists.proxmox.com>; Tue, 7 Nov 2023 09:26:51 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pbs-devel@lists.proxmox.com>; Tue, 7 Nov 2023 09:26:50 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 6702E46E4E for <pbs-devel@lists.proxmox.com>; Tue, 7 Nov 2023 09:26:50 +0100 (CET) Date: Tue, 7 Nov 2023 09:26:49 +0100 From: Wolfgang Bumiller <w.bumiller@proxmox.com> To: Thomas Lamprecht <t.lamprecht@proxmox.com> Cc: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> Message-ID: <25pvugernovezgv6u7qw7xiucsfkvbieizj7cija7aftln74ww@fopnbametx46> References: <20231023154302.2558918-2-p.hufnagl@proxmox.com> <54f6b050-02ce-4443-a3f3-e28ee2b875bd@proxmox.com> <fb844e0d-26ad-4a7c-a8e5-5d99c29c7b01@proxmox.com> <d9a94b91-e13a-470e-87c9-a600d7cb9d10@proxmox.com> <dc0cc081-ee54-4016-af3f-9a372faba9d1@proxmox.com> <69df7927-de20-4301-a785-2a57d53fcf2b@proxmox.com> <b42c40b6-b8f9-4269-9440-d527fb940b97@proxmox.com> <1b0eec17-d519-4d80-89f6-e08b9738fcd8@proxmox.com> <skraqtvbzlpulrr4u2joslsui7mhce2sichjefpnapbidspcjr@a3c4s3zmq7oy> <ae228735-6ea8-4f49-94f8-1da29c091c77@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <ae228735-6ea8-4f49-94f8-1da29c091c77@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.102 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-backup 1/3] fix #4315: jobs: modify GroupFilter so include/exclude is tracked X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion <pbs-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/> List-Post: <mailto:pbs-devel@lists.proxmox.com> List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Tue, 07 Nov 2023 08:26:51 -0000 On Tue, Nov 07, 2023 at 08:55:01AM +0100, Thomas Lamprecht wrote: > Am 07/11/2023 um 08:43 schrieb Wolfgang Bumiller: > > On Wed, Oct 25, 2023 at 05:45:11PM +0200, Thomas Lamprecht wrote: > >> Easier to understand is *much* cleaner though, any admin that changes > >> a simple include/exclude filter manually, e.g., reversing the order, > >> has no idea that the end result is completely different. > > > > I disagree that either of them is actually easier, and we already have > > order dependent include/exclude behavior in `.pxarexcludes` and on the > > order is an extra dimension that users need to take care when writing > these, so by that alone it's easy to state that not having that is > simpler (naturally one can make it way worse by doing a bad UI, but well, > just don't do that). > > And, we can always go for an order adhering model later I'm fine with either way in the end and think changing it later is worse. I'm just bringing this up thinking about consistency with other options following a similar mechanic. But sure, the pxar exudes aren't directly related as you stated later on. (Otherwise another similar mechanic would be in the pve firewall (and no, the way groups are translated to iptables rules is in no way a *fair* argument against ordering :-P)) (And yes, I know that one is not actually any easier either...) > > > CLI via `--exclude` when creating a backup with proxmox-backup-client. > > Which is not really good UX, the "find" core util, and similar consorts, > are exactly deemed as hard to understand as that implicit order matters > is making it harder for users, especially those without a programming > background (i.e., the majority of our users). Contrary to most tools, options come after the paths, you use single dashes for long options, use exclamation marks for inversion which used to get butchered by most shells with history expansion unless they recognize `find` themselves and parenthesis which don't work if you don't have spaces around them as they need to be actual separate parameters so you also need to watch for quotes... But sure, let's say the ordering is the issue... 🙄 The thing is, includes and excludes are conflicting statements, they must be resolved somehow, and in regular speech it's often by order. Which is not to say that people wouldn't get confused *regardless*, even if you use precise language. Then again, we also have a whole group of people insisting on always saying "including but not limited to...". I guess there's a point to that if we change the default depending on whether only includes or only excludes are present. Ultimately, *that* is the part that would confuse the hell out of me, personally, but sure, you'll end up dealing with both types of users anyway, so as long as that behavior is documented... 🤷 > > > Also, `.gitignore` also works like this, you have exclude and includes > > in order, the last match wins. > > Not sure if git should be used a pillar of good UX example, some would > even say that doing the opposite might be warranted in that case ;-P Well I mostly brought it up because it's what we used as a base to decide how the file based tools should work. > > > This makes it much easier to say things like "exclude 1-100 except 50", > > Not really, you just use "include 50" and if the remaining set is bigger > do "exclude 1-49; exclude 51-100;" and especially in bigger examples this > is easier to reason about for the standard users. Maybe we have different interpretations of the word "easier" :-P