#36 reword some of the charter, talk some about initial vs current policies, reword a few things
Merged 7 years ago by smooge. Opened 7 years ago by kevin.
kevin/epel policy-tweaks  into  master

file modified
+30 -14
@@ -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

no initial comment

Pull-Request has been merged by smooge

7 years ago
Metadata