Unstable EPEL? (frequent package updates)

[Thorsten Leemhuis]

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.

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)

- 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

CU
knurd