On Fri, May 29, 1998 at 04:37:10PM +0800, Lindsay Allen wrote:
> In my case, I have the interest, but not the knowledge, to do a good job.
> To be able to say "this package has no bugs" will require someone who
> knows in depth not only exactly how the package is supposed to work, but
> also to know how it fits in with a myriad other packages and with the
> kernel itself. Well, that rubs me out.
TO be able to say "this package has no bugs" simply requires someone who
is very arrogent, either about their skill as a programmer (if they wrote it
...as a nice quote I read once "All programmers are very humble...in private
anyway") or it someone arrogent of their testing ability.
Always remember "Lubarsky's Law of Cybernetic Entomology" :
"There is always one more bug"
The point is to try to find the most obvious and critical bugs...
it seems to me (note I am not part of the testing team) that it is more
a matter of just installing the package...seeing that it does what
it claims to do, testing all of its documented features (r as many as is
possible) to make sure they work as documented)
Basically it means installing packages you don't really need and pretending
that you do need them...and need to use a bunch of features
You can't expect to find every bug. (there are very very few programs
I would be surprized to hear of a bug in..."cat" is the only one
that immediately comes to mind... but it is waht? 20 lines
of C source code..and has been "tested" regularly by millions
unix/linux users for the past what? 30 years?)
> As an example of the problem, I read today on Brandon's web page, that
> sysvinit_2.75-1 was tested and passed. But I also read on the list where
> there is a problem with the database (wtmp?) which shows up with "last."
> So here we have a tested package which turns out to be flawed. And please
> note that I am not pointing the finger here - I missed that problem too.
A perfect example... "There is always one more bug".
> So assuming that I am correct, where do we go from here?
>
> As I see it, we already have thousands of "testers" out there who install
> and use the packages as they become available. Many of them submit bug
> reports (we have 22000+ bugs so far) and this army has far more punch than
> any testing team can hope for.
We just hafta squash them "one Bug at a time". We can never hope to be
"Bug Free"...I would conservativly estimate that if we have 22000 bug reports
then there are probably 220000 bugs in the system.
Just on my own package xfstt, as my first act as new maintainer I incorperated
a new version of the upstream source. At that time there were no debian bugs
reported against it (excpet one "Wishlist" saying it should start on startup
rather than have to be manually started) yet the changelog from the upstream
source lists at least 5 bug fixes.
(this doesn't even mention a possible bug that I am plannin gto look
into to see whether it is a bug worth reporting...or simply a limitation
inherrint in Truetype Fonts)
> So my view is that the testing team abandons actual testing and takes on a
> book-keeper role. It would keep a database of when packages were
> released. It would monitor the lists for reports of problems and it would
> monitor the bug system. After a "quiet" period of, say, two weeks, with
> no important bugs outstanding, a package would be "cleared." We could
> even go to the point of making clearance automatic unless the package was
> specifically knocked back.
I do like this idea...I think it has potential...but...
since this means monitoring the bug traking system...this could be
done almost automatically (or with very little human intervention)
and thus there is no need to have the testing team stop testing...
rather let them continue testing and filing bug reports
> This would reduce the team's task to one that can be handled by the
> resources available.
>
> Comments?
Yes...as I said I do like your idea...in fact someone else recently
suggested something similar (they went into more detail even suggesting
getting rid of (for the most part) versiond releaces and just having such a
clearence period where a pakcgae automaticlaly goes through unstable to stable
on its own, independant of other packages
and saving versiond releaces for major system overhauls (like libc5->glibc
etc)
Personally I have thought of ofering to join the testing team...but
right now I don't feel I can make a commitment like that. I have
little real free time to work on things anyway..and this weekend my
gilrfriend is moving to boston so we can be together...so I anticipate
to some extent even less free time ..at least for a little while
Once things in my life settle downa bit..and I have one or two systems
up and running on my personal network to "play with" (more of throwaway
machines I don't mind formatting and doing the ocasional clean install on
or purposly pushging to the point of crashing a few times) I would
be glad to join the testing team.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Lindsay Allen <allen@cleo.murdoch.edu.au> Perth, Western Australia
> voice +61 8 9316 2486 32.0125S 115.8445E vk6lj Debian Unix
^^^^^^^^^^^
just a note but...[begining nitpick mode]
There is AFAIK no Debian Unix. remember...Linux is based on Unix in every
way except the actual source code. Linux is Unix-Like...
Unix is actually a trademark of SCO (I think SCO bought the rights to the
name... last I heard) The only reason other companies can put out OSs and
use th ename Unix is because they licence it (AFAIK I am not a lawyer)
[Ending nitpick mode]
In truth it doesn't really matter...its justa fun point of confusion...
I often tell people "I love Unix" and "I run unix" because it is easier
than saying "I run a Unix-like OS" and ina practical sense I do
consider Linux to be Unix
of course I could always be wrong about all this... but I did get into
a discussion about this before with a few people
Attachment:
pgp0YRy7dSi0L.pgp
Description: PGP signature