Plans for EL4 End of Life

[Toshio Kuratomi]

On Thu, Jan 05, 2012 at 01:33:31PM +0100, Karel Volný wrote:
> 
> but I just don't like the attitude
> 
> it has bitten me just a few weeks ago - why should I buy a new 
> printer when the twelve years old one is in perfect shape, it 
> provides a good quality, and the price per page ratio is the 
> lowest in its class?
> 
> I'd rather pay the price of the new printer to someone to fix the 
> driver to work with new kernel than to throw away the old one, 
> trashing the Earth with another piece of waste
> 
There's two differences that I can see:

* We're only talking about throwing away support here.  If people can still
  get the old packages on archives.fp.o, we're really just saying that we
  don't support the software anymore (with updates, handling of bug reports,
  etc).  The product is still available for those who want it.
* The product we're throwing out is software, not hardware.  So there's no
  physical waste when abandoning it.

> > > > > 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.
> 
> now you say "is often" - and what about the rest of cases (e.g. 
> my experience is different, or the managers in my previous 
> company just couldn't do the math ...)?
> 
> will supporting them negatively affect the majority? - I don't 
> think so
> 
> will supporting them cost us more than it would cost them if we 
> dropped the support? - don't know ... but as we are talking about 
> moving things to archive, i.e. eating the same disk space, just 
> under another directory, I doubt our costs would be significant 
> in comparison
> 
The true cost is in manpower for whoever has to maintain the packages,
fix bugs, update software, etc.  EPEL is based on the idea that it costs us
less to collectively package software than it does for individuals to
package the same software separately so in absolute numbers, you're probably
right that our costs are lower than theirs.

However, our manpower comes from volunteers who need to consider what
they're doing as fun whereas their manpower comes from paid employees who
need to be convinced that their employers are doing what's most beneficial
for the company.  Maintaining software that doesn't run on any machines that
I have deployed and whose core software is so old is much less fun than
maintaining software for the latest releases.  When you contrast this with
someone who is being paid to maintain a RHEL4 machine and needs the software
being packaged to run on that machine.  I think the relative cost for us
becomes much higher.

Note that there are other options here.  In Fedora, the decision was an "all
packages or no packages" approach.  A group could work on a Fedora Legacy to
extend the EOL date only if they maintained all packages for a longer
period.  In RHEL4 itself, it appears that Red Hat is going to select
a subset of packages that may receive updates.  Other packages will not
(even if the package has a security flaw).  I suppose that we could follow
that model if less than the whole set of EPEL contributors wanted to
continue on with EPEL4.  However, doing this might mean that you also had to
allocate manpower to do rel-eng tasks related to building, signing, and
pushing updates; document which packages the EPEL4 group was willing to
continue maintainance on; pick up the slack on each others packages if
someone stops contributing to EPEL4; etc.

> ...
> > > 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.
> 
> this does not answer my question
> 
> okay, you "agreed to attempt" - now what?
> 
I suppose the next question is how long did you/I/we "agree to attempt"?

I agreed to go until EOL; not to the end of extended life.  But I don't see
that canonified on the EPEL wiki and policy pages... so it must have just
been what we talked about on the mailing lists back in 2006 and 2007.

> > > - 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.
> 
> so, wouldn't it be better to communicate with these customers and 
> present some resume rather then push everyone's selfish agenda on 
> this list?
> 
Well... what I see is that we're determining if there's manpower here to
support EPEL4 past EOL.  If there isn't manpower, our message is "EPEL will
not be supporting RHEL4 after RHEL4's End of Production date, Feb 29, 2012."

If there is manpower, I suppose the message changes.

Since our users aren't paying us, figuring out what our non-contributing
user's needs are, while nice to know, is not very rewarding.  The "selfish
agenda" that you speak of is much more important to this equation -- it's
the expression of whether we feel we're being paid enough to continue to do
the work that we do in EPEL4.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20120105/12253da5/attachment.sig>