What Fedora makes sucking for me - or why I am NOT Fedora

[Les Mikesell]

Jeff Spaleta wrote:
> 
>>> If I tell you that "it works" is that enough for you?
>> If you have identical hardware, an identical set of other packages, and a
>> similar workload, yes.
> 
> How do you know if I do or do not?  Are you saying that the only
> information that would help you make a determination as to 'known
> broken' or 'is working' as YOU define those concepts is if you have
> feedback from people who are doing what you are doing with the
> hardware you are using? How much detail do you need about other
> people's machines and workloads? How in the hell do you expect to
> capture that level of detail from other people?

Those are all good questions.  I don't think fedora has a way to answer 
any of them.

> You keep missing the point. I'm going to have to ratchet up the
> bluntness factor for you.

I'm trying to make a point so I can hardly miss it.  The point is that I 
need to minimize risk on certain machines and I'm not going to run 
fedora on them until I see a way to do that.  I don't think this is a 
unique need or that it is impossible for fedora to meet.

> You are trying to rely on other people's experiences with updates to
> justify whether you should be installing the update on your systems.

Yes, there is safety in numbers - there will always be problems that 
aren't exposed until a large number of machines run something.  But as 
always, I'm talking about other machines, not necessarily other people. 
I'd provide my own experience on a test machine to others, given some 
mechanism to do that usefully.

> You haven't described how you would expect to capture that distributed
> information from other people in such a way that you can make use of
> it before you need to make the decision as to whether or not to
> install that update on your very very precious machines.

We are talking about an expectation of risk here.  The ideal scenario is 
to know that the exact package set has been installed on the exact 
hardware and is currently running the same load.  That's the sort of 
testing you'd do if you had real QA.  Lacking that, knowing that a 
sufficiently large number of other machines have installed the packages 
in question without reporting problems is a good indication.

> You are talking in generalities and what this discussion needs at this
> point is implementation specifics.

It all has to start with being able to reproduce package sets.  What 
good does it do to track stability/usability of a configuration you or 
anyone else can't duplicate, or that after the testing period, aren't 
even available?

>> It's not a matter of trust for at least couple of reasons.  One is that your
>> hardware and installed package set is probably nothing like mine.
> 
> How do you know? How do you know that anyone out there is doing
> something close enough to what you are doing to be comparable?  If you
> are looking to compare systems and workloads you have to trust people
> they are reporting the right information.

As long as there are large number of users and any easy reporting 
mechanism, the simple lack of problem reports would satisfy my 
expectation of little risk.  But by the time this is evident, the 
configurations they were running successfully can't be created again.

>> Again, it isn't personal - it has to do with the need to keep certain
>> machines running.
> 
> Stop with the generalities. Talk about YOUR needs and YOUR workloads.

That varies wildly per machine.  The largest set would be java based web 
servers, then an assortment of squid proxies, the usual infrastructure 
services like DNS, dhcp, snmp monitoring, file, web (e.g. twiki running 
under mod_perl), email, subversion, backuppc, etc., with a few things 
running under VMware and and assortment of freenx sessions strategically 
positioned to be able to manage all the locations.

>> And what needs to happen is to know that somewhere,
>> someone has installed the same package set on the same kind of hardware and
>> has it still working.
> 
> How do you expect that information to be collected? How do you expect
> that information to be served up?

I'd opt in if there were a mechanism to publish my package set, hardware 
list, and uptime to some collecting mechanism.

>>> I've used it.
>> That hardly sounds like a recommendation.
> 
> I official recommend that you do whatever it is I've already
> suggested.  Does that help?
> Does that make the idea sound better to you? Need that in writing?

No, since I think my needs aren't unique, what I am looking for is 
advice published for fedora users in general - like something on the 
fedora project page that says that regressions in updates are rare but 
still expected, and here is the procedure to recover from them.

>> That sounds like at least an admission that the stock tools and mechanisms
>> aren't good enough.
> 
> Good enough for what? I do not expect the provided tools to meet all
> of my needs all the time. As an adminstrator I am accountable for the
> integrity of my systems...

OK, but doesn't that imply that you should be able to control your 
installed package set - or share or match it up with someone else?

> not Fedora...

And you don't think it would be helpful if fedora provided a way to 
install a package set exactly as known to work elsewhere?

 > not the mirrors which are
> serving fedora packages..and not my ISP who is providing me the
> network access to reach those mirrors.  I expect there to be a need
> for local administration policy that I control...which mitigates the
> dependence on any external entity which puts the integrity of my
> systems at risk.  For updates, that means doing several things, one of
> which is caching backups locally in case I need to back out
> something..even in situations where my ISP has a problem and my
> network access goes down.

OK, if fedora users are expected to do all that, shouldn't there be 
better tools set up for it as part of the distro and step by step 
procedures published so people know what to expect?

-- 
    Les Mikesell
     lesmikesell at gmail.com