@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 Permalink: https://openzfs.topicbox.com/groups/developer/Td66d70a086ae5a9e-M7e4fcf5b2ee0ed9b20cb5432 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
