On Mon, Feb 10, 2020 at 09:05:27PM -0700, John M. Harris Jr wrote:
On Monday, February 10, 2020 12:03:25 PM MST Robbie Harwood wrote:
> "John M. Harris Jr" <johnmh(a)splentity.com> writes:
> > On Saturday, January 25, 2020 2:52:05 PM MST Chris Murphy wrote:
> >> Question and (pre)proposal:
> >> Can Fedora converge on a single swap-on-ZRAM implementation, and if
> >> so, which one? Fedora Workstation WG wants to move to swap-on-ZRAM by
> >> default in Fedora 33, and the working group needs to pick something
> >> soon.
> > Using swap on zram disables the ability to hibernate, making it a
> > non-starter for many users. If this is going to be thrown into
> > anything, the user needs to be asked whether they want it or not in
> > the installer, otherwise you're just taking away features.
> I thought you told me that the workstation group considers hibernation
> unsupported? (id:2368390.zU9c8gpsLA@marvin.jharris.pw)
They do, but that doesn't negate the fact that it is actually supported (you
can hibernate your system), and using swap on zram outright breaks hibernation
(for obvious reasons).
This discussion is mixing up two different interpretations of meaning
- Supported, as in, "this use case is in scope & is a release criteria"
- Supported, as in, "the functionality works from a technical POV"
Thus since hibernation is declared an unsupported use case, the fact that
it might happen to work from a technical POV is merely good fortune and is
not required to stay that way, even if some people might be using that now.
IOW, if swap-on-ZRAM benefits core supported use cases, then it can be
acceptable to break unsupported use cases even if the latter currently
work at a technical POV. Enabling this kind of trade off to be made is
precisely why it is beneficial to define the scope of a product for
what is supported vs unsupported.