0007042: [fixes][tests] Whitling down unimplemented calls in sq7159

Notes
(0012079 - 877 - 1030 - 1030 - 1030 - 1030 - 1030) wiz 05-11-08 02:20	UnimpCallTests-wiz.1.cs contains two tests which run under ReleaseTests. They essentially implement formally what is in the ExploreUnimpCalls.text workspace routines. The internal constants are set so that the tests will fail in 3dot10 final until the patches in UnimpCallFixes-wiz.4.cs are instaled. Now I have tested things to show that the tests will fail and pass respectively before and after the install. I have not done a full suite of tests to prove that the patches do not cause problems. This needs to be done by someone. And I would like help and feedback on this. In any event the tests should be harvested. If the patches don't cause problems they should be harvested as well. My expectation is that as we get better at testing the image we will be able to tighten the release test to have higher and higher standards.

(0012080 - 159 - 225 - 225 - 225 - 225 - 225) wiz 05-11-08 02:23 edited on: 05-11-08 02:24	"fix begin" Installer mantis bug: 7042 fix: 'UnimpCallFixes-wiz.4.cs'. "fix test" Installer mantis bug: 7042 fix: 'UnimpCallFixes-wiz.4.cs'. "fix end"

(0012136 - 154 - 154 - 154 - 154 - 154 - 154) KenCausey 05-21-08 16:26	After reviewing these changes I think they could use further review and I would not recommend them for inclusion in 3.10.1 which must be narrowly defined.

(0012137 - 1252 - 1435 - 1435 - 1435 - 1435 - 1435) wiz 05-22-08 03:52	Hi Ken, Could you be a little more specific. If you reviewed them how did you do the review? What problems did you find? What part did you find not to have problems? 3.10.1 has a narrow scope and these are not essential fixes. But in what version do these get scheduled for inclusion? The point of the tests is to start having another guard against bugs. It also helps show where packaging could be done more tightly or cleanly. [OT] One of the problems of all releases and release teams so far is that they create new bugs in squeak. How do you catch those new bugs if you don't have tests to look for them? Release teams need to have some way to hold contributers to account. And to weed out the good contributions from the bad. In particular one fruitful area for bugs is integration bugs. A package may work perfectly well and consistently with its own assumptions but not with others. How do we have integration bugs show up before we have put incompatible packages together. This is one of the tests needed. [Back on topic]> I would be quite happy if this were scheduled for an early inclusion into an alpha version. Or if you gave me feedback on any of the patches that cause problems. Cheers --Jer

(0012144 - 355 - 367 - 367 - 367 - 367 - 367) KenCausey 05-22-08 22:44	Let me clarify: Edgar has asked me about whether or not this was appropriate for harvesting for 3.10.1. My intent was only to comment on this for that purpose. In general however the wide-ranging nature of the 'fix' (it affects a wide range of classes) warrants more eyeballs in my opinion, hopefully those with domain knowledge of the relevant areas.

(0012153 - 1648 - 1810 - 1810 - 1810 - 1810 - 1810) wiz 05-24-08 06:04 edited on: 05-24-08 06:06	Hi Ken, I realized you were aimed at getting the scope of 3.10.1 within reason. My frustration is this: I have a not infinite amount of self funded time to dedicate to squeak repair. I could have proposed each of these patches separately (they sit somewhere on my disk as single method fileouts.) but put them together as a batch for simplicity. I have asked for eyeballs and you are the only one who has shown up and you have not commented specifically on any of the patches in particular only on the unsuitablity for a gamma version. this leaves me nothing to do but guess. Thats not useful enough. As for a need for more eyeballs. The next step with these patches is to put them in an image (en-mass or individually) and see if they break any tests. If they have you haven't said. If they haven't then I don't know on what basis other eyeballs might have for rejecting them. If they haven't been tested and you don't know then that is a different issue. I believe testing for new sent but unimplemented methods is an essential tool for finding integration bugs. The tests (modified to pass w/o the fixes if need be) should be added early in an alpha development process if you want the other additions to the development image to be tested against them. The fixes could be added one by one or all together and tested. I would like feed back it they don't work. I don't want to put my time into the testing because other eyeballs will be sharper than those of the patcher. So if other eyes are needed, whose would they be? How to we focus them on the issue? Yours in curiosity and service, --Jerome Peace

(0013121 - 134 - 140 - 140 - 244 - 244 - 244) wiz 05-07-09 05:26	The vm-maker ccg:* methods were responsible for a goodly number of unimp calls. Glad to see a change set that removes them. See 0007221

(0013573 - 1048 - 1180 - 1180 - 1336 - 1336 - 1336) wiz 03-19-10 03:45	Okay. I have looked at the changeset uploaded here in the context of sq #9721. These changes have definitely NOT been loaded. Also the wonderfully great amount of activity has outdated a few of the changes. So what I propose to do is start a new report 0007481: In sq 9721 many old unimplemented calls remain unfix and new unimplemented calls have appeared as well. New report includes an update change set based on the fixes here. [OT] Unimplemented calls are good things to chase down because they will usually point to spelling and other trivial coding errors in code that otherwise does not get extensively exercised. The value of having an squeak with zero unimplemented calls is then new errors can be found because they will stand out. [Gritch] It is unfun to put in volunteer time. Do good work. Then have that work neglected until it needs to be redone. Hmmm. I seem to have gotten grumpy and bitter about this. --Jer Anyway better luck with the next report. Yours in curiosity and service, --Jerome Peace

(0013606 - 19 - 19 - 19 - 145 - 145 - 145) nicolas cellier 03-30-10 21:04	Superseded by 0007483

(0014267 - 35 - 35 - 35 - 191 - 191 - 191) FrankShearar 12-19-12 13:48	See 0007481 for the up to date issue.

Issue History
Date Modified	Username	Field	Change
05-11-08 02:07	wiz	New Issue
05-11-08 02:08	wiz	File Added: ExploreUnimpCalls.text
05-11-08 02:09	wiz	File Added: UnimpCallTests-wiz.1.cs
05-11-08 02:10	wiz	File Added: UnimpCallFixes-wiz.4.cs
05-11-08 02:20	wiz	Note Added: 0012079
05-11-08 02:23	wiz	Note Added: 0012080
05-11-08 02:24	wiz	Note Edited: 0012080
05-21-08 15:03	KenCausey	Status	new => assigned
05-21-08 15:03	KenCausey	Assigned To	=> KenCausey
05-21-08 16:26	KenCausey	Note Added: 0012136
05-22-08 03:52	wiz	Note Added: 0012137
05-22-08 22:44	KenCausey	Note Added: 0012144
05-24-08 06:04	wiz	Note Added: 0012153
05-24-08 06:06	wiz	Note Edited: 0012153
01-10-09 02:13	Keith_Hodges	Status	assigned => pending
05-07-09 05:23	wiz	Relationship added	related to 0007221
05-07-09 05:26	wiz	Note Added: 0013121
03-19-10 03:45	wiz	Note Added: 0013573
03-19-10 03:48	wiz	Relationship added	child of 0007481
03-30-10 21:04	nicolas cellier	Status	pending => closed
03-30-10 21:04	nicolas cellier	Note Added: 0013606
03-30-10 21:04	nicolas cellier	Resolution	open => duplicate
04-06-10 16:35	KenCausey	Status	closed => assigned
04-06-10 16:35	KenCausey	Assigned To	KenCausey => wiz
12-19-12 13:48	FrankShearar	Status	assigned => closed
12-19-12 13:48	FrankShearar	Note Added: 0014267