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

  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.

  :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.

  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.

  FTBFS:: Fails To Build From Sources

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

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

  retired after a period of time.

      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

        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.

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

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

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

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

      about doing so.

      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).

      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.

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

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

      adopts them.

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

      requested via a releng issue.

      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.)

  (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

  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.

  report.

  FTBFS blocker bug]

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

  due to] Features/ChangeInImplicitDSOLinking

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

  builds from the mass rebuild:

  * F22?

  * No mass rebuild in F25

  * 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*:

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

  branched.

  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>`

  also build the package in branched.

  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):

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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.

  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 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]]

  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.

  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.

  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.

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

  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.

  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.

  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.

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

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

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

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

  * 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

  * 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

  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:

  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.

  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.

  * 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.

  * 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.

  ** 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.

  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.

  * 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).

  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.

  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.

  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.

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

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

  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.

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

  [[introduction]]

  [[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]]

  * 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).

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

  [[applications-covered]]

  [[references]]

  [[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]]

  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]]

  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:

  * 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]]

  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;

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

  [[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:

  [[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

  Steps:

  [[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.

  The following are the members of previous FESCos.

  [[members-of-match-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

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

  [[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

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

  [[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

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

  [[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

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

  [[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

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

  [[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

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

  [[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

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

  [[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

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

  [[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

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

  [[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

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

  [[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)

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

  [[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)

  Chair is rotating.

  [[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)

  Chair is rotating.

  [[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)