EPEL Notes from .next discussion.

[Brian Stinson]

On Aug 13 01:25, Stephen John Smoogen wrote:
> 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:
> 
> 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.
> 
> Later when 7.1, 6.7, 5.12 (or whatever they are called) comes out then the
> process is repeated which will make sure that packages that aren't needed
> enough to have sponsors will not be in EPEL and potentially broken and
> large updates are possible so if python34 is in 7.0 but python35 is ready
> for 7.2 it can replace it without problems (or similarly with ruby23 etc
> etc). Once the next point release is made ready, the old point release will
> be archived off to keep storage levels within reason.
> 
> I know that this proposal needs a lot more fleshing out, but I think it
> covers the use cases many users of EPEL need for long term usage of
> packages.
> 
> 
> -- 
> Stephen J Smoogen.

Were there plans made (at flock or elsewhere) for regular EPEL-related meetings? I would like
to chip in and help where I can. I think this proposal strikes a happy medium
between stability (within a point-release) and updated features. 

--
Brian Stinson
bstinson at ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk