[sldev] Re: Feature freeze

[Matthew Dowd]

> >>> 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.
Hang on - not that I'm opposed to  rebalancing of features versus bug fixing with a much stronger balance on fixing things, but those particular words are Robin Cornelius's (I think) not mine!
 > 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!)
 
Well no project has no known bugs - but the number of severe and longstanding bugs in SL at the moment would really place it the quality of alpha or early beta!
 
The impression from outside LL is that bugs can reported, acknowledged, imported assigned an internal id, and then stagnate ignored!
 
A good example of the impression that LL just ignores bugs was Torley closing a lot of windlight bugs when windlight moved into the RC as "needs more info - please confirm these are still an issue with the RC", many of which were so trivial to confirm that it would have take someone less than a day to check (and some would have been obvious as not fixed by anyone using the RC). Combined with the fact that the way these were closed (a background script?) meant none of the watchers or reporter got any notification, doesn't help convince people LL takes bug fixing seriously.
 > > 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.
A total feature freeze is a little unrealistic, admittedly - however, the impression at the moment is that a bug doesn't get fixed unless it is addressed as a side effect of a new feature! (or picked up by the external open source community. We need some (visiable) Lindens dedicated to working through the bug backlog (and also from the sounds of things, the patch backlog too). Some would argue that this should have happened before forcing people onto the 1.19 line.
 > > 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 don't think any of the external open sources disagree a refactor is long overdue and necessary. However, no-one in the external community is likely to put the amount of effort required without some pretty cast iron assurance from LL that it will be incorporated into the code. There is also the practical logistics of doing this, since without access to the LL internal source repository any binary/source drop from LL would often result in the large amount of the work having to be redone. Unless/untill LL allows public access to their internal source repository (and perhaps even then), this is something LL needs to take a lead on.
 
Matthew
_________________________________________________________________
The next generation of Windows Live is here
http://www.windowslive.co.uk/get-live
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080408/ada62423/attachment.htm