Process, harvesting, getting your favorite things in the image
Richard A. O'Keefe
ok at cs.otago.ac.nz
Tue Mar 11 00:53:13 UTC 2003
Let me define some categories for these tags:
A a tag that the author SHOULD provide
a a tag that the author COULD provide
r a tag that only an external reviewer could provide.
Hannes Hirzel <hannes.hirzel.squeaklist at bluewin.ch> wrote:
[sm] Small. (Changesets should be under 10k.)
A In fact, what is the point of this at all? This is precisely the
kind of "QA" measurement the computer can do best.
a [cd] Changes documented (Reasoning is given that explains every
change made)
This would be an A except that the author might be wrong.
A [sl] SLint approved (You don't have to do what SLint says(sometimes
it's wrong), but have a good reason why you didn't)
Presumably the author and reviewr might disagree about what's a good
(enough) reason.
Sigh. I guess I'll have to learn about SLint.
r [er] Externally reviewed (Design + code, by someone other than the
author, quite knowledgeable about the package)
Although note that the author *could* very well say at the time of
submission that someone else has reviewed it.
A [et] Externally tested (Import into a fresh image; generally making
sure it doesn't break anything that uses it; run relevant existing SUnit
tests. (Implies [er] and[cd])).
It's not clear what "external" means here. As described, there is no
reason why it can't all be done by the author. It is far from clear
why it is said to imply cd. Does does "tested" imply "documented"?
If "external" means "by some other person", once again, there is no
reason why the author could not assert that something had been tested
by a third part _before_ submission.
A [su] Covered by and passes SUnit tests, either included or external.
Included tests should be described, and external tests should be pointed
to.
I was assured that these annotations were reviewer annotations.
Not so, NONE of them are such that they could never be meaningfully
asserted by the original submitter, and most of them are such that
they should normally be assertable by the original submitter.
I am not saying that these are bad quality assurance attributes,
far from it.
More information about the Squeak-dev
mailing list
|