On 10/31/11 20:44 Mark Miesfeld said: > Earlier Chip wrote: > > "There was indeed a change to the 'Call' search order between 3.2.0 and > 4.0.0. I was able to track it as far back as an SVN update on 6Feb09 > to the main/trunk/CHANGES document. It listed the RFE "1666636 - Add > source of caller to function search order" but that was the end of the > trail. I can find no documentation for "1666636" anywhere." > > If you look up the 1666636 item in the Request for Enhancement tracker > you can see that Rick opened it and stated the rational for it. He > opened it in February of 2007 and implemented it in August 2008.
My entire participation in this discussion started with not being able to find any reference to RFE-166636. My mistake was thinking that one could search on the "Artifact ID". Once I figured out how to find the RFE item however, there still wasn't much there. > That gave anyone, that wanted to make the effort, the opportunity to > discuss it for about a year and a half. That's a little disingenuous, Mark. Most of us don't have the time to follow every little issue that comes up. That's the responsibility of an Architecture Review Board, or absent that, a vibrant community of developers. Absent both of them, shit happens. > You can see that Rony was in > favor of it, he just was curious as to where it would be put in the > search order. I could have objected to it, but I didn't. Indeed. One question (that was never answered) is hardly what I would call a sufficient review of a proposal that changes the behavior of the language processor in a non-backwards-compatible way. > Anyone can subscribe to the SVN, Bug, RFE, and similar lists and track > every single thing the developers are doing. Anyone can subscribe to > the developers list and discuss these things as they are done / as they > appear. And I have been, since Mar07. Unfortunately, this all happened in Feb07 and the only other reference to the issue was when you closed a whole slew of items en masse. Yeah, I looked at a few of them and then mass-filed the rest. Not that it would have mattered; it was already released by that point (Sep10). > Anyone could have spoke up when Rick committed the implementation. The > final release wasn't done until around August 2009, which gave anyone > about a year to object to the change. Anything committed can be easily > rolled back. > > So, no one spoke up, no one objected, the change was finalized by the > release of 4.0.0. Translating to Vogon: "There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now. … What do you mean you’ve never been to Alpha Centauri? Oh, for heaven’s sake, mankind, it’s only four light years away, you know. I’m sorry, but if you can’t be bothered to take an interest in local affairs, that’s your own lookout. Energize the demolition beams." > I don't see how the lack of a prior design document should keep us > from discussing how this particular bug request should be handled. > > Exactly. We should discuss how the bug report should be handled. > Especially since it's not real clear if it is or is not a bug. No need. Once RFE-1666636 was implemented, and the documentation updated to reflect it, Uli's BUG-2978925 was valid in that the behavior didn't match the updated documentation for some reason. Now that it does, Jerry's BUG-3429383 _must_ be closed as "WAD". The fact that his working program is behaving differently between 3.2.0 and 4.1.0 is his own fault for not subscribing to (and assiduously following) Oorexx-rfes. > I would vote that this isn't a bug, but working as documented. I > would offer to change this bug into an enhancement request. "Dishancement request"? > Although we have two changes here. The implementation of RFE 1666636 > and the fix of Bug 2978925. The fix for bug 2978925 definitely changed > the behaviour from 4.0.1 to 4.1.0. I haven't had the time to check > behavior between 3.2.0 and 4.0.0. And I haven't given the exact details > here a lot of deep thought. So, it's not entirely clear where we are at > here. Fair enough. I wasn't either until I did a lot of digging. > Did the implementation of RFE 1666636 change existing, *documented* > behavior? Yes. > Was the implementation of RFE 1666636 not completely correct so it > needed the 2978925 bug fix to match the documentation? Apparently. > Or did the implementation of RFE 1666636 have an unintended consequence > that introduced bug 2978925? It doesn't look like it, but who knows? The issue was that it wasn't working as (newly) documented on Linux. > ... And besides, if you put Brad Pitt's photo on my Facebook page, > no one would notice the difference, since I'm mistaken for him quite > often. ;-) > > I had heard that, Bruce, that you were often mistaken for Brad Pitt. > Also I don't think your Facebook analogy is quite accurate. It would > be more like Facebook changes the way Facebook works, which they seem > to do a on frequent basis. My Facebook photo is user data, and to my > knowledge we are not changing any user data. It's perfectly valid: Jerry's program is his data to the language processor. The same data that ran one way in 3.2.0 now runs differently on 4.1.0. Someone complained that everyone on Facebook is ugly and submitted an RFE to put Brad's face on every image. Even if you were Matt Damon. Q.E.D. -Chip- ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
