Re: testing committee email (and minor essay)
One of the reasons few people take problems to the technical committee
is that doing so does no good. Problems that are brought to the
committee result in no desision at all -- take for example the one I
brought to the committee in December.
There needs to be a limit on how much time between when an issue is
brought up and when it is ruled on. (With extantions made if there is
a vote to do so and the problem is still being discussed.)
If the ctte is still looking for new members I'm willing to serve. I
know C and perl, have debugged C++ and python, and have gotten
confused trying to debug ruby. I'm an active member of
bugs.debian.org, mainly dealing with the spam problem there. (In the
past year, the volume of spam has increased, (requiring rewrites of
code to keep up) and the amount of spam going through has decreased.)
The packages I maintain are not very popular. I've been helping with
the sparc port of d-i, mainly limited to testing in the recent past.
I've been trying to prod the sparc buildd maintainer into either doing
his job well or letting someone else help.
(My debian user name is blarson.)
--
Blars Blarson blarson@blars.org
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
Reply to: