[sldev] Re: Feature freeze

[Paul Oppenheim (Poppy Linden)]

>>> On Mon, Apr 7, 2008 at 2:46 PM, Matthew Dowd <matthew.dowd at hotmail.co.uk> wrote:
>>> It would be really cool if we could feature freeze for a little while
>>> and chase some bugs out of the system to get things really stable
>>> before adding more new things.

I can see the appeal of the idea, but that doesn't seem feasible for this project. Consider some of the long-term branches now reaching completion. Would we just shelf LSL refactoring until everyone is happy, then resume? That is to say, should studio blighty spend the next quarter hunting bugs in the soon-to-be obsolete LSL runtime? (That is also to say, would you be the one who would tell Babbage and Scouse? I know Scouse could take me on by himself, I'm not gonna tell him that.)

> Henri Beauchamp wrote:
>> Yes, pretty please, DO feature freeze SL and DO hunt down every known bug
>> before resuming the development of new features.

Can you tell me a project that has no known bugs? Can you tell me the development lifecycle, budget, and business model of that software?
(I want to know how to do that!)

Lawson English wrote:
> Well, some bugs and source code oddities in the graphics subsystem were 
> automatically fixed/corrected by the Windlight team, so its 
> counter-productive to say "no new features" when new features are going 
> to fix certain bugs/issues for free as part of deploying said new feature.

*** THANK YOU! ***

There's quite a bit more of that on the horizon, as you probably know.

> An even more drastic proposal on MY part is to refactor the  client with 
> clean divisions of the GUI and the other subsystems, but for some 
> reason, few programmers who contribute to SL apparently see a need for 
> this...

... and that makes me a Sad Panda.

I recently tried to push internally for this. I got kinda deflected, because we have plenty of other APIs yet to design / code that we've already promised. (hello, AWG!) I'd *love* to see this as the first step toward moving forward on that viewer plugin SDK (not to be confused with a viewer scripting API) that everyone's been talking about. I don't work on the viewer now, so I'm not the best person to be rambling about this, but I do think what it would buy us alone in testing would be worth it. I know at least one Linden who could rant about how awesome automated testing becomes with an architecture like that.

Unfortunately it's really hard work for what may be seen as little benefit. A case needs to be made that a modular architecture is more important than, say, agni DB scalability, inventory loss, LSL refactoring, build system refactoring, or whatever else engineering is working on. (Contrary to belief, not everyone is working on "flashy new features" no matter how often people repeat that meme with no actual internal information.) It's also more difficult than your average task, because you're essentially developing an API, which you Better Not Screw Up.

There have been a few "viewer cleanup" branches going out which should be a step in the right direction, but aren't close to this. If you're interested and have experience doing modularizations like this, start to think about it and make some proposals. There's the AWG protocol development for the sim and grids, but no protocol working groups for the viewer. Make it happen!

+ poppy