Important Announcement: Please read https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.html and https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00009.html for information.
PackageMaintainers/Policy
From FedoraProject
Contents |
Fedora Package Maintainers Policies
This document should give you a quick overview of all the relevant policies for Fedora Package Collection. It covers only the most important things -- each section has a link to a document with more detailed explanations and examples that outline how to lay out the rules. For a full list of documents see the end of this document .
On maintaining packages
Who is allowed to modify which packages
Normally the maintainer that is listed as primary maintainer in the PackageDB (formerly this was owners.list ) of a package is the only one who modifies the package or gives others permission (e.g. by accepting them as co-maintainers) to commit and build changes for that package. Bugzilla is normally the best way to contact the package maintainer or to send him patches and suggestions because is neutral and trackable; but poking people one or twice in IRC or directly via mail might be a good idea.
But there are certain exceptions where the maintainer has to accept that other packagers will modify his packages. Those exception are described in detail below -- it mostly boils down to this:
If
- a packager doesn't fix important bugs in time
- if there are problems known that might be bad for the whole Project or a lot of users of the repo/a particular package
- the changes are quite minor or considered as a general cleanup to a lot of packages
then experienced Fedora packagers are allowed to fix stuff in other peoples packages.
Read on for more more details about this topic .
What to do if a Maintainer is absent
- File a bug against the package in bugzilla asking for the maintainer to respond (after checking if the maintainer is on Vacation ).
- After every 7 days, a reporter files a bug report for each unsuccessful attempt to contact.
- After 2 attempts of no contact, the reporter asks if anyone knows how to contact the maintainer.
- After another 7 days, the reporter posts a formal request to the fedora-devel list with the bug link.
- If at least one FESco member approves the take over and no one objects within 3 days, the requester may take over the package. If the requester is a not an existing Fedora contributor, he may still take over a package. Once approval has been given, follow PackageMaintainers/CVSAdminProcedure to have ownership of the package changed. In addition to this, the new owner must also reassign any open bugs on that package to themselves.
Read on for more more details about this topic
Co-Maintainership
All packages in Fedora should normally be maintained by a group of maintainers. Ideally, each package normally should have at least three maintainers in total. There is one primary maintainer and a primary maintainer per distribution release (both often will be identical); each distribution maintainer should have at least one co-maintainer per release, to make sure there are actually at least two people for a package per each supported release. Maintainers should work towards getting at least one co-maintainer.
One important goal of co-maintainership in Fedora is to help getting new people involved into the project, while the experienced and respected maintainers get a chance to get involved with the often more complicated and more important parts of the project if they want to.
Read on for more more details about this topic
Special rules for Packages with kernel modules
- Verify that there is an acceptable license for a kernel-module by asking on fedora-devel-list.
- A kernel-module should be merged into the upstream kernel.
- Open a review bug in bugzilla with an explanation from the maintainer of the kernel-module why it is not yet merged with the mainline kernel and a planned merge date.
- Send FESCo an email asking for permission to allow the module in Fedora. FESCo will investigate and vote if the kernel-module is suitable for Fedora.
- While anyone can review a kernel-module package, once it is set to APPROVED by the reviewer, a Fedora Sponsor or someone experienced with kernel modules should examine the package and post an additional approval notice before it is imported into CVS.
Read on for more more details about this topic
Fedora Maintenance Lifecycle Policy
- When a Fedora Core release reaches maintenance state in its lifecycle (such as Fedora Core 3 when Fedora Core 5 Test 2 was released), the corresponding release of Fedora Extras will also enter a maintenance state.
- Branches for new packages in CVS are not created for distributions that are in maintenance state. The official package maintainers are also urged to fix their packages for distributions that are in maintenance state.
- When the Fedora Project drops support for a Fedora Core release, the corresponding Fedora Extras is also dropped -- this is End-of-life (EOL).
- The EOL Policy depends on the creation of a Security Response Team that will lend assistance as needed if the maintainer is unable to fix the package.
Read on for more more details about this topic
Review workflow
What to do with stalled reviews
Reviewer not responding
- When a review ticket is assigned to a reviewer who does not respond to comments for one month, a comment is added to the ticket indicating that the review is stalled and that a response is needed soon.
- If there is no response within one week, the fedora‑review flag is set to the empty value. The ticket is reassigned to nobody@fedoraproject.org (use the Reassign bug to owner and QA contact of selected component radio button for this) with the intention to move the ticket back to a state where another reviewer can work on it.
Submitter not responding
- When the submitter of a review ticket has not responded to comments for one month, a comment is added to the ticket indicating that the review is stalled and that a response is needed soon.
- If there is no response within one week,the ticket is closed with resolution NOTABUG, and the fedora-review flag is set to the empty value. The intention is to close the bug so that it can be submitted by someone else in a separate bug, and also to make it easy to find bugs closed in this way.
Read on for more more details about this topic
FESCo
FESCo elections
- FESCo elections will be held twice a year, on the third Tuesday after a Fedora release.
- There will be 9 seats on FESCo.
- 9 seats will be up for the F9 elections, the F10 election will have 4 seats up for vote. The 4 seats that will be up for election will be the bottom 4 vote-getters from the prior election. The 5 seats not up for election in the F10 election, will be up for election in F11. After that, the seats up for election will alternate based on the seats up for election in the prior election.
- Elections will run for a period between one and two weeks, preferably to include two weekends.
- The elections will be announced in public lists. A reminder mail to eligible voters will be sent three days before the close of the election.
- Candidates may be any member of the cvsextras group in the Fedora Accounts System.
- Candidates must self-nominate at least three days before the election opens by writing their information onto the wiki.
- A minimum number of candidates are necessary in order to hold an election. This will be the number of open seats + 25%.
- If not enough candidates have signed up by the deadline, the election will be held back by one week for more candidates to appear. If there are still not enough candidates, the candidates who are present will be voted upon (or merely confirmed if there are less candidates than open seats.)
- If there are not enough candidates to complete the ballot, all the contributors listed in this section will be added to the ballot.
- If FESCo does not have the full number of seats filled at this point, the vacant seats will attempt to be filled by the following methods:
- If there are runner-up candidates from the previous election that did not have the opportunity to be on FESCo, they will be offered a seat according to their rank in the voting.
- If those candidates have been exhausted, FESCo will ask Fedora community members that they think would do a good job if they would be willing to hold the open seats.
- If the open seats are still not filled, FESCo will operate with less members until the next FESCo election.
The voting is as follows:
- A voter receives a ballot listing all the candidates.
- For each candidate the voter assigns from 0 to number of candidates points.
- At the close of the election, the points for each candidate are tallied and the ones with the most points win a seat.
There are no term limits imposed by this policy. If FESCo chooses to impose term limits for its internal positions (Chair, VP, etc.), those should be specified in the FESCo by-laws.
Read on for more more details about this topic
All approved Fedora policy documents
If you want more details look at the individual documents that cover the policies in depth:
[[PageList('PackageMaintainers/Policy/')]
