RE: re: TrueType font support and 3.6

Hi Andreas - 

I'm confused too. Let's try to isolate the problem.

Claim I - We have a piece of code that's candidate for inclusion. We all
agree it has flaws as detected by even cursory inspections. 

Claim II - I percieve as a very obvious, general rule that at every
stage of mixing code in with more of the real world, the price of fixing
errors goes up, because problems are easier to solve in isolation.
Therefore, make it work, make it right, then deploy wider.

Conclusion - I claim this piece of code (and all others) should be fixed
first, and accepted later. 

Do we disagree on the code, on the software engineering rule of thumb,
on its application to this code, or on its application to Squeak code in
general?

I don't see what this has to do with beta - beta is there because
inspections and isolated testing aren't perfect, not as an excuse to
ignore them.

I also never required that conflicts be checked with "all ongoing work"
- MCP is part of Squeak 3.6 as of 5240, IIRC. Conflicts with previously
included work should be detected and resolved, of course - when we don't
do this, we get the annoying "didnt I fix this already" effect.

This situation will always arise for each of us personally - we want to
include something because it is cool functionality. On the other hand,
the work hasn't been done yet to bring it up to the desired quality
level. What will we do, every time we're in this bind? argue on SqF, or
review on squeak-dev?

Daniel

Andreas Raab <[email protected]> wrote:
> Daniel,
> 
> > A quicky partial review of v5 does
> > show some things that could use some cleanup:
> >  - at least one method clashes with MCP.
> >  - The single GrafPort method sends to super but implicitly returns
> > self.
> >  - Paragraph>>asForm does an "isKindOf: TTCFont"
> > 
> > So IMO, this code doesn't belong in Basic, yet.
> 
> Err ... excuse me, but the above issues sound exactly like the things one
> would address in *beta* not in alpha. Requiring (for example) that there are
> no conflicts with any other ongoing work is almost impossible - the
> declarative pools have some conflicts too and I won't bother tracking all of
> the yet-to-come KCP changes until I actually know them (as in: being
> finalized and published).
> 
> Seriously confused,
>   - Andreas
> 
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sat Jun 21 15:11:32 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 23478 invoked from network); 21 Jun 2003 15:11:32 -0000
Received: from mxout4.netvision.net.il (194.90.9.27)
  by mail.theinternetone.net with SMTP; 21 Jun 2003 15:11:32 -0000
Received: from aSqueakSystem ([80.178.105.14]) 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]; Sat,
 21 Jun 2003 18:14:04 +0300 (IDT)
Date: Sat, 21 Jun 2003 18:13:42 +0200
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation]re: TrueType font support and 3.6
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://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: Sat, 21 Jun 2003 15:11:33 -0000

[email protected] wrote:
>   Sorry for really slow response, and sloow work on cleaning up the
> stuff!  I'm kind of embarrassed not finishing this up, but I have to
> say that there are more stuff than I can handle...
Nothing to be embarrassed about, you're creating good stuff that people
appreciate having in the first place.

> > (Hmm, I just tried "set font..." on some text in the middle 
> > of the Welcome window and it appears that TT fonts are a bit buggy when 
> > mixed with the regular strike fonts.  It's fine if I add some TT text at 
> > the end, though.  Or we could add a small standalone demo window.  Or 
> > just not have a demo. ;-) )
> 
>   This bug is known and fixed.  Stephane knows how to fix it:-)
I think it is very important to release an up to date version with all
known fixes - then people can help find and resolve the remaining
issues, like performance.

>   Ah, there going to be some changes, which should come first before
> the stuff gets incorporated...
Cool, let us know when it's ready.

Daniel
From [email protected] Sat Jun 21 15:54:53 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 17846 invoked from network); 21 Jun 2003 15:54:53 -0000
Received: from iramx1.ira.uni-karlsruhe.de (141.3.10.80)
  by mail.theinternetone.net with SMTP; 21 Jun 2003 15:54:53 -0000
Received: from acb069cd.ipt.aol.com ([172.176.105.205]
	helo=i09nbmarcus.ira.uka.de)
	by iramx1.ira.uni-karlsruhe.de with asmtp (Exim 3.30 #10 (Debian))
	id 19TkhY-00041t-00; Sat, 21 Jun 2003 17:54:52 +0200
Received: from marcus by i09nbmarcus.ira.uka.de with local (Exim 3.33 #2
	(Debian))	id 19TkiO-0000EE-00; Sat, 21 Jun 2003 17:55:44 +0200
Date: Sat, 21 Jun 2003 17:55:43 +0200
From: Marcus Denker <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
Subject: Re: [Squeakfoundation]re: TrueType font support and 3.6
Message-ID: <[email protected]>
References: <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email protected]>
User-Agent: Mutt/1.4.1i
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: Sat, 21 Jun 2003 15:54:53 -0000

On Sat, Jun 21, 2003 at 06:04:03PM +0200, Daniel Vainsencher wrote:
> Hi Andreas - 
> 
> I'm confused too. Let's try to isolate the problem.
> 
> Claim I - We have a piece of code that's candidate for inclusion. We all
> agree it has flaws as detected by even cursory inspections. 
> 
> Claim II - I percieve as a very obvious, general rule that at every
> stage of mixing code in with more of the real world, the price of fixing
> errors goes up, because problems are easier to solve in isolation.
> Therefore, make it work, make it right, then deploy wider.
> 

Problem is: Claim II is wrong. And obvioulsy so: Adding a big
changeset to Squeak takes a long time: It needs to be reviewed,
and discussed (image or package?). Most of the time those things
are pretty complicated, just because they tuch a lot of stuff 
where not many reviewsers are real experts. So adding big things
takes time.

On the other hand: small, isolated refactorings, that fix a little
thingy at one place can be harvested *very* fast: lots of people
can review a simple refactoring (e.g. removing a direct reference
to a class) without understanding the whole thing that was once that
big changeset. 

Another thing: Adding even not-perfectly working stuff can be good, because
it gets tested by lots of people, and most squeakers who
follow the update stream actively fix bugs they encounter. They
do this for the stuff in the update stream, not for those big changesets
that are in the review process.

So my claim (which is not new btw, it's the basis of the whole "Agile
Development" Hype) is that it's less expensive to fix things later
than most people would intuitivly guess.

  Marcus

-- 
Marcus Denker [email protected]  -- Squeak! http://squeak.de