He could release a patch that can be pulled by the people that need it.
If you’re using experimental file systems, I’d expect you to be pretty competent in being able to hold your own in a storage emergency, like compiling a kernel if that’s the way out.
Yeah the argument breaks down for me -- this project is so stable and mainstream, it's being used by a huge community of technically lay Linux users who can't boot a home built kernel temporarily to run a data recovery?
And yet simultaneously, it's a bleeding edge experimental system that needs a license to break the Linux rules on account of its experimental nature?
I just don't see how there's a critical mass of casual users that can't handle a complicated data recovery (as in, i won't generally believe this to be true, and if it is, those users should probably stick with something more mature), AND the system is still so experimental and developing so quickly that introducing features outside the merge window should be considered uncontroversial (or even necessary, as Kent seems to sometimes argue)
The inconvenience of this process is also addressed by the dev, as is the different definition of experimental that you're using (though your expectation re kernel doesn't follow even without the mismatch in definitions)
The kernel, even its bugs, should be stable (in that they shouldn't change unless it happens the correct way). If not, it starts introducing unexpected issues to users.
If someone's testing against these versions, adding their fixes and patches, stuff like this will break things for users. He can't assume all users will be regular desktop users, even on an experimental area of the code.
Things like 'RC' have meaning. Meaning that has been there for years. He can develop on a separate tree and users that want it can use it. This is used all over.
> The inconvenience of this process is also addressed by the dev, as is the different definition of experimental that you're using (...)
The only aspect of "experimental" that matters is what it means to the release process. If you can't meet that bar then debating semantics won't help either.
And by the way, the patch thread clearly stresses a) loss of data, b) the patch trying to sneak under the maintenance radar new features. That is the definition of unstable in anyone's book.
> Experimental has no defined meaning with respect to the release process.
Nonsense. And to make matters worse, you're commenting as if trying to sneak features in bug fixes late on the release process has no impact on quality assurance.
If you’re using experimental file systems, I’d expect you to be pretty competent in being able to hold your own in a storage emergency, like compiling a kernel if that’s the way out.
This is a made up emergency, to break the rules.