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

Greg Swallow greg at runlevel7.ca
Thu Mar 15 06:19:31 UTC 2007


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?

Greg




More information about the epel-devel-list mailing list