On Nov 7, 2003, at 1:14 PM, Brent Vukmer wrote:

>
>>
>> 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.

Cool.  Do you have any thought on whether the changeset or email should 
be specially tagged that it has passed?  Probably we shouldn't tag the 
changeset, actually.  "mail to list" could tag the email with a special 
email header like "X-Squeak-BugFix-Validated: yes" or something.  Or 
just an extra [v] in the subject line (although people might 
inadvertently add that with their own unvalidated posts).

The gsug sqfixes archive would then need to reject any posts without 
this email header. (whether posted to squeak-dev or squeak-harvest)

Or, we could not add a tag, but we could just tell everyone that they 
have to use "mail to list" if they want their changesets considered for 
inclusion.  But then that would be unenforced, people could still post 
unvalidated things by hand, and I'd still get stuck fixing all these 
little problems when incorporating, so I don't like this idea as much. 
;)

So I think I like the email header idea the most.  The only downside is 
that people informally posting things (not intended for inclusion) from 
their own email client with a [ENH] or [FIX] tag would not see them 
show up on the sqfixes page.  But I don't think that would be a great 
loss... they would still show up on the mailing list and be archived in 
the mailing list archives.

>> 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.

Right.

>> 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.

> Oops, sorry about that.  I meant to say, the "slips" check, and 
> whatever else isn't
> deemed absolutely necessary, could be a preference-based check.

Yeah.  Or, things like the "slips" check could just bring up a mild 
warning prompt, but still let you go ahead with mailing to the list.

>> 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 ... :)

Hope to start on it shortly...

- Doug