On 9/3/13 12:24 PM, Cristian Rodríguez wrote:
El 03/09/13 11:53, Jeff Mahoney escribió:
As I said then, the point isn't to take away functionality from anyone. If we have the ability to enable it in YaST (with a warning) or do it automatically (with a warning) if the features are already enabled on an older file system, nobody's lost anything. The point is that it will prevent users from losing their file systems using a feature set that hasn't been well tested.
It's great that you want to try features out that we don't consider safe yet. That's how we get bug reports that we can use to improve and further gauge the quality of a particular feature set. I just don't think that /all/ openSUSE users want to have that particular experience without knowing what's up beforehand.
Jeff, I do not object to the idea of warning people that certain features are unstable or dangerous a log message: "btrfs warning: FOOBAR is unstable".. will suffice in achiving this result. what I do strongly object is this pervasive tendency to add SUSE specific flags that are not documented anywhere else other than probably a wiki page or the openSUSE documentation, has distribution specific semantics,is not in upstream plus will cause confusion and increase the load of volunteers that answer questions in mailing list and the forums.
Your approach is favoring the experienced user over the inexperienced user, which can be reasonable especially if that's where we want to focus as a project. But it's dangerous when you also suggest a completely unintuitive method of informing the user. Nobody checks the log after successfully mounting a file system to see if there were any warnings. Documenting that in the release notes as a "best practice" isn't going to fly either. People do check the log when something unexpected happens and that's why we issue a message like the following when we reject a mount with immature features: "btrfs: compression is not supported, load module with allow_unsupported=1" (We can change the wording of that for openSUSE so that it reads "compression is considered an immature feature, load module with allow_unsupported=1".) I'm not sure many users will be comforted by being asked if they see a warning in their log after they've used an immature feature and discovered the hard way why it's considered immature. That's why I think an automated approach during upgrade and a yast checkbox to allow unsupported features is the way to go. Experienced users still get the full feature set to play with. Users with existing file systems with immature features enabled get to continue using them[1]. Inexperienced users get a reasonable picture of what is considered mature and what isn't and enjoy better data safety as a result. I'd prefer a better name than "allow_unsupported" but since this feature comes from SLES, it's better to use the existing name than to introduce another incompatibility.
This makes sense for SLE where you only want to support things known to be production quality and therefore reducing the number of support incidents. in the openSUSE land will only cause confusion (pretty much like the "unsupported module flag")
The unsupported module flag was removed from openSUSE for exactly that reason. This case is different, though. This isn't about managing support cases. Well, I suppose it is, but that's a nice side-effect of ensuring that users expecting that their file system uses only mature features have their expectations met. The naming of the module option is independent of the meaning of the option. That's largely a messaging thing and in the UI, it should be presented as "unstable" or "immature" feature enablement rather than trying to make a distinction over supportability. -Jeff [1] With the exception of file systems not in /etc/fstab. -- Jeff Mahoney SUSE Labs