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

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 07/11/2023 um 09:26 schrieb Wolfgang Bumiller:
> On Tue, Nov 07, 2023 at 08:55:01AM +0100, Thomas Lamprecht wrote:
> 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

my sentence wasn't finished, sorry, what I wanted to say it's easier to
add ordering later, if we really must due to overwhelming user feedback,
than vice versa (albeit simulating the removal of it via UI could always
be done, would have it's own confusion potential though).

> options following a similar mechanic.

same options should follow same logic, and we have such filters for
tasks and (in development) guests for bulk-actions, and also
notifications matches (also in development) and to those we
should align to, as they are (partially already) present in the UI,
that's why I also value Lukas' opinion here, he spent more time with
such higher-level matching/grouping/filter stuff already.

If ordering, then it should be at least encoded explicit, the order
of sub-properties in a config isn't mattering for anything IIRC.

>>
>>> 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... 🙄

you know that there can be more than one issue at the same time..
Again, ordering is *another* dimension, just like inversions and grouping
via parenthesis is, adding more of them is never going to make things
easier, but sure, more expressive and often turing complete, depending
on the use case that can be great or not – here it's not.

> 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.

Yeah sure, it's a given that one cannot make all users content at the
same time

> 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.

The defaults should IMO be unrelated to the existence of entries for
the other thing, and be:

Include: All
Exclude: None

> 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... 🤷
> 

What part do you mean exactly here?

>>> 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

definitively about the word "much" ;-)