[pbs-devel] [PATCH proxmox-backup 1/3] fix #4315: jobs: modify GroupFilter so include/exclude is tracked

[Wolfgang Bumiller]

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