[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
With Microsoft, failure is not an option.  It is a standard feature.

Reply to: