[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Jeff Spaleta wrote:
On Thu, Dec 11, 2008 at 12:12 PM, Les Mikesell <lesmikesell gmail com> wrote:
That wasn't a question.  I'll figure out how to test for brokenness after
you tell me how to reproduce exact tested, non-broken states. Or maybe I'll
watch the mail list for subjects like 'sucking' or "dbus disaster" before
doing any updates.

You are the one that introduced the "known broken" terminology and
have used in for like 3.2 million posts in this thread. Its your
concept. Not mine.

For my example of the late FC6 update, the machine didn't boot. I'd say that's clearly a 'known broken' state at that point. But not much more than that is clear. Why does that have to happen to more than one machine? Why does everyone it does happen to have to diagnose it further than not wanting that package set on any other machine?

2) Once you know its broken how prevent it from going on to a client
.... yum's configuration options work just fine for that.
No, I have to know a lot more than "it's broken" to do anything with a yum
configurations.  What I'd rather do is find an "it works", tested set and
duplicate that and only that.

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.

Are you willing
to trust me on that? Are you willing to trust any individual
maintainer on that?

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. Another is that a maintainer might not be running the same version he pushed to everyone else, either by design or mistake.

I'll just write an auto-fire script to send you
email every time I install an update telling you it works.  How do you
define what qualifies as working well enough for you before YOU
install it?

That depends entirely on which machine(s) you are talking about. It doesn't relate so much to me personally.

What specifically do YOU need to see happen for you to
feel an update is vetted enough for you to install?

Again, it isn't personal - it has to do with the need to keep certain machines running. 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. Either a dedicated similar test machine would work, or waiting until some large number of others had run the new package set with no problems.

And once you tell
us what those things are... are YOU going to help implement them?

I'd be relatively happy to keep a test machine up to date and make sure it runs and that the programs I care about still work. But, it doesn't make any sense to do that, knowing that no one else will be able to take advantage of that and that there is no way to duplicate the tested set of packages elsewhere. I'd have no privacy concerns about the test machines - if there were a way to export it's package set, hardware list, and the fact that it is still working to something that could accumulate these statistics, that would be fine.

3) If you found out its broken after you installed it on a client
system how do you revert to a previous update?
... you keep a local cache of previously installed updates. yum lets
you keep a local cache..per client. The caching is off by default but
it can be turned on.
Is that really the plan you expect users to follow?  Has anyone even tried
that to see if it works in the general case?

I've used it.

That hardly sounds like a recommendation.

On my systems running Fedora which I maintain to be used
and updated primarily by other people (like my wife's desktop).. I do
in fact keep a local cache of previously installed updates which I
purge based on my local administration policy judgement.  When there
is an update that breaks functionality for her I am able to manually
install the cached older version and then set an exclude. I don't have
to use it often.

That sounds like at least an admission that the stock tools and mechanisms aren't good enough.

  Les Mikesell
   lesmikesell gmail com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]