[squeak-dev] Re: Revising Squeak 7175 (3.10.1)
***
Klaus D. Witzel klaus.witzel at cobss.com Sat May 31 08:16:40 UTC 2008
On Sat, 31 May 2008 04:09:39 +0200, Jerome Peace wrote:
Revising Squeak 7175 (3.10.1)
I think you describe your appreciation/critique as if the issues which Ken was concerned about can be fixed and uploaded to the public download area until everybody is happy with them :(
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:
The first solution might be to simply build a replacement 3.10.1-7175-basic.zip without the problem and replace the copy on the FTP site. However I don't think that would be a good idea. Having spent a lot of time over the years helping users with issues I know how confusing it can be to try to replicate an issue and one of the keys is being able to start with the same image. Imagine a user has downloaded my faulty release and is experiencing this problem and is confused. Imagine also a helpful person who wants to assist them with this problem. The helper finds out they are using 3.10.1-7175 and downloads it from the FTP site. Unfortunately this helper has not heard of this issue and tries the newer 3.10.1-7175 image and is unable to replicate the problem. Substitute appropriately modified "Who's on First" variant; hilarity ensues at least if you are not a participant.
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 > ***