I believe the worst person to perform quality assurance on code is the
person who wrote the code. It would be best to have someone else who
didn't write the code to test and make sure the application and new code
are functional because they are going to be approaching it with fresh eyes.
Matthew Hartmann
/Systems Administrator | V: 812.378.4100 x 850 | E: mhartm...@tls.net/
TLS.NET, Inc.
http://www.tls.net
On 5/16/2012 12:38 AM, Alex Huang wrote:
Contributors - people who contribute in one way or another to the project
Committers - people who have commit access to the project's repo(s)
Maintainers - volunteers from the pool of committers who have stepped
forward to shepherd a single module. This is not a position of authority - but
rather one of responsibility - to ensure coding standards are met, that
accepted patches don't break things, etc.
So going into that, this is one area where I have difference opinion on
maintainer's responsibility.
In the write-up, it says "Review, and potentially acceptance, of code changes from
the community. The maintainer is responsible for testing that new contributions work and
do not break the application, and that the code changes are of high quality."
I think the maintainer should be responsible for making sure the process from feature design, code
design, code review, to unit testing and integration testing have been followed but I find that
"testing that new contributions work" to be challenging for a maintainer. I think the
committers need to prove as part of their patch that it doesn't break things. Maintainers can go
back and say "Well, you haven't proved this or that" and can give suggestions on how to
prove it.
What do others think?
--Alex
