[sldev] Closing out the merge window

[Philip Rosedale]

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
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090521/78e6affc/attachment.htm