Peter van Rooijen (squeak-dev) wrote:

>From: "Doug Way" <dway at riskmetrics.com>
>  
>
>>Well, only a "major" bugfix would warrant changing 3.6 now, since the
>>3.6 release is now done.  Any bug which has been around for more than a
>>year or so can not really be considered a major bug, so no, we won't be
>>slipping that fix in now...
>>    
>>
>
>Doug,
>
>I'm not sure how to respond. but I'm going to try:
>
>**On the one hand:
>
>If a bug is to be deemed non-major simply because it has been around for
>years, then I would agree that this bug is probably indeed not a major bug.
>  
>

Sorry, I should have used better wording to express this.  "Critical" or 
perhaps "urgent" would better describe the kind of bug I was talking 
about, rather than "major".

I would still maintain that these two rules are in effect, then:

1. Any bug which has been around for more than a year is not a 
critical/urgent bug, simply by virtue of it having been around for more 
than a year.
2. Only fixes for critical/urgent bugs will be considered for addition 
to an already-released "final" image, or a gamma image.

Note that rule #2 ONLY applies to gamma/final images... we consider all 
kinds of non-urgent bugfixes during the earlier alpha/beta stages of a 
release.  I was hoping I made that clear when I said "we should 
certainly consider the fix for 3.7alpha".

In other words, it's just a matter of when your fix can be considered in 
the release cycle, not whether it would be considered at all.

I can agree with the gist of the rest of your post.

- Doug


>I can't see the logic of the premise, however. I could see that something
>would be deemed not a major *problem* if it has been around for years
>without anyone noticing it, or at least, reporting/fixing it.
>
>This could make sense even if, *as a bug*, it is major.
>
>It does seem to be a rather inward-looking viewpoint.
>
>I mean inward-looking in the sense of: "if none of the historical Squeak
>users noticed this (or was bothered enough to take any action) for so long,
>it can't be very serious". In other words, the norm for "quality that
>matters" is what the historical user base has been able to live with for
>more than a year.
>
>One might reasonably argue that this is a stretch, but then it is only a
>small stretch, which I believe makes a valuable point. How inward-looking is
>the Squeak community? How much does that hurt?
>
>I freelu gtant taht I don't know the answers to those questions.
>
>**On the other hand:
>
>The scope rules of shared variables are described in the blue book. It
>doesn't explicitly describe the resolution process, but AFAICT it doesn't
>take more than a few minutes to figure out what the effect of the resolution
>process is supposed to be.
>
>I have worked with various Smalltalk dialects over the course of many years,
>and I haven't noticed any deviation of the blue book shared variable scope
>rules in any of those.
>
>To my mind, what the meaning of variable names appearing in the code is, is
>rather essential for a programming language. If an implementation deviates
>from the norm in that respect, I would have no problem labeling that as a
>serious bug.
>
>**What this comes from:
>
>I came upon this issue in Squeak when I tried to install a program that runs
>unmodified in VisualWorks, VisualAge and Smalltalk/X, and I could not even
>load it into an unmodified Squeak image.
>
>What happens is that there is a check in the class definition installation
>code that throws an error when a class variable is defined that has the same
>name of an existing global variable. However, a class variable having the
>same name of an existing global is totally OK. If not, the validity of each
>and every program that uses a class variable would depend on what globals
>happen to be present in a particular image. I doubt anyone would argue that
>that is how it is supposed to be.
>
>So, I comment out the check to let the code be installed. Installation
>proceeds without any further complaints.
>
>I run the tests of the installed program. Now there is another problem.
>
>Upon inspection it turns out to be this: while the class variables with the
>same name as a global are correctly processed in the class defining them, in
>subclasses the same name is taken to refer to the global. Another way of
>saying this is that class variables with the same name of a global are not
>inherited.
>
>It doesn't take much time to see the source of the problem, which is
>incorrect name resolution logic during the method compilation process. I
>would certainly call this a major bug, but I've already said all I want to
>say about that now ;-).
>
>  
>
>>However, we should certainly consider the fix for 3.7alpha.  Have you
>>already submitted a [FIX]?
>>    
>>
>
>Like I said, I have not. But I would be happy to *if* we agree that this
>wants fixing.
>
>I have no desire to write the fix, test it, find out how to submit it (is it
>okay to send a message to this list with a zipped changeset attached?),
>submit it, to be then told that this is a fundamental change for what is not
>a serious problem (because no one complained about it in years), and it
>might break something (although it should not, it might), so it won't get
>in.
>
>After all, a major part of my wanting this corrected is to be able to run my
>programs in an undoctored Squeak image. If that is not in the cards, I might
>as well make the changes without submitting them as a fix, or simply not
>bother about my programs running on Squeak.
>
>BTW, there is a funny twist to this. I believe the license requires one to
>share changes made to certain parts of the system. I don't know exactly
>which parts of the system qualify, but I would not be surprised if the parts
>affected here do infact qualify. Then after that, I don't know what action
>constitutes sharing the fix :-).
>
>So, I would appreciate some guidance in this respect.
>
>Best regards,
>
>Peter van Rooijen
>Amsterdam
>
>  
>
>>- Doug
>>    
>>
>
>  
>