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