RE: Harvester status for Marcus Denker

Hi all!

"Brent Vukmer" <[email protected]> wrote:
> > > Well, it would be interesting to write down the policy 
> > somewhere - at 
> > > least the non obvious and the mandatory stuff. I am not 
> > saying "Swiki" 
> > > because I am a bit tired of simply creating more and more 
> > pages on the 
> > > Swikis, but if no other smarter way is found then sure, why not.
> > What's wrong with the Swiki?
> > 
> > Daniel
> 
> I think the main issue with the Swiki is that there is not yet a tool
> that allows us to easily and quickly edit the Swiki from within Squeak.

Yes, and also - creating yet another swiki page feels... Well, you know.
:-)

It is just a gutfeeling I have. People discuss a problem and eventually
it tends to boil down to "lets create a swiki page for that", and
somehow people think it will solve things (unconsciously).

Note that I am overly negative because we have this phenomenon in our
company. Sure, we love the Swiki - but too often "creating a swiki page
for that" turns out to be the final thing that got done before the issue
went to sleep... This is why my "gut" tells me "Oh no, not another swiki
page...". :-)

So for example, if Brent had responded and said "Hey, I can add those
policy rules right inside the BugFixArchiveViewer! Easily accessible!"
then I would have been more interested! ;-)

regards, Göran
From [email protected] Tue Jun 10 17:33:20 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 18090 invoked from network); 10 Jun 2003 17:33:19 -0000
Received: from unknown (HELO lucy.riskmetrics.com) (12.3.62.14)
  by mail.theinternetone.net with SMTP; 10 Jun 2003 17:33:19 -0000
Received: from riskmetrics.com (w018.z064003232.det-mi.dsl.cnc.net
	[64.3.232.18]) by lucy.riskmetrics.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2653.13)
	id MGRFAJ28; Tue, 10 Jun 2003 13:32:06 -0400
Message-ID: <[email protected]>
Date: Tue, 10 Jun 2003 13:31:39 -0400
From: Doug Way <[email protected]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.3.1) Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Discussing the Squeak Foundation
	<[email protected]>
References: <[email protected]>
In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Squeakfoundation]
 Harvesting rules (was Re: Harvester status for Marcus Denker)
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: Tue, 10 Jun 2003 17:33:20 -0000


Well, I would describe my current practice of checking some people's 
code more thoroughly than others as a temporary expediency, not a 
long-term policy. ;-)  I agree that we need some sort of policy.

I guess what we're talking about here is what it means for something to 
be externally reviewed [er].  (Hmm, one confusing thing on 
http://minnow.cc.gatech.edu/squeak/3103 is that the description for [et] 
says that [et] also implies [er] and [cd], which seems incorrect to me.)

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


Daniel Vainsencher wrote:

>[what is important to review]
>I find myself surprised, not completely unpleasently, at how different
>our tendencies are on this.
>
>I say this is a little good, because it's a more complete picture of
>what we should be doing than any one of us would have. But it's mostly
>bad, because IMO, having each of us checking what we feel like stinks.
>
>A. It sends out a really confused message as to what code should be like
>(you need a class comment, except if dvf is checking it, in which case
>just make sure you're not adding anything to Object! ;-)
>B. It's not a way to improve the quality of the code. Let's face it, if
>three of the harvesters don't have the same standards, why the heck
>should we assume that Ted does have (and if does, who's does he have?
>Mine? Doug's?)
>
>We need a policy. It doesn't have to be complicated, but it needs to
>keep the image clean, systematically, not by chance. We need to balance
>this with keeping things fun, sure, so we'll have to be smart about it,
>but we need to deal with this. If we are warm and fluffy on this one, we
>can stop the cleanup projects right now, because quality will go down,
>not up, no matter how hard they work.
>
>If we agree on this, here are some things I think we could do -
>* Find a good online reference for writing good Smalltalk code, ideally,
>something like Kents "Best Smalltalk practices". 
>* All of us read it, read all code before approving stuff, and point
>people at the manual when said stuff stinks.
>* Require use of SLint. It's easy to install, there's a "SmallLint
>Tutorial" on SM.
>* Maybe make class comments mandatory, and implement some automated
>check for this, so I don't forget it.
>
>What do you think?
>Other ideas?
>
>Daniel
>
>  
>