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

[Les Mikesell]

Jeff Spaleta wrote:
> On Thu, Dec 11, 2008 at 12:12 PM, Les Mikesell <lesmikesell at 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
>>> system
>>> .... 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 at gmail.com