Package maintainer 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 it is neutral and trackable; but poking people once 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
- 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 provenpackagers 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, the reporter adds a comment to the 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 takeover and no one objects within 3 days, the requester may take over the package. If the requester is a not an existing Fedora contributor, they may still take over the 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
BugZappers' Role
- Help package maintainers save time by assisting in the bug work flow: mark duplicates, ask for more information from reporter and add trackers/blockers
- Guide Fedora EOL through HouseKeeping
- Rebase rawhide Bugzilla tickets during EOL (e.g. all bugs versioned rawhide become versioned to release X when it goes GA)
- Send emails to relevant mailing lists and add comments in Bugzilla to inform users of upcoming EOL, version change, etc
Fedora Maintenance Lifecycle Policy
- The Fedora Project maintains any given release X until one month after the release of X+2. Unmaintained releases are said to be in End-of-life state (EOL) (so fedora Fedora 7 was End-of-life one month after Fedora 9 release). See LifeCycle.
- Branches for new packages in CVS are not allowed for distribution X after the Fedora X+2 release. New builds are no longer allowed for EOL Fedora releases.
- Existing bugs against EOL releases are closed automatically.
- FESCo can approve exceptions of these rules if there are good reasons for it.
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 bug may be set as blocking FE-DEADREVIEW. 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.
If the bug is resubmitted by someone else, it is also reasonable to change the resolution on the closed bug to DUPLICATE and mark it as a duplicate of the new bug so that reviewers of the new ticket can easily find the work that was done on the old one.
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 packager 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
