Package maintainer policy

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(remove old kernel modules section... it no longer applies.)
(Fedora Package Maintainers Policies)
Line 25: Line 25:
 
[[PackageMaintainers/Policy/EncourageComaintainership#afterinclude|  Read on for more more details about this topic]]
 
[[PackageMaintainers/Policy/EncourageComaintainership#afterinclude|  Read on for more more details about this topic]]
  
 +
=== BugZappers' Role ===
  
 +
* Help package maintainers save time by assisting in the [[BugZappers/BugStatusWorkFlow|  bug work flow]]: mark duplicates, ask for more information from reporter and add trackers/blockers
 +
* Guide Fedora EOL through [[BugZappers/HouseKeeping|  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 ===
 
=== Fedora Maintenance Lifecycle Policy ===

Revision as of 16:36, 16 December 2008

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

  1. Check if the non-responsive maintainer is on vacation. To see if the maintainer has been recently active on Fedora, fedora-active-user can be employed.
  2. File a bug against the package in 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 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 posts a formal request to the FESCo trac 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 Package SCM 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.


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

  1. REDIRECTFedora_Release_Life_Cycle

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, as part of the Fedora Project combined election process.
  • 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.
  • 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 may be delayed waiting for more candidates to appear, in coordination with the schedule for combined Fedora elections. 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:
    1. 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.
    2. 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.
    3. 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/')]