On 5 September 2014 12:52, Kevin Fenzi <kevin@scrye.com> wrote:
On Thu, 4 Sep 2014 18:20:19 -0600
Stephen John Smoogen <smooge@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?


This would be a new seperate repo. The current Repositories are set up and have 6+ years of expectations on them. Trying to make changes to those expectations is not possible. I tried calling the seperate repo EPEL.dot to make sure it was clear it was seperate (and when I called it EPIC people didn't like that either).

 
> 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. ;(


I agree, if I were to do this with straight EPEL it would be a problem.



--
Stephen J Smoogen.