On 8 March 2017 at 10:32, Jeff Sheltren <jeff@xxxxxxxxxxxxxxxxxx> wrote: > 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@xxxxxxxxx> > 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@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > -- Stephen J Smoogen. _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
