From Fedora Project Wiki
(How do I show the status of a change I own?)
(seems like we're doing completion deadline on the day of alpha freeze, for f22 at least.)
(31 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{admon/tip | Quick Links | If you know the process already, you can jump immediately to [[Changes/EmptyTemplate | an empty Change Proposal form]].}}
{{admon/tip | Quick Links | If you know the process already, you can jump immediately to [[Changes/EmptyTemplate | an empty Change Proposal form]]. Looking for help? Contact the [[Change Wrangler]].}}


= Fedora Releases Planning Process =
== Fedora Release Planning Process ==


Motivation behind the planning process is to raise the visibility of planned changes, to make coordination and planning effort easier, as otherwise it is nearly impossible to follow all changes happening in such a big project as Fedora is. It has to be easy to submit the Change Proposal, as early as possible, before the change is implemented and even in very early state of idea, to gather community feedback and review.  
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 (Change Set) is used by different teams across the project, for example to prepare external facing materials like Release notes and Release announcements.  
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.  


Planning process is an internal planning and tracking tool and the final release does not have to reflect all proposed changes.   
The planning process is an internal planning and tracking tool, and the final release is not required to reflect all proposed changes.   


== Changes Categories ==
== Change categories ==
Fedora Engineering and Steering Committee (FESCo) defined two Change categories:
Fedora Engineering and Steering Committee (FESCo) defined two Change categories:
# Self Contained Changes
# Self contained changes
# System Wide Changes
# Complex system wide changes


=== Self Contained Changes ===
=== Self contained changes ===
The self contained changes are changes to isolate package(s) or generally all changes with limited scope and impact on the rest of distribution/project. For example addition of a group of leaf packages or coordinated effort within SIG with limited impact outside SIG functional area. Self Contained Changes could be used for early idea state proposals for wider and complex changes.
A self contained change is a change to isolated package(s), or a general changes 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 the new Self Contained Changes helps to co-operate on the change and extends proposed change 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, Self Contained Change can be updated to the System Wide Change category and Owner can be asked to provide more details and extend Change Proposal Papge.
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.


{{hidden|header=The process for Self Contained Features|content=
{{hidden|header=The process for self contained changes|content=
* Change Proposal is submitted according to the Change Proposal Submission policy
* The owner submits the change proposal according to the change proposal submission policy.
* The formal correctness of Proposed Change page is checked by the Wrangler
* The [[Change_Wrangler]] checks the proposed change page for formal correctness.
* Once the Change Proposal is correct, it's announced on Fedora Devel Announce list by the Wrangler.
* Once the change proposal is correct, the Wrangler announces it on the {{fplist|devel-announce}} mailing list.
* No documentation process (optional), only release notes advertisement
* '''WHO?''' advertises the change in the release notes. Other formal documentation process is optional.
* Aggregated list of Change Proposals is added to FESCo agenda no sooner than a week (or more) after the announcement on the mailing list.
* The Wrangler adds the aggregated list of change proposals to the FESCo agenda no sooner than a week after the announcement on the mailing list.
** In case of no complaints (possible breakage/conflicts, coordination needed) on Fedora Devel mailing list/or from FESCo members, FESCo approves those Change Proposals without more scope and etc. investigation. Every team on Fedora devel can share their views and escalate proposed change to FESCo to go through the regular System Wide Changes process. Change owner could be asked to provide more details/or move the change to the "complex changes" category. FESCo members are encouraged to ask questions on the mailing list instead of waiting for the meeting.
** In case of no complaints (possible breakage/conflicts, coordination needed) on the {{fplist|devel}} mailing list or from FESCo members, FESCo approves those change proposals without further investigation or scoping. Any team can share their views on {{fplist|devel}} and escalate a proposed change to FESCo to go through the regular complex system wide changes process. The change owner may be asked to provide more details or move the change to the "complex system wide changes" category. FESCo members are encouraged to ask questions on the mailing list instead of waiting for the meeting.
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}


=== Complex System Wide Changes ===
=== Complex system wide changes ===
Complex System Wide Changes are system-wide/defaults or critical path components changing changes which does not belong to Self Contained Changes.
Complex system wide changes involve system-wide defaults, critical path components, or other changes that are not eligible as self contained changes.


{{hidden|header=The process for Complex System Wide Changes|content=
{{hidden|header=The process for complex system wide changes|content=
* Change Proposal is submitted according to the Change Proposal Submission policy
* The owner submits the change proposal according to the change proposal submission policy below.
* The formal correctness of Proposed Change page is checked by the Wrangler
* The [[Change Wrangler]] checks the proposed change page for formal correctness.
* Once the Change Proposal is correct, it's announced on Fedora Devel Announce list by the Wrangler.
* Once the change proposal is correct, the Wrangler announces it on the {{fplist|devel-announce}} list.
* After a week on mailing list FESCo will discuss the change on their meeting.
* After at least one week on the mailing list, the Wrangler sends the change to FESCo for discussion and formal approval in their meeting.
** Optionally, the change is assigned to one of the FESCo members/or trusted community member within the functional area, who follows detailed status of the change with FESCo and helps with processes within Fedora (e.g. communicate about high-impact aspects, point out that a buildroot will be neccessary). The shepherd follows on status of the change until final release.
** Optionally, FESCo assigns the change to one of the FESCo members or a trusted community member within the functional area (a ''change shepherd''), who follows the detailed status of the change with FESCo and helps with processes within Fedora. For example, the change shepherd may communicate high-impact aspects of the change, or point out that a buildroot will be neccessary. The shepherd follows the status of the change until final release.
** Fedora QA reviews announced changes on Devel Announce list to commit to testing of the change and/or adjust release criteria in case of need
** Fedora QA reviews announced changes on the {{fplist|devel-announce}} list to commit to testing of the change, or adjust release criteria as necessary.
* Status of complex changes will be re-reviewed by FESCo one week before Beta Freeze.  At this time FESCo will typically decide whether to activate the contingency plan. Changes for which FESCo can't make this decision one week before beta need to note it on the respective Change wiki page/tracking bug.
* FESCo will re-review the status of complex changes one week before the [[Milestone freezes|Beta freeze]] ([[Schedule|see current schedule]]).  At this time, FESCo typically decides whether to activate the contingency plan. Any change for which FESCo can't make this decision one week before beta must include a note on its Change wiki page and tracking bug.
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* For changes that require modifications to the [[Packaging:Guidelines|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 Alpha Freeze or the Contingency Plan will be invoked.


== How-tos ==
== HOWTOs ==
=== For developers ===
=== For developers ===
{{hidden|header=How to propose a new change?|content=
{{hidden|header=How do I propose a new change?|content=
In order to be considered an official change proposal accepted for the next Fedora release, the change proposal has to be formally documented on a separate wiki page.
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
# Read the policies for self contained changes and complex system wide changes mentioned above.
# Pick the right category; remember - category can be changed to another one based on community/FESCo review!
# Pick the right category. Remember, the category can be changed to another one based on community or FESCo review!
# Fill in the [[Changes/EmptyTemplate | empty Change Proposal form]] with all details required for selected category (see inline comments)  
# Fill in the [[Changes/EmptyTemplate | 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 (with appropriate Change category - Category:SelfContainedChange or Category:SystemWideChange)
# 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! In case of not meeting this deadline, exception has to be granted by FESCo.
# 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 Wrangler is then 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.
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.
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}


{{hidden|header=How does a change get accepted?|content=
{{hidden|header=How is a change accepted?|content=
Self Contained Changes that passed 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 has to be accepted by FESCo individually on the weekly meeting. The scope and dependencies are thoroughly reviewed to control influence on the other parts of Fedora. It's beneficial to be available in the FESCo ticket for Change Proposal and relevant FESCo meeting (announced in advance). Change Proposal owner is notified when the Change was accepted for inclusion to the planned release.
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.
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}


{{hidden|header=How do I show the status of a change I own?|content=
{{hidden|header=How do I show the status of a change I own?|content=
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 Block/Depends on fields (for example package reviews), update bug description with an actual status and modify bug status to reflect current state. You may be asked by Wrangler or FESCo members to provide more detailed status (specifically for Complex System Wide Changes).
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).
   
   
Change is considered completed when the bug state is moved to CLOSED with resolution NEXTRELEASE and there are no blocking bugs still opened.  
A Change is considered ''code complete'' when the bug state is moved to ON_QA and when there are no blocking bugs open.
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}


* What are the changes deadlines?
{{hidden|header= What are the change process deadline dates (Checkpoints)?|content=
<!---* What to do in case of missing deadline?
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 (System Wide Changes) ====
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 falls three months before the release is [[Releases/Branched|Branched]], and will be announced well in advance. It's a strict deadline for System Wide Changes. Self Contained changes may be proposed after this deadline but we prefer developers to follow it as it helps with release planning.
==== Change Checkpoint: Completion deadline ====
This deadline falls on the same day as the Alpha [[Milestone freezes|milestone freeze]] (see [[Schedule]]).
* New changes must be feature complete or close enough to completion by the ''Change Checkpoint: Completion deadline'' date that a majority of its functionality can be tested during the Alpha and 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''.
{{Admon/tip | ''Testable'' | This means the change is substantially complete and can be tested when the change is not 100% completely implemented. This is an attempt to provide some flexibility without completely losing the understood meaning of a change being ''feature complete''. All new changes are tested during the Alpha and Beta releases.}}
==== Change Checkpoint: 100% code complete deadline ====
This date falls on the same day as the [[Schedule|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.
{{admon/note|Relationship to milestone freezes|Change Checkpoint: 100% code complete deadline coincides with the [[Milestone freezes|Beta Freeze]] date because that is the last date on which it can be ensured that a build will appear in a milestone release. The idea is really that these requirements be met in the Beta ''release'', but due to the nature of the milestone freezes, in order to ensure this is the case, the requirements must be met by the freeze date.}}
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
<!--
=== For documentation team ===
=== For documentation team ===


Line 73: Line 97:


== FAQs ==
== FAQs ==
Feel free to ask the Wrangler for help, currently held by [[JaroslavReznik|Jaroslav Reznik]].
Feel free to ask the [[Change_Wrangler]] for help.

Revision as of 22:54, 22 January 2015

Idea.png
Quick Links
If you know the process already, you can jump immediately to an empty Change Proposal form. Looking for help? Contact the Change Wrangler.

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.

The planning process is an internal planning and tracking tool, and the final release is not required to reflect all proposed changes.

Change categories

Fedora Engineering and Steering Committee (FESCo) defined two Change categories:

  1. Self contained changes
  2. Complex system wide changes

Self contained changes

A self contained change is a change to isolated package(s), or a general changes 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.

The process for self contained changes
  • The owner submits the change proposal according to the change proposal submission policy.
  • The Change_Wrangler checks the proposed change page for formal correctness.
  • Once the change proposal is correct, the Wrangler announces it on the devel-announce mailing list.
  • WHO? advertises the change in the release notes. Other formal documentation process is optional.
  • The Wrangler adds the aggregated list of change proposals to the FESCo agenda no sooner than a week after the announcement on the mailing list.
    • In case of no complaints (possible breakage/conflicts, coordination needed) on the devel mailing list or from FESCo members, FESCo approves those change proposals without further investigation or scoping. Any team can share their views on devel and escalate a proposed change to FESCo to go through the regular complex system wide changes process. The change owner may be asked to provide more details or move the change to the "complex system wide changes" category. FESCo members are encouraged to ask questions on the mailing list instead of waiting for the meeting.

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.

The process for complex system wide changes
  • The owner submits the change proposal according to the change proposal submission policy below.
  • The Change Wrangler checks the proposed change page for formal correctness.
  • Once the change proposal is correct, the Wrangler announces it on the devel-announce list.
  • After at least one week on the mailing list, the Wrangler sends the change to FESCo for discussion and formal approval in their meeting.
    • Optionally, FESCo assigns the change to one of the FESCo members or a trusted community member within the functional area (a change shepherd), who follows the detailed status of the change with FESCo and helps with processes within Fedora. For example, the change shepherd may communicate high-impact aspects of the change, or point out that a buildroot will be neccessary. The shepherd follows the status of the change until final release.
    • Fedora QA reviews announced changes on the devel-announce list to commit to testing of the change, or adjust release criteria as necessary.
  • FESCo will re-review the status of complex changes one week before the Beta freeze (see current schedule). At this time, FESCo typically decides whether to activate the contingency plan. Any change for which FESCo can't make this decision one week before beta must include a note on its Change wiki page and tracking bug.
  • 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 Alpha Freeze or the Contingency Plan will be invoked.

HOWTOs

For developers

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.

  1. Read the policies for self contained changes and complex system wide changes mentioned above.
  2. Pick the right category. Remember, the category can be changed to another one based on community or FESCo review!
  3. Fill in the empty change proposal form with all details required for selected category (see inline comments).
  4. 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.
  5. 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 (System Wide Changes)

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 falls three months before the release is Branched, and will be announced well in advance. It's a strict deadline for System Wide Changes. Self Contained changes may be proposed after this deadline but we prefer developers to follow it as it helps with release planning.

Change Checkpoint: Completion deadline

This deadline falls on the same day as the Alpha milestone freeze (see Schedule).

  • New changes must be feature complete or close enough to completion by the Change Checkpoint: Completion deadline date that a majority of its functionality can be tested during the Alpha and 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.
Idea.png
Testable
This means the change is substantially complete and can be tested when the change is not 100% completely implemented. This is an attempt to provide some flexibility without completely losing the understood meaning of a change being feature complete. All new changes are tested during the Alpha and Beta releases.

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.
Note.png
Relationship to milestone freezes
Change Checkpoint: 100% code complete deadline coincides with the Beta Freeze date because that is the last date on which it can be ensured that a build will appear in a milestone release. The idea is really that these requirements be met in the Beta release, but due to the nature of the milestone freezes, in order to ensure this is the case, the requirements must be met by the freeze date.

FAQs

Feel free to ask the Change_Wrangler for help.