Fedora Release Planning Process
The motivation for the planning process is to raise the visibility of planned changes and make coordination and planning effort easier. Otherwise it is nearly impossible to follow all changes happening in a big project such as Fedora. It must be easy to submit the change proposal as early as possible, before the change is implemented and even in the very early state of the idea, to gather community feedback and review.
The list of accepted changes, or change set, is used by different teams across the project. For example, the change set may be used to prepare external facing materials like release notes and release announcements.
Change owners are trusted and depended upon to highlight all relevant changes. Not noting important changes (whether due to oversight, different opinion of importance, or intentionally) breaks the Change process.
The planning process is an internal planning and tracking tool, and the final release is not required to reflect all proposed changes.
Fedora Engineering and Steering Committee (FESCo) defined two Change categories:
- Self contained changes
- Complex system wide changes
Self contained changes
A self contained change is a change to isolated package(s), or a general change with limited scope and impact on the rest of distribution/project. Examples include addition of a group of leaf packages, or a coordinated effort within a SIG with limited impact outside the SIG's functional area. Self contained changes could be used for early idea state proposals for wider and complex changes.
Public announcement of a new self contained change promotes cooperation on the change, and extends its visibility. Change owners may find help from the community or useful comments. These changes don't have to be thoroughly reviewed by FESCo. Based on the community review, the self contained change can be updated to the complex system wide change category, and the owner may be asked to provide more details and extend the change proposal page.
Complex system wide changes
Complex system wide changes involve system-wide defaults, critical path components, or other changes that are not eligible as self contained changes.
Fedora Packaging Committee
For changes that require modifications to the Fedora Packaging Guidelines:
- The person or group proposing the Change is responsible for providing a first draft of packaging guideline changes to the FPC.
- This draft does not need to be prepared prior to submitting the Change request, but must be complete by Branch point or FESCo might decide to apply the Contingency Plan.
For all changes you need to file an issue in releng pagure to check if your change requires Release Engineering involvement:
- You must work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.
- File a ticket with Release Engineering when working on your change and link to it in your change page, with a detailed breakdown of changes needed.
- Work must be substantially complete and in place by Branch point or FESCo might decide to apply the Contingency Plan.
For all changes you need to file an issue in Release Notes pagure once a Change is approved by FESCo.
- You must work with Fedora Documentation team to ensure that one week before Beta Freeze the Release Notes are ready for Beta Release.
- You must also work with the Fedora Documentation team on any changes in the Release Notes which might appear after the Beta Freeze.
If your Change may require trademark approval (for example, if it is a new Spin), file a ticket requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process; if the request receives at least three positive votes and no negative votes within an approved period, it is considered approved.
For Change-related trademark approval, the Council has decided that 14 days is the normal time to reach consensus. This may be extended when it seems necessary to allow an adequate period for input.
In general, Changes are for coordination of development effort and for communication (both internally and externally). They aren't mandates that someone else implement an idea (no matter how good that idea). If you have improvement in mind, work to get implementers committed to the effort before filing a Change, rather than expecting them to show up for work once the Change is accepted — that's simply unlikely to happen and the effort will likely fail, leading to sadness and disappointment all around.
How do I propose a new change?
In order to be considered an official change proposal accepted for the next Fedora release, the change proposal must be formally documented on a separate wiki page.
- Read the policies for self contained changes and complex system wide changes mentioned above.
- Pick the right category. Remember, the category can be changed to another one based on community or FESCo review!
- Fill in the empty change proposal form with all details required for selected category (see inline comments).
- Once you're satisfied with the change proposal page, set the wiki page category to Category:ChangeReadyForWrangler, and set the appropriate change category -- Category:SelfContainedChange or Category:SystemWideChange. Both categories must be set! Also ensure that the proposal URL follows the "Changes/<proposalname>" scheme.
- Make sure to finish your change proposal by the change proposal submission deadline! If you do not meet this deadline, you must seek an exception from FESCo.
The Change_Wrangler is responsible for the actual announcement of the change proposal, creating the FESCo ticket and tracking bug in Bugzilla. For status tracking, see the next section.
How is a change accepted?
Self contained changes that pass community review (the announcement) are accepted by FESCo without further investigation in a batch, no sooner than one week after the announcement. Complex system wide changes must be accepted by FESCo individually in the weekly meeting. The scope and dependencies are thoroughly reviewed to determine influence on the other parts of Fedora. It's beneficial for the change proposal owner to be available in the FESCo ticket for the change proposal, and in the relevant FESCo meeting (announced in advance). The change proposal owner is notified when the change is accepted for inclusion in the planned release.
How do I show the status of a change I own?
The progress of development is shown in Bugzilla with defined bug states as explained in the change proposal template. Use this tracking bug to show blockers, using the Blocks/Depends on fields (for example package reviews), update the bug description with an actual status, and modify the bug status to reflect current state. You may be asked by the Change_Wrangler or FESCo members to provide more detailed status (specifically for complex system wide changes).
A Change is considered code complete when the bug state is moved to ON_QA and when there are no blocking bugs open.
What are the change process deadline dates (Checkpoints)?
For specific dates refer to the current release's Schedule. For the general template of a Fedora release, to see when the Change Checkpoints relate to the rest of the cycle, see Fedora_Release_Life_Cycle.
Change Checkpoint: Proposal submission deadline
New change proposals may be submitted using the guidelines described elsewhere and accepted by FESCo until the change proposals submission deadline. For a given release, this date is available in Schedule and will be announced well in advance.
- Changes requiring Mass rebuild' may be proposed untill Change Checkpoint: Proposal submission deadline (Changes requiring mass rebuild)
- System Wide Changes may be proposed until Change Checkpoint: Proposal submission deadline (System Wide Changes).
- Self Contained Changes may be proposed until Change Checkpoint: Proposal submission deadline (Self Contained Changes).
Change Checkpoint: Completion deadline
This deadline falls on the same day as the Branch point (see Schedule).
- New changes must be feature complete or close enough to completion by the Change Checkpoint: Completion deadline (testable) date that a majority of its functionality can be tested prior the Beta releases.
- If a change proposal page specifies a change will be enabled by default, it must be so by this date.
- Changes meeting the preceding bullets are considered testable.
- Use the MODIFIED status in the tracker bug to show the change made the change deadline and is testable.
Change Checkpoint: 100% code complete deadline
This date falls on the same day as the Beta Freeze.
- New accepted changes must be code complete, meaning all the code required to enable to the new change is finished.
- The level of code completeness is reflected as tracker bug state ON_QA. The change does not have to be fully tested by this deadline.
Feel free to ask the Change_Wrangler for help.