[sldev][META] Release Candiate Cycles (was 1.18.2.1 source code)

[Joshua Bell]

Nicholaz Beresford wrote:
> From what I've seen with 18.3 RC I'd expect that the work (fixes) get
> progressively less ... at least the source diffs between each of the
> RC iterations were smaller and smaller.
Yes, that's the idea. I like to think of any build having a certain 
amount of "risk" associated with it. Having QA look at a build reduces 
the risk. Having public eyeballs (in an RC, code drop) reduces risk. 
Code changes of any sort increase risk (usually proportional to the size 
of the change).  Even hitting the "rebuild" button introduces risk - how 
deterministic is your compiler, linker, and packager? Risk is never zero.

The desire is to always be reducing risk and increasing quality, but 
those don't go hand in hand - in fact, they can be opposing. A feature 
that doesn't work correctly is low quality, but if it's had sufficient 
time in QA, public previews, etc. it can be low risk. (i.e. low chance 
of causing data loss, etc). Attempting to fix the feature changes the 
code and therefore increases the risk! Then again, shipping broken 
features is generally considered bad... but I'd rather ship a feature 
that was known broken but also known to not erase your data. Balancing 
this is the point of triage.
> How are you doing that practically?  I guess theoretically you'd merge
> fixes into a 18.4 branch now and as soon as the RC goes gold, a new
> 18.4 RC should be waiting in the wings and an 18.5 ready to branch for
> merging postponed fixes/patches?
Basically, we have our trunk (the ill named "release"). At some point we 
branch off of that and create an RC branch, "Branch_1-18-3-Viewer". We 
stabilize that with RC bugfixes. Meanwhile, other features and fixes are 
going into "release". Patches made into the RC branch also get 
propagated into "release". Once the particular release "goes gold", we 
take a vacation on a tropical island for a few days (ha!), then come 
back and repeat the process.

So right now, for example, 1.18.4 doesn't exist in any form distinct 
from the trunk (and hand-wavy discussions). Given infinite resources, we 
could carve 1.18.4 off even before 1.18.3 goes gold, and be stabilizing 
that in parallel with the ever-*decreasing* amount of work going on with 
1.18.3 (as the rate of change slows to a trickle). But in practice we're 
balancing both server and viewer releases and doing QA on individual 
features so we'll let the previous release finish before we lock down 
1.18.4.