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 :
> "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.
> 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
> too much caution because the guys will really make sure that every package is
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