What's the backstory on this? It mostly looks good to me. Is
there a way to
propose edits off-list (editing this in an email doesn't seem great).
I am going to put these up on the epel pagure so that people can make
pulls and such.
The back story is that EPEL has a ton of very old and out of date
information that people find on the wiki. EPEL also has not had its
'charter' looked at or renewed by Fedora in a long time while most
other groups have. So I am trying to get us back under a clear set of
documents and to remove all the old cruft.
-Jeff
On Tue, Mar 7, 2017 at 5:48 PM, Stephen John Smoogen <smooge(a)gmail.com>
wrote:
>
> ========
> Vision
> ========
>
> Visions are for people who stand on mountains. System administrators
> and operators are people just trying to get stuff done and have the
> pager not go off one night.
>
> =========
> Mission
> =========
>
> To build and maintain a curated set of packages built from Fedora
> releases that help system administrators get their jobs done on Red
> Hat Enterprise
> Server and related operating systems.
>
> =========
> History
> =========
>
> Red Hat Enterprise Linux (RHEL) is technically a downstream of the Fedora
> Project. Various RHEL releases have been based off either Red Hat
> Linux or Fedora releases.
>
> * RHEL 2.1 == Red Hat Linux 7.2
> * RHEL 3 == Red Hat Linux 9/Fedora Core 1
> * RHEL 4 == Fedora Core 3
> * RHEL 5 == Fedora Linux 6
> * RHEL 6 == Fedora Linux 12/13
> * RHEL 7 == Fedora Linux 18/19
>
> 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.
>
> Early on, many of these packages were maintained by various Forges and
> developers who would put these packages up on websites for others to
> use as they needed. Sometimes these packages would conflict with
> either RHEL packages or each other. Othertimes the packages would get
> updated rapidly to meet the developers needs but not other
> users. Various people felt that maybe it would be better to build
> packages from Fedora into an Extras repository that could be used by
> people.
>
> 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.
>
> ==================
> 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.
>
> 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]
>
>
> ===================
> Organization Rules
> ====================
>
> Steering Committee
> ==================
>
> The EPEL Steering Committee (EPSCO) is made up of interested members
> of the various Red Hat Enterprise Linux rebuild communities. As of
> 2017-03, the membership consists of 2 members from CentOS, 2 members
> from Fedora and 1 member who sits in both.
>
> * Stephen Smoogen (smooge)
> * Kevin Fenzi (nirik)
> * Brian Stinson (bstinson)
> * Jim Perrin (Evolution)
> * Anssi Johansson (avij)
>
> EPEL and the EPEL Steering Committee are chartered by the Fedora
> Council. The Fedora Council can override any decision made by EPSCO.
> The size of the EPSCO committee is set by the committee but can be
> increased or decreased by the Fedora Council.
>
> Each member of EPSCO will confirm their continued membership on the
> committee once a year. If a member leaves, then the remaining members
> should canvas for a replacement and at the next general meeting hold a
> general nomination and in meeting "election" of any candidates. If
> there are multiple candidates or other complications, an election
> using the Fedora voting system will be held.
>
> A committee member can be removed by a super plurality vote of the
> other Steering Committee Members. [For the current committee size that
> would be 4/5ths.]
>
> Responsibilities
> ================
> EPSCO is charged with meeting regularly to go over current problems
> and concerns of the EPEL community. It will create policies governing
> what releases EPEL will build for, what packages may be in the
> repository, testing and packaging requirements and all other policies
> needed for the well being of the EPEL community.
>
>
> Meetings
> ========
> * EPSCO will hold meetings no less than once a month in
> #fedora-meeting on Wednesdays at 1800 UTC. This time will not change
> with various country daylight savings.
> * A quorum of members is 4/5ths of the committee members.
> * An agenda for each meeting should be published 12 hours before the
> 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
> * 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
> list. They should be also posted by the chair to the epel-devel
> mailing list.
>
> Making Decisions
> ================
> In general, decisions by EPSCO should be done by consensus. [
>
https://en.wikipedia.org/wiki/Consensus_decision-making#Objectives ] In
> the
> case, where there is a disagreement by members, a simple majority vote
> of the committee will decide the matter.
>
> ==================
> General Policies
> ==================
> 1. Package Inclusion
> 2. Package Exclusion
> 3. Package Removal
> 4. Package General Updates
> 5. Package Incompatible Updates
> 6. Packaging Rules
> a. RHEL6
> b. RHEL7
>
>
> --
> Stephen J Smoogen.
> _______________________________________________
> epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org