RE: Harvesting rules (was Re: Harvester status for Marcus Denker)

> 
> Anyway, a good start on getting a policy going might be to create a 
> standalone tool which operates on a changeset, which would check for 
> things like class comments being in place for newly defined 
> classes.  It 
> could also run some subset of SLint tests (whichever rules we 
> agree on), 
> so SLint would be a prerequisite of the tool.  (One issue I ran into 
> with SLint is that it would be nice if it could just be run on the 
> changed code, not the entire method.  That might not be simple to 
> implement, I realize.)
> 
> Plus the tool could have a few simple checks to make my life as the 
> update-stream manager easier, such as making sure the changeset name 
> isn't too long, doesn't have funny characters in it, etc.  (Simply 
> forcing it to be a changeset is even of some value... for example I'm 
> about to incorporate Michael's network rewrite, but that's a 
> SAR file, 
> so I have to incorporate the 10 or so changesets/fileins separately, 
> some of which could probably be combined, etc.  Not a huge 
> problem but 
> still it's a bit of extra work for me.)
> 
> Then the idea would be that any submission must pass through the tool 
> before it is [approved].  The harvesters could use the tool at first, 
> but eventually people submitting things would want to run submissions 
> through the tool themselves.
> 

Doug, it's like you're reading my mind.   The one thing I would add to
your list, is that this tool should register with the FileList.

If this tool existed, and registered with the FileList, it would
automagically be available in the BugFixArchiveViewer.
From [email protected] Wed Jun 11 13:28:10 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 21990 invoked from network); 11 Jun 2003 13:28:09 -0000
Received: from mxout4.netvision.net.il (194.90.9.27)
  by mail.theinternetone.net with SMTP; 11 Jun 2003 13:28:09 -0000
Received: from aSqueakSystem ([80.178.108.51]) by mxout4.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with SMTPA id <[email protected]> for
 [email protected]; Wed,
 11 Jun 2003 15:38:56 +0300 (IDT)
Date: Wed, 11 Jun 2003 15:39:40 +0200
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation] Harvesting review policies (and a lil' love
 from the BFAV)
To: Discussing the Squeak Foundation
 <[email protected]>
Cc: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5174
Content-transfer-encoding: 7BIT
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.squeakfoundation.org/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Wed, 11 Jun 2003 13:28:10 -0000

Brent Vukmer <[email protected]> wrote:
> I immediately think of integrating SLint services into the
> BugFixArchiveViewer, which seems like it would provide the biggest
> immediate gain...  Do you guys agree? 
That sounds definitely worth doing.

> Can SLint be run on a changeset file?  
Unfortunately not. I've looked at the code a little, but it passes
around class names, that are then looked up in Smalltalk, making it
difficult to replace. What we could do is run it on the changed code
after installing the changeset. This will also require a little
integration - something that creates a SelectorEnvironment from the cs
and then runs a SmalllintChecker on them.

> Daniel, would it be easy for you to make SLint a separate package?  I
> *could* create a dependency on the Refactoring Browser .. But that seems
> a bit heavyweight to me.

As you see above, packaging is not our biggest problem. I'll see about
doing the above, and then we'll think more.

Daniel
From [email protected] Wed Jun 11 20:30:03 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 9213 invoked from network); 11 Jun 2003 20:30:03 -0000
Received: from mailhub01.unibe.ch (130.92.9.52)
  by mail.theinternetone.net with SMTP; 11 Jun 2003 20:30:03 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailhub01.unibe.ch (Postfix) with ESMTP id 67E7C25BACD
	for <[email protected]>;
	Wed, 11 Jun 2003 22:30:03 +0200 (MEST)
Received: from mailhub01.unibe.ch ([127.0.0.1])
 by localhost (mailhub01 [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 24107-01-100 for <[email protected]>;
 Wed, 11 Jun 2003 22:30:02 +0200 (MEST)
Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4])
	by mailhub01.unibe.ch (Postfix) with ESMTP id 7E49225BAD4
	for <[email protected]>;
	Wed, 11 Jun 2003 22:30:02 +0200 (MEST)
Received: from iam.unibe.ch (asterix [130.92.64.4])
	by asterix.unibe.ch (8.11.6+Sun/8.11.6) with ESMTP id h5BKU1K16370
	for <[email protected]>;
	Wed, 11 Jun 2003 22:30:01 +0200 (MET DST)
Date: Wed, 11 Jun 2003 22:30:01 +0200
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Stephane Ducasse <[email protected]>
To: Discussing Foundation <[email protected]>
Content-Transfer-Encoding: 7bit
Message-Id: <[email protected]>
X-Mailer: Apple Mail (2.552)
X-Virus-checked: by University of Berne
Subject: [Squeakfoundation]Just let me know if I lose my time and yours
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.squeakfoundation.org/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Wed, 11 Jun 2003 20:30:04 -0000

Hi guides and others

I can tell you that the last email of Andreas makes me think a lot.

I'm a respectable researcher, I have a lot of cool ideas and write a 
lot of smart
papers, I have lot of fun programming in Smalltalk, organizing ESUG, I 
have kids,
and a nice social life.

But I do not need KCP, really I do not need it. I do it because I feel 
it important.
Now if you think that I'm over cleaning, over refactoring, if you think 
that I'm
creating too much classes and that Squeak should stay the way it is, 
please let
me now immediately because I ***really*** have something else to do for 
my evenings.
I have enough to do. Really!

You may think that I'm over exaggerating, in such a case consider that 
this over
exaggeration is the clear sign that I have something else to do.

Stef





From: Stephane Ducasse <[email protected]>
Date: Wed Jun 11, 2003  10:14:15 PM Europe/Zurich
To: The general-purpose Squeak developers list 
<[email protected]>
Cc: Roel Wuyts <[email protected]>, Alexandre Bergel 
<[email protected]>
Subject: Re: [KCP] SystemDictionary cleaning: Comments and design

Come one andreas

	Image abandoneSources

Does not tell you something?

Please tell me that I'm wrong and stupid to lose my time cleaning 
Squeak and I stop.
Seriously. No joke. I have something else that hearing that.


Stef

On Wednesday, June 11, 2003, at 09:18 PM, Andreas Raab wrote:

> Stef,
>
>>>  Look for instance at Utilities class comment. It
>>> says: 'methods that don't naturally attach to anything else'. These
>>> methods are functions and you won't create instances of the new
>>> classes, they are just more or less function-holders. There is no
>>> complicated interdependency of classes and methods to understand. It
>>> is only a question of 'listing' these functions.
>>
>> If this is what **you** believe...
>
> And me too. If there is a recognizable concept for a number of methods 
> which
> make sense to think about them as "attached to" a common class (system
> navigation for example) then I'm all for it. But in many other cases we
> merely have utility functions and forcing "arbitrary concepts" will 
> only
> make things more complex - mostly you will start moving around the 
> methods
> for the mere purpose of putting them NOT into a specific place which 
> means
> you'll have much more confusion in the long term.
>
> For example, consider a method like #abandonSources. I don't see any 
> easy
> place where this method should live and if you would forcefully "clean 
> up"
> SystemDictionary then all you know is that you do NOT want it there - 
> but
> you've got no good concept yet where to stick it otherwise. Let's 
> consider
> someone says "let's put this into FileDirectory" because it does 
> something
> with files. Now, any code has to be rewritten against file directory. 
> Except
> that at some later point someone might say "oh, it really belongs into
> FileStream" and then any code has to be rewritten against that place. 
> And so
> on. In the long-term, there are always going to be some utility methods
> which cannot be cleanly attached to some class or other and then it's 
> really
> more about "listing" them.
>
> The bottom line of this is really: a) Think *very* carefully about the
> classes (concepts) you want to introduce for utility methods. b) 
> Provide a
> (couple of) generic places where utility methods can live. Right now 
> we have
> two such places - SystemDictionary which holds most of the "environment
> related" utility methods and Utilities which holds most of the rest.
> Introducing a hundred new classes all of which have one or two methods 
> just
> so that they are NOT in some place isn't very good design either. IMO 
> at
> least.
>
> Cheers,
>   - Andreas