Dne Út 3. ledna 2012 22:46:41, Toshio Kuratomi napsal(a):
On Tue, Jan 03, 2012 at 09:21:31PM -0800, Michael Stahnke
wrote:
So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).
What are the plans for EPEL 4?
The way I see we have a few options:
- We stop putting new content in EPEL4 and take down the
EPEL mirror (thus really end-of-lifeing EPEL 4) 2. We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates 3. We keep allow people to add content to EPEL4 due to things like extended support 4. Some other option I haven't though about yet.
I like 1 the best, because it only helps enforce lifecycle planning.
planning is a nice thing, but ... what if you are stuck with some hardware that works with the old software only, for example?
And when I worked in big enterprise, I needed all the help I could get to be able to move systems. :)
was it big enough to create its own software support team (I do not mean helpdesk but real developers) because it was way cheaper than to adapt to vendor's lifecycles? - why do you think that Red Hat created the EUS option?
Plus it allows our maintainers to focus effort on 5/6 enhancements and fixes.
see below
Kind of a hybrid between 1) and 2) => Stop putting new content into EPEL4. Move current EPEL4 repositories to archives.fedoraproject.org. This shows that we're EOLing support for EPEL4 and also allows mirrors to opt out of carrying it but still lets people who are desperate to keep their RHEL/Centos4 boxes running a chance to benefit from the software that we built.
OTOH, I may be being selfish -- in Fedora Infrastructure we've long since moved away from RHEL4 (we're 3/4 of the way through migratin from RHEL5 to RHEL6 as well). I have a python module that's needed for running fedpkg on top of RHEL4 and if we drop EPEL4, I don't have to support that (and the python-2.3 compatibility that it entails) anymore.
and if we do not drop EPEL4, what forces you to support the module?
- I thought we are talking about volunteer project ...
I'd prefer 3 - depending on what is meant by "adding content": bugfixes? - yes, if there's someone willing to take care new packages? - no, unless someone is really desperate (then he can create his own repo, for sure, but why not to allow him to use the existing EPEL infrastructure, are we short on hardware resources?)
K.