<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 4, 2012 at 5:46 PM, Ken Dreyer <span dir="ltr"><<a href="mailto:ktdreyer@ktdreyer.com" target="_blank">ktdreyer@ktdreyer.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Dec 4, 2012 at 3:48 PM, Greg Swift <<a href="mailto:gregswift@gmail.com">gregswift@gmail.com</a>> wrote:<br>
> I'm personally inclined to lean toward the concept I was pushing in the<br>
> thread discussing multiple versions [1]. I'd imagine that a 'api stable'<br>
> repo and a 'rolling' repo would be less support effort than attempting to<br>
> manage >8 repositories per major release and the security updates that need<br>
> to be applied on older version.<br>
<br>
</div>My main concern with multiple EPEL repos is that users will be in a<br>
worse condition security-wise. Many users will download an application<br>
from the "api stable" repo, but they will not realize that no one is<br>
doing backports any more, because all the interested EPEL maintainers<br>
left that behind to focus on the "rolling" repo.<br>
<br>
The analogy that comes to my mind is Fedora: What if we kept old<br>
Fedora releases going back all the way to Fedora 6 open to maintainers<br>
to patch on a voluntary basis, and we never really announced EOL for<br>
any Fedora release? Fedora users would have to know enough to keep<br>
jumping along with whatever's maintained.<br>
<br>
It seems to me that we have to choose between occasional instability<br>
and insecurity. I'd rather EPEL's reputation err on the side of<br>
instability rather than insecurity.<br></blockquote><div><br>I can back that line of thought. Plus providing 1 path means less change! :) <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> So, unless someone wants to turn EPEL into a paid service, #1 is out<br>
> (hey... thats an interesting concept...)<br>
<br>
</div>Maybe money does have to enter the picture at some point. Corporations<br>
should commit to pay salaries for more developers to do EPEL backports<br>
if it's important to their businesses.<span class="HOEnZb"></span><br></blockquote><div><br>So... anyone got any motivation in pushing a product internally @ Red Hat that does this? :)<br><br><br>Also.... I hadn't mentioned it before on here, because in general mentioning tends to mean you have to do it and I don't really have the cycles available. But as of this morning I figured I'd float the concept anyways.<br>
<br>What would it take to basically have a yum plugin would check a 'notification' feed (something simple like rss or atom) about a specific repository. Notifications found on that feed would throw messages in the yum output and /var/log/messages. This feed could provide notices like 'Hey, this version is deprecated and insecure, you need to update'. An extension of this might be that it marks the package as an 'exclude' if it can't just be updated without interference. This would allow a notification method, and a way for users to not get an update if its going to break them, but also allowing the main page to just continuously be updated.<br>
<br>Then this package could possibly be a required package from the epel-release package.<br><br>-greg<br></div></div></div>