[sldev] Re: Feature freeze

Henri Beauchamp sldev at free.fr
Tue Apr 8 11:15:29 PDT 2008


On Mon, 07 Apr 2008 20:31:36 -0700, Paul Oppenheim (Poppy Linden) wrote:

> >>> 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?

If it works, don't touch it as it would break it. If it got bugs, then
simply fix them.

And _yes_ it does mean putting every other development on hold till at least
all the identified bugs are fixed !

> > 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?

Please, do not try and twist my words: I did write _known_ bugs: look at the
JIRA: they are hundreds !!!  Way enough to keep you busy for months.

> 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! ***

Yes, thank you indeed for v1.19.1.4: a viewer that is MUCH slower than
1.19.0.5 was for (by LL's onw admission on the blog) 50% of your residents,
a viewer which slows down to a crawl (< 5fps !!!) after only one hour online
while 1.19.0.5 runs happily at 20-60fps for hours...

What is more counter-producive ?  Fixing the bugs in a well tested render
pipeline, or writing a new one, with new bugs, less speed and more
incompatibilities ?

The current headlong rush for more features is certainly not helping to
make the viewer more stable neither faster. Bloating the code only brings
more issues. You should really start to _optimize_ the code instead (and
yes, there is MUCH room for optimization in the current code).

Regards,

Henri.


More information about the SLDev mailing list