From Fedora Project Wiki
(Merge Mitr's proposals)
(→‎For developers: Note to follow the URL scheme)
(23 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "edit" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
{{admon/tip | Quick Links | If you know the process already, you can jump immediately to [[Changes/EmptyTemplate | an empty Change Proposal form]].}}


<!-- Self Contained or System Wide Change Proposal?
== Fedora Release Planning Process ==
Use this guide to determine to which category your proposed change belongs to.


Self Contained Changes are:
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.
* changes to isolated/leaf package without the impact on other packages/rest of the distribution
* limited scope changes without the impact on other packages/rest of the distribution
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG


System Wide Changes are:
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.  
* changes that does not fit Self Contained Changes category touching
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)
* changing system defaults


For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is  
The planning process is an internal planning and tracking tool, and the final release is not required to reflect all proposed changes.
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies).  


We request that you maintain the same order of sections so that all of the change proposal pages are uniform.
== Change categories ==
-->
Fedora Engineering and Steering Committee (FESCo) defined two Change categories:
 
# Self contained changes
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
# Complex system wide changes
 
= Change Proposal Name <!-- The name of your change proposal --> =
 
== Summary ==
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. -->
 
== Owner ==
<!--
For change proposals to quality as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
This should link to your home wiki page so we know who you are.
-->
* Name: [[User:FASAcountName| Your Name]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: <your email address so we can contact you, invite you to meetings, etc.>
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
-->


== Current status ==
=== Self contained changes ===
* Targeted release: [[Releases/<number> | Fedora <number> ]]  
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.
* Last updated: (DATE)
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
Bugzilla states meaning as usual:
NEW -> change proposal is submitted and announced
ASSIGNED -> accepted by FESCo with on going development
MODIFIED -> change is substantially done and testable
optional ON_QA -> change is tested by Fedora QA
FIXED as NEXTRELEASE -> change is completed and will be delivered in next release under development
-->
* Tracker bug: <will be assigned by the Wrangler>


== Detailed Description ==
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.
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. -->


== Benefit to Fedora ==
{{hidden|header=The process for self contained changes|content=
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->
* The owner submits the change proposal according to the change proposal submission policy.
* The Wrangler checks the proposed change page for formal correctness.
* Once the change proposal is correct, the Wrangler announces it on the {{fplist|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 {{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}}


== Scope ==
=== Complex system wide changes ===
<!-- What work do the developers have to accomplish to complete the change in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
Complex system wide changes involve system-wide defaults, critical path components, or other changes that are not eligible as self contained changes.


* Feature owners:
{{hidden|header=The process for complex system wide changes|content=
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
* The owner submits the change proposal according to the change proposal submission policy below.
* The Wrangler checks the proposed change page for formal correctness.
* Once the change proposal is correct, the Wrangler announces it on the {{fplist|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 {{fplist|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 [[Schedule|Beta change deadline]].  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}}


* Other developers: N/A <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
== HOWTOs ==
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
=== For developers ===
{{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 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 [[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, ''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.


* Release engineering: N/A <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
The 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.
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here. -->
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}


* Policies and guidelines: N/A <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
{{hidden|header=How is a change accepted?|content=
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
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}}


== Upgrade/compatibility impact ==
{{hidden|header=How do I show the status of a change I own?|content=
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
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 Wrangler or FESCo members to provide more detailed status (specifically for complex system wide changes).
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}}


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
{{hidden|header= What are the change deadlines?|content=
N/A
For specific dates refer to the [[Schedule]].


== How To Test ==
==== Submitting new change proposals ====
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  
New change proposals may be submitted using the guidelines described elsewhere and accepted by [[FESCo]] until the ''change proposals submission deadline''.


Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
==== Change freeze ====
* New changes must be feature complete or close enough to completion by the [[Schedule|Alpha change deadline]] so 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 at the Alpha change deadline.
* 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 ''frozen''. All new changes are tested during the Alpha and Beta releases.}}


A good "how to test" should answer these four questions:
==== Beta deadline/accepted changes 100% complete  ====
* At the ''Beta change deadline'', 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.
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
<!--
=== For documentation team ===


0. What special hardware / data / etc. is needed (if any)?
=== For marketing team ===
1. How do I prepare my system to test this change? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the change is
working like it's supposed to?
3. What are the expected results of those actions?
-->
-->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
== FAQs ==
N/A
Feel free to ask the Wrangler for help. Currently this position is held by [[JaroslavReznik|Jaroslav Reznik]].
 
== User Experience ==
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A
 
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A
 
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: N/A <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A, Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A
 
== Release Notes ==
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this change, indicate them here.  A link to upstream documentation will often satisfy this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release.
 
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.
-->
 
[[Category:ChangePageIncomplete]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
 
<!-- Select proper category, default is Self Contained Change -->
[[Category:SelfContainedChange]]
<!-- [[Category:SystemWideChange]] -->

Revision as of 14:55, 6 November 2013

Idea.png
Quick Links
If you know the process already, you can jump immediately to an empty Change Proposal form.

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 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 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 change deadline. 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.

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 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 Wrangler or FESCo members to provide more detailed status (specifically for complex system wide changes).

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 deadlines?

For specific dates refer to the Schedule.

Submitting new change proposals

New change proposals may be submitted using the guidelines described elsewhere and accepted by FESCo until the change proposals submission deadline.

Change freeze

  • New changes must be feature complete or close enough to completion by the Alpha change deadline so 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 at the Alpha change deadline.
  • 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 frozen. All new changes are tested during the Alpha and Beta releases.

Beta deadline/accepted changes 100% complete

  • At the Beta change deadline, 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.

FAQs

Feel free to ask the Wrangler for help. Currently this position is held by Jaroslav Reznik.

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Policy&oldid=359507"