On Jan 26, 2013, at 4:50 AM, Chris Hegarty wrote:
>> To be clear I'm not saying this can't happen. I'm just saying that the right
>> people need to ensure that all the necessary pieces are in place, and the
>> procedures established before we actually start doing it on a regular basis.
>
> Yes, I agree.
I agree vigorously with David about the high risk and cost of flag days. If
your job as an individual engineer is complicated 10x by the cost of avoiding a
flag day, it is still well worth the effort.
I will say this: It shouldn't happen very often at all. The last 292 flag day
involved 10,000's of LOC, replacing an old implementation by a new one. It was
also very expensive and difficult and distracting to manage. It required 10's
of engineers throughout the engineering pipeline to pay special attention, for
days. It caused semi-expected regressions and hiccups in the backport
processes. It required SQE to know when *not* to pay attention to certain
regressions.
This is so totally not worth it for almost all changes! One engineer with a
little cleverness can figure out a way to make the micro-version matrix pass
nightly tests. (That's at least three of {jdk0,jdk1}x{jvm0,jvm1}.) It makes
ugly code, but that is far preferable to ugly process adventures. Mark the
code as "FIXME: clean up after ..." and then trust that, if it's important, it
will get cleaned up.
The 292-scoped JDK changes are a special case also, which has been discussed at
length elsewhere. It requires a lot of groundwork laying, and a significant
"teething process" until everybody knows that stuff is coming from that
direction. It is not a cut-and-paste-your-own type of process.
Having been this this micro-version matrix many times with 292, I can point out
some useful tricks for making things work out; just ask. (1-1 mail probably
works best for that sort of question.)
— John
P.S. This is mostly FTR. For the problem at hand, Eric tells me he already
thought of a suitable "trick". Yay!
