[Squeakfoundation]KCP & 3.6

[Stephane Ducasse]

Hi

I think that this is important to stick with the plan in terms of new 
stuff in the image you fix in terms of stuff that should be done in 3.6
	...
> 1 Removals
> 2 KCP
> 3 MCP
> 4 Anthony runtime enhancements (split in two - fixes and closures)
> 5 Craig's simulator fixes
> 6 mir Network rewrite
> 7 TrueTypeTextStyle
> 8 Diego look style enhancements
> 9 Replace fonts with AccuFonts (mainly in order to remove the old -
> people can now load additional nice fonts themselves anyway).
> 10 SM 1.1
> 11 Inclusion of SM plus related packages in the release image (though
> maintained as packages, not directly by update stream).

KCP in that is minor for my point of view (even if I prefer that the 
changes do not stay
too long been not harvested.)

What is ***really*** important is that people should be willing to move 
to 3.6
not just because the number changed but because this is better.

Stef

On Friday, June 20, 2003, at 07:27 PM, Doug Way 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
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
>