Unstable EPEL? (frequent package updates)

[Manuel Wolfshant]

Thorsten Leemhuis wrote:
> On 01.07.2008 10:32, Paul Howarth wrote:
>> Felix Schwarz wrote:
>>> in the past few months there were quite a few packages in EPEL
>>> which got version updates. This has come to a point where I
>>> seriously doubt my understanding of the EPEL policy.
>>>
>>> Rahul Sundaram wrote [1]:
>>> "The simple rule: Don't release an update unless absolutely necessary.
>>> This is to avoid regressions."
>>>
>>> This was exactly my understanding of how package updates should be
>>> done in EPEL.
>>>
>>> But obviously other packagers don't see this policy so strictly - or
>>> maybe I'm just too blind to find important information why all these
>>> updates were absolutely necessary.
> [examples striped]
>>> I understand that there are packages like Firefox, Wine and clamav 
>>> which must be
>>> always at the latest version because it makes no sense/its 
>>> impossible to backport
>>> all the important stuff. But what I don't understand is why all 
>>> these library
>>> packages are updated so often.
>>>
>>> IMHO EPEL should have more control over updates so that every 
>>> package update gets
>>> a solid reasoning why the package has to updated, if there are known 
>>> compatibility
>>> issues and so on...
>>>
>>> I always thought of EPEL as 'this is an repository where I can pull 
>>> updates without
>>> too much caution because the guys will really make sure that every 
>>> package is
>>> necessary'.
>>> </rant>
>>> [1] 
>>> https://www.redhat.com/archives/epel-devel-list/2008-April/msg00019.html 
>>>
>> Agree 100%. I tend to take the same approach on stable Fedora 
>> releases too, but it's even more important to do so in EPEL.
>
> I don't have time to discuss the details right now, but I tend to agree.
So do I. But with a grain of salt



>
> Some suggestions how to fix this:
>
> - do the general testing -> stable moves less often (every three or 
> four months maybe?); that was in the initial EPEL plans (but was 
> changed later on) and will indirectly force maintainers to slow down a 
> bit (but that doesn't solve the problem completely; further: new 
> packages IMHO should be moved more often)
We could follow the RH pace, but I really really do not like it.

>
> - educate EPEL contributors; e.g. let someone watch the CVS commits to 
> EL branches closely; if there is a big update ask the maintainer why 
> that is needed (I did that in the past now and then when I was EPEL 
> chair, but I don't have time for it anymore; sorry); if unneeded 
> remove the build before it gets pushed to testing
I agree 100% here. Education is the key.