'policy' for multiple versions of same software in EPEL

[Greg Swift]

On Wed, Oct 24, 2012 at 2:40 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> On Wed, 24 Oct 2012 11:30:53 -0500
> Greg Swift <gregswift at gmail.com> wrote:
>
>>
>> Between thinking about it more, reading the RHEL/EPEL conflict post
>> again, and this post I'm inclined to go with the separate branch path.
>
> I'm still leary of the seperate branch. ;)
>
> Even aside from more work I worry that we will run into several
> possible problems:
>
> - New unstable branch is too unstable. Ie, people will enable that and
>   yum upgrade and it breaks them and they will be unhappy. Even if the
>   expectation of the branch is that it will be not stable.

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...)

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

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

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.

>> I have some cycles to work on this, but i would much rather have help,
>> especially people that have more experience in these tools than I.
>> This falls into the 'i either do it privately to benefit
>> myself/company, or try and make it work in EPEL to benefit others that
>> have expressed the need' category.  Personally, I prefer to work
>> upstream on it, but unless others are gonna hop on board its going to
>> be much easier in the short term for me to go the private route.
>
> Perhaps it would help if you could spell out exactly what things you
> need for yourself/company and we could try and figure out a better way
> to get them... if it's just a few packages that must be newer, perhaps
> a side repo would be best.

So what got me going on this _this time_ was wanting to have
rspec-puppet and collectd5 in EPEL.  Which led to the need for rspec
to be updated to rspec2 (for EPEL5/6).  Combine that with my past
interest in bugzilla, zabbix, puppet, and a few other projects.
Because of that I thought it would be nice to try and address the
obvious overall issue rather than just get my two packages taken care
of.

-greg