[sldev] Closing out the merge window

[Mike Monkowski]

Melinda Green wrote:
> That's a great question. Even though in theory this could be a 
> continuous release process, there are some practical reasons to do it in 
> cycles. The main reason is that during the normal phase where features 
> are added and changed, we will naturally introduce bugs that tend to 
> accumulate over time. The stabilization phases bring the bug levels down 
> to acceptable levels. If it ever turned out code quality stayed high 
> enough throughout development then you could make a great case for 
> skipping this bit of protocol but I doubt that will ever happen and I 
> think that's OK.

You're working from a paradigm different from any that I have known.  To 
say, "that during the normal phase where features are added and changed, 
we will naturally introduce bugs that tend to accumulate over time" is 
astounding to me.  Who lets bugs accumulate over time?

If you assume that you're going to start with dirty code and hope to 
clean it up when you get a chance, you're kidding yourself.  You should 
start with clean, well reviewed code and expect bugs caused by 
interactions to be fixed over time.  If you tolerate junk, you'll get junk.

> Another good reason for having release cycles is so that other parties 
> can plan around them. One such party is LL who will want to cherry-pick 
> from highly stable versions in order to inherit the fewest bugs in the 
> process. Another party is the casual user who will only be willing to 
> upgrade occasionally and will want to know which versions to grab. Yet 
> another party is you!  :-)  Your private branch or copy that you work in 
> will drift from the main Snowglobe branch and if your do a substantial 
> (i.e. destabilizing) amount of work, you will want to merge approved 
> changes back to Snowglobe when it is in a most stable phase so that the 
> problems you introduce are most easily fixed. Even if you only intend to 
> make small, infrequent changes, you will want to do that work when 
> Snowglobe is most stable.

Snowglobe is alpha code.  It's not a competitor to the production 
viewer.  Each new feature will stabilize over time, but there's no need 
to stabilize the entire set of features, because the entire set will 
never be merged at once into the production viewer.  You're not pulling 
files from Snowglobe, you're just pulling the changesets.

If you want stablity, you work with the production viewer source, not 
Snowglobe.  Any way you do it, you'll have to eventually merge back into 
code that's constantly changing.

If Snowglobe is ever stable, it means people no longer are contributing.

> I don't think that having a release cycle fragments a product. It simply 
> regularizes the natural ebb and flow of quality and lets people plan 
> around it. It's fine if we decide that Snowglobe's quality does not need 
> to be as high as the main LL viewer (at the points where *its* quality 
> is highest in its cycle). We just need to decide what our quality 
> standard should be and then adjust the length of our stabilization 
> phases in order to hit that target.

I meant that it fragmented the audience of alpha testers.  If you accept 
an ebb and flow of quality, be prepared for more ebb than flow.  The 
standard should be "clean in," because the alternative is "garbage in; 
garbage out."

Mike