== Overview ==
Back at the beginning of the Fedora.next initiative when we created the working groups, we tasked them with creating "Product Requirement Documents" (PRDs) to guide the development of each of these core groups. * https://fedoraproject.org/wiki/Workstation/Workstation_PRD * https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Doc ument * https://fedoraproject.org/wiki/Cloud/Cloud_PRD?rd=Cloud_PRD * https://fedoraproject.org/wiki/Server/Product_Requirements_Document
More than a year has passed and the Fedora Council feels that it's a good time to give another pass at these documents and re-align them, both with the current reality and the next phase of this process. Additionally, the Council feels that it would be good to perform such a re-alignment and update each year.
This year, we have set an admittedly short deadline: the PRDs need to be updated and ready for review on June 12th (11 days from now). In the future, this will be scheduled further in advance and with more time to address it (see below).
== What do we have to do? == There are two things that should be done during a PRD refresh exercise (though their implementation is left as an exercise to the Working Groups).
1) Review the PRD for plans that are outdated. Some examples: * Support for CPU architectures that no longer make sense * Features that have been de-prioritized or indefinitely deferred * References to technology that has been replaced or obsoleted 2) Add new plans and requirements for the evolving technology. Some possible examples: * Fedora Cloud commits to producing an implementation of the Nulecule Container Specification * Fedora Server commits to producing Server Roles that can be migrated to a Fedora Atomic deployment * Fedora Workstation integrates seamlessly with a self- or publicly -hosted ownCloud deployment.
(Optional): The PRD review period may be an excellent time for those WGs with persistent membership to evaluate whether it is time to refresh the WG membership as well.
== Future PRD Refreshes == Starting at Flock 2016 (yes, *next* calendar year), each working group will have a workshop scheduled at Flock to go over its PRD and plan for the following year. Note: because Flock generally falls between Alpha and Beta of a Fedora release, all PRD planning is presumed to be a directive for Fedora N+1 and N+2 at that time, not retroactively applied to the current release.
The workshops are expected to cover the majority of the update, and then they will be brought back to the respective mailing lists for further review before being due to the Council one month after Flock concludes.
----- Original Message -----
From: "Stephen Gallagher" sgallagh@redhat.com To: "Server SIG" server@lists.fedoraproject.org, desktop@lists.fedoraproject.org, devel-announce@lists.fedoraproject.org, cloud@lists.fedoraproject.org Sent: Tuesday, June 2, 2015 2:03:44 AM Subject: Fedora.next PRD refresh
<snipped>
== Future PRD Refreshes == Starting at Flock 2016 (yes, *next* calendar year), each working group will have a workshop scheduled at Flock to go over its PRD and plan for the following year. Note: because Flock generally falls between Alpha and Beta of a Fedora release, all PRD planning is presumed to be a directive for Fedora N+1 and N+2 at that time, not retroactively applied to the current release.
The workshops are expected to cover the majority of the update, and then they will be brought back to the respective mailing lists for further review before being due to the Council one month after Flock concludes.
+1. This is a good idea and it is important to push products toward on the right way. I am just curious why it would not be held from this year? because of time constrains?
Rgds, Tuan
On Tue, 2015-06-02 at 09:55 +0700, Truong Anh Tuan wrote:
----- Original Message -----
From: "Stephen Gallagher" sgallagh@redhat.com To: "Server SIG" server@lists.fedoraproject.org, desktop@lists.fedoraproject.org, devel-announce@lists.fedoraproject.org, cloud@lists.fedoraproject.org Sent: Tuesday, June 2, 2015 2:03:44 AM Subject: Fedora.next PRD refresh
<snipped>
== Future PRD Refreshes == Starting at Flock 2016 (yes, *next* calendar year), each working group will have a workshop scheduled at Flock to go over its PRD and plan for the following year. Note: because Flock generally falls between Alpha and Beta of a Fedora release, all PRD planning is presumed to be a directive for Fedora N+1 and N+2 at that time, not retroactively applied to the current release.
The workshops are expected to cover the majority of the update, and then they will be brought back to the respective mailing lists for further review before being due to the Council one month after Flock concludes.
+1. This is a good idea and it is important to push products toward on the right way. I am just curious why it would not be held from this year? because of time constrains?
We had already communicated to several groups that we wanted to refresh it before Alpha this cycle (Cloud in particular had moved far from its original PRD). We decided to keep that plan and adjust the future.
On Tue, Jun 02, 2015 at 09:08:05AM -0400, Stephen Gallagher wrote:
I am just curious why it would not be held from this year? because of time constrains?
We had already communicated to several groups that we wanted to refresh it before Alpha this cycle (Cloud in particular had moved far from its original PRD). We decided to keep that plan and adjust the future.
And, yeah, it's really too late to be putting more demands on this year's Flock.
Proposed changes:
Under Target Audience, General, after "Desktop apps should be sufficient to make this system the user's only computer," insert a new paragraph: "Developers are not expected to be familiar with the terminal. Users should not be required to use the terminal for essential tasks, including software development."
Under Target Audience, Other users, replace the first sentence with "While our focus is on creating a top-class developer workstation, our developer focus will not compromise the aforementioned goal to be a polished and user friendly system that can appeal to a wide general audience." Replace the final sentence with "We will welcome feedback and requests from all our users and will consider accommodating it when possible."
Under Develop application guidelines and designs, replace the entire section with "Fedora Workstation follows the GNOME Human Interface Guidelines. These guidelines are mandatory for applications that are installed by default. Third-party software developers are encouraged to follow them too."
Under Delivery Mechanism, replace the final sentence with "The product will be offered for installation via either live or netinstall ISO images."
Under Packaging for the Workstation", remove the sentence "No software will be blocked from being packaged as long as it doesn't break any part of the core workstation system upon install," or remove the packaging committee that enforces our quality standards. :)
Comments on other sections:
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 Workstation. Upgrade should be a safe and process that never leaves the system needing manual intervention." We violated this rule quite badly for the upgrade from F21 to F22. For example, the default font on ttys is different for fresh installs than for upgrades, and fresh installs use xorg-x11-drv-libinput whereas upgrades do not. I still agree with Owen that this is a desirable goal, so maybe we can keep it as-is and just accept that we haven't made progress on it yet.
Better upgrade/rollback control: We haven't really made progress on this, either.
I want to add a section specifying that regular updates should follow similar QA policies as releases (we can clump the updates together into monthly updates packs), but I guess that might be controversial.
I'm not sure about the Work Model section. It doesn't seem to accurately reflect how we operate.
"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." I guess we don't need to remove this per se, since Christian kind of fills that role, but it also doesn't seem to accurately reflect how we operate.
on Thu, Jun 04, 2015 at 09:41:15AM -0500, Michael Catanzaro wrote:
Proposed changes:
Under Target Audience, General, after "Desktop apps should be sufficient to make this system the user's only computer," insert a new paragraph: "Developers are not expected to be familiar with the terminal. Users should not be required to use the terminal for essential tasks, including software development."
Under Target Audience, Other users, replace the first sentence with "While our focus is on creating a top-class developer workstation, our developer focus will not compromise the aforementioned goal to be a polished and user friendly system that can appeal to a wide general audience." Replace the final sentence with "We will welcome feedback and requests from all our users and will consider accommodating it when possible."
Under Develop application guidelines and designs, replace the entire section with "Fedora Workstation follows the GNOME Human Interface Guidelines. These guidelines are mandatory for applications that are installed by default. Third-party software developers are encouraged to follow them too."
Under Delivery Mechanism, replace the final sentence with "The product will be offered for installation via either live or netinstall ISO images."
Under Packaging for the Workstation", remove the sentence "No software will be blocked from being packaged as long as it doesn't break any part of the core workstation system upon install," or remove the packaging committee that enforces our quality standards. :)
I edited these changes (with slight tweaks here and there) into the PRD. I didn't see any objections here or other suggestions.
https://fedoraproject.org/w/index.php?title=Workstation%2FWorkstation_PRD&am...
Comments on other sections:
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 Workstation. Upgrade should be a safe and process that never leaves the system needing manual intervention." We violated this rule quite badly for the upgrade from F21 to F22. For example, the default font on ttys is different for fresh installs than for upgrades, and fresh installs use xorg-x11-drv-libinput whereas upgrades do not. I still agree with Owen that this is a desirable goal, so maybe we can keep it as-is and just accept that we haven't made progress on it yet.
Better upgrade/rollback control: We haven't really made progress on this, either.
For upgrade, not necessarily rollback, there is some work underway AIUI to combine with Software/PackageKit. See devel@.
I want to add a section specifying that regular updates should follow similar QA policies as releases (we can clump the updates together into monthly updates packs), but I guess that might be controversial.
It would be if the specification doesn't come attached to an idea for finding testing cycles, since it's a significant additional QA effort.
I'm not sure about the Work Model section. It doesn't seem to accurately reflect how we operate.
"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." I guess we don't need to remove this per se, since Christian kind of fills that role, but it also doesn't seem to accurately reflect how we operate.
We talked about this in the meeting, IIRC. Christian does actually meet with folks this way.
Proposed changes:
Under Target Audience, General, after "Desktop apps should be sufficient to make this system the user's only computer," insert a new paragraph: "Developers are not expected to be familiar with the terminal. Users should not be required to use the terminal for essential tasks, including software development."
Under Target Audience, Other users, replace the first sentence with "While our focus is on creating a top-class developer workstation, our developer focus will not compromise the aforementioned goal to be a polished and user friendly system that can appeal to a wide general audience." Replace the final sentence with "We will welcome feedback and requests from all our users and will consider accommodating it when possible."
Under Develop application guidelines and designs, replace the entire section with "Fedora Workstation follows the GNOME Human Interface Guidelines. These guidelines are mandatory for applications that are installed by default. Third-party software developers are encouraged to follow them too."
Under Delivery Mechanism, replace the final sentence with "The product will be offered for installation via either live or netinstall ISO images."
Under Packaging for the Workstation", remove the sentence "No software will be blocked from being packaged as long as it doesn't break any part of the core workstation system upon install," or remove the packaging committee that enforces our quality standards. :)
Comments on other sections:
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 Workstation. Upgrade should be a safe and process that never leaves the system needing manual intervention." We violated this rule quite badly for the upgrade from F21 to F22. For example, the default font on ttys is different for fresh installs than for upgrades, and fresh installs use xorg-x11-drv-libinput whereas upgrades do not. I still agree with Owen that this is a desirable goal, so maybe we can keep it as-is and just accept that we haven't made progress on it yet.
Better upgrade/rollback control: We haven't really made progress on this, either.
I want to add a section specifying that regular updates should follow similar QA policies as releases (we can clump the updates together into monthly updates packs), but I guess that might be controversial.
I'm not sure about the Work Model section.
"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." I guess we don't need to remove this per se, since Christian kind of fills that role.
desktop@lists.fedoraproject.org
-
Matthew Miller -
Michael Catanzaro -
Paul W. Frields -
Stephen Gallagher -
Truong Anh Tuan