#13 Fix markup issues throughout the repo
Merged 5 years ago by zbyszek. Opened 5 years ago by pbokoc.
fesco/ pbokoc/fesco-docs master  into  master

@@ -1,24 +1,19 @@ 

- Bundled software policy

- =======================

+ = Bundled software policy

  

- [.lead]

  This policy concerns the use of bundled software in the Fedora Package Collection.

  

- Policy

- ------

+ == Policy

  

  All packages whose upstreams allow them to be built against system libraries must be built against system libraries.

  

  All packages whose upstreams have no mechanism to build against system libraries must be contacted publicly about a path to supporting system libraries. If upstream refuses, this must be recorded in the spec file using a persistent mechanism to be clarified in the packaging guidelines.

  

- All packages whose upstreams have no mechanism to build against system libraries may opt to carry bundled libraries, but if they do, they must include Provides: bundled() = in their RPM spec file. The FPC will maintain the list of bundled provides, please consult with them when adding new provides or in case of disputes.

+ All packages whose upstreams have no mechanism to build against system libraries may opt to carry bundled libraries, but if they do, they must include `Provides: bundled() =` in their RPM spec file. The FPC will maintain the list of bundled provides, please consult with them when adding new provides or in case of disputes.

  

- Packages that bundle libraries must follow the https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Private_Libraries[AutoProvides filtering guidelines] for private libraries.

+ Packages that bundle libraries must follow the link:https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Private_Libraries[AutoProvides filtering guidelines] for private libraries.

  

- References

- ----------

+ == References

  

- https://fedorahosted.org/fesco/ticket/1483

- 

- https://fedorahosted.org/fesco/ticket/1491

+ * link:https://fedorahosted.org/fesco/ticket/1483[#1483 Decision on bundling policy in the Fedora Package Collection]

  

+ * link:https://fedorahosted.org/fesco/ticket/1491[#1491 clarifications/improvements for new bundling policy]

@@ -1,32 +1,29 @@ 

- Fails to build from source, Fails to install

- ============================================

- 

+ = Fails to build from source, Fails to install

+ :experimental:

  :toc:

  

  This page describes *the policy for packages that no longer build or install* and

  need developer attention.

  

  The schedule for most releases of Fedora includes a mass rebuild (e.g.

- https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild[Fedora 27 Mass Rebuild],

- https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild[Fedora 28 Mass Rebuild]) to update the

+ link:https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild[Fedora 27 Mass Rebuild],

+ link:https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild[Fedora 28 Mass Rebuild]) to update the

  packages with new features of the compiler, packaging, build flags, etc.

  This serves as a convenient opportunity to detect all packages which no

  longer build properly.

  

- Glossary

- --------

+ == Glossary

  

  FTBFS:: Fails To Build From Sources

  FTI:: Fails To Install (usually due to broken dependencies)

  

  

- Package removal for long-standing FTBFS and FTI bugs

- ----------------------------------------------------

+ == Package removal for long-standing FTBFS and FTI bugs

  

  Packages which fail to build or fail to install will be orphaned and/or

  retired after a period of time.

  

- 1.  If a package *fails to build from sources* or *fails to install*,

+ .  If a package *fails to build from sources* or *fails to install*,

      any concerned party can *file a bug* in Bugzilla blocking a FTBFS/FTI

      tracker, providing information about the failure.

      * A bug about build failure needs to block the FTBFS tracker for the
@@ -35,42 +32,42 @@ 

        the appropriate release, eg. F30FailsToInstall for Fedora 30, see list below.

      * One bug can block multiple trackers if convenient. Reporters are

        encouraged to search for duplicates first.

- 2.  Maintainers should either fix and close the bug or acknowledge that

+ .  Maintainers should either fix and close the bug or acknowledge that

      they are working on a solution by setting the state to ASSIGNED.

- 3.  If an FTBFS or FTI bug remains in the NEW state for at least *1

+ .  If an FTBFS or FTI bug remains in the NEW state for at least *1

      week*, any concerned party can set a *NEEDINFO* for the maintainer to

      respond and send an *e-mail reminder* with the Bugzilla link to

-     `<component_name>-maintainers@fedoraproject.org`, cc'ing the

-     https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/[devel

+     `<component_name>-\maintainers@fedoraproject.org`, cc'ing the

+     link:https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/[devel

      mailing list] (so there is a public record) and commenting on the bug

      about doing so.

- 4.  If the bug remains in NEW state for at least another 3 weeks after

+ .  If the bug remains in NEW state for at least another 3 weeks after

      the NEEDINFO and e-mail (= at least for *4 weeks* in total), any concerned party

      can send *another comment and e-mail* (as in the previous point).

- 5.  If the bug remains in NEW state for at least another 4 weeks after

+ .  If the bug remains in NEW state for at least another 4 weeks after

      the second e-mail and comment (= at least *8 weeks* in total), the package

      will be *orphaned*. Orphaning can be requested via a releng issue.

- 6.  The normal

-     https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers[Orphaned

+ .  The normal

+     link:https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers[Orphaned

      package that needs new maintainers procedure] will be followed for the

      packages orphaned in this way, leading to their *retirement* if nobody

      adopts them.

- 7.  A week before the *mass branching*, any packages which still have

+ .  A week before the *mass branching*, any packages which still have

      open FTBFS bugs from the previous release will be *retired*. This can be

      requested via a releng issue.

- 8.  A week before the scheduled *beta freeze*, any packages which have

+ .  A week before the scheduled *beta freeze*, any packages which have

      open FTI bugs in the NEW state with at least 8 weekly reminders will

      be** retired** from the relevant release and rawhide (in addition to

      being orphaned). (Releng ticket for this needs to be opened at least a

      week before the freeze, but can be opened sooner.)

- 9.  The previous point repeats for the *final freeze*.

+ .  The previous point repeats for the *final freeze*.

  

  (Effectively, packages will be retired after 14 weeks or sooner if there

  is no maintainer response and the package is orphaned, or after 6½

  months if the maintainer responds to FTBFS but the bug is not fixed.)

  

  When releng performs the

- https://docs.pagure.org/releng/sop_mass_rebuild.html[mass rebuild],

+ link:https://docs.pagure.org/releng/sop_mass_rebuild.html[mass rebuild],

  releng opens FTBFS bugs for any packages which fail to build. Anyone can

  send the weekly reminders and request packages to be orphaned/retired –

  in other words, the procedure can be applied manually.
@@ -81,104 +78,97 @@ 

  report.

  

  

- Tracking bugs

- -------------

+ == Tracking bugs

  

- * https://bugzilla.redhat.com/showdependencytree.cgi?id=440169[generic

+ * link:https://bugzilla.redhat.com/showdependencytree.cgi?id=440169[generic

  FTBFS blocker bug]

- * https://bugzilla.redhat.com/showdependencytree.cgi?id=440169&hide_resolved=1[F9FTBFS]

- * https://bugzilla.redhat.com/showdependencytree.cgi?id=463452&hide_resolved=1[F10FTBFS]

+ * link:https://bugzilla.redhat.com/showdependencytree.cgi?id=440169&hide_resolved=1[F9FTBFS]

+ * link:https://bugzilla.redhat.com/showdependencytree.cgi?id=463452&hide_resolved=1[F10FTBFS]

  * F11 was handled by Release Engineering, no FTBFS bugs were filed.

- http://jkeating.fedorapeople.org/needed-f11-rebuilds.html

- (https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild[Fedora 11 Mass Rebuild])

- * https://bugzilla.redhat.com/showdependencytree.cgi?id=511348&hide_resolved=1[F12FTBFS]

- (https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild[Fedora 12 Mass Rebuild])

- * https://bugzilla.redhat.com/showdependencytree.cgi?id=538681&hide_resolved=1[F13FTBFS]

- ** https://bugzilla.redhat.com/showdependencytree.cgi?id=564245&hide_resolved=1[F13FTBFS

+ link:http://jkeating.fedorapeople.org/needed-f11-rebuilds.html[]

+ (link:https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild[Fedora 11 Mass Rebuild])

+ * link:https://bugzilla.redhat.com/showdependencytree.cgi?id=511348&hide_resolved=1[F12FTBFS]

+ (link:https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild[Fedora 12 Mass Rebuild])

+ * link:https://bugzilla.redhat.com/showdependencytree.cgi?id=538681&hide_resolved=1[F13FTBFS]

+ ** link:https://bugzilla.redhat.com/showdependencytree.cgi?id=564245&hide_resolved=1[F13FTBFS

  due to] Features/ChangeInImplicitDSOLinking

- * https://bugzilla.redhat.com/show_bug.cgi?id=596849[F14FTBFS]

- * https://bugzilla.redhat.com/show_bug.cgi?id=659965[F15FTBFS]

- (https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild[Fedora 15 Mass Rebuild])

- * https://bugzilla.redhat.com/show_bug.cgi?id=713919[F16FTBFS]

- * https://bugzilla.redhat.com/show_bug.cgi?id=817273[F17FTBFS]

- (https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild[Fedora 17 Mass Rebuild])

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=596849[F14FTBFS]

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=659965[F15FTBFS]

+ (link:https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild[Fedora 15 Mass Rebuild])

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=713919[F16FTBFS]

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=817273[F17FTBFS]

+ (link:https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild[Fedora 17 Mass Rebuild])

  * There seem to be no FTBFS bugs reported for Fedora 18, list of failed

  builds from the mass rebuild:

- http://fedorapeople.org/~ausil/f18-failures.html

- (https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild[Fedora 18 Mass Rebuild])

- * https://bugzilla.redhat.com/show_bug.cgi?id=913825[F19FTBFS]

- (https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild[Fedora 19 Mass Rebuild])

- * https://bugzilla.redhat.com/show_bug.cgi?id=991858[F20FTBFS]

- (https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild[Fedora 20 Mass Rebuild])

- * https://bugzilla.redhat.com/show_bug.cgi?id=1105908[F21FTBFS]

- (https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild[Fedora 21 Mass Rebuild])

+ link:http://fedorapeople.org/~ausil/f18-failures.html[]

+ (link:https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild[Fedora 18 Mass Rebuild])

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=913825[F19FTBFS]

+ (link:https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild[Fedora 19 Mass Rebuild])

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=991858[F20FTBFS]

+ (link:https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild[Fedora 20 Mass Rebuild])

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=1105908[F21FTBFS]

+ (link:https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild[Fedora 21 Mass Rebuild])

  * F22?

- * F23? (https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild[Fedora 23 Mass Rebuild])

- * https://bugzilla.redhat.com/show_bug.cgi?id=1305208[F24FTBFS]

- (https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild[Fedora 24 Mass Rebuild])

+ * F23? (link:https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild[Fedora 23 Mass Rebuild])

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=1305208[F24FTBFS]

+ (link:https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild[Fedora 24 Mass Rebuild])

  * No mass rebuild in F25

- * https://bugzilla.redhat.com/show_bug.cgi?id=1423041[F26FTBFS]

- (https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild[Fedora 26 Mass Rebuild])

- * F27? (https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild[Fedora 27 Mass Rebuild])

- * https://bugzilla.redhat.com/show_bug.cgi?id=1555378[F28FTBFS]

- (https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild[Fedora 28 Mass Rebuild]),

-   https://bugzilla.redhat.com/show_bug.cgi?id=1700320[F28FailsToInstall]

- * https://bugzilla.redhat.com/show_bug.cgi?id=1602938[F29FTBFS]

- (https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild[Fedora 29 Mass Rebuild]),

-   https://bugzilla.redhat.com/show_bug.cgi?id=1700321[F29FailsToInstall]

- * https://bugzilla.redhat.com/show_bug.cgi?id=1674516[F30FTBFS]

- (https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild[Fedora 30 Mass Rebuild]),

-   https://bugzilla.redhat.com/show_bug.cgi?id=1700323[F30FailsToInstall]

- * https://bugzilla.redhat.com/show_bug.cgi?id=1700317[F31FTBFS],

-   https://bugzilla.redhat.com/show_bug.cgi?id=1700324[F31FailsToInstall]

- 

- 

- 

- 

- What to do if you get a FTBFS bug?

- ----------------------------------

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=1423041[F26FTBFS]

+ (link:https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild[Fedora 26 Mass Rebuild])

+ * F27? (link:https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild[Fedora 27 Mass Rebuild])

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=1555378[F28FTBFS]

+ (link:https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild[Fedora 28 Mass Rebuild]),

+   link:https://bugzilla.redhat.com/show_bug.cgi?id=1700320[F28FailsToInstall]

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=1602938[F29FTBFS]

+ (link:https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild[Fedora 29 Mass Rebuild]),

+   link:https://bugzilla.redhat.com/show_bug.cgi?id=1700321[F29FailsToInstall]

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=1674516[F30FTBFS]

+ (link:https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild[Fedora 30 Mass Rebuild]),

+   link:https://bugzilla.redhat.com/show_bug.cgi?id=1700323[F30FailsToInstall]

+ * link:https://bugzilla.redhat.com/show_bug.cgi?id=1700317[F31FTBFS],

+   link:https://bugzilla.redhat.com/show_bug.cgi?id=1700324[F31FailsToInstall]

+ 

+ == What to do if you get a FTBFS bug?

  

  * Read the logs. Each FTBFS bug should have the build logs attached.

  * If the build of your package fails due to a bug in *your package*:

  

- 1.  Fix the problems uncovered and commit the changes.

- 2.  Build the package. The fixed package will land in rawhide, generally

+ .  Fix the problems uncovered and commit the changes.

+ .  Build the package. The fixed package will land in rawhide, generally

  the next day. If branching has already occurred, also fix the build in

  branched.

- 3.  If the build succeeds, close the bug as CLOSED: RAWHIDE, and include

+ .  If the build succeeds, close the bug as CLOSED: RAWHIDE, and include

  the package version number in the _Fixed In Version_ field.

      Here is a command line template for powerusers:

      `bugzilla modify --close RAWHIDE <bug-number> --comment

      'Built successfully in rawhide' -F <package-nevr>`

- 4.  If branching already occurred, but bodhi hasn't been activated yet,

+ .  If branching already occurred, but bodhi hasn't been activated yet,

  also build the package in branched.

- 5.  If bodhi has already been activated for branched, also make an

+ .  If bodhi has already been activated for branched, also make an

  update. An update should be made even if branched has already been

  released.

  

  * If the build of your package fails due to a bug in *another package*

  (such as a compiler bug or missing dependency):

  

- 1.  Find an existing bug for that package describing the problem. Set

+ .  Find an existing bug for that package describing the problem. Set

  your bug to "Depends on" that other bug. Do not change the component of

  your bug to the other package, or you will get more FTBFS bugs created

  against you.

- 2.  When that other bug is closed, you'll get an email from bugzilla as

+ .  When that other bug is closed, you'll get an email from bugzilla as

  usual. Rebuild your package using a koji scratch build, to verify it

  builds cleanly again. Proceed according to points 2-5 above.

  

  * If the package is no longer useful to the Fedora project, it should be

  retired.

- See https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life[How

+ See link:https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life[How

  to remove a package at end of life].

  

  In all cases, if you close an FTBFS bug as a duplicate of another bug,

  please make the other bug to block the right FTBFS tracking bugs. This

  way the bug left open will appear in the FTBFS reports properly.

  

- See also

- --------

+ == See also

  

- * FESCo ticket updating this policy: https://pagure.io/fesco/issue/2109

- * releng docs:

- https://docs.pagure.org/releng/sop_deprecate_ftbfs_packages.html

+ * link:https://pagure.io/fesco/issue/2109[FESCo ticket updating this policy]

+ * link:https://docs.pagure.org/releng/sop_deprecate_ftbfs_packages.html[Releng docs]

@@ -1,24 +1,18 @@ 

- Fedora Council Engineering Rep

- ==============================

- 

- [.lead]

+ = Fedora Council Engineering Rep

  

  As a major steering commitee under the Fedora Council, FESCo is responsible for selecting a representative that covers the engineering aspects of the Fedora Project. This person is responsible for representing engineering as a collective, and not as a single voice. They will be required to work with all of the various groups that collaborate with FESCo on technical things and act as a liasion between these groups and the Council itself. The role will require a fair amount of time investment and good communication skills. Below is the process for selecting the Council Engineering representative.

  

- Duration of Service

- -------------------

+ == Duration of Service

  

  The representative will serve in this role until they wish to step down, or the Council or FESCo wish to replace them. Careful consideration of time commitments should be taken when doing the selection and the Council, FESCo, and the representative should evaluate their effectiveness as a group on a fairly regular basis. In the event that one of the three involved parties wishes to make a change in representative, sufficient reason should be given and then a new representative will be chosen by FESCo.

  

- Nomination

- ----------

+ == Nomination

  

  There will be a one week nomination period open for potential representatives. Nominees can be self-nominated or nominated by others, with the nominee giving a public acknowledgment of interest in the role. People wishing to be nominees should have a solid understanding of FESCo process, the higher level technical processes of the project and sufficient time to perform the duties required. The nominees are not required to be FESCo members. It is recommended that they should be members of one of the engineering focused groups in FAS.

  

  In the event that there are no nominees, FESCo will work with the Council to broaden the search message and request more time. Should no nominees be found after that, the role will rotate among existing FESCo members until the next FESCo election is completed. The nomination period will open again and a search for a new representative will commence.

  

- Selection

- ---------

+ == Selection

  

  After the one week nomination period expires, FESCo will discuss the candidates in their public meeting and select the person they believe will be the best fit for the Engineering Representative role. The criteria are flexible and will differ based on many factors which will change over the course of time based on the current project's focus and goals. Nominees are encouraged to attend the meeting to answer any questions that FESCo or other groups may have.

  

@@ -1,45 +1,37 @@ 

- Mass package changes

- ====================

+ = Mass package changes

  

  From time to time changes are required across a group of packages. When the changes are complex or the number of affected packages is large, coordination is absolutely required to avoid confusion and wasted effort. The mass filing of bugs may be required, which must be done with care. This page attempts to describe some steps to take when mass changes are needed and to outline the procedure for a mass bug filing in the event that it is necessary.

  

  Everyone is busy, and package maintainers are often volunteers. Many maintainers also receive far too much email from bugzilla, so additional bugs are often not desired. A little extra effort up front can result in a smoother process for everyone, even though this can take a little longer. And often an actual mass bug filing can be avoided.

  

- Gain consensus of needed changes

- --------------------------------

+ == Gain consensus of needed changes

  

  First you should post to the Fedora devel list and gain consensus for the changes you want to make. No matter how simple or needed you might think they are, there may be better ways to do things or the change may not be needed for other reasons. Part of this discussion should be the development of a concise set of instructions which packagers will need to follow in order to fix the affected packages. This can of course refer to external documents but packagers should be able to get the basic idea of what changes are needed without having to chase down links.

  

- Indicate the packages which need to change

- ------------------------------------------

+ == Indicate the packages which need to change

  

  The set of packages which will need changes should be posted to the devel-announce list as soon as that set has been determined. To make things as easy as possible on the maintainers involved, this should take the form of two lists, one listing packages and their owners, and the other listing maintainers and their packages. This makes it trivial for a single maintainer to see how much work there is to do, and also for others to have an idea of who might need help. For convenience, a utility which will generate these lists given a file of package names is available from as "find-package-maintainers".

  

  These lists should be updated throughout the discussion as packages are fixed, and should also include the instructions for fixing the packages mentioned above.

  

- Automated cleanup

- -----------------

+ == Automated cleanup

  

  Automated package cleanup is encouraged. If it is possible to make the relevant change in an automated fashion with a low chance of unwanted side effects then this should at least be considered, even if that can only be done for a subset of the affected packages. The actual details of this process (such as whether builds are required or if the changes should simply be committed) are almost certainly dependent on the changes involved and should be worked out during the discussion. Proven packagers may perform automated cleanup without using pull requests by pushing directly to source control.

  

  [[review-announcement-bug-text]]

- Review announcement / bug text

- ------------------------------

+ == Review announcement / bug text

  

  Either ask the list or several interested maintainers to look over the text you intend to send to the devel-announce list (next step) and intend to use in your bug text. This will help make your text clear and understandable and free from typos or other simple errors. Make sure several people see your text and agree it describes the problem clearly along with solutions. This text should include the instructions developed above.

  

- Announce to devel-announce

- --------------------------

+ == Announce to devel-announce

  

  Once you have a clear idea of the changes needed, post a clear email on changes needed to the devel-announce list. Wait at least a week to allow maintainers to make changes or ask you further questions about the change on the devel list. If the change must be done due to some deadline, please note it in the email. If you intend to have provenpackager(s) or an automated process simply make the changes to all unchanged packages, please note that as well in the email.

  

- File tracker bug

- ----------------

+ == File tracker bug

  

  Now you can file a tracker bug in bugzilla and bugs against all the packages that still need changes. Note that you should check to make sure maintainers didn't already make the changes and only file bugs against those packages that didn't.

  

- Things to note in bugs

- ~~~~~~~~~~~~~~~~~~~~~~

+ === Things to note in bugs

  

  * Make sure you note what releases you consider must be fixed, or if only rawhide is fine.

  

@@ -1,28 +1,25 @@ 

- Package maintainer responsibilities

- ===================================

+ == Package maintainer responsibilities

+ :experimental:

+ :toc:

  

  link:Package_maintainer[Package maintainers] take care of the packages in Fedora. This includes both the packaging of upstream software into Fedora rpms and working with upstream to improve the software in various ways.

  

- How long to maintain?

- ---------------------

+ == How long to maintain?

  

  Each Fedora release lasts at least 13 months until it reaches end of life. A package maintainer is responsible for the package for at least this length of time. Refer to link:Fedora_Release_Life_Cycle[Fedora Release Life Cycle] for more details.

  

- Belong to the appropriate low-traffic mailing list

- --------------------------------------------------

+ == Belong to the appropriate low-traffic mailing list

  

  Package maintainers will receive important announcements through the moderated devel-announce mailing list. Maintainers will be automatically subscribed to this list. Everyone that is a primary maintainer of a package in Fedora is also strongly encouraged to subscribe to the devel list, though this is not mandatory.

  

- * https://admin.fedoraproject.org/mailman/listinfo/devel-announce

- * https://admin.fedoraproject.org/mailman/listinfo/devel

+ * link:https://admin.fedoraproject.org/mailman/listinfo/devel-announce[]

+ * link:https://admin.fedoraproject.org/mailman/listinfo/devel[]

  

- Manage security issues

- ----------------------

+ == Manage security issues

  

  * Package maintainer should handle security issues quickly, and if they need help they should contact the link:Security/ResponseTeam[Security Response Team].

  

- Work with upstream

- ------------------

+ == Work with upstream

  

  It is recommended that package maintainers work closely with upstream wherever possible. This can include:

  
@@ -33,8 +30,7 @@ 

  

  Refer to link:staying_close_to_upstream_projects[staying close to upstream projects] for more information on this.

  

- Work with Testing

- -----------------

+ == Work with Testing

  

  There are lots of places for package maintainers to interface with QA to improve the quality of Fedora. It is recommended that maintainers:

  
@@ -42,15 +38,13 @@ 

  * Provide test cases of general functionality, for use when testing for regressions

  * On update submission, provide test cases for things fixed in the update, for testers to use

  

- Deal with reported bugs in a timely manner

- ------------------------------------------

+ == Deal with reported bugs in a timely manner

  

- * If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the https://admin.fedoraproject.org/mailman/listinfo/devel[devel] and/or https://admin.fedoraproject.org/mailman/listinfo/test[test] lists. Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora. Consider reaching out for some (more) co-maintainers to assist as well.

+ * If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the link:https://admin.fedoraproject.org/mailman/listinfo/devel[devel] and/or link:https://admin.fedoraproject.org/mailman/listinfo/test[test] lists. Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora. Consider reaching out for some (more) co-maintainers to assist as well.

  * If there are bugs which you aren't capable of fixing yourself because they deal with intricacies of the source code which you don't fully understand, then you still need to address these bugs. It can be helpful to work with the upstream maintainer of the code, obtain help from more code-oriented people on fedora-devel, or check other distributions for patches. Always be sure to post to the bug report what you have done so that the reporter knows what it happening and what to expect. It is recommended that non-coder packagers should find co-maintainers who are familiar with the programming language used by their package(s), and can help with such bugs as a kind of 'second line support'.

  * Try and solve bugs or issues for the release against which they were reported, or if that is impractical note to bug reporters why their bug cannot be fixed in that release

  

- Package updates

- ---------------

+ == Package updates

  

  link:PackageMaintainers/Package_update_guidelines[Package update guidelines] provides guidance for maintainers updating packages on an already-released branch. In summary, however, maintainers should bear in mind that:

  
@@ -58,22 +52,19 @@ 

  2.  Fedora users who do not update automatically may review the descriptions attached to updates before choosing whether they should apply them.

  3.  Not all Fedora users have good Internet bandwidth available and may prefer a single update with multiple changes rather than many updates in a short period.

  

- Mentor and watch over co-maintainers

- ------------------------------------

+ == Mentor and watch over co-maintainers

  

  When you take on co-maintainers you enter into a partnership with them. They are able to work on the package which takes some of the burden off of you but you need to also be prepared to both help them along and make sure they aren't committing any grevious mistakes. So do be available to answer questions that the co-maintainers may have and also keep an eye on the changes they make to the package to keep issues from cropping up unexpectedly.

  

  Watching over the changes to your package also goes for changes made by people who are not explicit co-maintainers if you have opened your package for any packager to commit to.

  

- You can also take on co-maintainers that are not yet sponsored into the packager group provided that you agree to mentor them in the ways of packaging for Fedora: teaching them both about the tools we use and the https://fedoraproject.org/wiki/Packaging:Guidelines[ packaging guidelines] they need to follow. See the link:How_to_get_sponsored_into_the_packager_group#Become_a_comaintainer[ How to get sponsored page] for details on getting a new packager sponsored if you are not a sponsor yourself.

+ You can also take on co-maintainers that are not yet sponsored into the packager group provided that you agree to mentor them in the ways of packaging for Fedora: teaching them both about the tools we use and the link:https://fedoraproject.org/wiki/Packaging:Guidelines[ packaging guidelines] they need to follow. See the link:How_to_get_sponsored_into_the_packager_group#Become_a_comaintainer[ How to get sponsored page] for details on getting a new packager sponsored if you are not a sponsor yourself.

  

- Track dependency issues in a timely manner

- ------------------------------------------

+ == Track dependency issues in a timely manner

  

  * In Rawhide, updates to packages may cause other packages to have broken dependencies. Maintainers will be alerted when this happens, and should work to rebuild their packages with all due haste. Broken dependencies may leave end user systems in a state where no updates will be applied. In order to keep the distribution in a reasonable state, someone will step in and rebuild packages that have had dependency issues for some time, but package maintainers should not rely on these rebuilds.

  

- Notify others of changes that may affect their packages

- -------------------------------------------------------

+ == Notify others of changes that may affect their packages

  

  * Some packages are depended upon by others; in this case, changes to one package may cause issues for others. Maintainers should be aware of the effects that changes to their packages may have, and should alert to the fedora-devel-announce mailing list of updates which contain ABI or API changes which may cause dependency problems for other packages. The announcement should occur a week before the packages update, so all maintainers affected are notified. The announcement should include the following information:

  ** Nature of the change.
@@ -82,16 +73,14 @@ 

  ** List of packages which are affected by the change. Generally, this is merely the list of packages which depend directly on the package which is being updated, and can be found with `repoquery --whatrequires <package>` where `<package>` is the package being updated.

  ** If your package upgrade breaks other packages in Rawhide, you should try to help fix the packages affected. For example, if you're a provenpackager, queue the rebuilds yourself.

  

- Respect Schedules

- -----------------

+ == Respect Schedules

  

  Each Fedora release has a schedule indicating, among others, freezes such as string freeze : link:Releases/20/Schedule[see for example planning for F20]. When creating a new package or updating an existing package, the release planning has to be respected.

  

- Miscellaneous Items

- -------------------

+ == Miscellaneous Items

  

  * Maintainers need to maintain an upgrade path for their packages.

- 

+ +

  F(current-1) -> F(current) -> Rawhide

  

  * Packages should be pushed to the Rawhide branch first. If it builds and works fine for a few days, then it can be pushed to F(current). If there is a good reason to push it to F(current-1), it should be done after a few days of being in F(current).

@@ -1,29 +1,24 @@ 

- Packager sponsor responsibilities

- =================================

+ = Packager sponsor responsibilities

  

  Packager Sponsors are maintainers that have a good record of maintaining packages, doing reviews and assisting others with the processes and procedures of Fedora. Sponsors act as mentors for new contributors to help point them to areas they would like to contribute, assist them with processes and procedures and assist them when they need general guidance. Sponsors may also be called on by FESCo to talk to a contributor that doesn't seem to be living up to their xref:Package_maintainer_responsibilities.adoc[Package maintainer responsibilities]. Every Fedora package maintainer should have a sponsor.

  

  The following is an outline of some of the expectations of what a sponsor should be doing for their sponsorees. These are just ideas, a packager sponsor should generally plan on being able to help or direct the packager to a place to find help with any Fedora issues that may arise.

  

- Help answer maintainers' questions

- ----------------------------------

+ == Help answer maintainers' questions

  

- Packager sponsors should be available to their sponsored maintainers to answer questions. It's up to the sponsor if they wish to be available via IRC, email, bugzilla, mailing list posts, phone or the like. In the event a sponsor is unable to answer a question, they should escalate it to the appropriate mailing list, xref:index.adoc[FESCo], https://docs.fedoraproject.org/en-US/council/[Fedora Council] or the like and get an answer passed back.

+ Packager sponsors should be available to their sponsored maintainers to answer questions. It's up to the sponsor if they wish to be available via IRC, email, bugzilla, mailing list posts, phone or the like. In the event a sponsor is unable to answer a question, they should escalate it to the appropriate mailing list, xref:index.adoc[FESCo], link:https://docs.fedoraproject.org/en-US/council/[Fedora Council] or the like and get an answer passed back.

  

- Questions sponsors should answer in particular are all the questions related with practical aspects of Fedora (https://fedoraproject.org/wiki/Packaging:Guidelines[Packaging Guidelines], https://fedoraproject.org/wiki/Using_the_Koji_build_system[Build system], https://fedoraproject.org/wiki/Package_maintenance_guide[VCS], FAS, updates...).

+ Questions sponsors should answer in particular are all the questions related with practical aspects of Fedora (link:https://fedoraproject.org/wiki/Packaging:Guidelines[Packaging Guidelines], link:https://fedoraproject.org/wiki/Using_the_Koji_build_system[Build system], link:https://fedoraproject.org/wiki/Package_maintenance_guide[VCS], FAS, updates...).

  

- Guide the sponsored maintainer in the Fedora Project

- ----------------------------------------------------

+ == Guide the sponsored maintainer in the Fedora Project

  

  Packager sponsors should also be able to guide (or coerce) the sponsored packager in other aspects of Fedora. For example, point to xref:Package_maintainer_responsibilities.adoc[maintainer policies] appropriately, help the sponsored maintainer to feel at ease in the Fedora community, and explain what Fedora is and what it is not.

  

- Fix issues in sponsored maintainers' packages

- ---------------------------------------------

+ == Fix issues in sponsored maintainers' packages

  

  If one of your sponsored maintainers is unable to fix an issue in their package(s) you should be able to step in and either provide a fix or help them find a fix from other resources. This might include pushing a security update when the maintainer is unavailable, applying a patch, removing an improperly built package, or other time or security sensitive issue. It could also mean sending a message to the devel list asking for help or coaching the packager in finding the upstream mailing list and requesting help there. Note that the maintainer should be shown the fix and how to manage the issue moving forward.

  

- Revoking Sponsorship

- --------------------

+ == Revoking Sponsorship

  

  A sponsor may elect to revoke their sponsorship of a maintainer in rare and extreme situations.

  
@@ -31,13 +26,12 @@ 

  

  FESCo should be notified of the reasons why a sponsorship is being revoked.

  

- Sponsorship Duration

- --------------------

+ == Sponsorship Duration

  

  Sponsorship of a maintainer begins when the Sponsor approves them in the Fedora Account System.

+ 

  Sponsorship of a maintainer ends when that sponsorship is revoked or when that maintainer themselves becomes a Sponsor.

  

- Who Sponsors the Sponsors?

- --------------------------

+ == Who Sponsors the Sponsors?

  

- Once a maintainer has been granted sponsorship status (via a vote of existing sponsors), that Sponsor will be held accountable by FESCO and not their previous Sponsor. https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor#Becoming_a_Fedora_Package_Collection_Sponsor[More on becoming a sponsor].

+ Once a maintainer has been granted sponsorship status (via a vote of existing sponsors), that Sponsor will be held accountable by FESCO and not their previous Sponsor. link:https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor#Becoming_a_Fedora_Package_Collection_Sponsor[More on becoming a sponsor].

@@ -1,48 +1,42 @@ 

- Passphrase policy

- =================

+ = Passphrase policy

  

  Policy for initially setting or changing local passphrases/passwords in Fedora installs.

  

  [[introduction]]

- Introduction

- ------------

+ == Introduction

  

- This policy is for applications that set or change passphrases/passwords locally on Fedora installations. One central place for policy for passphrases was desired and that is now in the libpwquality package. This package ships defaults for Fedora as decided by FESCo. Fedora products can override the defaults by creating their own /etc/security/pwquality.conf.d/ configuration file. The local administrators can set their own policy in the master /etc/security/pwquality.conf file.

+ This policy is for applications that set or change passphrases/passwords locally on Fedora installations. One central place for policy for passphrases was desired and that is now in the `libpwquality` package. This package ships defaults for Fedora as decided by FESCo. Fedora products can override the defaults by creating their own `/etc/security/pwquality.conf.d/` configuration file. The local administrators can set their own policy in the master `/etc/security/pwquality.conf` file.

  

  [[scope]]

- Scope

- -----

+ == Scope

  

  This policy is only for applications that set or change local passwords/passphrases. It has nothing to do with remote/central authentication stores, which can and do still have their own policies.

  

  [[summary-of-defaults]]

- Summary of defaults

- -------------------

+ == Summary of defaults

  

  * passwords/passphrases must be at least 8 characters long.

  

  * passwords/passphrases must have at least 1 character different from previous existing password/passphrase (if applicable).

  

- * passwords that fail to pass libpwquality should display the failure to the user.

+ * passwords that fail to pass `libpwquality` should display the failure to the user.

  

  * root / admin users should be able to override quality checks (for purposes of this, the installing user is root/admin)

  

- * applications may use the libpwquality 'score' to display an analog strength meter to users as an informational tool, but should not use score as a decision making factor for acceptance.

+ * applications may use the `libpwquality` 'score' to display an analog strength meter to users as an informational tool, but should not use score as a decision making factor for acceptance.

  

  [[applications-covered]]

- Applications covered

- --------------------

+ == Applications covered

  

- * anaconda

+ * `anaconda`

  

- * passwd, anything using pam (such as login for changing expired passwords)

+ * `passwd`, anything using `pam` (such as login for changing expired passwords)

  

- * gnome-initial-setup

+ * `gnome-initial-setup`

  

  [[references]]

- References

- ----------

+ == References

  

- https://fedorahosted.org/fesco/ticket/1455

+ * link:https://fedorahosted.org/fesco/ticket/1455[#1455 F23 System Wide Change: Standardized Passphrase Policy]

  

- https://fedoraproject.org/wiki/Changes/Standardized_passphrase_policy

+ * link:https://fedoraproject.org/wiki/Changes/Standardized_passphrase_policy[Changes/Standardized passphrase policy]

@@ -1,65 +1,59 @@ 

- Non-responsive maintainer policy

- ================================

+ = Non-responsive maintainer policy

+ :experimental:

+ :toc:

  

  [[purpose]]

- Purpose

- -------

+ == Purpose

  

  The purpose for this policy is to provide a mechanism within Fedora to handle situations when a package maintainer becomes unavailable to continue maintainership, often referred to as non-responsive. The end goal is to help prevent packages becoming stale through non-maintenance, reduce open bugs on non-maintained packages and assist in the overall quality of Fedora.

  

  [[coverage]]

- Coverage

- --------

+ == Coverage

  

- This policy covers existing Fedora packages; for non-responsive package submitters or reviewers, see the https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews[Policy for stalled package reviews]. This mechanism is not limited to existing Fedora contributors. For non-contributors, see below for instructions.

+ This policy covers existing Fedora packages; for non-responsive package submitters or reviewers, see the link:https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews[Policy for stalled package reviews]. This mechanism is not limited to existing Fedora contributors. For non-contributors, see below for instructions.

  

  The policy is targeted at maintainers that can still be reached through the mail they have registered in fedora. If the mail of the maintainer has changed in a way that seems permanent, and cannot be contacted (with reasonable effort), this policy also applies. If there is no known way of contacting the former maintainer, or they are not willing to make the required change in the packagedb, one can short-circuit the normal 3 week interval required in the Outline steps 1 to 3, and make the formal request to orphan mentioned in step 4.

  

  [[outline]]

- Outline

- -------

+ == Outline

  

  When a Fedora member notices that a maintainer isn't answering their bugs, not answering rebuild requests, src.fedoraproject.org pull requests, emails or the like, these steps should be followed:

  

- 1.  Check if the non-responsive maintainer is on https://fedoraproject.org/wiki/Vacation[vacation]. To see if the maintainer has been recently active on Fedora, https://github.com/pypingou/fedora-active-user[fedora-active-user] can be employed.

- 2.  File a bug against the package in https://bugzilla.redhat.com/[Bugzilla] asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a *must*.

- 3.  After every 7 days, the reporter adds a comment to the bug report asking again for a response. Others can add to the bug that they also were not successful in contacting the maintainer, or providing additional contact information for the maintainer (i.e., alternative email, IRC, etc).

- 4.  After 2 failed attempts (2 weeks of no response from the maintainer), the reporter posts to the Fedora https://admin.fedoraproject.org/mailman/listinfo/devel[devel list] with a link to the bug report and asks if anyone knows how to contact the maintainer.

- 5.  After other 7 days (now 3 weeks total), the reporter creates a https://pagure.io/fesco/new_issue[FESCo issue] with the bug link, indicating all reasonable efforts to contact the maintainer have failed and that they wish to take over the package.

- 6.  If at least one FESCo member approves the takeover, and no one objects within 3 days, the reporter may take over the package.

- 7.  Once approval has been given, follow https://fedoraproject.org/wiki/PackageDB_admin_requests[PackageDB admin requests] to request ownership of the package. In addition to this, the new owner must also reassign all open bugs for this package to themselves.

+ .  Check if the non-responsive maintainer is on link:https://fedoraproject.org/wiki/Vacation[vacation]. To see if the maintainer has been recently active on Fedora, link:https://github.com/pypingou/fedora-active-user[fedora-active-user] can be employed.

+ .  File a bug against the package in link:https://bugzilla.redhat.com/[Bugzilla] asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a *must*.

+ .  After every 7 days, the reporter adds a comment to the bug report asking again for a response. Others can add to the bug that they also were not successful in contacting the maintainer, or providing additional contact information for the maintainer (i.e., alternative email, IRC, etc).

+ .  After 2 failed attempts (2 weeks of no response from the maintainer), the reporter posts to the Fedora link:https://admin.fedoraproject.org/mailman/listinfo/devel[devel list] with a link to the bug report and asks if anyone knows how to contact the maintainer.

+ .  After other 7 days (now 3 weeks total), the reporter creates a link:https://pagure.io/fesco/new_issue[FESCo issue] with the bug link, indicating all reasonable efforts to contact the maintainer have failed and that they wish to take over the package.

+ .  If at least one FESCo member approves the takeover, and no one objects within 3 days, the reporter may take over the package.

+ .  Once approval has been given, follow link:https://fedoraproject.org/wiki/PackageDB_admin_requests[PackageDB admin requests] to request ownership of the package. In addition to this, the new owner must also reassign all open bugs for this package to themselves.

  

- If you are a not an existing Fedora contributor, you can still take over a package. All of the above *must* be followed. When you seek approval for the takeover, you, again, *must* provide a Bugzilla report as if it were a new Fedora package review. This will allow the normal review process to happen -- that includes finding a sponsor that believes you understand the packaging rules. Information on sponsorship is at https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group[How to get sponsored into the packager group] and the full process for becoming a contributor to Fedora is at https://fedoraproject.org/wiki/Join_the_package_collection_maintainers[Join the package collection maintainers]. You'll probably want to start from https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request[creating your review request]. You can peruse the https://fedoraproject.org/wiki/Packaging:Guidelines[packaging guidelines].

+ If you are a not an existing Fedora contributor, you can still take over a package. All of the above *must* be followed. When you seek approval for the takeover, you, again, *must* provide a Bugzilla report as if it were a new Fedora package review. This will allow the normal review process to happen -- that includes finding a sponsor that believes you understand the packaging rules. Information on sponsorship is at link:https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group[How to get sponsored into the packager group] and the full process for becoming a contributor to Fedora is at link:https://fedoraproject.org/wiki/Join_the_package_collection_maintainers[Join the package collection maintainers]. You'll probably want to start from link:https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request[creating your review request]. You can peruse the link:https://fedoraproject.org/wiki/Packaging:Guidelines[packaging guidelines].

  

- Notes for mass orphaning

- ------------------------

+ == Notes for mass orphaning

  

  * It is common for a Fedora contributor to maintain multiple packages within Fedora, and the situation may arise where multiple packages with a single maintainer need to be orphaned. Given that, it would be quite impractical to create a Bugzilla ticket for each package. In the case where a mass orphaning is likely, the above should still be followed by choosing a single package owned by the potential non-responsive developer. However, the formal request to the Fedora development mailing list should include all other bug reports open on all neglected packages from the same maintainer, indicating that the maintainer is indeed non-responsive. The Steering Committee can then step in and orphan the other packages if necessary.

  

  [[notes-for-maintainers]]

- Notes for maintainers

- ---------------------

+ == Notes for maintainers

  

  It is understood that maintainers will go on vacation or will otherwise be unavailable for possibly significant lengths of time. There are a couple of things that maintainers should consider doing if they know in advance that they will be unavailable;

  

- * Designate a co-maintainer. Currently there is no policy on the exact details of this, but, in general, another Fedora contributor can be asked to maintain the package in the maintainer's absence. To add a co-maintainer, have the co-maintainer request commit rights in the https://admin.fedoraproject.org/pkgdb/[Package Database] and approve the request.

+ * Designate a co-maintainer. Currently there is no policy on the exact details of this, but, in general, another Fedora contributor can be asked to maintain the package in the maintainer's absence. To add a co-maintainer, have the co-maintainer request commit rights in the link:https://admin.fedoraproject.org/pkgdb/[Package Database] and approve the request.

  

  * Edit the Vacation page to indicate when you will be away.

  

  [[notes-for-invalid-email-addresses]]

- Notes for invalid email addresses

- ---------------------------------

+ == Notes for invalid email addresses

  

  bugzilla.redhat.com uses the email address in the Fedora Account System to send messages to the package maintainer. If it becomes known that this email address no longer goes to the package maintainer the policy may be short-circuited. Start with Step #4 in the Outline. If the maintainer hasn't become responsive at the end of that process FESCo will mass orphan all packages they own.

  

  Situations where it becomes known that an email address is no longer going to go to the maintainer are:

  

- 1.  Email to the address bounces (to differentiate from temporary bounces like a mailbox full, this should go on for a period of 7 days)

- 2.  Red Hat lets us know that an email address is no longer valid for the package maintainer (usually because the person has left Red Hat).

+ .  Email to the address bounces (to differentiate from temporary bounces like a mailbox full, this should go on for a period of 7 days)

+ .  Red Hat lets us know that an email address is no longer valid for the package maintainer (usually because the person has left Red Hat).

  

  [[exception-procedure]]

- Exception procedure

- -------------------

+ == Exception procedure

  

  There are some cases where it may be needed to reassign a package even if

  this procedure has not yet finished. Examples include when many dependencies
@@ -70,13 +64,12 @@ 

  

  Steps:

  

- 1.  Explain why the exception process is needed and note all communication attempts in an email to the devel@lists.fedoraproject.org list with the non-responsive maintainer CC'ed on the email.

- 2.  Mention and maintainers FAS account (after an '@' sign) and describe the situation in a new ticket with the 'meeting' label to notify FESCo to discuss the situation during the next xref:index.adoc#_meetings[meeting].

- 3.  The next FESCo meeting will discuss the case and reach a decision.

+ .  Explain why the exception process is needed and note all communication attempts in an email to the devel@lists.fedoraproject.org list with the non-responsive maintainer CC'ed on the email.

+ .  Mention and maintainers FAS account (after an '`@`' sign) and describe the situation in a new ticket with the 'meeting' label to notify FESCo to discuss the situation during the next xref:index.adoc#_meetings[meeting].

+ .  The next FESCo meeting will discuss the case and reach a decision.

  

  [[orphaning-process]]

- Orphaning process

- -----------------

+ == Orphaning process

  

  Unless there is a reason not to (the maintainer's email is bouncing, the maintainer has told someone that they are not interested in continuing to maintain Fedora packages) we will make the maintainer a comaintainer on the package in all branches they were an owner. Then we will orphan the packages.

  

@@ -1,11 +1,11 @@ 

- Previous Fedora Engineering Steering Committee Members

- ======================================================

+ = Previous Fedora Engineering Steering Committee Members

+ :experimental:

+ :toc:

  

  The following are the members of previous FESCos.

  

  [[members-of-match-2018---june-2019]]

- Members of March 2018 - June 2019

- -------------------------------------

+ == Members of March 2018 - June 2019

  

  * https://fedoraproject.org/wiki/User:Kevin[Kevin Fenzi] (nirik) — F30/F31

  * https://fedoraproject.org/wiki/User:bowlofeggs[Randy Barlow] (bowlofeggs) — F29/F30
@@ -18,8 +18,7 @@ 

  * https://fedoraproject.org/wiki/User:Bookwar[Aleksandra Fedorova] (bookwar) — F30

  

  [[members-of-december-2018---march-2019]]

- Members of December 2018 - March 2019

- -------------------------------------

+ == Members of December 2018 - March 2019

  

  * https://fedoraproject.org/wiki/User:Kevin[Kevin Fenzi] (nirik) — F30/F31

  * https://fedoraproject.org/wiki/User:bowlofeggs[Randy Barlow] (bowlofeggs) — F29/F30
@@ -32,8 +31,7 @@ 

  * https://fedoraproject.org/wiki/User:otaylor[Owen Taylor] (otaylor) — F30/F31

  

  [[members-of-june-2018---december-2018]]

- Members of June 2018 - December 2018

- ------------------------------------

+ == Members of June 2018 - December 2018

  

  * https://fedoraproject.org/wiki/User:Kevin[Kevin Fenzi] (nirik) — F28/F29

  * https://fedoraproject.org/wiki/User:bowlofeggs[Randy Barlow] (bowlofeggs) — F29/F30
@@ -46,8 +44,7 @@ 

  * https://fedoraproject.org/wiki/User:Psabata[Petr Šabata] (contyk/psabata) — F29/F30

  

  [[members-of-august-2017---june-2018]]

- Members of August 2017 - June 2018

- ----------------------------------

+ == Members of August 2017 - June 2018

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik) - F28/F29

  * https://fedoraproject.org/wiki/User:bowlofeggs[ Randy Barlow] (bowlofeggs) - F27/F28
@@ -60,8 +57,7 @@ 

  * https://fedoraproject.org/wiki/User:Sgallagh[ Stephen Gallagher] (sgallagh) - F27/F28

  

  [[members-of-january-2017---august-2017]]

- Members of January 2017 - August 2017

- -------------------------------------

+ == Members of January 2017 - August 2017

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik) - F26/F27

  * https://fedoraproject.org/wiki/User:Jwboyer[ Josh Boyer] (jwb) - F25/F26
@@ -74,8 +70,7 @@ 

  * https://fedoraproject.org/wiki/User:Sgallagh[ Stephen Gallagher] (sgallagh) - F25/F26

  

  [[members-of-july-2016---january-2017]]

- Members of July 2016 - January 2017

- -----------------------------------

+ == Members of July 2016 - January 2017

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik) - F24/F25

  * https://fedoraproject.org/wiki/User:Jwboyer[ Josh Boyer] (jwb) - F25/F26
@@ -88,8 +83,7 @@ 

  * https://fedoraproject.org/wiki/User:Sgallagh[ Stephen Gallagher] (sgallagh) - F25/F26

  

  [[members-of-december-2015---july-2016]]

- Members of December 2015 - July 2016

- ------------------------------------

+ == Members of December 2015 - July 2016

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik) - F24/F25

  * https://fedoraproject.org/wiki/User:Jwboyer[ Josh Boyer] (jwb) - F23/F24
@@ -102,8 +96,7 @@ 

  * https://fedoraproject.org/wiki/User:Sgallagh[ Stephen Gallagher] (sgallagh) - F23/F24

  

  [[members-of-june-2015---december-2015]]

- Members of June 2015 - December 2015

- ------------------------------------

+ == Members of June 2015 - December 2015

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik) - F22/F23

  * https://fedoraproject.org/wiki/User:Jwboyer[ Josh Boyer] (jwb) - F23/F24
@@ -116,8 +109,7 @@ 

  * https://fedoraproject.org/wiki/User:Sgallagh[ Stephen Gallagher] (sgallagh) - F23/F24

  

  [[members-of-february-2015---june-2015]]

- Members of February 2015 - June 2015

- ------------------------------------

+ == Members of February 2015 - June 2015

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik) - F22/F23

  * https://fedoraproject.org/wiki/User:Jwboyer[ Josh Boyer] (jwb) - F21/F22
@@ -130,8 +122,7 @@ 

  * https://fedoraproject.org/wiki/User:Rishi[ Debarshi Ray] (rishi) - F22/F23

  

  [[members-of-feb-2014---february-2015-after-special-elections-in-june]]

- Members of Feb 2014 - February 2015 (after special elections in June)

- ---------------------------------------------------------------------

+ == Members of Feb 2014 - February 2015 (after special elections in June)

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik) - F20/F21

  * https://fedoraproject.org/wiki/User:Jwboyer[ Josh Boyer] (jwb) - F21/F22
@@ -144,8 +135,7 @@ 

  * https://fedoraproject.org/wiki/User:Sgallagh[ Stephen Gallagher] (sgallagh) - F21/F22

  

  [[members-of-fifteenth-fesco-jun-2013---feb-2014]]

- Members of Fifteenth FESco (Jun 2013 - Feb 2014)

- ------------------------------------------------

+ == Members of Fifteenth FESco (Jun 2013 - Feb 2014)

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik)

  * https://fedoraproject.org/wiki/User:Notting[ Bill Nottingham] (notting)
@@ -158,8 +148,7 @@ 

  * https://fedoraproject.org/wiki/User:Sgallagh[ Stephen Gallagher] (sgallagh)

  

  [[members-of-eleventh-fesco-dec-2011---current]]

- Members of Eleventh FESco (Dec 2011 - current)

- ----------------------------------------------

+ == Members of Eleventh FESco (Dec 2011 - current)

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik)

  * https://fedoraproject.org/wiki/User:Notting[ Bill Nottingham] (notting)
@@ -174,8 +163,7 @@ 

  Chair is rotating.

  

  [[members-of-tenth-fesco-jun-2011---dec-2011]]

- Members of Tenth FESco (Jun 2011 - Dec 2011)

- --------------------------------------------

+ == Members of Tenth FESco (Jun 2011 - Dec 2011)

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik)

  * https://fedoraproject.org/wiki/User:Notting[ Bill Nottingham] (notting)
@@ -190,8 +178,7 @@ 

  Chair is rotating.

  

  [[members-of-ninth-fesco-jan-2011---jun-2011]]

- Members of Ninth FESCo (Jan 2011 - Jun 2011)

- --------------------------------------------

+ == Members of Ninth FESCo (Jan 2011 - Jun 2011)

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik) (Chair)

  * https://fedoraproject.org/wiki/User:Notting[ Bill Nottingham] (notting)
@@ -204,8 +191,7 @@ 

  * https://fedoraproject.org/wiki/User:Mmaslano[Marcela Mašláňová] (mmaslano)

  

  [[members-of-eighth-fesco-may-2010---dec-2010]]

- Members of Eighth FESCo (May 2010 - Dec 2010)

- ---------------------------------------------

+ == Members of Eighth FESCo (May 2010 - Dec 2010)

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik) (Chair)

  * https://fedoraproject.org/wiki/User:Notting[ Bill Nottingham] (notting)
@@ -218,8 +204,7 @@ 

  * https://fedoraproject.org/wiki/User:Pjones[Peter Jones] (pjones)

  

  [[members-of-seventh-fesco-jan-2010---may-2010]]

- Members of Seventh FESCo (Jan 2010 - May 2010)

- ----------------------------------------------

+ == Members of Seventh FESCo (Jan 2010 - May 2010)

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik) (Chair)

  * https://fedoraproject.org/wiki/User:Ausil[ Dennis Gilmore] (dgilmore)
@@ -232,14 +217,12 @@ 

  * https://fedoraproject.org/wiki/User:Mjg59[ Matthew Garrett] (mjg59)

  

  [[members-of-sixth-fesco-jul-2009---dec-2009]]

- Members of Sixth FESCo (Jul 2009 - Dec 2009)

- --------------------------------------------

+ == Members of Sixth FESCo (Jul 2009 - Dec 2009)

  

  * https://fedoraproject.org/wiki/User:Jwboyer[ Josh Boyer] (jwb) - left FESCo in November 2009

  

  [[members-of-fifth-fesco-dec-2008---jul-2009]]

- Members of Fifth FESCo (Dec 2008 - Jul 2009)

- --------------------------------------------

+ == Members of Fifth FESCo (Dec 2008 - Jul 2009)

  

  * https://fedoraproject.org/wiki/User:Jwboyer[ Josh Boyer] (jwb)

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik)
@@ -252,8 +235,7 @@ 

  * https://fedoraproject.org/wiki/User:Dwmw2[ David Woodhouse] (dwmw2)

  

  [[members-of-fourth-fesco-jul-2008---dec-2008]]

- Members of fourth FESCo (Jul 2008 - Dec 2008)

- ---------------------------------------------

+ == Members of fourth FESCo (Jul 2008 - Dec 2008)

  

  * https://fedoraproject.org/wiki/User:Kevin[ Kevin Fenzi] (nirik)

  * https://fedoraproject.org/wiki/User:Bpepple[ Brian Pepple] (bpepple) (chair)
@@ -266,8 +248,7 @@ 

  * https://fedoraproject.org/wiki/User:Jwilson[ Jarod Wilson] (j-rod)

  

  [[members-of-third-fesco-jul-2007---jul-2008]]

- Members of third FESCo (Jul 2007 - Jul 2008)

- --------------------------------------------

+ == Members of third FESCo (Jul 2007 - Jul 2008)

  

  * https://fedoraproject.org/wiki/User:Katzj[ Jeremy Katz] (jeremy)

  * https://fedoraproject.org/wiki/User:Spot[ Tom Callaway] (spot)
@@ -284,8 +265,7 @@ 

  * https://fedoraproject.org/wiki/User:Caillon[ Christopher Aillon] (caillon)

  

  [[members-of-second-fesco-jun-2006---jul-2007]]

- Members of second FESCo (Jun 2006 - Jul 2007)

- ---------------------------------------------

+ == Members of second FESCo (Jun 2006 - Jul 2007)

  

  * https://fedoraproject.org/wiki/User:Thl[ Thorsten Leemhuis] (thl) - chair until January 2007; left FESCo in February 2007 as being a member of FESCo became conflicting with his day job due to the Core and Extras merge

  * VilleSkyttä (scop) -- left FESCo in January 2007
@@ -305,8 +285,7 @@ 

  * BillNottingham (notting)

  

  [[members-of-the-original-fesco-feb-2005---jun-2006]]

- Members of the original FESCo (Feb 2005 - Jun 2006)

- ---------------------------------------------------

+ == Members of the original FESCo (Feb 2005 - Jun 2006)

  

  * AdrianReber (adrianr)

  * ColinCharles (bytee)

@@ -1,17 +1,15 @@ 

- Policy for provenpackagers

- ==========================

+ = Policy for provenpackagers

  

- Provenpackagers are members of the 'provenpackager' group. In addition to the rights granted to members of 'packager', provenpackagers are able to commit changes to packages they do not own or maintain. They are a group of skilled package maintainers who are experienced in a wide variety of package types and who are familiar with the https://fedoraproject.org/wiki/Packaging:Guidelines[packaging guidelines] and xref:Package_maintainer_responsibilities.adoc[package maintainer policies], as well as acutely aware of https://fedoraproject.org/wiki/Releases/Schedule[release schedule] and https://fedoraproject.org/wiki/ReleaseEngineering#Freeze_Policies[freeze policies].

+ Provenpackagers are members of the 'provenpackager' group. In addition to the rights granted to members of 'packager', provenpackagers are able to commit changes to packages they do not own or maintain. They are a group of skilled package maintainers who are experienced in a wide variety of package types and who are familiar with the link:https://fedoraproject.org/wiki/Packaging:Guidelines[packaging guidelines] and xref:Package_maintainer_responsibilities.adoc[package maintainer policies], as well as acutely aware of link:https://fedoraproject.org/wiki/Releases/Schedule[release schedule] and link:https://fedoraproject.org/wiki/ReleaseEngineering#Freeze_Policies[freeze policies].

  

- Provenpackagers lend a hand when help is needed, always with a desire to improve the quality of Fedora. Provenpackagers should try to communicate with owners of a package in bugzilla, irc or email prior to making changes. They should be careful not to change other people's packages needlessly and try to do the minimal changes required to fix problems, as explained more in depth in the policy explaining https://fedoraproject.org/wiki/who_is_allowed_to_modify_which_packages[who is allowed to modify which packages]. To exclude a package from provenpackagers access, you have to open a ticket at https://pagure.io/fesco/new_issue[FESCo issue tracker] and explain why provenpackagers should not have access to it. xref:index.adoc[FESCo] will discuss and vote on one of its weekly meetings about your request.

+ Provenpackagers lend a hand when help is needed, always with a desire to improve the quality of Fedora. Provenpackagers should try to communicate with owners of a package in bugzilla, irc or email prior to making changes. They should be careful not to change other people's packages needlessly and try to do the minimal changes required to fix problems, as explained more in depth in the policy explaining link:https://fedoraproject.org/wiki/who_is_allowed_to_modify_which_packages[who is allowed to modify which packages]. To exclude a package from provenpackagers access, you have to open a ticket at link:https://pagure.io/fesco/new_issue[FESCo issue tracker] and explain why provenpackagers should not have access to it. xref:index.adoc[FESCo] will discuss and vote on one of its weekly meetings about your request.

  

- Becoming provenpackager

- -----------------------

+ == Becoming provenpackager

  

  To become a member of the 'provenpackager' group, the procedure is the following:

  

- 1.  File a ticket in the https://pagure.io/fesco/issues[FESCo issue tracker] indicating why you wish to become a provenpackager.

- 2.  A FESCo member will send an e-mail to the sponsors, so they are aware about the ticket.

- 3.  Sponsors vote in the FESCo ticket.

- 4.  You must get at least 3 positive votes from sponsors with no negative votes, over a one week review period, to be approved.

- 5.  If you haven’t been approved after one week, FESCo will vote (normal FESCo voting machanism applies).

+ .  File a ticket in the link:https://pagure.io/fesco/issues[FESCo issue tracker] indicating why you wish to become a provenpackager.

+ .  A FESCo member will send an e-mail to the sponsors, so they are aware about the ticket.

+ .  Sponsors vote in the FESCo ticket.

+ .  You must get at least 3 positive votes from sponsors with no negative votes, over a one week review period, to be approved.

+ .  If you haven’t been approved after one week, FESCo will vote (normal FESCo voting machanism applies).

@@ -1,24 +1,21 @@ 

- Third party repository policy

- =============================

+ = Third party repository policy

  

  End users sometimes want to install software that is not provided by Fedora. This policy lays out the extent to which Fedora Products can make it easier for end users to do that.

  

  At the moment, FESCo policy is that no third party repositories can be configured in package managers in Fedora. However, Fedora may ship application search software that searches for applications in some specific third party repositories in addition to the Fedora Main Repository and install packages from them. This application search software can search for applications in these specific third party repositories as long as the user is explicitly asked to enable the repository before installing packages from them.

  

- Copr Repositories

- -----------------

+ == Copr Repositories

  

  Fedora allows contributors to build rpms and host the output in some repositories on our servers. These are known as Copr repositories. Packages in these repositories are not held to the same packaging standards as packages in the Main Fedora Repositories but they are all held to the same Licensing and Legal requirements. Fedora Legal has the authority to remove packages from the Copr repositories or have problematic Copr repositories removed as Red Hat is liable for any legal issues that may arise here. Due to this relationship, we are a little more flexible in our policy for Copr repositories than other third party repositories.

  

  * The COPR Repositories can provide RPMS with .repo files pointing to themselves because Red Hat is the provider and assumes liability

- * It is permissible to ship RPM packages containing .repo files that point to COPR repositories in the Fedora package collection under the following conditions per https://fedorahosted.org/fesco/ticket/1421[FESCo decree]:

- ** The repo file has the setting enabled=0. This means that yum, dnf and other tools cannot install software from this repository without a manual step (such as --enablerepo=)

- ** The repo file has the setting enabled_metadata=1. This means that some tools can optionally retrieve the metadata from this repository to provide a list of its contents to the user. The option is not used by yum or dnf.

+ * It is permissible to ship RPM packages containing .repo files that point to COPR repositories in the Fedora package collection under the following conditions per link:https://fedorahosted.org/fesco/ticket/1421[FESCo decree]:

+ ** The repo file has the setting `enabled=0`. This means that yum, dnf and other tools cannot install software from this repository without a manual step (such as `--enablerepo=`)

+ ** The repo file has the setting `enabled_metadata=1`. This means that some tools can optionally retrieve the metadata from this repository to provide a list of its contents to the user. The option is not used by yum or dnf.

  

  Application installers in the main Fedora repositories may search COPR repos for applications to install as long as they explicitly ask the user to enable the copr repository as noted in the introductory section.

  

- Other Repositories with only free (libre) software

- --------------------------------------------------

+ == Other Repositories with only free (libre) software

  

  Of course, Fedora doesn't have the only software repositories that contain free (libre) software. There are other third party repositories that Fedora users want to use. Since Red Hat has no relationship with these repositories as it does with Copr repositories, allowing things in Fedora to point users to these repositories would represent a new legal liability. Fedora Legal would need to audit the packages in these repositories for legal problems both when the repositories are initially approved and on an ongoing basis (as the software in the repositories is updated, Fedora Legal would need to check that the new versions of packages in the repository remained legally okay for us to point people at.) For this reason, the rules for including a non-Copr third party repository are more strict than for Copr repos.

  
@@ -29,8 +26,7 @@ 

  

  Application installers in the main Fedora repositories may search repositories that are currently approved under the above list as long as they explicitly ask the user to enable the third party repository as noted in the introductory section.

  

- Repositories with non-free (libre) software

- -------------------------------------------

+ == Repositories with non-free (libre) software

  

  Repositories that contain non-free software may be offered to users under the following conditions:

  

@@ -1,39 +1,37 @@ 

- Updates policy

- ==============

+ = Updates policy

  

  Fedora has differing policies for each of its branches. This document describes for maintainers what

  sort of updates should be created in packages for each of the various branches of existing Fedora.

  In the event of questions or clarifications, please file a

- https://fedorahosted.org/fesco/newticket[FESCo trac ticket] or discuss on the devel list. In

+ link:https://fedorahosted.org/fesco/newticket[FESCo trac ticket] or discuss on the devel list. In

  general, releases should go from less conservative (rawhide) to more so (the oldest supported stable

  release). This document attempts to describe when and what kinds of updates maintainers should push

  to Fedora users of its various branches. The

- https://fedoraproject.org/wiki/Stable_release_updates_vision[Stable release updates vision] from the

+ link:https://fedoraproject.org/wiki/Stable_release_updates_vision[Stable release updates vision] from the

  Fedora Board includes more high level discussion and philosophy, while this

  document is more a practical guide. Refer to

- https://fedoraproject.org/wiki/Package_update_HOWTO[Package update HOWTO] for the technical steps on

- pushing the updates. The https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[Fedora Release

+ link:https://fedoraproject.org/wiki/Package_update_HOWTO[Package update HOWTO] for the technical steps on

+ pushing the updates. The link:https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[Fedora Release

  Life Cycle] provides a more detailed overview of the development process.

  

- Rawhide / devel / master

- ------------------------

+ == Rawhide / devel / master

  

- https://fedoraproject.org/wiki/Releases/Rawhide[Rawhide] is the always-rolling development tree.

+ link:https://fedoraproject.org/wiki/Releases/Rawhide[Rawhide] is the always-rolling development tree.

  Package updates built for rawhide are composed every day and pushed out to all rawhide consumers.

- There are no "updates" or "updates-testing" Repositories for rawhide. The Bodhi updates system is

+ There are no "`updates`" or "`updates-testing`" Repositories for rawhide. The Bodhi updates system is

  not used. New builds against this tree also are added to the build root (ie, other packages build

  from them) daily (usually).

  

- repos available: https://fedoraproject.org/wiki/Repositories#rawhide[_rawhide_]

+ repos available: link:https://fedoraproject.org/wiki/Repositories#rawhide[_rawhide_]

  

  For updates to rawhide packages, Maintainers SHOULD:

  

  * Try not to push a clearly broken build (breaks the default buildroot package set, etc)

  * When a proposed update contains an ABI or API change: notify *a week in advance* both fedora-devel

-   and maintainers directly (using the _packagename-owner@_ alias) whose packages depend on yours to

+   and maintainers directly (using the` _packagename-owner@_` alias) whose packages depend on yours to

    rebuild or offer to do these rebuilds for them.

  * Use a separate buildsystem tag when dealing with mass builds of many packages, so they can land at

-   the same time. File a ticket with https://fedorahosted.org/rel-eng/newticket for this.

+   the same time. File a ticket with link:https://fedorahosted.org/rel-eng/newticket[rel-eng] for this.

  * Feel free to push out the newest version of packages as long as they do not cause breakage. Also

    keep in mind when the next Fedora release will be branched off, and be fairly confident that there

    will be a stable enough release in time for the next Fedora release. Otherwise you may have to
@@ -44,10 +42,9 @@ 

    here. The benefits of the early real-world testing of and upstream collaboration on these key

    packages far exceeds the risks that they may introduce.

  

- Branched release

- ----------------

+ == Branched release

  

- A https://fedoraproject.org/wiki/Releases/Branched[Branched] release exists for part of the

+ A link:https://fedoraproject.org/wiki/Releases/Branched[Branched] release exists for part of the

  development cycle. It is branched off Rawhide and eventually becomes the next stable release.

  After the <<bodhi-enabling>> point, Branched releases do use the update feedback system (Bodhi).

  There are several "phases" that a branched release goes through that affect what updates can and
@@ -55,42 +52,39 @@ 

  for the next release, so changes should be careful and considered and heading toward stability.

  

  [[branched-pre-bodhi-enabling]]

- https://fedoraproject.org/wiki/Releases/Branched[Branched], pre-Bodhi enabling

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ === https://fedoraproject.org/wiki/Releases/Branched[Branched], pre-Bodhi enabling

  

- For a short time after https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[the branch event

+ For a short time after link:https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[the branch event

  happens] but before the <<bodhi-enaling>> point, the Branched release works just like Rawhide:

  builds submitted by packagers are considered

- https://fedoraproject.org/wiki/Repositories#stable[stable] immediately, and sent to the

- https://fedoraproject.org/wiki/Repositories#fedora[_fedora_ repository] directly in the next nightly

+ link:https://fedoraproject.org/wiki/Repositories#stable[stable] immediately, and sent to the

+ link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_ repository] directly in the next nightly

  compose. There are no restrictions beyond those for Rawhide at this point, but maintainers SHOULD be

  thinking about stabilization from this point onwards, and making sure their packages will be in good

  condition well in advance of the stable release. Some packages will be signed at this point, but not

- all of them. You may have to use --nogpgcheck to install or update.

+ all of them. You may have to use `--nogpgcheck` to install or update.

  

- repos available: https://fedoraproject.org/wiki/Repositories#fedora[_fedora_]

+ repos available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_]

  

  [[bodhi-enabling]]

- Bodhi enabling

- ~~~~~~~~~~~~~~

+ === Bodhi enabling

  

  At the _Bodhi enabling point_, the Bodhi update system is enabled for the Branched release. After

  this point *for the entire remaining lifetime of the release*, all updates must go through Bodhi

  before they can be marked _stable_ and moved to either

- https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] or

- https://fedoraproject.org/wiki/Repositories#updates[_updates_]. At present, the _Bodhi enabling

- point_ occurs on the day of the https://fedoraproject.org/wiki/Milestone_freezes[Beta freeze], but

+ link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] or

+ link:https://fedoraproject.org/wiki/Repositories#updates[_updates_]. At present, the _Bodhi enabling

+ point_ occurs on the day of the link:https://fedoraproject.org/wiki/Milestone_freezes[Beta freeze], but

  it is important to remember that they are distinct events: the Beta freeze lasts until Beta release,

  but Bodhi enabling is permanent.

  

- repos available: https://fedoraproject.org/wiki/Repositories#fedora[_fedora_],

- https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

+ repos available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_],

+ link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

  

  At this point all packages will be signed and gpgcheck should be enabled for all installs/updates.

  

  [[pre-beta]]

- Pre Beta

- ~~~~~~~~

+ === Pre Beta

  

  This is the time between the _Bodhi enabling point_ and the Beta release. During this time we are

  attempting to stabilize the major versions of software that will be shipped with the final release
@@ -99,12 +93,12 @@ 

  of Live media, install media or testing should be avoided. Packages for Changes should be landing

  and getting major testing.

  

- repos available: https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

+ repos available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_], link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

  

  From this point onwards Maintainers **MUST**footnote:[_Must_ requirements are enforced by Bodhi.]:

  

  * Push all updates first to updates-testing.

- * All https://fedoraproject.org/wiki/Critical_path_package[ critical path] updates MUST either get

+ * All link:https://fedoraproject.org/wiki/Critical_path_package[critical path] updates MUST either get

    one +1 karma, OR spend at least 14 days in updates-testing and have no negative karma before being

    moved to stable.

  * All non critical path updates MUST either reach the prescribed karma level for that update, OR
@@ -116,80 +110,75 @@ 

    packages in or a mass build/update, by filing a https://pagure.io/releng/new_issue[releng ticket].

  

  [[milestone-freezes]]

- Milestone freezes

- ^^^^^^^^^^^^^^^^^

+ ==== Milestone freezes

  

- During this period there are two https://fedoraproject.org/wiki/Milestone_freezes[Milestone

+ During this period there are two link:https://fedoraproject.org/wiki/Milestone_freezes[Milestone

  freezes], _Alpha freeze_ and _Beta freeze_. Each is scheduled to run for the two weeks leading up to

  the release date (and in fact lasts until the release is signed off, even if it is delayed). During

  these times, builds will not be marked _stable_ and moved from

- https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_] to

- https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] (and hence included in the milestone

+ link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_] to

+ link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] (and hence included in the milestone

  release composes) except for those approved under the

- https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process[QA SOP blocker bug process] or

- https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process[QA SOP freeze exception bug process].

+ link:https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process[QA SOP blocker bug process] or

+ link:https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process[QA SOP freeze exception bug process].

  Once the milestone release is made, these freezes are lifted.

  These freezes are technically not a part of the Updates Policy, but are briefly mentioned here for

- clarity. The https://fedoraproject.org/wiki/Milestone_freezes[Milestone freezes] page provides more

+ clarity. The link:https://fedoraproject.org/wiki/Milestone_freezes[Milestone freezes] page provides more

  details and is the canonical reference in case of any conflict.

  

  [[beta-to-pre-release]]

- Beta to Pre Release

- ~~~~~~~~~~~~~~~~~~~

+ === Beta to Pre Release

  

  This is the time between the Beta release and the

- https://fedoraproject.org/wiki/Milestone_freezes[Final freeze]. The branched tree should now be

+ link:https://fedoraproject.org/wiki/Milestone_freezes[Final freeze]. The branched tree should now be

  stabilized and prepared for release. Major changes should be avoided during this period. Bear in

  mind that in most cases, the state your package has reached in the stable

- https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] repository at the time of the Final

+ link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] repository at the time of the Final

  freeze is the state it will be in for the final release.

  

- repos available: https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

+ repos available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_], link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

  

  From this point onwards maintainers **MUST**[multiblock footnote omitted]:

  

  * Avoid Major version updates, ABI breakage or API changes if at all possible.

  * Push updates first to updates-testing.

- * All https://fedoraproject.org/wiki/Critical_path_package[ critical path] updates MUST either have

+ * All link:https://fedoraproject.org/wiki/Critical_path_package[critical path] updates MUST either have

    a sum of +2 karma, OR spend at least 14 days in updates-testing and have no negative karma.

  * All non critical path updates MUST either reach the prescribed karma level for that update, OR

    spend at least 7 days in updates-testing before being allowed to go to stable.

  

  [[pre-release]]

- Pre release

- ~~~~~~~~~~~

+ === Pre release

  

- This is the time after the https://fedoraproject.org/wiki/Milestone_freezes[Final freeze]. During

+ This is the time after the link:https://fedoraproject.org/wiki/Milestone_freezes[Final freeze]. During

  this time the release is being composed and only packages granted exceptions through the

  QA:SOP_blocker_bug_process or QA:SOP_freeze_exception_bug_process are marked as _stable_ and moved

- to the https://fedoraproject.org/wiki/Repositories#fedora[_fedora_ repository]. The

- https://fedoraproject.org/wiki/Repositories#updates[_updates_] repository is enabled at some point

+ to the link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_ repository]. The

+ link:https://fedoraproject.org/wiki/Repositories#updates[_updates_] repository is enabled at some point

  during this time, and packages other than freeze exception / blocker fixes are queued for so called

  "zero day" updates, meaning they will be available in the _updates_ repository at the time of the

  release (day zero).

  

- repos available: https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] https://fedoraproject.org/wiki/Repositories#updates[_updates_] https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

+ repos available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_], link:https://fedoraproject.org/wiki/Repositories#updates[_updates_], link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

  

  During this period:

  

  * All updates pulled into the release **MUST**[multiblock footnote omitted] fix an accepted blocker

    or freeze exception bug.

  * All update pushes will go to updates-testing.

- * All https://fedoraproject.org/wiki/Critical_path_package[ critical path] updates *MUST* either

+ * All link:https://fedoraproject.org/wiki/Critical_path_package[ critical path] updates *MUST* either

    have a sum of +2 karma, *OR* spend at least 14 days in updates-testing and have no negative karma.

  * All non critical path updates *MUST* either reach the prescribed karma level for that update, *OR*

    spend at least 7 days in updates-testing before being allowed in stable.

  * Once the _updates_ repository is available, builds marked as

-   https://fedoraproject.org/wiki/Repositories#stable[_stable_] will go there instead of to

-   https://fedoraproject.org/wiki/Repositories#fedora[_fedora_].

+   link:https://fedoraproject.org/wiki/Repositories#stable[_stable_] will go there instead of to

+   link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_].

  

  [[stable-releases]]

- Stable Releases

- ---------------

+ == Stable Releases

  

  [[philosophy]]

- Philosophy

- ~~~~~~~~~~

+ === Philosophy

  

  Releases of the Fedora distribution are like releases of the individual packages that compose it. A

  major version number reflects a more-or-less stable set of features and functionality. As a result,
@@ -213,25 +202,24 @@ 

  common patches for older releases, particularly when rebasing would require large dependency chain

  updates.

  

- repos available: https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] https://fedoraproject.org/wiki/Repositories#updates[_updates_] https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

+ repos available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_], https://fedoraproject.org/wiki/Repositories#updates[_updates_], link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]

  

  [[updates-to-critical-path-packages]]

- Updates to 'critical path' packages

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ === Updates to 'critical path' packages

  

  Updates that constitute a part of the 'critical path' package set (defined

  below) *including security updates* MUST follow the rules as defined for

- https://fedoraproject.org/wiki/Critical_path_package[critical path packages] for

+ link:https://fedoraproject.org/wiki/Critical_path_package[critical path packages] for

  pending releases, meaning:

  

  * At the time of the request to stable, the update needs to have either a

-   https://fedoraproject.org/wiki/Bodhi[Bodhi karma] sum of 2 *OR*

+   link:https://fedoraproject.org/wiki/Bodhi[Bodhi karma] sum of 2 *OR*

  * It must spend at least 14 days in updates-testing *AND* have no negative

-   https://fedoraproject.org/wiki/Bodhi[Bodhi karma] points.

+   link:https://fedoraproject.org/wiki/Bodhi[Bodhi karma] points.

  

  For the purposes of this policy, the 'critical path' package set is defined as the following:

  

- * The current https://fedoraproject.org/wiki/Critical_Path_Packages[critical path package set]

+ * The current link:https://fedoraproject.org/wiki/Critical_Path_Packages[critical path package set]

  * All major desktop environments' core functionality (GNOME, KDE, Xfce, LXDE)

  * Package updating frameworks (, )

  * Major desktop productivity apps. An initial list would be , (konqueror), , , (kmail).
@@ -239,15 +227,14 @@ 

  Changes to this definition may only be made by xref:index.adoc[FESCo] or their delegate.

  

  [[all-other-updates]]

- All other updates

- ~~~~~~~~~~~~~~~~~

+ === All other updates

  

  All other updates *MUST* either:

  

  * reach the criteria laid out in the previous section *OR*

  * reach the positive Bodhi karma threshold specified by the updates submitter *OR*

  * spend some minimum amount of time in

-   https://fedoraproject.org/wiki/QA:Updates_Testing[updates-testing], currently one week

+   link:https://fedoraproject.org/wiki/QA:Updates_Testing[updates-testing], currently one week

  

  Package maintainers *MUST*:

  
@@ -261,8 +248,7 @@ 

    and before).

  

  [[exceptions]]

- Exceptions

- ~~~~~~~~~~

+ === Exceptions

  

  Some classes of software will not fit in these guidelines. If your package does not fit in one of

  the classes below, but you think it should be allowed to update more rapidly, propose a new
@@ -293,14 +279,12 @@ 

    fixes for other platforms or configurations).

  

  [[exceptions-list]]

- Exceptions list

- ^^^^^^^^^^^^^^^

+ ==== Exceptions list

  

  The following packages have been granted exceptions for the following reasons:

  

  [[kernel-package]]

- kernel package

- ++++++++++++++

+ ===== kernel package

  

  * Manpower of kernel maintainers prevents us from easily backporting all the bug fixes, security

    fixes and new hardware enablement we would need to maintain older, no longer supported kernels.
@@ -310,22 +294,19 @@ 

    bugs in new kernels on older stable releases.

  

  [[kde]]

- KDE

- +++

+ ===== KDE

  

- Refer to the https://fedoraproject.org/wiki/SIGs/KDE/Update_policy[KDE update policy] for more

+ Refer to the link:https://fedoraproject.org/wiki/SIGs/KDE/Update_policy[KDE update policy] for more

  details

  

  [[girara-and-zathura]]

- girara and zathura

- ++++++++++++++++++

+ ===== girara and zathura

  

  These packages are allowed to update in stable releases together.

  See https://fedorahosted.org/fesco/ticket/1255

  

  [[security-fixes]]

- Security fixes

- ^^^^^^^^^^^^^^

+ ==== Security fixes

  

  If upstream does not provide security fixes for a particular release, and if backporting the fix

  would be impractical, then the package maintainer(s) MUST open a FESCo ticket for approval to rebase
@@ -353,14 +334,12 @@ 

    users

  

  [[packages-with-exceptions-granted]]

- Packages with Exceptions Granted

- ++++++++++++++++++++++++++++++++

+ ===== Packages with Exceptions Granted

  

  * kernel

  

  [[interoperability]]

- Interoperability

- ^^^^^^^^^^^^^^^^

+ ==== Interoperability

  

  If a package primarily serves to interoperate with hardware or network protocols, and the interface

  changes, then a package may be rebased if necessary. This includes network games, IM protocols,
@@ -370,8 +349,7 @@ 

  Examples of this type of package: , , ,

  

  [[database-packages]]

- Database packages

- ^^^^^^^^^^^^^^^^^

+ ==== Database packages

  

  Packages like virus scanners and spam filters typically have two components: a rules engine and a

  database. The database is expected to update frequently (sometimes not through the normal OS update
@@ -382,8 +360,7 @@ 

  Examples of this type of package: ,

  

  [[examples]]

- Examples

- ^^^^^^^^

+ ==== Examples

  

  * Mozilla releases Firefox 4.0.1 with a security fix. Fedora 12 is shipping with 3.0.7, and though

    the bug is also present there, the fix in 4.0.1 does not apply because that part of the browser
@@ -425,19 +402,17 @@ 

    bases based on all the above.

  

  [[problems-or-issues-with-updates]]

- Problems or issues with Updates

- -------------------------------

+ == Problems or issues with Updates

  

  In an effort to learn from any mistakes made, in the event of a update causing a widespread or

  serious problem for Fedora users, please file a FESCo trac ticket. FESCo will discuss and try and

  work to prevent the issue from happening again. A past record of such issues can be found at

- https://fedoraproject.org/wiki/Updates_Lessons[Updates Lessons].

+ link:https://fedoraproject.org/wiki/Updates_Lessons[Updates Lessons].

  

  FESCo will work with QA and others to prevent or mitigate the issue.

  

  [[updating-inter-dependent-packages]]

- Updating inter-dependent packages

- ---------------------------------

+ == Updating inter-dependent packages

  

  When one updated package requires another (or more than one other), the packages should be submitted

  together as a single update. For instance, if package A depends on packages B and C, and you want to
@@ -446,12 +421,11 @@ 

  three separate updates, because if the update for package A is pushed stable before the updates for

  packages B and C, it will cause dependency problems. There is information on how to submit

  multi-package updates in the

- https://fedoraproject.org/wiki/Package_update_HOWTO#Updating_inter-dependent_packages[package update

+ link:https://fedoraproject.org/wiki/Package_update_HOWTO#Updating_inter-dependent_packages[package update

  HOWTO].

  

  [[taskotron]]

- Taskotron

- ---------

+ == Taskotron

  

  The Taskotron automated testing system runs two tests against all updates submitted to Bodhi: a

  dependency check (to ensure all dependencies of the package(s) can be fulfilled from the
@@ -466,13 +440,12 @@ 

  

  Previously, the old AutoQA system ran similar checks to Taskotron. The scope of these automated

  checks is expected to expand in future. The

- https://fedoraproject.org/wiki/QA:Package_Update_Acceptance_Test_Plan was written as the original

+ link:https://fedoraproject.org/wiki/QA:Package_Update_Acceptance_Test_Plan[Package Update Acceptance Test Plan] was written as the original

  plan for AutoQA update validation, and may still be seen as a framework for future work on

  Taskotron.

  

  [[bodhi-use]]

- Bodhi Use

- ---------

+ == Bodhi Use

  

  Bodhi is meant as the method for getting updates into an existing release or pre-release. It does

  provide a testing mechanism to make sure that nothing unforeseen will arise, but the expectation is
@@ -481,6 +454,5 @@ 

  users kind enough to test these packages have come to expect this, and doing anything else moves

  against their good will, and is likely to drive testers away. Bodhi and updates-testing are not a

  place for experimentation or advanced notification of potentially disruptive updates. These should

- be handled with packages in https://copr.fedorainfracloud.org/[Copr] or another public repository

+ be handled with packages in link:https://copr.fedorainfracloud.org/[Copr] or another public repository

  with a message to call for testing on the appropriate mailing lists.

- 

@@ -1,10 +1,9 @@ 

- Updating Fedora Engineering Steering Committee Members

- ======================================================

+ == Updating Fedora Engineering Steering Committee Members

  

  After a FESCo election, the new members need to be granted the necessary privileges and the leaving members' privileges need to be revoked. At least the following services need to be updated:

  

- 1.  Update members of the https://lists.fedoraproject.org/admin/lists/fesco.lists.fedoraproject.org/[FESCo mailing list]

- 2.  Update members of the https://pagure.io/fesco[FESCo pagure group]

- 3.  Update list of xref:index.adoc#fesco-members[FESCo members]

- 4.  Grant https://badges.fedoraproject.org/badge/the-last-argument-of-kings[FESCo badge] to new members

- 5.  Coordinate meeting time with new members

+ .  Update members of the link:https://lists.fedoraproject.org/admin/lists/fesco.lists.fedoraproject.org/[FESCo mailing list]

+ .  Update members of the link:https://pagure.io/fesco[FESCo pagure group]

+ .  Update list of xref:index.adoc#fesco-members[FESCo members]

+ .  Grant link:https://badges.fedoraproject.org/badge/the-last-argument-of-kings[FESCo badge] to new members

+ .  Coordinate meeting time with new members

@@ -1,20 +1,16 @@ 

- Fedora Engineering Steering Committee

- =====================================

+ = Fedora Engineering Steering Committee

  

- [.lead]

  FESCo is the Fedora Engineering Steering Committee.  It is a fully community

  elected body and represents the technical leadership in Fedora.

  

- Overall Mission

- ---------------

+ == Overall Mission

  

  FESCo handles the process of accepting new features, the acceptance of new

  packaging sponsors, Special Interest Groups (SIGs) and SIG Oversight, the

  packaging process, handling and enforcement of maintainer issues and other

  technical matters related to the distribution and its construction.

  

- Common tasks and responsibilities

- ---------------------------------

+ == Common tasks and responsibilities

  

  FESCo is responsible for technical issues and coordination of technical resources for the project.

  
@@ -36,62 +32,56 @@ 

  FESCo has a designate for each Working Group that coordinates with that Group and communicates back to FESCo any issues or concerns. Currently there are: Workstation, Server and Atomic Working groups.

  

  [[fesco-members]]

- Members

- -------

- 

- * https://fedoraproject.org/wiki/User:Kevin[Kevin Fenzi] (nirik) — F30/F31

- * https://fedoraproject.org/wiki/User:jforbes[Justin Forbes] (jforbes) — F30/F31

- * https://fedoraproject.org/wiki/User:zbyszek[Zbigniew Jędrzejewski-Szmek] (zbyszek) — F30/F31

- * https://fedoraproject.org/wiki/User:Bookwar[Aleksandra Fedorova] (bookwar) — F29/F30 (from https://pagure.io/fesco/issue/2098[2019-03-04])

- * https://fedoraproject.org/wiki/User:Sgallagh[Stephen Gallagher] (sgallagh) — F31/F32

- * https://fedoraproject.org/wiki/User:Psabata[Petr Šabata] (contyk/psabata) — F31/F32

- * https://fedoraproject.org/wiki/User:Churchyard[Miro Hrončok] (churchyard/mhroncok) — F30/F31

- * https://fedoraproject.org/wiki/User:otaylor[Owen Taylor] (otaylor) — F30/F31

- * https://fedoraproject.org/wiki/User:Ignatenkobrain[Igor Gnatenko] (ignatenkobrain) — F31/F32

+ == Members

+ 

+ * link:https://fedoraproject.org/wiki/User:Kevin[Kevin Fenzi] (nirik) — F30/F31

+ * link:https://fedoraproject.org/wiki/User:jforbes[Justin Forbes] (jforbes) — F30/F31

+ * link:https://fedoraproject.org/wiki/User:zbyszek[Zbigniew Jędrzejewski-Szmek] (zbyszek) — F30/F31

+ * link:https://fedoraproject.org/wiki/User:Bookwar[Aleksandra Fedorova] (bookwar) — F29/F30 (from https://pagure.io/fesco/issue/2098[2019-03-04])

+ * link:https://fedoraproject.org/wiki/User:Sgallagh[Stephen Gallagher] (sgallagh) — F31/F32

+ * link:https://fedoraproject.org/wiki/User:Psabata[Petr Šabata] (contyk/psabata) — F31/F32

+ * link:https://fedoraproject.org/wiki/User:Churchyard[Miro Hrončok] (churchyard/mhroncok) — F30/F31

+ * link:https://fedoraproject.org/wiki/User:otaylor[Owen Taylor] (otaylor) — F30/F31

+ * link:https://fedoraproject.org/wiki/User:Ignatenkobrain[Igor Gnatenko] (ignatenkobrain) — F31/F32

  

  Chair is rotating.

  

- Their interviews for previous elections are published in the https://communityblog.fedoraproject.org/category/elections/[Community Blog].

+ Their interviews for previous elections are published in the link:https://communityblog.fedoraproject.org/category/elections/[Community Blog].

  

  The xref:Previous_Fedora_Engineering_Steering_Committee_Members.adoc[Previous committee members] page contains a list of previous members.

  The xref:Updating_Fedora_Engineering_Steering_Committee_Members.adoc[Updating FESCo members] page outlines the necessary steps to update FESCo members after an election.