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