[EPEL-devel] Re: 0.0 Draft of EPEL Charter

[Stephen John Smoogen]

On 8 March 2017 at 10:32, Jeff Sheltren  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 
> 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
> > ==================
> > Package Inclusion
> > Package Exclusion
> > Package Removal
> > Package General Updates
> > Package Incompatible Updates
> > Packaging Rules
> >
> > a. RHEL6
> >   b. RHEL7
> >
> > --
> > Stephen J Smoogen.
> > _______________________________________________
> > epel-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]