'policy' for multiple versions of same software in EPEL

[Kevin Fenzi]

On Wed, 24 Oct 2012 16:23:28 -0500
Greg Swift <gregswift at gmail.com> wrote:

...snip...

> So... going back to my REPEL name recommendation ;)
> 
> Okay... seriously though.  Fedora has the same issue.  Fedora is not
> stable.  Doesn't claim to be.  But people still install it and expect
> it to be.  I don't see us actually changing what Fedora is just
> because of that. (lots of talk on occasion and i guess maybe there is
> a action item I haven't heard of...)

Sure. 

> > - Old branch gets forgotten about... ie, maintainer pushes new and
> >   ignores bugs/security issues on old branch because they now don't
> >   have the same incentive to make it work. ;(
> 
> That is a problem.  However, its already the case from what I've
> observed.  The old packages stagnate and the users move to an
> internal/separate repository or start a separate package path, or in a
> few cases just update the package.

Perhaps, but I suspect many also just continue blindly using the old
packages. ;( 

> > - Extra confusion around tools and branch changes...
> 
> To me the biggest set of confusion around this whole thing is that it
> is inconsistent and not set forth in a policy.  Right now the policy
> ends up being  'well.. don't break the customer, otherwise figure it
> out'.
> 
> If the policy was:
> 
> EPEL is a slow moving, safe to upgrade, but not always safe from a
> security standpoint after X amount of time repository.

Yeah, I dislike that, because how is someone to know? 
check the other repo for a newer version? But that might be due to
features, not security... 

> REPEL is a faster moving repository that may include updates that
> require manual intervention.  Use at your own risk, but you'll
> probably have more secure updates since its staying current.
> 
> or going to Ken's suggestion:
> 
> EPEL is a slower moving repository.  In line with RHEL dot releases
> new packages maybe released that require manual intervention to work
> post install, however this is due to the need to keep software secure
> and current.  As long as a release branch is receiving updates from
> upstream, that package will be able to update safely.  Once upstream
> has EOL'd the tool it will be updated based on an assessment of the
> tool's newer releases.  To stay aware of these potential updates we do
> X, Y, and Z to notify users.  You can protect yourself from the change
> by placing the package in your exclude list per these instructions.

Yeah, I like that better personally. But it also has it's issues. ;) 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121029/0313b08b/attachment.sig>