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
_______________________________________________
epel-devel-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/epel-devel-list
