[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Unstable EPEL? (frequent package updates)



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]