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