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