m (internal link cleaning) |
mNo edit summary |
||
Line 1: | Line 1: | ||
== The procedure for getting a package in EPEL == | == The procedure for getting a package in EPEL == | ||
If you are already a Fedora contributor, for your own package use the standard procedures for | If you are already a Fedora contributor, for your own package use the standard procedures for requesting a new release branch. | ||
Otherwise, if you'd like to see a Fedora package in EPEL that is not yet available, check Fedora's [https://admin.fedoraproject.org/pkgdb/ Fedora database] or [https://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora Bugzilla] and look up who owns the package in Fedora. Then check the [[EPEL/ContributorStatus| Contributors Status document]] to see if the package owner is not interested in EPEL. | Otherwise, if you'd like to see a Fedora package in EPEL that is not yet available, check Fedora's [https://admin.fedoraproject.org/pkgdb/ Fedora database] or [https://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora Bugzilla] and look up who owns the package in Fedora. Then check the [[EPEL/ContributorStatus| Contributors Status document]] to see if the package owner is not interested in EPEL. |
Revision as of 16:32, 15 September 2017
The procedure for getting a package in EPEL
If you are already a Fedora contributor, for your own package use the standard procedures for requesting a new release branch.
Otherwise, if you'd like to see a Fedora package in EPEL that is not yet available, check Fedora's Fedora database or Bugzilla and look up who owns the package in Fedora. Then check the Contributors Status document to see if the package owner is not interested in EPEL.
If the Fedora maintainer of the package has indicated a desire not to participate in EPEL then the proposed EPEL maintainer can request the branch directly via the standard procedures Package Change Request (e.g. via bugzilla currently). The proposed EPEL maintainer should CC the Fedora maintainer on the branch request, so the Fedora maintainer knows that the package is maintained in EPEL as well. Additionally, please note that that the Fedora maintainer is not interested in EPEL in your request.
If it is unclear if the Fedora maintainer of the package intends to participate in EPEL then the proposed EPEL maintainer should file a bug against the package and ask about their plans for EPEL in general and the package at hand. If there is no answer within seven days the proposed EPEL maintainer is free to request the EPEL branch and become the EPEL Maintainer (CC the Fedora maintainer here as well). Please note on your CVS request the number of the bug you filed. If the Fedora maintainer decides not to be active in EPEL they should be added to the CC list for all bugs so that collaboration can happen where a bug effects Fedora and EPEL.
If the Fedora maintainer later decides to participate in EPEL, Then the Fedora maintainer will become co-maintainer for EPEL. (Of course co-maintainership can be extended to Fedora).
Templates
You can use the following templates to contact fedora contributors who have not stated that they are not interested in EPEL.
Template 1
Hi! There are people around that would like to see some of your Fedora packages in Extra Packages for Enterprise Linux (EPEL) [1] -- I for example would like to see FOOBARBAZ in EPEL and mainly send you this mail on behalf of the EPEL team as you didn't yet let the team know via the Contributor Status [2] page if you are planning to build some or all of your Fedora packages for EPEL. Are you interested in maintaining your packages in EPEL? EPEL is similar to Fedora Extras -- just that EPEL is a add-on repo for RHEL and compatible spinoffs such as CentOS. EPEL uses the same CVS and the same build servers as Fedora and a lot of Fedora maintainers are EPEL maintainers as well; the main difference is just that packages in EPEL are updated more carefully and supported for a longer timeframe. See [3] and [4] for details. In short: EPEL tries to ship a package once and update it to later versions only when there is a strong need to. For branching your packages for EPEL follow the standard Fedora procedure[5] -- instead of FC-6 or F-7 targets just use EL-4 or EL-5 as branch names. If you maintain several packages (> 2) you can also use a scripted branching method (all packages from a contributor) by using the scripted branch process[6] . If you are not interested in EPEL please let the EPEL contributors know and update the information on [2] to avoid further mails like this -- that just takes a minute or two and would be a great help for the EPEL team. Please note that EPEL maintainers that might want to see your package in EPEL will likely start to maintain the package in EPEL sooner or later and thus become co-maintainers [7] of your packages for EPEL. The EPEL team appreciate your help with EPEL. [1] http://fedoraproject.org/wiki/EPEL [2] http://fedoraproject.org/wiki/EPEL/ContributorStatus [3] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies [4] http://fedoraproject.org/wiki/EPEL/FAQ [5] http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure [6] http://fedoraproject.org/wiki/MichaelStahnke/ScriptedBranchProcess [7] http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership
Template 2
Attention $USER Your packages <insert packages here> currently found in Fedora have been requested for inclusion in Extra Packages for Enterprise Linux (EPEL)[1] . Thus far, while looking at our Contributor Status[2] page, we are unable to determine if you are planning to build your packages for EPEL. If you are interested in building, please follow the Branching Procedure[3] for EPEL. If you maintain several packages (> 2) you can also use a scripted branching method (all packages from a contributor) by using the Scripted Branch Process[4] . If you are not interested in EPEL or don't feel like you have the time to put your packages into EPEL, the EPEL project would like to request that a co-maintainer who is a part of EPEL be added to your packages. To do this, please follow the co-maintainer process[5] . We appreciate your help with EPEL. The EPEL team [1] http://fedoraproject.org/wiki/EPEL [2] http://fedoraproject.org/wiki/EPEL/ContributorStatus [3] http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure [4] http://fedoraproject.org/wiki/MichaelStahnke/ScriptedBranchProcess [5] http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership
Template for wishlist processing
Subject: Someone asked for foobar to be added to the EPEL repos Hi! It seems someone thinks having your Fedora package foobar available in the Extra Packages for Enterprise Linux (EPEL) [1] repositories would be a nice to have, as the package was added to the EPEL wishlist [2] . As a result to that you get this semi-automatic generated mail on behalf of the EPEL SIG. Please take a moment and read through it; it contains instructions how to prevent similar mails in the future. If you don't know what EPEL is take a look at the bottom of this mail. In short: EPEL is similar to how Fedora Extras was -- just that EPEL is a add-on repo for RHEL and compatible spinoffs such as CentOS. Are you interested in maintaining your Fedora packages in EPEL or are you participating in EPEL already? Then please consider to branch the package mentioned above for EPEL using the standard Fedora procedure [5] -- instead of F-7 or F-8 targets just use EL-4 or EL-5 as branch names. Once you branched and build your package please remove it from the wishlist [1] . If your packages requires other packages that are not yet in EPEL please add them to the wishlist. If you need help then feel free to ask on the EPEL developers mailing list at [6] or in the #epel channel on the Freenode ICR network. For example if you want to participate in EPEL but don't have a RHEL or CentOS system around then just ask there for help -- with a bit of luck you will find someone that checks if the packages you build for EPEL work fine. If you definitely are not interested in EPEL at all please let the EPEL contributors know and add your Fedora Account Systems (FAS) username to [7] . That takes just a minute or two should avoid further mails like this. Please note that EPEL maintainers that might want to see your package in EPEL will likely start to maintain the package in EPEL sooner or later and thus become co-maintainers [8] of your packages. There are situations when bogus request make it onto the EPEL wishlist -- if it for example makes no sense to have the package mentioned above in EPEL please just remove it from the wishlist. The EPEL SIG appreciates your help. foo bar, on behalf of the EPEL SIG Footnotes: [1] http://fedoraproject.org/wiki/EPEL [2] http://fedoraproject.org/wiki/EPEL/WishList [3] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies [4] http://fedoraproject.org/wiki/EPEL/FAQ [5] http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure [6] https://www.redhat.com/mailman/listinfo/epel-devel-list [7] http://fedoraproject.org/wiki/EPEL/ContributorStatusNo [8] http://fedoraproject.org/wiki/PackageMaintainers/Policy/EncourageComaintainership = What is EPEL = EPEL is similar to how Fedora Extras was -- just that EPEL is a add-on repo for RHEL and compatible spinoffs such as CentOS. As those are based on Fedora most of the Fedora packages that didn't make it into the Enterprise distributions work there after a simple recompile or after some small adjustments to the spec file. A lot of Fedora maintainers are EPEL maintainers as well. EPEL uses the same CVS and build servers as Fedora so it's easy to use for Fedora contributers; the main difference is just that packages in EPEL are updated more carefully and supported for a longer timeframe. See [3] and [8] for details. In short: EPEL tries to ship a package once and update it to later versions only when there is a strong need to. That similar to how Red Hat does it for the package in its Enterprise Linux.