"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
> 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.


Thank you for clarifiying and asking further questions!

At the moment I think we just should try to begin to use this process.
People have to get used to this way of working.
In a sense it is like reversing the situation. Before people sent in
fixes with the assumption that somebody other takes care of them.
Now all of us are faced with the situation that fixes are coming in and
we have to process them. The task of the (original) harvesters is
reduced
to survey this process, help and at the end take the result and put
it into the update stream. With this we hope to be able to process
a larger amount of fixes in the weeks to come.

As we go along we may update the FAQ and processing instructions.

-- Hannes