I wanted this event to just slide away silently into my rear view mirror
but I have received a formal request to do some explaining so here goes:
================================================
May 6 6PM -- I checked in source without noticing that another module
depended on the changes. Oops.
Build broken
May 6 8 PM -- FIXED -- Sorry, mea culpa!
================================================
Our Release Engineers are (of necessity) part vampire which explains the
error discovery time below
May 7 -- 4 AM -- Quicklook Test Errors discovered
May 7 -- 11:27 AM -- Quicklook Test Errors Fixed -- Sorry!
Here's how I managed to bungle up the QL Tests -- learn the easy way by
reading this.
* I reinstalled GlassFish from the build from before my changes
because of a QL bug -- you can not run it twice in a row
* I am SUPPOSED to now copy over the 2 jars with the changed
classes. OOPS. Forgot this step. And I ran QL on 3 different
computers to be absolutely positively sure ;-)
* Run thorough QL tests which of course pass with flying colors
because my new classes are not there at runtime
* Doh!
================================================
May 7 -- 6PM Web devtests are reported to be failing. IT #8262
My response was, of course, say what?!? I thought we did not have
devtests for V3. Surprise! We do. There is even a Hudson job running
the web portion of the devtests.
May 7 8 PM Jane Young rides to the rescue and backs out my changes.
This gets really boring now. If you are still reading this my hat is
off to you...
Apparently what happened was that there was a bug in the devtests --
stop-domain never was really called.
The immediately following start-domain would always error because the
domain was still running. I suspect my ill-fated changes changed the
start-domain from a warning to a solid error thus illuminating the bug
in the devtests themselves.
=================================================
Lessons Learned:
Modifying any code that has "public" or "protected" in it is
treacherous! /Note that protected is exactly as bad as public/. It is
virtually impossible to find all possible users -- e.g. what if a
project is pulled in as a binary but the source is dependent on the
public thing you just changed. The safest course is to chisel the
public or protected into stone and never remove it or change
signatures. Avoiding making methods protected or public is a wise course.
In my case I did not change the public signatures but I "improved" the
behavior just a bit. Big mistake. Very treacherous waters!