| |
@@ -32,8 +32,8 @@
|
| |
RHEL releases are not the entirety of any Fedora release, but a subset
|
| |
that Red Hat feels best meets the needs of their customers while being
|
| |
long term maintainable by Red Hat. This means that many packages that
|
| |
- a customer might need was never included and that customer would need
|
| |
- to search for a package somewhere else.
|
| |
+ are available in Fedora wouldn't be available in RHEL and would have
|
| |
+ to be found somewhere else.
|
| |
|
| |
Early on, many of these packages were maintained by various Forges and
|
| |
developers who would put these packages up on websites for others to
|
| |
@@ -46,25 +46,41 @@
|
| |
|
| |
Initially there was some consensus of packagers joining together, but
|
| |
eventually disagreements emerged on various packaging philosophies
|
| |
- which caused EPEL to go one way and others to join at organizations
|
| |
- like RPMforge.
|
| |
+ which caused EPEL to go one way and others to go another.
|
| |
|
| |
==================
|
| |
Initial Policies
|
| |
==================
|
| |
|
| |
The initial packaging philosophy has been that EPEL will never replace
|
| |
- a package that is shipped in Red Hat Enterprise Server. The reason for
|
| |
- this limitation was that this was the only release that the builders
|
| |
- had access to, so other RHEL releases (desktop, etc) could not be
|
| |
- easily checked if there was a conflict.
|
| |
+ a package that is shipped in Red Hat Enterprise Linux and that maintainers
|
| |
+ would not push any updates that required interactive attention to
|
| |
+ continue working.
|
| |
|
| |
- Secondly, updates were to try and not break things. The idea was that
|
| |
- system administrators should not need to manually update or change
|
| |
- anything to make a process work again after an 'yum update'. [This
|
| |
- policy is no longer valid as the philosophy of various software
|
| |
- upstreams has become much less open to automated updates]
|
| |
+ ==================
|
| |
+ Current Policies
|
| |
+ ==================
|
| |
+ When RHEL was small it was easy to not conflict, but as RHEL split into
|
| |
+ various products (Server, Workstation, etc) and then further split
|
| |
+ into a great many (sometimes conflicting) channels, this policy became
|
| |
+ untenable.
|
| |
+
|
| |
+ Likewise when software was designed for long periods of stablity, it
|
| |
+ was easy to ensure unattented updates worked fine, but many new packages
|
| |
+ have a much faster life cycle than the RHEL they are built on, so this
|
| |
+ policy as well became difficult.
|
| |
+
|
| |
+ Currently EPEL will strive to never replace a package in some specific
|
| |
+ set of RHEL channels. See:
|
| |
+
|
| |
+ epel7 - https://koji.fedoraproject.org/koji/taginfo?tagID=259
|
| |
+ epel6 - https://koji.fedoraproject.org/koji/taginfo?tagID=140
|
| |
+ epel5 - https://koji.fedoraproject.org/koji/taginfo?tagID=81
|
| |
|
| |
+ EPEL maintainers will strive to make updates non interactive and working,
|
| |
+ however exceptions will be made from time to time due to upstream
|
| |
+ support life cycles. Interested parties are encouraged to
|
| |
+ subscribe to the epel-announce list.
|
| |
|
| |
====================
|
| |
Organization Rules
|
| |
@@ -119,7 +135,7 @@
|
| |
meeting.
|
| |
* If there is no agenda or not a quorum for meeting, then the meeting
|
| |
will have only one item which is "select items for the next meetings
|
| |
- agenda". This will be emailed to the list and requests for
|
| |
+ agenda". This will be emailed to the list and requests from there added.
|
| |
* If a voting member can not attend, they can ask for a vote to be
|
| |
retaken either by email or the next meeting.
|
| |
* After meetings, meeting minutes will be posted to the Fedora meeting
|
| |