Heya
Sprint planning meeting is later today, so I thought it'd be good to
list some issues that I think should be tackled soon:
Low hanging fruits
VWR-12984 <https://jira.secondlife.com/browse/VWR-12984> Water
flickers and disappears in patches
* Very annoying and high-voted bug, especially apparent in skyboxes
* Has been fixed in Snowglobe 1 half a year ago
* Fix has been ported to Snowglobe 2 this summer (see SNOW-643
<https://jira.secondlife.com/browse/SNOW-643>)
* Merov ported the fix to viewer-development recently, so the code
'only' needs some review. (The change is huge, though.)
VWR-19643 <https://jira.secondlife.com/browse/VWR-19643> /
STORM-312 <https://jira.secondlife.com/browse/STORM-312> linux
libndofdev version <= 0.2 incompatible to kernel >=2.6.33
* This has been fixed upstream (linux libndofdev version 0.3), so
just using the newer library version will resolve this.
* The upstream fix is
o a small and easy to understand change (thus low-risk)
o backwards compatible (will continue working with kernels <=
2.6.32)
o well tested (I'm using it for months now)
* Please note that ---while serving the same purpose--- linux
libndofdev is a different project than the windows/mac library of
the same name, and thus has different version numbers.
VWR-23459 <https://jira.secondlife.com/browse/VWR-23459> Viewer
compiled against Boost-1.42 crashes when certain command line
options are given
* Fixed in Snowglobe 1 and 2 this summer (see SNOW-626
<https://jira.secondlife.com/browse/SNOW-626>)
* Fix already ported to viewer-development (needs testing and
review, but the change is small)
* As far as I know, this is the only thing left for
viewer-development to become fully compatible with Boost 1.42
* Fix is backwards compatible
Features I'd personally would like to work on
VWR-22044 <https://jira.secondlife.com/browse/VWR-22044> Option
to inline Navigation Bar into Menu Bar
* Needs product manager approval
VWR-23306 <https://jira.secondlife.com/browse/VWR-23306> Detect
UI skins at runtime
* Needs some discussion: As skins can change functionality (to some
extend) or change how/where certain functionality is accessible,
we need ways to avoid this feature to become a major problem for
customer support.
* Some code by Robin Cornelius that's related to this has been
annexed by some LL-internal project and she was asked not to
publish it to avoid merge problems. In order to avoid duplication
of efforts (and probably even worse merge problems), can this
project please be opened up? If not, it'd be good to release at
least sufficient information to make some collaboration on this
topic possible.
(no particular jira issue yet) Coding Standard application /
code cleanup
Our current code still violates our own coding standard
<https://wiki.secondlife.com/wiki/Coding_standard> a lot. Then there is
unnecessary code (like derived classes re-implementing inherited methods
in the exact same way the base class already implemented it) and maybe
even still dead code (got rare, I think). I'll file jira issues for
stuff like this as I get to do it. Could issues of this sort be allowed
to be added to the current sprint list even during a sprint? It makes
little sense to have such changes pile up until the respective next
sprint is started.
(no jira issue) Improve the Coding Standard
What's the process for changing the coding standard? Sure, I could just
edit the wiki page, but because all will have to follow it, making
substantial changes needs consensus and warrants some discussion.
Cheers,
Boroondas
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
