<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 5, 2012 at 8:58 AM, Troy Dawson <span dir="ltr"><<a href="mailto:tdawson@redhat.com" target="_blank">tdawson@redhat.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 12/05/2012 08:47 AM, Greg Swift wrote:<br>
><br>
> On Tue, Dec 4, 2012 at 5:46 PM, Ken Dreyer <<a href="mailto:ktdreyer@ktdreyer.com">ktdreyer@ktdreyer.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:ktdreyer@ktdreyer.com">ktdreyer@ktdreyer.com</a>>> wrote:<br>
><br>
> On Tue, Dec 4, 2012 at 3:48 PM, Greg Swift <<a href="mailto:gregswift@gmail.com">gregswift@gmail.com</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:gregswift@gmail.com">gregswift@gmail.com</a>>> wrote:<br>
> > I'm personally inclined to lean toward the concept I was pushing<br>
> in the<br>
> > thread discussing multiple versions [1]. I'd imagine that a 'api<br>
> stable'<br>
> > repo and a 'rolling' repo would be less support effort than<br>
> attempting to<br>
> > manage >8 repositories per major release and the security updates<br>
> that need<br>
> > to be applied on older version.<br>
><br>
> 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>
><br>
><br>
> I can back that line of thought. Plus providing 1 path means less<br>
> change! :)<br>
><br>
><br>
> > So, unless someone wants to turn EPEL into a paid service, #1 is out<br>
> > (hey... thats an interesting concept...)<br>
><br>
> 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.<br>
><br>
><br>
> So... anyone got any motivation in pushing a product internally @ Red<br>
> Hat that does this? :)<br>
><br>
><br>
> Also.... I hadn't mentioned it before on here, because in general<br>
> mentioning tends to mean you have to do it and I don't really have the<br>
> cycles available. But as of this morning I figured I'd float the<br>
> concept anyways.<br>
><br>
> What would it take to basically have a yum plugin would check a<br>
> 'notification' feed (something simple like rss or atom) about a specific<br>
> repository. Notifications found on that feed would throw messages in<br>
> the yum output and /var/log/messages. This feed could provide notices<br>
> like 'Hey, this version is deprecated and insecure, you need to<br>
> update'. An extension of this might be that it marks the package as an<br>
> 'exclude' if it can't just be updated without interference. This would<br>
> allow a notification method, and a way for users to not get an update if<br>
> its going to break them, but also allowing the main page to just<br>
> continuously be updated.<br>
><br>
> Then this package could possibly be a required package from the<br>
> epel-release package.<br>
><br>
> -greg<br>
<br>
</div></div>Not volunteering at the moment because I don't have the cycles, but I<br>
really like that idea.<br>
Something similar, except opposite, of the security plugin. If a<br>
package has the "breakable update" option set, then don't update it<br>
unless they do the "--reallyupdate" option. But also give them a nag<br>
that says the package has an update.<br></blockquote><div> </div><div>I'm very amused with myself for forgetting about the security plugin (mainly cause I never used it but still...) <br></div></div></div>