Re: Proposal for removal of mICQ package
>>>>> In article <[🔎] 20030214061134.GB20555@gwyn.tux.org>, Timothy Ball <timball@tux.org> writes:
> I'm of the firm mindset that you should have to pass some sort of
> test or get a license to write code that a) runs as root b)
> interacts w/ the kernel. By the same token it seems logical that a
> deb maintainer should at least test the pkg before it's put in
> incoming.
But is the person in question tested it, it would have
worked -- the 'xploit was clever enough to test for the presence
> Now the brokeness of the mICQ pkg could and *should* have been
> found by the maintainer *way* before this ever became an issue. It
> should have been worked out by the maintainer and the upstream
> author. The sheer fact that it has become an issue shows negligence
> of the debian maintainer.
Well, yes and no. No single person can test all code paths
in, say, emacs, or all kernel config options, or all parts of
Gnus. Test as best you can, release early, release often.
All One can really ask a maintainer is that the auses opckage is
installable, and they ran the apckage through a test
suite. Exhaustive testing is not something that can be reasonably
expected of the maintainers (or even the authors).
Unstable is an integral part of testing an QA process for
debian -- the precise user base that the micq trojan targeted.
manoj
--
Optimization hinders evolution.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: