On Thu, 4 Sep 2014 18:20:19 -0600
Stephen John Smoogen <smooge(a)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