[CentOS-devel] Shipping an EPEL release

Thu Sep 13 23:04:00 UTC 2012
Manuel Wolfshant <wolfy at nobugconsulting.ro>

On 09/14/2012 01:36 AM, John R. Dennison wrote:
> On Fri, Sep 14, 2012 at 12:53:11AM +0300, Manuel Wolfshant wrote:
>> Right. Only that you KNEW what to google for. Incidentally you also took
>> for granted that the package name is "epel-release".
> Google for "epel on centos" or "hwo to use epel with centos" or anything
> else and you will get the same results.
Or not. Google results are tailored based on your previous searches. A 
friend of mine I used to work for was very excited to see his company 
listed as second in google's results on his specific queries performed 
from his office workstation. Guess what? It was not even on the second 
page when his sister performed the same search from her home computer.

>> If only that was true...
> And that's centos' problem... how?  Again, re-thinking of career paths
> comes to mind.
It's not. But helping them does not hurt anyone and increases those 
users' satisfaction level.

> I'm not trying to single you out here, Manuel, even though it probably
> seems like it from the thread, and my apologies if you think I am.
There is no need for apologies. We are just professionals debating a 
technical thing and that's all.
Not to mention that I also play a bit of the devil's advocate role. I 
help when I can/want in and out the official support channels. I am not 
a fan of spoon feeding but I do it from time to time if I find it 
useful. In this particular case my perception is that lowering the 
barrier will help users. Even the fact that the issue was raised at 
LinuxCon proves that there exists a need. And the sad truth is that no 
matter what WE as professionals want, users do what they want. And most 
of the time they want to do as little as possible. Quality is a nice 
thing to have. However people would rather pay for convenience instead.

> I just don't see any merit to this idea whatsoever; it's an idiotic one
> from the get-go.  Either people are able to cope with a real OS or they
> are not.
I know quite a few people who see the computer as a tool and nothing 
else. They need this specific tool to solve a problem and they are not 
willing to invest their time into learning more than a minimal needed to 
have things going. I know that in an ideal world all those should read 
the fine manuals but if you are a physicist interested in just having a 
local $whatever server which will help you and your colleagues to share 
data you will not spend more than the bare minimum of your time into 
setting it up. And the lower this barrier, the better for those people. 
You and me are professionals and dedicate most of our time to computers. 
Those who would benefit from the lower barrier are not. They will not 
use kickstarts because they do not have the infra for that. They would 
not use puppet. They would not use spacewalk ( what the hack, I do not 
use spacewalk ! ). They would just boot from an install disk, click 
click , Once done they just use putty to connect to it and they want to 
add whatever they are missing without spending time in bing ( yes, bing 
might very well be their default search engine and you know very well 
why ). THOSE are the people who need a lower entry barrier.

>    Catering to those that aren't is just going to increase
> support burdens on people on the lists and irc channels for little, if
> any, positive outcome.
Based on what I've seen on IRC during the last months I think the 
opposite is true.

> Adding a repo is not rocket science.  If there are issues then fix the
> centos wiki.  But from my last read of that page it should be pretty
> straight-forward if people read and follow links where needed.
Try to imagine that you read that after it has been translated by google 
from a language you do not understand. CentOS is quite used by people 
who do not grasp English well enough. Sometimes (by choice or not..) 
even by people who have limited computer knowledge. Lowering the barrier 
helps them with no impact on those with proper knowledge.