One thing to keep in mind is that the release process that we are
talking about will result in a snowglobe build which is made available
to people on secondlife.com/download, which is a much larger (hopefully)
audience than has ever used an open source Second Life build before.
Hence the desire to make reasonably sure it is stable and safe.
P
Mike Monkowski wrote:
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
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
