On 9/3/13 9:47 PM, Cristian Rodríguez wrote:
El 03/09/13 13:26, Jeff Mahoney escribió:
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.
Ok, Jeff, since I am a reasonable person I will concede that your argument is reasonable and workable.
I still do not like the idea of SUSE specific parameter but there are much bigger fish to catch around to continue this argument.
As far as SUSE-specific patches go, it's minor. Realistically, we could push it to a last-line file in the Makefile if we had to. For now, it's integrated. The maintenance load is pretty minimal.
Just some questions:
- How and who will determine what it is stable/production-ready?
As I mentioned in another thread, the answer is essentially the "SUSE Labs Storage and File System Team" with a ton of input from our users. The trust has to start somewhere, and it seems that an obvious place to start would be the people maintaining the code for the release.
- How will you deal with the parameter going away ? I ask because the kernel moves at the pace of a cheetah and YAST like a old turtle. suggesting that a configuration option has to be added to YAST turns a kernel implementation detail into an userspace interface. does parameter stays forever as as no-op when everything becomes "stable" ?
Short answer: yes. We basically do need to maintain its existence forever. We pretty much need to do that anyway for compatibility with SLES. Ideally it will eventually become a no-op. Eventually it may be re-used to describe the maturity of other features. -Jeff -- Jeff Mahoney SUSE Labs