Unstable EPEL? (frequent package updates)

[Ray Van Dolson]

On Tue, Jul 01, 2008 at 11:06:16AM +0200, 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.
>>>
>>> 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 would love to see there be a place for some elasticity.  And it'll
end up being pretty arbitrary to enforce I imagine.  Not all of us have
the technical ability or time to backport fixes and so the risk of
regression is always going to be higher than it would with a normal
RHEL package.

>
> 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

This would definitely be a necessary step, and probably not a fun job.
Lots of people simply push new updates to their packages when upstream
releases it... and by and large it's been harmless but certainly
doesn't fit in with EPEL's goals...

I'm somewhat torn though.  It's one thing to not update something that
provides an API to other programs, but maybe less of an issue to update
a client only program -- something like freehoo (CLI Yahoo messenger
client) which is something I would hate to see stuck at a really old
version just because it's against policy to update it.

Is there a place for a -unstable branch for those of us who want to
have updated / newer packages? 

I just want to avoid a situation where I end up either maintaining a
personal repository of "newer" packages for EL-5 simply because I'm
stuck at an old version in EPEL, or end up deciding to maintain a new
package in a repository with less restrictive rules....

Take with a grain of salt; this is coming from a guy who only maintains
a few packages for personal and work use.

Ray