Getting 3dot10 done was [ Taking the blue pill ] Hi Matt,
I had not been thinking about the amount of work involved because with changesets (or going forward delta streams ) there would be a minimal amount of hassle. And it could be done in finite time. The priority for 3dot10 should be in finishing up without killing the release team. To that end I think your idea of fixing by reverting the methods in 7158 would work well enough in practice. The versions were available in 7158. That's how I found the bug. The timestamps for the methods that you choose not to revert still need to be changed. So we can tell that we have the "blessed" ones. This would mean touching their packages etc. Lots of work. But anything less would be hard to debug if the need arose. (see my comments in the mantis bug report). Code review by several reviewers could be considered sufficient "testing", for the purposes of commiting the code. Then we can just go forward from the new image and "deal with problems as they come up". In theory, theory and practice are the same. In practice, they are not. My earlier comments in this thread were from the lofty realm of theory. I have now thought a little on the priority of getting 3dot10 done and shifted my pov over into the nitty-gritty realm of practicality. Yours in curiosity and service, --Jeorme Peace *** >Matthew Fulmer tapplek at gmail.com >Sat Nov 3 00:10:31 UTC 2007 > >On Fri, Nov 02, 2007 at 02:05:16PM -0700, Andreas Raab wrote: >> Edgar J. De Cleene wrote: >>> I afraid the blue pill way take a couple of years for the 98% of 172 >>> methods >>> going to future releases. >> >> Maybe so. But why exactly is this a problem? The changes are >> "beautifications" at best, they don't fix a problem, they don't improve >> behavior, they don't add features. Why the pressure to get them done >> immediately? > >For me, it is an urgent feature because it is the fastest way to >re-incorperate all the changes made between 7142 and 7158. With >the current MCZ update stream, it is nearly impossible to just >take a buggy change set out of the update stream and expect it >the issue to disappear; you also have to re-do all changes >since, since each update can re-introduce the bug thanks to the >redundency inherent in packages. It would be easier to review >the update and patch it in 7159 than to redo the work between >7142 and 7158. Edgar is already over-worked. > *** __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ V3dot10 mailing list [email protected] http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
