On 8 September 2016 at 00:25, Gregor Kopka <[email protected]> wrote: > Tying that option name change to a system tuneable > (zfs.rollback-recursive-syntax) which can be used to walk through the > steps of the proposal > (as-is|deprecate-r|deprecate-r-and-warn|remove-r|r-is-really-recursive-now) > with a sane default (as-is|deprecate-r|deprecate-r-and-warn). > > Then someone who read the changelog/documentation can opt to set the > tuneable to live in a better future while someone who dosn't want it > (for whatever reason) can set it to freeze the option naming to an > eternal past and the curious can set it to test if a system will bomb > somewhere. And should, some day, the decision be made to 'officially' > cure this interface inconsistency it can be done by changing the default > (without breaking scripts for people who read the documentation).
People that read the documentation already have all of the information they need with the options as they are today. If there's any argument for changing an existing flag, I think it's that people who _don't_ read the documentation might be less likely to get behaviour that they don't expect. Rollback is such a nuanced operation, though, that I don't really expect any usage without consulting the documentation will entirely align with intuition. Having a tuneable that changes the behaviour of the flags means that operators and tool builders will need to deal not _just_ with the passage of time, or the release of new versions of operating systems, but also with the dynamic configuration of every system at run time. This is likely to cause much more pain than the relatively minor (and arguably subjective) problem of a potentially unexpected choice of flag. > Nevertheless, I still don't see the need for later generations (zfs = > futureproof) encountering the fallout of a bad decision of someone > (possibly) long dead by then, and though I would like to see the change > sooner than later the 'reasonable time' I though about was more towards > years to give time to adapt to the change. At this point, the "-r" and "-R" flags to "zfs rollback" appear to have been in the ZFS code since integration in 2005. If we were to deprecate this flag -- which I don't think we should! -- we would arguably need to wait at _least_ another 11 years before removing it, to give people as much time to notice its passing as they had to internalise its arrival. Then, similarly, another 11 years after that before replacing it with some other functionality. It seems more practical to accept that it is by now a committed interface and focus on new flags and features. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org ------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
