11:11 a.m.
On 13 August 2014 06:28, Dennis Gilmore <dennis(a)ausil.us> wrote:
On Wed, 13 Aug 2014 01:25:04 +0200
Stephen John Smoogen <smooge(a)gmail.com> wrote:
> On 12 August 2014 21:56, Dennis Gilmore <dennis(a)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.