Plans for EL4 End of Life

[Michael Stahnke]

2012/1/4 Karel Volný <kvolny at 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 at jabber.cz
> :: "Never attribute to malice what can
> ::  easily be explained by stupidity."
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20120104/e0471370/attachment.htm>