[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RFC: Package maintenance and update policy for EPEL -- take 1

Thorsten Leemhuis wrote:
== Policy ==

EPEL packages should only enhance and never disturb the Enterprise Linux distributions the packages were build for. Thus packages from EPEL should never replace packages from the base distribution they get build against; kernel-modules further are not allowed, as they can disturb the base kernel easily.

The Packages in the Repository should if possible get maintained in similar ways like the packages get maintained in the Enterprise Linux Distribution they get build against. In other words: have a mostly stable set of packages that normally does not change at all and only changes if there are good reasons for changes.

The changes that cant be avoided get routed into different release trees. Only updates that fix important bugs (say: data-corruption, security problems, really annoying bugs) go to a testing branch for a short time period and then build a second time for the stable branch; those people that sign and push the EPEL packages to the public repo will skim over the list of updated packages for the stable repo to make sure that sure the goal "only important updates for the stable branch" is fulfilled.

Other updates get queued up in a testing repository over time. That repository becomes the new stable branch in parallel with the quarterly update that get released by the Linux Distributor that creates the Enterprise Linux the packages gets build against. There will be a short freeze time period before the quarterly update happens to make sure the repo and its packages are in a good shape. But even this updates should be limited to fixes only as far as possible and should be tested in Fedora beforehand if possible. Updated Packages that change the ABI or require config file adjustments must be avoided if somehow possible. Compat- Packages that provide the old ABI need to be provided in the repo if there is no way around a package update that changes the ABI.

The discussion about repotag's makes me think we will soon see some of the same packages in 2 or 3 different repositories. I would hope all the packagers can work together and not duplicate each others efforts, but I guess that's not always possible due to different preferences in having the latest versus the more stable, or other differences of opinion. Anyways, as a start, I would suggest adding something like this to the 'Policy' section a paragraph suggesting maintainers of EPEL packages take in to account existing packages for EL4/5 from RPMforge, ATrpms, etc:

"Before creating an EPEL branch for a package, maintainers should check if the package is available from RPMForge, ATrpms, or CentOS Extras (and others??). If that is the case, it would be best to consider that many thousands of users may have that package installed already on their EL4/EL5 systems. Maintainers should inform the other packager of their intention to create the EPEL branch, and include them in any discussion regarding the package. It is also recommended to ensure that the EPEL package is a compatible upgrade from the other package, while still ensuring the Fedora packaging guidelines are followed."

Does that sound reasonable?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]