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