#115 F32 planning
Closed: Fixed by aday. Opened by aday.

F31 is out the door so we should think about what the WG wants to achieve for F32. This is mostly a discussion topic, but we could use it to generate actions, such as flagging particular issues that we want to prioritise, or scheduling events or activities for this development cycle.

WG members: please share any thoughts that you might have on what you'd like us to achieve for the next Workstation release. Now would also be a good time to review our open issues, with a view to selecting priorities for F32.


If this is going to be a wishlist: I'd like Firefox to learn to use OpenH264 for video playback. It's the only remaining flaw in our plan for out-of-the-box media playback support, and it's a pretty big one.

For my own part, I think I'd like the WG to use this cycle to develop its role.

I'd like to see the WG have greater focus on its core functions, such as deciding which software makes up the Workstation. In this regard, I'd like to see more analysis and review of what's included in the workstation and why. It would also be interesting to think about what processes we want around this.

I'd also like to see the WG take greater ownership of the release and actively participate in making it a success. That could involving pushing for certain features to land, advertising or supplementing QA and testing, ensuring that marketing has what it needs to promote F32 Workstation, and so on.

Enable low memory conditions handler by default.

  • Enable low-memory-monitor by default but only without OOMK triggering support (it has a critical bug https://gitlab.freedesktop.org/hadess/low-memory-monitor/issues/8 and Bastien fails to see the problem)

  • Enable earlyoom by default to handle low MemAvailable and SwapFree. earlyoom is a stable and well-established application.

PSI-based process killing should not be used by default, because this topic is still poorly understood and we don’t know what thresholds are desirable for most users: it’s hard to find good default values.

Enable low memory conditions handler by default.

Can you post this comment in issue #98?

Some key dates from the release schedule:

  • 2019-12-31: change proposal deadline
  • 2020-02-11: change completion deadline
  • 2020-02-25: changes code complete & beta freeze
  • 2020-03-17: beta target date
  • 2020-04-21: F32 release target date

For F32 it would also be good to see progress on some of the big ticket items we have, like #54 and #82.

The WG discussed this issue yesterday. Specific issues and features we're interested in pursuing for F32:

  • Broadcom wireless: #116
  • Unable to see disk usage: #101
  • Disk partitioning and encryption: #54 and #82
  • Low memory monitoring: #98

(This isn't an exclusive list.)

The first two are outstanding pain points. The third is a question of clarifying what the options are and what our direction of travel is (which will potentially help us to know how to handle other issues/questions). The fourth item is an area where we've seen progress and could make a good feature.

There's also interest in the WG doing stewardship of the release, including:

  • Identifying and pursing a good set of features for the release
  • Ensuring that changes are communicated to marketing
  • Conducting a review of which apps are included by default

Actions:

  • WG to discuss #54 and #82 in a meeting, to discuss the plans and identify options/constraints
    • Off the back of this, return to #101 and figure out a design
  • Add the app review to the schedule (I think we agreed around the time of the beta)
  • Figure out next steps for low memory monitoring: do we need to track and encourage adoption by apps? Is there anything we can do to leverage this work without patching the world?
  • Do something for the marketing item... got any suggestions here, @chrismurphy ?

I've created issues in Taiga for each of the action items, so I think that this issue can be closed.

Metadata Update from @aday:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/workstation/tickets/issues/115

Please continue any further discussion there.

Metadata