'Christian Schwarz wrote:'
>
>If you want to add something to our policy manual, someone has to try to
>formulate the idea, so we can simple discuss it. We need something more
>"general" for our manual, as for example:
>
>``It is not allowed that two packages install programs with different
>functionality but with the same filenames. (The case of two programs
>having the same functionality but different implementations is handled via
>`alternatives.') If this case happens, one of the programs has to be
>renamed. The maintainers should report this to the developers' mailing
>list where it will be dicussed. The VP of Engineering will make a final
>decision which program has to be renamed.''
Kill the last sentence replacing it with: "If consensus can not be
reached, the two packages will have to conflict with each other."
I'm appalled by the word "VP" occuring anywhere in the the policy
manual. Someone else recently said that we should make our decisions
based on technical reasons. I concur. I'm disappointed to see so many
compromises on quality lately (right after our long thread on QA).
Engineering excellence requires an uncompromising approach to
problems: complete solutions must be sought (solutions that satisfy
all parties). And consensus is the best way to accomplish said
excellence (I cite the Internet STD documents and Linux kernel
development as proof). Is my fear being realized: that the existence
of a quality control manager will decrease quality because one can
lobby the QA manager to get a hack "approved"?
We all need to be QA managers. We all need to be Distribution
managers.
PS. Dale, can you make sure the Board emphasizes the importance of
consensus in this constitution they are working on.
--
Christopher J. Fearnley | Linux/Internet Consulting
cjf@netaxs.com, cjf@onit.net | UNIX SIG Leader at PACS
http://www.netaxs.com/~cjf | (Philadelphia Area Computer Society)
ftp://ftp.netaxs.com/people/cjf | Design Science Revolutionary
"Dare to be Naive" -- Bucky Fuller | Explorer in Universe