RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Ken Dreyer]

On Tue, Dec 4, 2012 at 3:48 PM, Greg Swift <gregswift at gmail.com> wrote:
> I'm personally inclined to lean toward the concept I was pushing in the
> thread discussing multiple versions [1].  I'd imagine that a 'api stable'
> repo and a 'rolling' repo would be less support effort than attempting to
> manage >8 repositories per major release and the security updates that need
> to be applied on older version.

My main concern with multiple EPEL repos is that users will be in a
worse condition security-wise. Many users will download an application
from the "api stable" repo, but they will not realize that no one is
doing backports any more, because all the interested EPEL maintainers
left that behind to focus on the "rolling" repo.

The analogy that comes to my mind is Fedora: What if we kept old
Fedora releases going back all the way to Fedora 6 open to maintainers
to patch on a voluntary basis, and we never really announced EOL for
any Fedora release? Fedora users would have to know enough to keep
jumping along with whatever's maintained.

It seems to me that we have to choose between occasional instability
and insecurity. I'd rather EPEL's reputation err on the side of
instability rather than insecurity.

> So, unless someone wants to turn EPEL into a paid service, #1 is out
> (hey...  thats an interesting concept...)

Maybe money does have to enter the picture at some point. Corporations
should commit to pay salaries for more developers to do EPEL backports
if it's important to their businesses.

- Ken