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@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
