Something that drizzle might consider is systematic, public bug
analysis. It's a little ego wrenching at first, but a bug by bug
analysis of howa bug occurred, how it didn't get caught, and how it
might have been prevented in the first place is well worth having,
particularly if it needs to more robust engineering practices.
MySQL 5.1, originally an maintain release, probably fixed an order of
magnitude more bugs than it started with, and probably also ended with
more bugs (Monty?) than it started with. The logical conclusion is that
the rate of bug introduction overwhelmed the rate of bug closure. It's
a pity that no-one took the time and effort to analyze why this was, but
that's water over the dam.
Bugs, in most cases, aren't personal failings, but weaknesses in
architecture that require a greater understanding that is humanly
possible. Spending some time thinking about the nature of bugs found
would probably be instructive for all involved.
To salve the precious egos of those involved, it should be universally
recognized that he or she who writes the most code is likely to
introduce (or expose!) the most bugs.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
