| |
@@ -5,6 +5,27 @@
|
| |
|
| |
This document describes the process for promoting an existing Fedora deliverable to Edition status.
|
| |
|
| |
+
|
| |
+
|
| |
+ == What makes an "Edition"?
|
| |
+
|
| |
+ A Fedora Edition:
|
| |
+
|
| |
+ * addresses a distinct,
|
| |
+ relevant,
|
| |
+ and broad
|
| |
+ use-case or userbase
|
| |
+ that a Fedora Edition is
|
| |
+ not currently serving;
|
| |
+
|
| |
+ * is a long term investment
|
| |
+ for the Fedora Project; and
|
| |
+
|
| |
+ * is consistent
|
| |
+ with all of
|
| |
+ Fedora's foundations.
|
| |
+
|
| |
+
|
| |
== Prerequisites
|
| |
|
| |
* The candidate Edition must be backed by a team that holds regular public meetings
|
| |
@@ -25,12 +46,16 @@
|
| |
|
| |
== Process
|
| |
|
| |
- When all of the prerequisites have been met, the team submits promotion as a System-Wide Change.
|
| |
+ When all of the prerequisites have been met,
|
| |
+ and approved by the Fedora Council,
|
| |
+ the team submits promotion as a System-Wide Change.
|
| |
This ensures that Release Engineering, FESCo, and the community at large have the opportunity to provide input.
|
| |
It also implies that the promotion may be delayed to the next release if the appropriate supporting pieces are not in place by the Beta or GA freezes.
|
| |
|
| |
Prior to submitting the Change proposal, the following tasks should be completed:
|
| |
|
| |
+ * *Approval from the Council.*
|
| |
+ File a ticket and participate in related discussion.
|
| |
* *Review test cases and release criteria with QA.*
|
| |
The QA team will draft test cases and release criteria based on the PRD.
|
| |
However, the Edition team must verify that these are valid.
|
| |
See https://pagure.io/Fedora-Council/tickets/issue/382 and https://fedoraproject.org/w/index.php?title=Fedora.next&oldid=391234#What_makes_a_.22product.22.3F