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).
-Jeff On Tue, Mar 7, 2017 at 5:48 PM, Stephen John Smoogen <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
