If the primary purpose is to enforce a consistent baseline of behavior
on all platforms, letting you override those baselines defeats the
point, because then you need to explicitly specify it all the time in
case someone decided they knew better.

Adding additional ones seems like a debatable tradeoff of value
(though I agree that if you need to have the config for an -o
features=custom123 in order to import the pool, Something Is Very
Wrong With The Design), but overriding the builtins makes this
valueless for people trying to produce consistent results on different
systems.

- Rich

On Wed, Mar 27, 2019 at 1:17 PM Gregor Kopka
<[email protected]> wrote:
>
> @ahrens: Having an additional user-defined feature set list dosn't make 
> sense, it doubles the coding effort (having to check hardcoded and user 
> defined ones).
> It would also open the question of who takes precedence: the user ones (as I 
> would expect from OS software) or you enforcing your hardcoded perspective on 
> what's 'right' on your users (closed source style)?
>
> @sef (in the video) seems to think the latter being a good idea (so users 
> can't 'shoot themselves in the foot') - I strongly object and ask to 
> reconsider this stance.
>
> Making it as a text file in the first place is only once the effort (code 
> wise), text files get updated nicely using the usual package managers (giving 
> the user the option to preserve his modications) and avoids paternalism. It 
> would also give your users the ability to easily deal with the things you 
> don't seem want to (root pool) to give them QoL, simply by adding a 
> definition that works for them.
>
> Make the code interprete a features definition not on the system as empty (no 
> features activated), so importing a pool with a custom definition in a system 
> that dosn't know it will make sure that it'll be left alone by an accidental 
> zpool upgrade.
> openzfs / openzfs-developer / see discussions + participants + delivery 
> options Permalink

------------------------------------------
openzfs: openzfs-developer
Permalink: 
https://openzfs.topicbox.com/groups/developer/Td66d70a086ae5a9e-Mf39e1243fcabf22b4c6c8cb2
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription

Reply via email to