Packager sponsor policy
Getting sponsored into the packager group allows anyone interested to become a Fedora maintainer.
Maintainers get commit access to package sources, ability to build packages,
and the ability to review new packages for inclusion in the distribution.
This applies to packages where they become either primary or co-maintainers.
Sponsoring is required to ensure that packagers have someone that they can go to with questions. Sponsorship is not automatic and requires finding a willing sponsor.
Note that membership in the packager group, and thus sponsorship,
is not required to contribute to Fedora packaging.
Anybody can open a pull request to any package,
which the package maintainers can then review and merge.
It is recommended to start working with pull requests in this way,
rather than immediately seeking sponsorship.
See Package Maintenance Guide: Using fedpkg anonymously
for description of this method.
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, help them to find areas to contribute, assist them with processes and procedures, and provide 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 Package maintainer responsibilities.
Requesting sponsorship
There are several ways to get sponsored into the packager group.
Submitting a package
Sponsorship can be requested when a review request is submitted for a new package,
or for a retired package that requires a new review.
Such request is submitted by making the review request Bugzilla ticket block the
FE-NEEDSPONSOR tracking bug.
Although FE-NEEDSPONSOR is set on the package’s review request,
it is the person that needs to be sponsored, not the package.
Becoming a co-maintainer
Another way to enter the packager group
is by co-maintaining a package that is already in Fedora.
The current owner of that package will allow the applicant to co-maintain the package
and will act as their mentor.
If the package owner is a sponsor, they can sponsor the applicant themselves. If they are not a sponsor, they can get another existing sponsor to do so. This can be done either by contacting a sponsor personally, or by opening a ticket in the packager sponsors pagure instance. The ticket should state that they are a package owner and that they would like the applicant to co-maintain their package. They agree to be responsible for mentoring the applicant as described in section Package Sponsor Responsibilities.
Adopting an orphaned or freshly retired package
If the applicant wants to start maintaining a package that has been orphaned, or retired recently enough so that, according to Policy for Orphan and Retired Packages, it does not yet require a new review, they can open a ticket in the packager sponsors pagure instance, stating that they want to maintain that package and need a sponsor.
Before submitting the sponsorship request, the applicant should inspect the package and check if it has any open Bugzilla issues. The request should only be submitted if the applicant is sure that they can get the package into good shape. They should open a pull request to fix any discovered issues and link to them in their sponsorship request. Sponsors can then give feedback on these pull requests and evaluate the applicant’s knowledge at the same time.
Sponsorship requirements
Applicants should be sponsored only if the sponsor is reasonably certain that the applicant is, with mentoring from the sponsor, able to fulfill the Package Maintainer Responsibilities.
In the co-maintainership path, it is the primary maintainer who decides if the applicant is suitable. The sponsor only needs to trust that the primary maintainer will give the required support.
The following sections describe some actions that may be taken by the applicant to show their packaging skills.
The applicant should include all relevant information in their application.
Opening pull requests
Opening pull requests to fix issues in existing packages is an excellent way to help other package maintainers, and demonstrate expertise.
Submitting quality new packages
If the applicant has submitted a new package for review, the package can be inspected to see if the applicant understands rpm packaging and the Fedora Packaging Guidelines.
Commenting on review requests
Applicants can demonstrate their level of understanding by commenting on package review requests. This also helps out the other reviewers, which will be much appreciated.
Such comments should follow the usual Review Guidelines, but clearly state that the commenter is not yet a packager and the review is thus unofficial. While it is not strictly necessary to work through the entire checklist, more comprehesive reviews are more valuable.
Package sponsor responsibilities
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
Packager sponsors should be available to answer questions by their sponsored maintainers. 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 forum: devel mailing list, one of the language specific mailing lists, Packaging Committee, legal mailing list, FESCo, 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 ( Packaging Guidelines, Build system, VCS, FAS, updates… ).
Guide the sponsored maintainer in the Fedora Project
Packager sponsors should also be able to guide the sponsored packager in other aspects of Fedora. For example, point to 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
If a sponsored maintainer is unable to fix an issue in their package(s) the sponsor 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
If any sponsor concludes that a sponsored maintainer does not want to, or is
not able to, fulfill the requirements listed in
Package Maintainer Responsibilities,
they should file a FESCo ticket describing the
situation. Any sponsor may initiate the process to revoke sponsorship. Following
their normal procedures, FESCo will vote whether to remove the maintainer from
the packager group.
Who Sponsors the Sponsors?
The Fedora Package Collection has been setup so to encourage "learning by doing" and the development of cooperative relationships between Fedora packagers. Once a packager has acquired sufficient packaging knowledge to help others through the process, they may apply for sponsor status. As a guideline for sufficient knowledge, an applicant should:
-
Maintain at least three packages
-
Have done five high quality, nontrivial package reviews
-
Have been members of the packager group for at least one release cycle so that they have seen the process of branching for a new release.
These are not hard requirements, but provide a reasonable idea of how much experience is required.
A packager who feels ready to move up to sponsor status can simply file a ticket in the packager sponsors ticket system. These tickets are automatically sent to the sponsors list. A report will be added containing information about the applicant’s reviewed, owned and co-maintained packages. As needed, the applicant may provide additional information, such as informal review done or prospective packagers they would like to sponsor.
Votes will be collected in the ticket for a week. At the end of that time, if the differential between positive and negative votes stands at +3 or greater, the request is approved and the applicant is promoted to sponsor status immediately. If not, the request is closed. The applicant may reapply anytime they feel they have more support. After the new permissions to propagate through the system, the accepted applicant is able to sponsor new packagers.
Want to help? Learn how to contribute to Fedora Docs ›