EPEL Notes from .next discussion.

[Stephen John Smoogen]

On 13 August 2014 06:28, Dennis Gilmore <dennis at ausil.us> wrote:

> On Wed, 13 Aug 2014 01:25:04 +0200
> Stephen John Smoogen <smooge at gmail.com> wrote:
>
> > On 12 August 2014 21:56, Dennis Gilmore <dennis at ausil.us> wrote:
>
> > > >   * Example: When RHEL7.1 comes out we have a 30 day window to get
> > > > packages updated and new packages in that make incompatible
> > > > changes.
> What is the problem you're trying to solve here?
>
>
The problem I am trying to solve is that we have packages that require
large deltas to stay patched and relevant to users. However users do not
want to have these appearing 'randomly' during a release cycle. So by
keying such large deltas to the Red Hat point releases we have a place
where the updates can occur and if old stuff is still wanted with new stuff
how to maintain both.



> > > >     * Archive 7.0.  The toplevel 7 tree is a symlink to whatever
> > > > point release is latest.
> > > > * Formalize the governance of EPEL.
> > > >   * Written policies of some sort for decision making
> > > >   * Elections?
> > > >   * Problems to solve:
> > > >     * Don't want to just listen to the people who are loudest
> > > >     * Don't want to just listen to the people who have been
> > > > around the longest
> > > > * Do we want automated testing of EPEL?  yes.  get it working on
> > > > whatever subset you can and we'll go on from there.
> > > > * Move to CentOS as build system?  Gives us additional arches.
>
> It doesn't actually give us any extra arches.  I would like to work out
> a way to enable EPEL contribution via a CentOS path and have EPEL be
> part of both Fedora and CentOS.
>
>
if CentOS gets ARM32 and i386 then it would add 2 arches that people are
'wanting' but RHEL does not support.


> > > > * Could we do an ISV program like quaid does?
> > >
> > > something to consider is moving epel to /opt/fedora/epel or
> > > somewhere like it, then dealing with overlap etc should be simpler,
> > > but it would take a massive change in packaging and could really
> > > only be done in epel8
> > >
> >
> > I think that would be something with softwarecollections.org as that
> > seems in line with their way of packaging items.  I think that for
> > some sorts of packages and libraries it makes sense for that, but I
> > don't know if EPEL would mix and match like that. What I would like
> > to do is the following:
>
> I disagree. FHS says that anything not part of the OS should go
> in /opt/ EPEL is an add on and not part of the OS.
>
>
In the past we did not do this because we were bound by the Fedora
Packaging Rules. I don't have the energy or want to try and fight that
Windmill but I am not going to stand in someone who wants to.



> > We move from our moving distribution to a point release cycle with a
> > disk layout like the following:
> >
> > epel
> > epel/development/
> > epel/development/5
> > epel/development/6
> > epel/development/7
> > epel/beta/5.12
> > epel/beta/6.7
> > epel/beta/7.1
> > epel/releases
> > epel/releases/6.6
> > epel/releases/5.11
> > epel/releases/7.0
> > epel/updates
> > epel/updates/6.6
> > epel/updates/5.11
> > epel/updates/7.0
> > epel/updates/testing/
> > epel/updates/testing/6.6
> > epel/updates/testing/5.11
> > epel/updates/testing/7.0
> >
> > epel/development would be like the current EPEL directories but
> > without the stringent requirements that packages are locked to a
> > specific version for the lifetime of the overall RHEL release.
> > Instead whenever RHEL releases a new dot release (7.0, 6.6, 5.11),
> > EPEL would branch off the releases from development to beta/7.0 or
> > beta/6.6 etc. Packages would be built against the point release and
> > would need to be tested to get sufficient karma for 'release'. Once 6
> > weeks have passed from the RHEL point release, all packages which had
> > gotten enough karma and that had completed repository trees would be
> > put into epel/releases/6.6. Updates to that package would be put into
> > updates/testing/6.6 and then promoted to updates/6.6 when enough
> > karma had been given for an update. New packages which were added
> > after the point release would show up in updates following the
> > process Fedora does for new packages between point releases.
>
> This will make a much larger work load for releng. what extra resources
> will we have? I find it quite confusing. I honestly do not like the
>

What extra resources do you need?  I am sorry it is confusing.. I am trying
to communicate it while severely jetlagged. Part of this is to get a
conversation going so that we can find out why this would not work or would
work.


> idea of having a static snapshot for releases. we have a few options
> available to make older versions available. we can mash the tree with
> every package ever released. or we can work on fixing the patches in
> mash to have say the last 2 or 3 builds.  I think we are better off
> having epel as somthing stable where you can not put incompatible
> changes for the life of the rhel release and epel-extras where things
> are able to change quickly and in incompatible ways.
>
>
That was an alternative but I wasn't sure how much koji/bodhi/pkg changes
it would require or what packages would actually stay in EPEL versus
EPEL-extras as most packages have had to require a major change over a 10+
year lifetime that RHEL is going to.



> Dennis
>



-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20140813/6ad98aa1/attachment-0001.html>