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.