I believe in tool because I'm not determinist :")

Stef
On Vendredi, nov 7, 2003, at 05:18 Europe/Zurich, Doug Way wrote:

>
> On Thursday, November 6, 2003, at 02:17 PM, Brent Vukmer wrote:
>
>> Thanks, Scott!  Wow.  Who knew?  I didn't :)  But then, I'm ignorant
>> about *tons* of cool stuff already built into the image.
>>
>> I have a feeling that we ought to always run those five checks as part
>> of the "mail to list" ChangeSorter option.  Also might be good to
>> incorporate in the BFAV and in Doug's UpdateTool. Hmm.....
>
> Yeah, somehow I didn't know about these checks either. :)  Well 
> actually, I've used "check for slips" before, but that's it.
>
> I've been thinking about creating a changeset "validator" tool to 
> handle this sort of thing.  Having it happen as part of the "mail to 
> list" makes the most sense to me.  It could do a bunch of checks and 
> only allow a changeset to be posted (for possible inclusion) if:
>
> - it includes a preamble
> - any new classes include a class comment (like Scott's check)
> - all methods have author initials timestamps
> - methods contain no linefeeds
> - the changeset name doesn't start with a number, and that it ends 
> with a dash + initials
> - the changeset name is less than 28 characters (well, maybe.  We've 
> been requiring this to fully support Mac OS 9, which may not really be 
> necessary)
> - maybe a few other checks, eventually maybe we could also check for 
> egregious SLint violations
>
> 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.)  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.
>
> 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.
>
> 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.
>
> And then yeah, we could also run the validator when incorporating, 
> although if it's always done when people post to the list, it should 
> very rarely fail. :)
>
> - Doug
>
>
>> Cheers,
>> Brent
>>
>> P.S. Documentation folks, this would be a good thing to put on the 
>> wiki.
>>
>> -----Original Message-----
>> From: Scott Wallace [mailto:scott.wallace at squeakland.org]
>> Sent: Thursday, November 06, 2003 2:01 PM
>> To: The general-purpose Squeak developerslist
>> Subject: Re: Harvesting classes without class comments?!
>>
>>
>> Most squeakers are probably familiar with the simple 
>> change-set-checking
>> tools that have been available via the "Dual Change Sorter" for years,
>> but for those who are not...
>>
>> When preparing a change-set for publication, and also when vetting
>> someone else's change-set for harvesting, you can point a
>> DualChangeSorter at the change-set, and then bring up (and *keep up*
>> with the push-pin) the "more..." branch of the change-set-list menu:
>>
>> The five "check for" items allow you to explore potential deficiencies
>> in the change-set; they detect "slips" (e.g. halts and Transcript
>> references,) messages that have no senders, uncommented methods,
>> uncommented classes, and uncategorized methods.
>>
>> If it were agreed that no change-set would be considered a candidate 
>> for
>> harvesting until it had passed all these checks, it would help.
>>
>>
>
>