From Fedora Project Wiki

(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{autolang|base=yes}}
= EPEL Package Maintainers =
= EPEL Package Maintainers =


Line 7: Line 9:
There are several ways you can join the EPEL package maintainer group:  
There are several ways you can join the EPEL package maintainer group:  


1. If you are an existing Fedora package maintainer, you can maintain EPEL packages by becoming a maintainer or comaintainer of an existing EPEL package, which you can apply for in pkgdb. You can also request EPEL branches for your Fedora package and maintain them for EPEL with a Package SCM request.  
1. If you are an existing Fedora package maintainer, you can maintain EPEL packages by becoming a maintainer or comaintainer of an existing EPEL package, which you can apply for in pkgdb. You can also [[EPEL/FAQ#How_do_I_request_a_EPEL_branch_for_an_existing_Fedora_package.3F|request EPEL branches]] for your Fedora package and maintain them for EPEL with a Package SCM request.
 
2. If you are not currently in the Fedora packager group, you could join that group by submitting one or more new packages for Fedora/EPEL, and following the normal Fedora sponsorship process. Then, simply [[EPEL/FAQ#How_do_I_request_a_EPEL_branch_for_an_existing_Fedora_package.3F|request EPEL branches]] for your new packages once they are approved.  


2. If you are not currently in the Fedora packager group, you could join that group by submitting one or more new packages for Fedora/EPEL, and following the normal Fedora sponsorship process. Then, simply request EPEL branches for your new packages once they are approved.  
3. If you are not currently in the Fedora packager group and wish to help co-maintain one or more packages in EPEL, you can try and find an existing package and maintainer of that package who wishes to mentor you. You can then follow the [[How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer|"Become a co-maintainer" path to sponsorship]].  


3. If you are not currently in the Fedora packager group and wish to help co-maintain one or more packages in EPEL, you can try and find an existing package and maintainer of that package who wishes to mentor you. You can then follow the "Become a co-maintainer" path to sponsorship.  
4. If you are an existing EPEL/Fedora maintainer and wish to maintain a package in EPEL that someone else maintains in Fedora, file a bug asking them if they would like to maintain it in EPEL, if no response in a week or if the Fedora maintainer has no interest in EPEL, [[EPEL/FAQ#How_do_I_request_a_EPEL_branch_for_an_existing_Fedora_package.3F|request the branch yourself]] and maintain it.


== EPEL Policies and Guidelines ==
== EPEL Policies and Guidelines ==


Where possible, EPEL tries to use and follow any applicable Fedora guidelines. There are of course some exceptions due to older packages and EPEL seeking stability over newer packages. You can find a list of all such guidelines at the [User:Kevin/new_EPEL_Package_Guidelines] page.  
Where possible, EPEL tries to use and follow any applicable Fedora guidelines. There are of course some exceptions due to older packages and EPEL seeking stability over newer packages. You can find a list of all such guidelines at the [[Packaging:EPEL|EPEL Packaging Guidelines]] page.


== EPEL Updates policy ==
== EPEL Updates policy ==


EPEL strives to provide updates that are compatible and stable to compliment the Enterprise Linux packages it's built on. You can find a detailed list of updates policies on the [User:Kevin/new_EPEL_Updates_Policy]
EPEL strives to provide updates that are compatible and stable to compliment the Enterprise Linux packages it's built on. You can find a detailed list of updates policies on the [[EPEL_Updates_Policy|EPEL Updates Policy page]] as well as [[EPEL_incompatible_upgrades_policy|a page on incompatible updates when they absolutely can't be avoided]]
 
== RHEL Entitlements for EPEL package maintainers ==
 
Some EPEL maintainers do not have access to RHEL to test and develop their packages. The easiest method for testing EPEL is to use CentOS or Scientific
Linux in order to do initial testing of builds. These are 'rebuilds' of Red Hat Enterprise Linux and may contain packages which slightly differ from the upstream release.
 
A developer who wants to build and test against a particular Red Hat Enterprise Linux should join the Red Hat developer program at https://developers.redhat.com/products/rhel/download/ .
 
== New Package Wish List ==
 
The best way to get a new package into EPEL is to first get it added to Fedora. You can add such packages to the [[PackageMaintainers/WishList| wishlist for Fedora]].
 
It is possible to have packages only in EPEL, for example if the functionality has already been merged in a more recent package in Fedora, but it should be exceptional. Such packages can be submitted for review as per the regular process. Be ready to discuss why your package only applies to EPEL.


== EPEL package wishlist ==
If the package is in Fedora but not in EPEL, see above.


There's a wishlist available for packages that are desired in the EPEL collection, but are not yet available there.
[[Category:EPEL]]

Revision as of 17:30, 31 August 2017

EPEL Package Maintainers

EPEL packages are maintained by members of the community. These maintainers respond to bug reports, update packages and add new packages to the collection as needed. EPEL packagers are members of the Fedora "packagers" group.

Joining the EPEL Package Maintainers

There are several ways you can join the EPEL package maintainer group:

1. If you are an existing Fedora package maintainer, you can maintain EPEL packages by becoming a maintainer or comaintainer of an existing EPEL package, which you can apply for in pkgdb. You can also request EPEL branches for your Fedora package and maintain them for EPEL with a Package SCM request.

2. If you are not currently in the Fedora packager group, you could join that group by submitting one or more new packages for Fedora/EPEL, and following the normal Fedora sponsorship process. Then, simply request EPEL branches for your new packages once they are approved.

3. If you are not currently in the Fedora packager group and wish to help co-maintain one or more packages in EPEL, you can try and find an existing package and maintainer of that package who wishes to mentor you. You can then follow the "Become a co-maintainer" path to sponsorship.

4. If you are an existing EPEL/Fedora maintainer and wish to maintain a package in EPEL that someone else maintains in Fedora, file a bug asking them if they would like to maintain it in EPEL, if no response in a week or if the Fedora maintainer has no interest in EPEL, request the branch yourself and maintain it.

EPEL Policies and Guidelines

Where possible, EPEL tries to use and follow any applicable Fedora guidelines. There are of course some exceptions due to older packages and EPEL seeking stability over newer packages. You can find a list of all such guidelines at the EPEL Packaging Guidelines page.

EPEL Updates policy

EPEL strives to provide updates that are compatible and stable to compliment the Enterprise Linux packages it's built on. You can find a detailed list of updates policies on the EPEL Updates Policy page as well as a page on incompatible updates when they absolutely can't be avoided

RHEL Entitlements for EPEL package maintainers

Some EPEL maintainers do not have access to RHEL to test and develop their packages. The easiest method for testing EPEL is to use CentOS or Scientific Linux in order to do initial testing of builds. These are 'rebuilds' of Red Hat Enterprise Linux and may contain packages which slightly differ from the upstream release.

A developer who wants to build and test against a particular Red Hat Enterprise Linux should join the Red Hat developer program at https://developers.redhat.com/products/rhel/download/ .

New Package Wish List

The best way to get a new package into EPEL is to first get it added to Fedora. You can add such packages to the wishlist for Fedora.

It is possible to have packages only in EPEL, for example if the functionality has already been merged in a more recent package in Fedora, but it should be exceptional. Such packages can be submitted for review as per the regular process. Be ready to discuss why your package only applies to EPEL.

If the package is in Fedora but not in EPEL, see above.