EPEL EpSCO Email Meeting:

[Kevin Fenzi]

On Thu, 4 Sep 2014 18:20:19 -0600
Stephen John Smoogen <smooge at gmail.com> wrote:

> So this is my general proposal for per point release.
> 
> 
> Problem trying to be solved:
> 
> EPEL's original goal around a 5-7 year product has run into issues
> where various packages end up having shorter lifetimes than can be
> maintained in that period. What happens is that the upstream is
> changing the code too massively for any sort of 'back-port' to be
> possible. Some software can be 'patched' around by making it parallel
> installable but others (say puppet) only work if there is only one
> version not just on the system but throughout an entire ecosystem of
> systems (thus if you update one, they all have to be updated to the
> same version.) While EPEL has a process of saying you can announce a
> major change it is severely frowned on and usually ends up with
> various users asking 'can you just keep the older version around a
> bit longer...' ad infinitum. Another problem is that it isn't clear
> how much notice is needed for a change to be made or what changes are
> being made so that users and package owners end up confused and upset
> with each other.
> 
> Possible solution:
> 
> Make it so that updates to these sorts of packages occur at regular
> intervals. There are three cycles these could occur: regular date
> driven (July 1st of every year for example), the Fedora release cycle
> (Fedora 22 has been released, you can update now), and the Red Hat
> Enterprise release cycle (RHEL-6.6 is out, you can release now). Each
> of these cycles has their bonuses and minuses but I think that
> connecting to the RHEL cycle will be more in line with what
> downstream users of EPEL are going to be more in sync with.

ok, so to be clear this is a change in the existing EPEL repo(s)? 
Or is this new seperate repos?

> Proposed implementation:
> 
> Every Red Hat Enterprise Dot Release has a beta period and then a
> release period. After the release period there is a couple of weeks
> until a CentOS release is available. Since only the betas and CentOS
> release are generally available to any person off the street I am
> looking at those being 'action points' where the dot release period
> would be done. When a RHEL beta dot release (example RHEL-6.6 beta)
> is announced, EPEL.dot would say that packages to be updated in the
> next release are going to be accepted into EPEL-dot-testing. Package
> owners who are needing or wanting to make major changes in their EPEL
> package sets would target builds to that channel. People can test as
> needed or at least be aware where they could have tested. Sometime
> after the next dot release, CentOS releases their latest 'this is the
> state of CentOS build' which anyone needing to test latest builds can
> get. This acts as a marker for when EPEL.dot will 'release' its next
> tree which would be 1 month after the CentOS GA. 

The problem with that IMHO is that a month after people have updated,
they have forgotten about this, and get surprised when a chud of
incompatible changes land. ;( 

If this is a seperate repo they opt into, we could try and manage
expectations for that tho. 

> During that time,
> everything is rebuilt against the latest RHEL (to find any FTBS or
> ooops they dropped libmuffin and I needed it) and at the end of the
> month EPEL-6.7 is put out and EPEL-6.6 is set to be sent to archives
> after an appropriate time. Like CentOS, EPEL-6 -> EPEL-6.6 and then
> EPEL-6.7.
> 
> In the case of last planned release (RHEL-5.12?), a different
> mechanism could be used for when updates occur if there is enough
> people willing to do the work. Otherwise packages go into that tree
> until EPEL ends building for it.
> 
> Note only one tree is being built against. If someone wants to 'keep'
> EPEL-6.5 running, they can grab the src.rpms from archives and do it
> themselves on their own hardware.. EPEL only deals with RHEL current.
> 
> Have I made this clearer or muddier?

Some clearer.  :) 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20140905/26bbb852/attachment.sig>