operations/docs
operations/docs
4
2
Fork 11
Code Issues 3 Pull requests 1 Activity Actions

Move Changes content to docs

Browse source
This commit is contained in:
Ben Cotton 2019-10-17 17:08:08 -04:00
commit 59e0894888
3 changed files with 310 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

7
modules/ROOT/nav.adoc
View file

@ -1,4 +1,9 @@
* xref:pgm_guide/index.adoc [PgM Guide]
* Changes
** xref:changes_policy.adoc[Changes policy]
** xref:changes_guide.adoc[Change submission guidance]
*** xref:changes_guide.adoc#_what_are_the_change_process_deadline_dates_checkpoints[Deadlines]
*** xref:changes_guide.adoc#_section_by_section_guidance[Section-by-section guidance]
* xref:pgm_guide/index.adoc[PgM Guide]
** xref:pgm_guide/changes.adoc[Changes]
** xref:pgm_guide/release_process.adoc[Release process]
** xref:pgm_guide/prioritized_bugs.adoc[Prioritized bugs]

196
modules/ROOT/pages/changes_guide.adoc Normal file
View file

@ -0,0 +1,196 @@
= Change submission guidance
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 proposal, rather than expecting them to show up for work once the Change is accepted.
== 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.
TIP: Read the xref:changes_policy[policies] for self-contained changes and system-wide changes.
TIP: Pick the right category. Remember, the category can be changed to another one based on community or FESCo review!
. Fill in the https://fedoraproject.org/wiki/Changes/EmptyTemplate[empty change proposal form] with all details required for selected category (see inline comments and guidance below).
. Once you're satisfied with the change proposal page, set the wiki page category to `ChangeReadyForWrangler`, _and_ set the appropriate change category (`SelfContainedChange` or `SystemWideChange`.
Both categories must be set!
Also ensure that the proposal URL follows the `Changes/<proposalname>` scheme.
WARNING: 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 Program Manager is responsible for the actual announcement of the change proposal, creating the FESCo ticket and tracking bug in Bugzilla.
== 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 Program Manager or FESCo members to provide more detailed status (especially for 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.
NOTE: See the xref:changes_policy.adoc#_bugzilla_trackers[Bugzilla trackers] section of the Changes policy for more information on Bugzilla statuses.
== 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 https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[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 the schedule and will be announced well in advance.
* *Changes requiring infrastructure changes* may be proposed until _Change Checkpoint: (Changes requiring infrastructure changes)_ (typically 4 weeks before the start of the mass rebuild)
* *Changes requiring Mass rebuild* may be proposed until _Change Checkpoint: Proposal submission deadline (Changes requiring mass rebuild)_ (typically 16 days before the start of the mass rebuild)
* *System-Wide Changes* may be proposed until _Change Checkpoint: Proposal submission deadline (System-Wide Changes)_ (typically 16 days before the start of the mass rebuild)
* *Self Contained Changes* may be proposed until _Change Checkpoint: Proposal submission deadline (Self Contained Changes)_ (typically 3 weeks before the branch point)
=== Change Checkpoint: Completion deadline
This deadline falls on the same day as the branch point.
* 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 start of the Beta Freeze.
* New accepted changes must be code complete, meaning *all* the code required to enable 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: 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.
== Section-by-section guidance
=== Change Proposal Name
This should be descriptive, but unique.
For example "glibc 2.29" is preferable to "glibc upgrade".
TIP: Make sure your page is in the `Changes` namespace (e.g. call it `Changes/glibc_2.29`)
=== 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.
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?".
TIP: Assume that not everyone who sees this will know what you're talking about.
Give a brief description of packages or services where it makes sense.
=== Owner
For change proposals to qualify 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.
TIP: Use your Bugzilla email in the `email` field to make your Program Manager happy.
=== Current status
Do not edit this section except to set the target release version.
=== Detailed Description
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
What is the benefit to the distribution?
Will the software we generate be improved?
How will the process of creating Fedora releases be improved?
Be sure to include the following areas if relevant:
* If this is a major capability update, what has changed?
For example: This change introduces Python 5 that runs without the Global Interpreter Lock and is fully multithreaded.
* If this is a new functionality, what capabilities does it bring?
For example: This change allows package upgrades to be performed automatically and rolled-back at will.
* Does this improve some specific package or set of packages?
For example: This change modifies a package to use a different language stack that reduces install size by removing dependencies.
* Does this improve specific Spins or Editions?
* For example: This change modifies the default install of Fedora Workstation to be more in line with the base install of Fedora Server.
* Does this make the distribution more efficient?
For example: This change replaces thousands of individual %post scriptlets in packages with one script that runs at the end.
* Is this an improvement to maintainer processes?
For example: Gating Fedora packages on automatic QA tests will make rawhide more stable and allow changes to be implemented more smoothly.
* Is this an improvement targeted as specific contributors?
For example: Ensuring that a minimal set of tools required for contribution to Fedora are installed by default eases the onboarding of new contributors.
TIP: When a Change has multiple benefits, it's better to list them all.
=== Scope
* Proposal owners: 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?
* Other developers: *REQUIRED FOR SYSTEM WIDE CHANGES* 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?
* Release engineering: *REQUIRED FOR SYSTEM WIDE CHANGES* Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?
Is a mass rebuild required?
Include a link to the releng issue.
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication.
* Policies and guidelines: 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.
* Trademark approval: If your Change may require trademark approval (for example, if it is a new Spin), file a https://pagure.io/Fedora-Council/tickets/issues[Fedora Council ticket] requesting trademark approval.
=== Upgrade/compatibility impact
*REQUIRED FOR SYSTEM WIDE CHANGES*
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?
=== How To Test
*REQUIRED FOR SYSTEM-WIDE CHANGES*
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.
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.
A good "how to test" should answer these four questions:
. What special hardware / data / etc. is needed (if any)?
. How do I prepare my system to test this change? What packages need to be installed, config files edited, etc.?
. What specific actions do I perform to check that the change is working like it's supposed to?
. What are the expected results of those actions?
=== User Experience
If this change proposal is noticeable by users, how will their experiences change as a result?
This section partially overlaps with the Benefit to Fedora section above.
This section should be primarily about the User Experience, written in a way that does not assume deep technical knowledge.
More detailed technical description should be left for the Benefit to Fedora section.
Describe what Users will see or notice, for example:
* Packages are compressed more efficiently, making downloads and upgrades faster by 10%.
* Kerberos tickets can be renewed automatically. Users will now have to authenticate less and become more productive. Credential management improvements mean a user can start their work day with a single sign on and not have to pause for reauthentication during their entire day.
* Libreoffice is one of the most commonly installed applications on Fedora and it is now available by default to help users "hit the ground running".
* Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
=== Dependencies
*REQUIRED FOR SYSTEM-WIDE CHANGES*
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)? -->
=== Contingency Plan
*REQUIRED FOR SYSTEM-WIDE CHANGES*
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.
A contigency plan should include:
* Contingency mechanism: (What to do? Who will do it?)
* Contingency deadline: When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze.
=== Documentation
*REQUIRED FOR SYSTEM-WIDE CHANGES*
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.
=== 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.

108
modules/ROOT/pages/changes_policy.adoc Normal file
View file

@ -0,0 +1,108 @@
= Changes policy
TIP: If you know the process already, you can jump immediately to https://fedoraproject.org/wiki/Changes/EmptyTemplate[an empty Change Proposal form].
== Fedora Changes Process
The motivation for the Changes process is to raise the visibility of planned changes and make coordination and planning effort easier.
It is nearly impossible to follow all changes happening in a big project such as Fedora.
By providing a mechanism for sharing changes, it is easier for contributors to know what is coming and to ensure that we can address impacts of changes well before the release date.
Change proposals should be shared 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 Change 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) has defined two Change categories:
1. Self-contained changes
2. 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 Special Interest Group (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.
Based on the community review, the self contained change can be updated to the system-wide change category, and the owner may be asked to provide more details and extend the change proposal page.
=== System-Wide Changes
System-wide changes involve system-wide defaults, critical path components, or other changes that are not eligible as self-contained changes.
== Change Proposal Sections
.Change proposal sections
|===
|Element|Self-Contained|System-Wide
|Summary|required|required
|Owner|required|required
|Current status|required|required
|Detailed description|required|required
|Benefit to Fedora|required|required
|Scope/Proposal owners|required|required
|Scope/Other developers|as applicable|required
|Scope/Release Engineering|as applicable|required
|Scope/Policies and guidelines|as applicable|as applicable
|Scope/Trademark approval|as applicable|as applicable
|Upgrade & Compatibility impact|optional|required
|How to test|optional|required
|User experience|optional|optional
|Dependencies|optional|required
|Contingency plan|optional|required
|Documentation|optional|required
|Release notes|optional|required
|===
== Essential Communication
=== Fedora Packaging Committee
For changes that require modifications to the https://docs.fedoraproject.org/en-US/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 Branch point or FESCo might decide to apply the Contingency Plan.
=== Release Engineering
For all system-wide changes you must file an issue in https://pagure.io/releng/issues[releng pagure] to check if your change requires Release Engineering involvement.
NOTE: Release Engineering tickets are not required by default for self-contained changes, but may be necessary if the change involves, for example, adding a new output artifact.
=== Trademark Approval
If your Change may require trademark approval (for example, if it is a new Spin), https://pagure.io/Fedora-Council/tickets/issues[file a ticket] requesting trademark approval from the Fedora Council.
== Change process
This is the general flow for change proposals:
* The owner submits the change proposal by setting the wiki page to the *ChangeReadyForWrangler* category.
* The Program Manager checks the proposed change page for formal correctness.
This includes Release Engineering, Fedora Packaging Committee, and trademark approval tickets where necessary.
* Once the change proposal is correct, the Program Manager announces it on the devel-announce and devel mailing lists.
* The Program Manager adds the aggregated list of change proposals to the FESCo agenda no sooner than a week after the announcement on the mailing list.
** Any team can share their views on {{fplist|devel}} and escalate a proposed change to FESCo.
The change owner may be asked to provide more details or address proposed concerns.
FESCo members are encouraged to ask questions on the mailing list instead of waiting for the 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.
* The Program Manager will create Bugzilla trackers in the _Changes Tracking_ component and issues in the Release Notes repository for approved changes.
* FESCo will re-review the status of changes one week before the beta freeze.
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.
=== Bugzilla trackers
Approved change proposals will have Bugzilla issues created by the Program Manager. The following status fields should be used to reflect the status of the change:
.Bugzilla tracker statuses
|===
|BZ Status|Meaning
|ASSIGNED|Change approved by FESCo
|MODIFIED|Change is code complete enough to be testable
|ON_QA|Change is 100% code complete
|===
NOTE: Do not close tracking bugs when a change is complete.
The Program Manager will do that as part of release housekeeping.