Unstable EPEL? (frequent package updates)

[Jeroen van Meeuwen]

Michael A. Peters wrote:
> Jeroen van Meeuwen wrote:
>> Michael A. Peters wrote:
>>> There are a few exceptions. I do think RHEL is justified in moving 
>>> Firefox to FF3. The reason is twofold -
>>>
>>> 1) Firefox has a huge codebase. It would take extreme amount of man 
>>> power to continue to maintain FF 1.x without upstream.
>>>
>>> 2) The web evolves quickly, and a browser must keep in touch with 
>>> modern web innovations, particularly in the area of javascript and 
>>> CSS implementation.
>>>
>>
>> A small addition here; RHEL does so by releasing a minor update to the 
>> entire operating system (5.2) - so everyone knows to look for changes 
>> like these. Is this something EPEL can do as well?
>>
>> EPEL 5.1/nethack-3.4.3
>>
>> EPEL 5.2/nethack-4.0 (for the right reasons)
>>
>> Just a thought.
> 
> To be honest, I think it would be too much effort to keep separate 
> branches of EPEL for each point release just for the few cases where 
> there is a legitimate reason to update a package.
> 

It doesn't need to be actual CVS / build branches, it could be done the 
way this-other-EL5-distribution does it.

It does mean keeping EPEL 5.1 RPM files around.

It may mean a maintainer can but doesn't need to update 
non-current-point-releases.

Like I said, it's just a thought. Something to ponder, if you will. This 
is how I anticipated EPEL would work back in Boston, February 2007. It 
has been disappointing to see that it doesn't, but who am I to say that 
not having been involved with setting it up and contributing to it's 
infrastructure.

Miguel Filho wrote:
 > That is exactly my point on another mail I sent to this list. A
 > repository that don't follow the RHEL release is just a no go to me.
 >

+1.

If there's anything that needs to happen to make it so, let me know and 
I'll know what I can do (and I'd like to think some others will have 
that too).

Kind regards,

Jeroen van Meeuwen
-kanarip