[squeak-dev] Re: Revising Squeak 7175 (3.10.1)

[squeak-dev] Re: Revising Squeak 7175 (3.10.1)

***
In the part I mentioned. Yes. I think that is doable.
If only by adopting the update stream version as the release candidate.

I don't get why the last step needed to be hard or difficult.
99% should have been done by the update stream
 with just a release cleanup necessary to get from there
 to the first release candidate.
Surely that could have been done from a change set postscript.

Ken did something he described as hard and more involved than he expected.
 How did he do that?

I am very troubled by the reintroduction of the phantom catagory.

I can't imagine how that was done.
It makes me suspicious (as only a bug tracker will get)
 of whatever else was done to obtain
 the image that was the first release candidate.
My experience is that when you find an obvious bug
 the code is telling you to check it more carefully.

Why should I trust that this was the only error introduced?

Also my quick check of the "click fix" showed
 that it left out some necessary cleanup.
My experience is that this can often be expected
 when trying to correct things quickly.

This is not discouraging only frustating.
I've learned to trust that felling as a friend.
It means the solution is close at hand,
 but a breakthru must/will come first.
>
>Can you reformulate so that the [main] concerns which Ken raised in his  
>message on Wednesday are addressed, if possible one-by-one, TIA.
>

Ken Wrote: I agree.  


The revised release needs to have a different name.
So it can be distinguished.
One elegant way I saw in a linux enviorment
 was that you could take the release and append -RC1,-RC2 etc.
 until a release candidate passes the test of time
 then the -RCn is dropped.
The final candidate is also known as the final release.

I didn't know about that naming scheme a week ago.
It stuck when I saw it because it's an obvious way to get a name right.

So here we start with maybe 3.10.1-7176-basic-RC1.
Run until we are stable.
At this point it shouldn't take long.
We got our lessons and learned from them. Right?

Ken was pushing to achieve something by a deadline.
And he did a wonderful job of accomplishing that.
He was aiming for that something to be the release.
It turns out it was not. But it was a release candidate
 and that is pretty important.
An accomplishment not to be diminished
 by the problems we are currently dealing with.

The deadline did not allow time for release candidates.
 In hindsight, it turns out that time was needed.

Great programming comes from making great mistakes
 and thinking about them.

Yours in curiosity and service, --Jerome Peace

<original message snipped >
***