> 
> If any of these checks fail, it would tell you what to do to resolve 
> the problem.  The idea would be that only submissions which have 
> already passed these checks would be considered for 
> inclusion.  (Maybe the changeset, or the "mail to list" email, could
be somehow tagged 
> that it had passed the checks... hm.)  

Yep!  Sounds *great*, Doug.

> I'm not sure we'd want 
> to force these checks on people merely filing out changesets, though.
People 
> should still be allowed to throw any old code up to the 
> mailing list if 
> they don't care about inclusion in the base release.

Definitely, they should be able to file out and send manually.  I just
want the "mail to list" function to apply the checks.

> 
> We should only include checks for things that we really want to 
> enforce... I don't think we want to enforce that all methods have 
> comments, for example.  Checking for "slips" might be good, except on 
> certain occasions it is reasonable to output to the transcript.

Seems best to always do the must-be-enforced checks, but only check the
not-s preferences on the stuff that's really not critical - "slips", for
example.

> 
> Also, it might be good to have the validator operate on an external 
> file (like the FileContentsBrowser and ConflictChecker do) 
> rather than an already-loaded ChangeSet object.  At least, it's
probably 
> easier to file out an in-image changeset and validate it externally
(without 
> mucking up your image), than vice versa.

Exactly!  I would love to have this available as a file service.

Looking forward to seeing the Validator ... :)

BKV