EPEL EpSCO Email Meeting:

[Brian Stinson]

On Sep 04 18:20, Stephen John Smoogen 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.
> 
> 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. 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?
> 
> 
> -- 
> Stephen J Smoogen.

I think this fits in well with the release calendar(s) that EPEL consumers are
already working with. Not sure what other feedback I can give, except that I
like it.

Brian 

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