2012/1/4 Karel Volnę <kvolny@redhat.com>
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:
> >
> > 1.  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?

Well the hardware that won't run something newer is probably approaching 10 years old at this point.  It's probably time for an upgrade, or virtualization.

> > 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?
Yes it was large enough, but that wasn't a good option.  Moving on a planned schedule, though difficult is often the cheapest and best solution. 
- why do you think that Red Hat created the EUS option?
Because people can't write software that doesn't break API/ABI, and to penalize them for that, Red Hat can charge more? :)  We had 4,000 RHEL systems and never bought that once.
 

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

When you put something into EPEL, you are more-or-less agreeing to attempt to support it throughout the life of the operating systems EPEL is tracking.  If we stop tracking EPEL4, people who have been trying to keep compatibility with E4, and back port fixes, etc will get a significant amount of time (in some cases) back.   

- I thought we are talking about volunteer project ...

It is.  It's also primarily in use by business customers this is why planning and communication is key.

 
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.

--
Karel Volnę
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol@jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list