Linux community software-update-anarchy polemic (Re:)
From: Anonymous Coward (acoward_at_mail.ru)
Date: 03/12/04
- Next message: Anonymous Coward: "Hardware reliability (was: Re: Linux community software-update-anarchy polemic)"
- Previous message: Gary J Smither: "Problem with Dual Boot Win98 and Linux 6.x"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 12 Mar 2004 05:14:52 -0800
"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote
>>Defining "stable", or "release", or whatever, as meaning
>>zero-known-bugs,
>
>You're evading the question. How does Knoppix define updates?
I don't know, but "any change at all" would I suppose be a reasonable
definition. However I've become confused about how your question
applies to this subthread.
>>Then define it as unstable when you ship it.
>
>For what purpose? That would convey no useful information, and
destroy
>the utility of the word in describing stable builds versus
development
>builds.
>
>>Defining it by fiat as stable doesn't make it stable.
>
>Please look up the word "stable" in a dictionary. Debian stable *is*
>stable; it remains unchanged for an extended period. That is not a
>promise of how reliable it is.
>
>>If you want to argue "but despite a few bugs it really is very
>>stable" then you just want stability to mean something other than
>>zero-known-bugs.
>
>The dictionary publishers also seem to believe that it means
something
>other than zero-known-bugs.
The word "stable" as I'm using it here applies to a particular version
of a program, and means "not buggy". The word "stable" as you're using
it (and as Debian uses it too) applies to a program in general, not to
a particular version, and means "new versions are released seldom". I
acknowledge that your definition is valid, but mine is valid too; it
is very common to refer to a version of a program which crashes all
the time as "unstable", and a version of a program which never crashes
as "stable as a rock". Because of the different, and incompatible,
definitions, I attempted to solve the problem for the sake of this
thread by referring to the number of known bugs rather than
"stability", since the concept referred to by your definition of
"stable" is not what I'm referring to. How the word is defined doesn't
impact the point I was making, which was that the present methods of
distributing knowledge of bugs is not satisfactory and should be
improved, e.g. in general there's no automatic way to get a list of
all presently known bugs for a particular arbitrary version of a
program.
>>That's fine; just introduce the term ZKB.
>
>It's not useful for any large program.
It IS useful, at least according to the man pages for many programs,
which report no bugs in the "Bugs" section, meaning that at the time
of release either there were no known bugs, or the author was lying.
>>You're talking about a process (the production of new releases of
>>software); I'm talking about products (the releases themselves).
>
>The stable release themselves come at long intervals; that's why
>they're called stable.
See my explanation above.
>>The question is whether the label "stable" is immutable even in
>>light of future revelation of bugs.
>
>Yes, in the English language.
According to my definition of "stable" as low-known-bug-count rather
than long-version-release-interval (which I'd already made clear prior
to this message), my question here is relevant to the discussion, and
your answer is an answer to a different question, not to my question.
>>Because the Debian people have no automated way to tell, for any
>>given program, whether the tests which they will run have already
>>been run.
>
>Were there an automated way to tell, it wouldn't change anything,
>because the tests would have been run in a different environment.
>They'd still have to run the tests themselves.
Two tests run in different environments are different tests, not the
same test. The environment itself is a parameter to the test. And
anticipating a possible objection that "then your point is moot,
because the Debian people would of course be testing in a different
environment from other testers who had already run the 'same' test",
note that the logical conclusion of such an objection means that even
the Debian people's testing is pointless, because their tests are run
in a different environment from end users' environments, because no
two environments are completely identical; obviously, for the sake of
testing, limits have to be placed on how much of the environment the
test is parameterized over. And for properly defined limits, at least
some tests results can be reusable, reducing redundancy in testing.
>>ell me exactly what it is that you think I'm asking for,
>
>A list of all known bugs.
And you said that this is not obtainable. Of course it's obtainable;
for any particular program which has a bug tracking database, and the
database is actually used properly (all bug reports get entered into
the database, then marked, as the developers have time to do so, as
"not a bug", "verified but not yet fixed", "fixed in (new) version x",
etc), the database holds a list of all bugs known to the developers.
My complaint is that in general among open source programs, there's no
standardized way to obtain this information, hence there's no way to
make a general program "find-bugs" which will recursively check a
version of a program and all its dependencies and report a (possibly
empty) list of all bugs known to the program's developers or the
program's dependencies' developers.
Even if this problem were to be solved, my secondary complaint is that
independent testing bodies in general don't report their test suites
or the results of their tests (including bugs discovered) to the
developers but instead maintain their own databases.
>>No change of user behavior is necessary to accomplish what I'm
>>talking about, just a change of programmer behavior.
>
>How does the programmer correct a bug that has not shown up in his
>testing and that nobody has bothered to report?
He doesn't. I'm not defining such a bug as "known". I'm including only
those which have shown up in his own testing, or have been reported to
him. In general, yes, all bugs as known bugs, some to individuals who
never report them, and all at least to God, but that's not relevant
here.
BTW I apologize for the unreasonably long delay of my reply, so of
course it would be reasonable if you choose to consider this thread
already dead. Google groups, my usenet client (don't laugh) won't even
let me post an official follow-up to your message, due to age, so this
message is officially a new post and will have to join the thread only
by subject and by body content rather than by the references header.
And google just told me "Subject must not start with "Re:" unless it
is a followup." So no "Re:" prefix. Grrr. So I put it at the end just
to spite google.
- Next message: Anonymous Coward: "Hardware reliability (was: Re: Linux community software-update-anarchy polemic)"
- Previous message: Gary J Smither: "Problem with Dual Boot Win98 and Linux 6.x"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
