Re: KCP & 3.6

[Accufonts in if Doug happy with his changes
DecPools in or out is Tim's call, 
KCP in or out my call, 
3.7 alpha opens with 3.6 gamma]
I agree on these. We enter beta friday the 27th?

[other things like TT fonts]
>4 Anthony runtime enhancements (split in two - fixes and closures)
>5 Craig's simulator fixes
>7 TrueTypeTextStyle
>8 Diego look style enhancements
4 - I started to review this, and Anthony made a revision, which I
haven't looked at yet. I asked for help, and am not getting it, so we
can forget about it for 3.6, unless someone does something new. The
problems outstanding are - 
A. I'm don't know enough about exceptions to notice if something there
fubars exceptions in some strange case. We need a reviewer that knows
the area.
B. Anthony for some reason includes in this package myriad changes to
existing classes. I think that class library extensions should be
discussed on the list, and shouldn't sneak past on the tails of fixes or
enhancements. I started reviewing these, but frankly, it's quite
tedious, especially since I don't know which, if any, the code we
actually want depends on. To be honest, I would be quite glad if someone
simply verifies they are not needed, rewrites the code to not need them
if the do, and gives us a very short list of changes that are actually
needed, if any, with some explanation of what general case this code
serves.

5. Were reposted, but we have no review. Berne have expressed some
interest in testing this, but nothing more. IMO, this gets pushed from
3.6, though it might be reasonable to accept in beta, since they're
fixes.
7. Yoshiki said he's working on a revision. Will need to get reviewed...
not 3.6.
8. Avi said he doesn't like something about the scrollbars. These don't
have a preference, which Diego said he'd treat as a bug. I don't know of
review/testing status. 

BTW, at some point it was starting to look like we might get some
feedback from people working with the m17n work, and be able to get it
into 3.6. I guess not, now, but anyone know what's going on with that?

Daniel

Doug Way <[email protected]> wrote:
> 
> Daniel Vainsencher wrote:
> 
> >I disagree with the current calls to delay the release. If we wait for
> >everyone to get whatever matters to them in, we might never make a
> >release again :-) I don't see anything wrong with stuff waiting for 3.7
> >- DecPools included.
> >
> >I know a few of us feel "in the middle of" various projects, but I think
> >the release process has value too - it reminds us to clean the table
> >every so often. I think between the KCP deprecations and the network
> >rewrite, we've had enough change that it will do us good to focus on
> >stability before we keep moving ahead.
> >  
> >
> 
> I was on the fence somewhat, but this sounds like a reasonable plan.  We 
> will delay beta for a week or so, but stick to our final release date of 
> August 1st.  There is some value in sticking to release dates unless 
> there is a pretty big problem.
> 
> If the DecPools stuff feels like it's "ready", we could put it in now, 
> otherwise we can put it in right at the beginning of 3.7alpha, which 
> isn't too far away anyway.  (It sounds like there are still some 
> outstanding issues at the moment...?)  I'll leave it up to Tim as to 
> when it feels ready.
> 
> I actually wanted to at least get the Accufonts changes in for 3.6alpha 
> also, which I don't think should be *too* destabilizing, and was on our 
> 3.6 plan.  I was going to work on that right after including the current 
> batch of approved items (which I'll try to do today).  There are a few 
> tweaks that I think should be made to the Accufonts stuff before it gets 
> incorporated (for example I don't think it should change the default 
> text size), so I was going to post my tweaked version as an [ENH] for 
> people to try before rolling it in as an update.
> 
> I originally wanted to get the TrueTypeTextStyle stuff in as well, but 
> there may or may not be time for that.  The items such as this on the 
> 3.6 plan which don't make it in will get pushed off to 3.7alpha.  But we 
> could plan on listing them first on the 3.7 plan (say, before further 
> package removals), so they'll be more likely to actually get done in 3.7.
> 
> >More generally - if we think about the process as a whole, not just the
> >particular point in time were in, the only right kinds of reasons to
> >delay the move to beta are "it doesn't meet our functionality goals". A
> >more specific example is "without this new function, all of this other
> >stuff we inserted makes no sense AND it is hard to remove that stuff".
> >Only right kind of reason to avoid moving from beta to gamma is "this
> >version doesn't meet our stability goals". Which I think should be "this
> >version should be stabler than the previous one".
> >  
> >
> 
> ("Previous" meaning 3.6gamma should be stabler than 3.6beta, or stabler 
> than 3.5gamma?)
> 
> >So a one week delay of beta to insert parts of KCP that relate to what's
> >already in makes a little sense. Delaying by a month just to get more
> >stuff in now that the harvesting process is livelier, seems unjustified
> >to me - we can get that after the version fork.
> >
> 
> Yes... we can try to get most of the current KCP changes in this week, 
> and then the next batch wouldn't go in until 3.7alpha.
> 
> >Speaking of which - at which stage do we create the 3.7 update stream?
> >last time we did it on entry to beta, IIRC, yet some might say entry to
> >gamma is more reasonable. What do we think?
> >  
> >
> 
> Good question.  I'd lean toward opening the 3.7alpha stream when we move 
> 3.6 to gamma... this is a good way to encourage people to use and test 
> the beta version so that things actually get fixed.  And since the beta 
> is only ~3 weeks long it doesn't seem like too big a sacrifice to not 
> have an alpha version during that time.  It also simplifies update 
> stream management a bit.  I could go either way on this, though.
> 
> - Doug Way
> 
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Fri Jun 20 19:00:14 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 26786 invoked from network); 20 Jun 2003 19:00:14 -0000
Received: from sccrmhc11.comcast.net (HELO sccrmhc11.attbi.com)
	(204.127.202.55)
	by mail.theinternetone.net with SMTP; 20 Jun 2003 19:00:14 -0000
Received: from goldskin.attbi.com
	(12-234-54-55.client.attbi.com[12.234.54.55](misconfigured sender))
	by attbi.com (sccrmhc11) with SMTP
	id <200306201900120110046more>; Fri, 20 Jun 2003 19:00:13 +0000
Date: Fri, 20 Jun 2003 11:52:51 -0700
From: Tim Rowledge <[email protected]>
To: [email protected]
Subject: Re: [Squeakfoundation]KCP & 3.6
Message-ID: <[email protected]>
References: <[email protected]>
In-Reply-To: <[email protected]>
User-Agent: Messenger-Pro/2.60a (MsgServe/2.00g) (RISC-OS/4.02)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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: Fri, 20 Jun 2003 19:00:14 -0000

> > 4 Anthony runtime enhancements (split in two - fixes and closures)
Well right there you have a problem. How many people have even looked at
this? What about the SmaCC license issue? Does it work reliably on all
platforms? Has anyone given it a good workover? This is a big change and
needs careful attention.

> 7 TrueTypeTextStyle
It works ok, looks beautiful but seems to slow down my system quite a
bit. We need profiling and improvements to make it suitable for default
usage - something I think very important.

tim
--
Tim Rowledge, [email protected], http://sumeru.stanford.edu/tim
Useful random insult:- Can easily be confused with facts.
From [email protected] Fri Jun 20 19:00:16 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 26863 invoked from network); 20 Jun 2003 19:00:16 -0000
Received: from sccrmhc11.comcast.net (HELO sccrmhc11.attbi.com)
	(204.127.202.55)
	by mail.theinternetone.net with SMTP; 20 Jun 2003 19:00:16 -0000
Received: from goldskin.attbi.com
	(12-234-54-55.client.attbi.com[12.234.54.55](misconfigured sender))
	by attbi.com (sccrmhc11) with SMTP
	id <200306201900130110046mose>; Fri, 20 Jun 2003 19:00:13 +0000
Date: Fri, 20 Jun 2003 11:58:50 -0700
From: Tim Rowledge <[email protected]>
To: [email protected]
Subject: Re: [Squeakfoundation]Squeak downloads
Message-ID: <[email protected]>
References: <000001c33679$f17b05a0$1f00a8c0@atlantis>
In-Reply-To: <000001c33679$f17b05a0$1f00a8c0@atlantis>
User-Agent: Messenger-Pro/2.60a (MsgServe/2.00g) (RISC-OS/4.02)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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: Fri, 20 Jun 2003 19:00:16 -0000

I'm being hopelessly nitpicky here but I can't get to minnow to look at
the example page so I have to do _something_ :-)

> a) we make a copy of the current download page and name it appropriately
> (such as "DownloadsForSqueak3.5") - this is now a "previous version"
This should be Download _of_ Squeak since 'for' implies stuff to add to
squeak. SM would properly be 'for'.

See, I told you it was hopelessly nitpicky.


tim
--
Tim Rowledge, [email protected], http://sumeru.stanford.edu/tim
The next generation of computers will have a "Warranty Expired" interrupt.
From [email protected] Fri Jun 20 19:02:30 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 28965 invoked from network); 20 Jun 2003 19:02:30 -0000
Received: from mailhub02.unibe.ch (130.92.9.53)
  by mail.theinternetone.net with SMTP; 20 Jun 2003 19:02:30 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailhub02.unibe.ch (Postfix) with ESMTP id 85C127647E
	for <[email protected]>;
	Fri, 20 Jun 2003 21:02:30 +0200 (MEST)
Received: from mailhub02.unibe.ch ([127.0.0.1])
 by localhost (mailhub02 [127.0.0.1:10024]) (amavisd-new) with LMTP
 id 22185-01-8 for <[email protected]>;
 Fri, 20 Jun 2003 21:02:29 +0200 (MEST)
Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4])
	by mailhub02.unibe.ch (Postfix) with ESMTP id C4CE47647B
	for <[email protected]>;
	Fri, 20 Jun 2003 21:02:29 +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 h5KJ2SK11669;
	Fri, 20 Jun 2003 21:02:28 +0200 (MET DST)
Date: Fri, 20 Jun 2003 21:02:27 +0200
Subject: Re: [Squeakfoundation]KCP & 3.6
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
To: Discussing the Squeak Foundation
	<[email protected]>
From: Stephane Ducasse <[email protected]>
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-Virus-checked: by University of Berne
cc: Alexandre Bergel <[email protected]>
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: Fri, 20 Jun 2003 19:02:31 -0000

Hi daniel

I know that you are doing a lot. Here are my suggestions.

> [Accufonts in if Doug happy with his changes
> DecPools in or out is Tim's call,
> KCP in or out my call,
Please have a look until KCP-0088 = 15 changeset (where a third are 
simple fix).
Because they all belongs to the same logical flow.

> 3.7 alpha opens with 3.6 gamma]

> [other things like TT fonts]
>> 4 Anthony runtime enhancements (split in two - fixes and closures)
>> 5 Craig's simulator fixes
>> 7 TrueTypeTextStyle
>> 8 Diego look style enhancements

> 4 - I started to review this, and Anthony made a revision, which I
> haven't looked at yet. I asked for help, and am not getting it, so we
> can forget about it for 3.6, unless someone does something new. The
> problems outstanding are -
> A. I'm don't know enough about exceptions to notice if something there
> fubars exceptions in some strange case. We need a reviewer that knows
> the area.
> B. Anthony for some reason includes in this package myriad changes to
> existing classes. I think that class library extensions should be
> discussed on the list, and shouldn't sneak past on the tails of fixes 
> or
> enhancements. I started reviewing these, but frankly, it's quite
> tedious, especially since I don't know which, if any, the code we
> actually want depends on. To be honest, I would be quite glad if 
> someone
> simply verifies they are not needed, rewrites the code to not need them
> if the do, and gives us a very short list of changes that are actually
> needed, if any, with some explanation of what general case this code
> serves.

So reask for an official help into the mailing-list and state it like 
that.
I'm not good in exception either and I agree with you that if there are 
a lot of
small changes everywhere this can be tedious.

>
> 5. Were reposted, but we have no review. Berne have expressed some
> interest in testing this, but nothing more. IMO, this gets pushed from
> 3.6, though it might be reasonable to accept in beta, since they're
> fixes.

Alex is using that daily. He is really happy with that, because he can 
finally debug
its own VM extensions/modifications with it. This is now one week and 
half that
he is working with it and nothing wrong is happening so I would include 
it.
Ask him his point of view. I think that this is a really important 
aspects of squeak
that we should not continue to keep desynchronized.

> 7. Yoshiki said he's working on a revision. Will need to get 
> reviewed...
> not 3.6.

Why why why. Just wait. Ask Yoshiki to do something faster.


> 8. Avi said he doesn't like something about the scrollbars. These don't
> have a preference, which Diego said he'd treat as a bug. I don't know 
> of
> review/testing status.

If one guy say something why should we stop. because all kinds of 
people said stupid stuff
about SystemDictionary recently and then. They have no point.

So ask diego.

> BTW, at some point it was starting to look like we might get some
> feedback from people working with the m17n work, and be able to get it
> into 3.6. I guess not, now, but anyone know what's going on with that?
>
> Daniel
>
> Doug Way <[email protected]> wrote:
>>
>> Daniel Vainsencher wrote:
>>
>>> I disagree with the current calls to delay the release. If we wait 
>>> for
>>> everyone to get whatever matters to them in, we might never make a
>>> release again :-) I don't see anything wrong with stuff waiting for 
>>> 3.7
>>> - DecPools included.
>>>
>>> I know a few of us feel "in the middle of" various projects, but I 
>>> think
>>> the release process has value too - it reminds us to clean the table
>>> every so often. I think between the KCP deprecations and the network
>>> rewrite, we've had enough change that it will do us good to focus on
>>> stability before we keep moving ahead.
>>>
>>>
>>
>> I was on the fence somewhat, but this sounds like a reasonable plan.  
>> We
>> will delay beta for a week or so, but stick to our final release date 
>> of
>> August 1st.  There is some value in sticking to release dates unless
>> there is a pretty big problem.
>>
>> If the DecPools stuff feels like it's "ready", we could put it in now,
>> otherwise we can put it in right at the beginning of 3.7alpha, which
>> isn't too far away anyway.  (It sounds like there are still some
>> outstanding issues at the moment...?)  I'll leave it up to Tim as to
>> when it feels ready.
>>
>> I actually wanted to at least get the Accufonts changes in for 
>> 3.6alpha
>> also, which I don't think should be *too* destabilizing, and was on 
>> our
>> 3.6 plan.  I was going to work on that right after including the 
>> current
>> batch of approved items (which I'll try to do today).  There are a few
>> tweaks that I think should be made to the Accufonts stuff before it 
>> gets
>> incorporated (for example I don't think it should change the default
>> text size), so I was going to post my tweaked version as an [ENH] for
>> people to try before rolling it in as an update.
>>
>> I originally wanted to get the TrueTypeTextStyle stuff in as well, but
>> there may or may not be time for that.  The items such as this on the
>> 3.6 plan which don't make it in will get pushed off to 3.7alpha.  But 
>> we
>> could plan on listing them first on the 3.7 plan (say, before further
>> package removals), so they'll be more likely to actually get done in 
>> 3.7.
>>
>>> More generally - if we think about the process as a whole, not just 
>>> the
>>> particular point in time were in, the only right kinds of reasons to
>>> delay the move to beta are "it doesn't meet our functionality 
>>> goals". A
>>> more specific example is "without this new function, all of this 
>>> other
>>> stuff we inserted makes no sense AND it is hard to remove that 
>>> stuff".
>>> Only right kind of reason to avoid moving from beta to gamma is "this
>>> version doesn't meet our stability goals". Which I think should be 
>>> "this
>>> version should be stabler than the previous one".
>>>
>>>
>>
>> ("Previous" meaning 3.6gamma should be stabler than 3.6beta, or 
>> stabler
>> than 3.5gamma?)
>>
>>> So a one week delay of beta to insert parts of KCP that relate to 
>>> what's
>>> already in makes a little sense. Delaying by a month just to get more
>>> stuff in now that the harvesting process is livelier, seems 
>>> unjustified
>>> to me - we can get that after the version fork.
>>>
>>
>> Yes... we can try to get most of the current KCP changes in this week,
>> and then the next batch wouldn't go in until 3.7alpha.
>>
>>> Speaking of which - at which stage do we create the 3.7 update 
>>> stream?
>>> last time we did it on entry to beta, IIRC, yet some might say entry 
>>> to
>>> gamma is more reasonable. What do we think?
>>>
>>>
>>
>> Good question.  I'd lean toward opening the 3.7alpha stream when we 
>> move
>> 3.6 to gamma... this is a good way to encourage people to use and test
>> the beta version so that things actually get fixed.  And since the 
>> beta
>> is only ~3 weeks long it doesn't seem like too big a sacrifice to not
>> have an alpha version during that time.  It also simplifies update
>> stream management a bit.  I could go either way on this, though.
>>
>> - Doug Way
>>
>>
>> _______________________________________________
>> Squeakfoundation mailing list
>> [email protected]
>> http://lists.squeakfoundation.org/listinfo/squeakfoundation
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
>