From Fedora Project Wiki

Line 50: Line 50:
* Musicians and music producers
* Musicians and music producers
* Documentation writers
* Documentation writers
'''Case 4: System Admin'''
TBD





Revision as of 10:42, 7 March 2014

Warning
This page is work in progress.

Fedora Plasma PRD

Mission statement

The WG aims to create a reliable, user-friendly and powerful operating system for laptops and PC hardware, leveraging the KDE Plasma Workspaces technologies. The system will be primarily aimed at providing educational and scientific software but should be attractive to a range of power users and content creators - people who build our community. And also as a platform for development of modern KDE and Qt applications - even in mobile space. The product will be built upon the foundations of the Fedora Base product and closely cooperating with the Workstation WG on the technical aspects and (inter)compatibility.

The Fedora Plasma WG will have a special focus on providing a platform for everyone working on and with the KDE Plasma Workspaces and to be a possible basis for other interested Fedora spins (e.g. the Scientific spin). This document is not meant to be an exhaustive list of what potential users can or will use the Fedora Plasma for, but rather outline the WG's development priorities and overall goals.

Why Fedora Plasma

Plasma is one of the four fundamental states of matter [1], complementary to other three Fedora products and physics term. Fedora Plasma Product aims on scientists, students and teachers. We believe in that Fedora could serve as number one educational and scientific distribution - knowledge is our future. Last but not least - Plasma Desktop is a name of the technology powering this product, developed by the amazing KDE Project community.

We want the Fedora Plasma platform to be attractive to a range of users, developers and professionals alike -- from hobbyists and students to developers working in corporate environments.

This is meant to be a living document which evolves along with the project and which can be changed as time goes on by the working group.

Target Audience

Case 0: Power user

  • Great configurability and extensibility
  • Sane defaults, not forced choices

Desktop Apps: Up to date desktop with email client, browser, productivity suite, messaging, and a complete set of desktop apps and utilities to make this system the user's only computer.

Case 1: Scientist

  • Numerical tools
  • Typesetting
  • Data Analysis, statistics & visualizations

Case 2: Student/Teacher

Engineering/CS student who needs a personal system for software classwork and personal projects. Software class work may require particular tool chain versions. Tries out new versions of open source applications when released. Uses computer to play games. Ability to play 3D games from commercial publishers distributing games for Linux. Multiple developer environments i.e. school standard for class work, latest tools for personal use.

Case 3: Developer

  • Personal development system for an independent software developer doing contract work or developing apps for a new opportunity.
  • Software developer working on an individual project or coordinated small team. DevOps.
  • Software developer working on a large, coordinated project in a large organization.

Programming Environment: web languages and tools, open source databases, IDE, Compilers, debug tools, performance monitoring Easy to configure Virtual Machines for testing software. Support for enterprise login. Generally a single development environment with the latest development tools.

Case 4: Content Creator

  • Visual artists (graphics, illustration, drawing, rendering, ...)
  • CGI artists
  • Musicians and music producers
  • Documentation writers


Other users

While the power user desktop is the main target of this system and what we try to design this for, we do of course also welcome other users to the Fedora Plasma product. In fact many of the changes and improvements we expect to implement for the above use cases will be equally beneficial to other user segments, for instance our plans around multi-screen handling and improved terminal functionality should also be highly beneficial to a system administrator. Or the work we are doing to provide a high performance graphics workstation would be useful to people who want a linux gaming PC. Or a student who just want a system with a productivity suite to write their papers will of course get benefit from the fact that we do ship a good productivity suite. We will welcome feedback and request from all our users and try to accommodate it as long as it doesn't negatively impact our developer target group and we have people available who have the time and ability to work on the requests.

Overall plans and policies for the product

Technical goals and design principles:

  • Robust Upgrades

Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Plasma. Upgrade should be a safe and process that never leaves the system needing manual intervention.

  • Encapsulation of development environments

In general, development environments should allow targeting deployment environments that are different than the operating system itself, and an upgrade to a newer version of Fedora Plasma should not mean that a coding project needs to be modified to work with new versions of libraries and runtimes.

  • Quality releases

We want to focus on engineering practices that ensures that the core product offered is of the highest quality possible. This includes keeping the core test matrix as small as possible a high degree of testing automation and collaborating with upstream to increase general test coverage of core modules.

  • 3rd party software

Fedora Plasma will work to ensure that 3rd party software has a stable underlying OS with a known set of APIs/services that ISVs and other developers can rely on for their software. Fedora will not include any non-free software by default or host any non-free software in our repositories.

  • Fedora ecosystem integration

While the desktop will have a different target than the Server and Cloud images, it is still important that the 3 variations share technology and infrastructure. The systems will all be RPM based and while for instance the open source databases will be packaged primarily with the Server in mind we want to be able to pull them into the developer desktop too.

  • Work towards standardizing and unifying the Linux desktop space

We want to use and develop technologies that can be widely shared with the rest of the community and we want to allow developers to use the tools they prefer for their application development yet make them all feel like a natural fit into our integrated desktop experience. This would include items like themeing and making sure we offer a consistent accessibility story across different development toolkits. The product will reach out and collaborate with the Fedora Design team and other relevant groups on such items.

  • Develop application guidelines and designs

The working group will develop guides and style recommendations for applications that target the desktop. These guidelines will be mandatory for the core apps that are specifically developed for the desktop, but 3rd party software developers will be encouraged to follow them too.

  • Delivery Mechanism

The Fedora Plasma Product plans to leverage the existing image/repo delivery mechanisms already present in Fedora. This would possibly include a live USB image and/or ISO image of the Product.

Core Platform Components

The WG will define a set of packages that are considered required be installed in order for the system to qualify as a Fedora Plasma.

These installed packages will together form the basis of the API and service promises the system makes to 3rd party developers.

The WG will also define two set of requirements, one for anything that is to be considered for inclusion in the core platform components list and one for optional packages. This will include a requirement to support specific system services and libraries, for example the working group might make it a requirement that any software that wants to be part of Fedora Plasma can run against Wayland or directly output sound to Pulse Audio.

The working group will also specify policies in terms of branding, themeing and desktop graphics, although these items will of course need to be in line with the overall Fedora branding guidelines and styles.

Work Model

We will at any given time try to have one major engineering effort underway for the Fedora Plasma. The definition of a major engineering effort is something that requires changes in a wide set of packages and tools. At the same time we will be working on smaller projects to improve various aspects of the distribution and also setting things up to be ready for the next major effort. We will try to announce and plan these things well in advance, by putting up a public timeline. Of course resources and changing market conditions might make changes to the plans necessary on an ongoing basis.

Other tasks for working group

The working group will also be responsible for on-going feedback and suggestions on release schedules, based on collaboration with upstream components, the other Working Groups and FESCo, and Fedora Infrastructure. The working group will also regularly meet with a designated representative of Red Hat to discuss how Red Hats product and development plans will affect the Fedora product development and resource allocation.

Packaging for Fedora Plasma

The working group hopes and expects that there will continue to be a wide range of software, packaged and maintained by the wider Fedora community, software that will available for install through the desktop software installer. A lot of this software might not have any direct relevance to the main goals of the product or working group, but that is not a problem or something that the working group wants to discourage. No software will be blocked from being packaged as long as it doesn't break any part of the core desktop system upon install.

Document Approval