[Squeakfoundation]KCP & 3.6

[Stephane Ducasse]

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 <dway at riskmetrics.com> 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
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
>