Re: How to proceed for the kernel cleaning harvesting

Ok, now we're talking.

Send in a mail with changesets 9,7,4, and I'll approve them, I've
already seen that part. The others until 10 are either tests (which no
longer go into the image, since we'll be removing SUnit into a package),
or your internal tools, or already in the image.

When you've reviewed another bunch, let me know which. 

Daniel

Stephane Ducasse <[email protected]> wrote:
> Ok so let us know. I think that making a try  on the current changes
> could help to tighten the process and see if we can work this way.
> What I suggest is the following (depending on the availability of 
> Noury's and Roel's time there is a deadline for ESUG for the end of the 
> week)
> 
> 1. we proceed to an internal/external review as soon as possible.
> 2. we let you know.
> 3. you try to assess the changes as fast as you can and report how we 
> can improve communication.
> 4. If in the meantime you/harvesters evaluate the proposed changes 
> which are simple (the only design point is that we introduced a new 
> class for the navigation and UI related actions that the tools can 
> reuse), and accept them we just pass to the next ones.
> 
> 
> Stef
> 
> 
> 
> Prof. Dr. Stéphane DUCASSE
> http://www.iam.unibe.ch/~ducasse/
>   "if you knew today was your last day on earth, what would you do 
> different? ...  especially if,
>   by doing something different, today might not be your last day on 
> earth" Calvin&Hobbes
> 
> "The best way to predict the future is to invent it..." Alan Kay.
> 
> Open Source Smalltalks: http://www.squeak.org, 
> http://www.gnu.org/software/smalltalk/smalltalk.html
> Free books for Universities at 
> http://www.esug.org/sponsoring/promotionProgram.html
> Free Online Book at 
> http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sun Apr 06 22:16:03 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 18274 invoked from network); 6 Apr 2003 22:16:02 -0000
Received: from mxout2.netvision.net.il (194.90.9.21)
  by mail.theinternetone.net with SMTP; 6 Apr 2003 22:16:02 -0000
Received: from aSqueakSystem ([80.178.108.27]) by mxout2.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Mon,
 07 Apr 2003 01:15:18 +0300 (IDT)
Date: Sun, 06 Apr 2003 14:31:45 +0200
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation]3.6 MasterPlanner!?
To: 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://lnx-12.ams-2.theinternetone.net/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: Sun, 06 Apr 2003 22:16:04 -0000

I agree that we should make sure removal of a package doesn't break
either it or other stuff in the image.

I don't know whether there's a point in separating the refactorings from
the removal package. After all, the removal package is supposed to get
rolled into the updatestream.

The Celeste removal does the refactorings required and then removes the
package, which seemed reasonable to me at the time. If someone thinks
this is a problem, I don't mind reworking it so refactorings and
removals are separate.

Other quality criteria - we should encourage package maintainers to
never override code, but we can't enforce it. Right now, there isn't
even a warning when loading a package that overrides code. We should
provide the tool support first, start pushin the rule later.

Agree on Accufonts now, further developments later.

Daniel

Doug Way <[email protected]> wrote:
> 
> On Saturday, April 5, 2003, at 04:28 PM, Tim Rowledge wrote:
> 
> >> * Apply some number of package removals to the image.  (Perhaps you 
> >> were
> >> taking this one for granted.)  I don't think we should try to plan 
> >> exactly
> >> which ones will be removed, but we could set a rough goal of a 
> >> certain number
> >> of MB removed from the image, perhaps.
> > Before any goals relating to size, number or whatever we should
> > establish a _quality_ goal. For example, no removal package is much use
> > unless the package can subsequently be installed and actually work. 
> > This
> > relates to the problem I'm having right now with filing out a changeset
> > not being even close to filing out the classes individually. Without
> > tools that let package maintainers work sensibly we're going to be in
> > trouble pretty quick.
> 
> Yes, quality of package removals/additions should be more important 
> than making sure we reach a specific target number/size of removals.  
> The size goal for removals could be more of a prediction than a 
> must-have goal.
> 
> As far as quality criteria for package removals go, we'd have the usual 
> harvesting criteria as a minimum (externally tested, etc.), which 
> should hopefully cover things like the package addition being 
> installable and generally working.
> 
> One other quality criteria for package removals/additions that I was 
> wondering about:  Should we have a strict rule that package removals 
> can only remove classes and (class-extension) methods, they cannot 
> overwrite any methods?  Conversely, package additions could only add 
> classes and (class-extension) methods, no method overwrites.  This 
> would of course often require that some refactoring be done in 
> preparation for the removal, so that registering menus were used, etc.  
> (And we already have a plan that refactorings should be done prior to 
> removal, anyway.)  However, having this as a general rule might be 
> unrealistically strict. (?)
> 
> >> * Remove the Apple fonts from the image, and replace them with 
> >> functionally
> >> similar bitmap fonts.  We would still need to decide whether this 
> >> meant the
> >> Accufonts, or a move to ISO-8859-1.
> > Simplest first I'd say. Just get the Apple fonts out and _something_ 
> > in.
> > Accufonts seem reasonable to me. One could consider use of TTFs since
> > there are quite a lot of reasonable TTF free fonts around. That would
> > involve some decision on $_ etc. :-(
> 
> I agree that Accufonts seem reasonable.  We'd have to agree that the 
> license was acceptable and Squeak compatible (which I think it is, 
> IMO).  Even after adding the Accufonts, we could have a move toward 
> supporting ISO-8859-1, as soon as someone did the required work.
> 
> >>> * Restart harvesting using the new process, hopefully removing some
> >>> backlog.
> > Some explicable process and cleaning up of swiki pages would help here.
> > I tried a week or two ago and got lost in a forest of oldlinks and
> > irelevant pages. And at the end I still didn't understand where to send
> > code I wanted reviewed or to approve.
> > ...
> 
> Yes, I've been meaning to clean these pages up and have a good summary 
> of the process... I will try to get to this ASAP.
> 
> - Doug
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Mon Apr 07 06:17:37 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 17506 invoked from network); 7 Apr 2003 06:17:36 -0000
Received: from mailhost1-sfldmi.sfldmi.ameritech.net (HELO
	mailhost.det2.ameritech.net) (206.141.193.105)
	by mail.theinternetone.net with SMTP; 7 Apr 2003 06:17:36 -0000
Received: from riskmetrics.com ([66.72.184.202])
	by mailhost.det2.ameritech.net
	(InterMail vM.4.01.02.17 201-229-119) with ESMTP
	<20030407061730.GSDH8853.mailhost.det2.ameritech.net@riskmetrics.com>
	for <[email protected]>;
	Mon, 7 Apr 2003 02:17:30 -0400
Date: Mon, 7 Apr 2003 02:17:30 -0400
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
From: Doug Way <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
X-Mailer: Apple Mail (2.551)
Subject: [Squeakfoundation]Current Harvesting Process
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://lnx-12.ams-2.theinternetone.net/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: Mon, 07 Apr 2003 06:17:37 -0000


On Saturday, April 5, 2003, at 04:28 PM, Tim Rowledge wrote:

>>> * Restart harvesting using the new process, hopefully removing some
>>> backlog.
> Some explicable process and cleaning up of swiki pages would help here.
> I tried a week or two ago and got lost in a forest of oldlinks and
> irelevant pages. And at the end I still didn't understand where to send
> code I wanted reviewed or to approve.

Okay, I finally put together a swiki page outlining what I believe to 
be the current harvesting process, as was sorted out here on this list 
recently:

http://minnow.cc.gatech.edu/squeak/3152

Let me know if there are any problems with this.  If not, I'll post the 
page on squeak-dev too.  Of course, we can refine the process as we go.

(I used the term "Harvest Master" for my role as 
update-stream-incorporator.  I think Hannes came up with this... I 
couldn't think of another good term.  Maybe "Incorporator"... eh.)

I think I cleaned up most of the related harvesting pages so that 
they're no longer horribly out of date, and added links between pages 
where appropriate.

Also, related to Stephane's thread about the Kernel group harvesting, 
we need to think about how that will fit in with the process outlined 
above.  I think Stephane and Daniel are on the right track... I will 
try to offer extra suggestions tomorrow, but I'm up way to late here 
and am about to fall asleep... :-)

- Doug