12 Sep
2012
12 Sep
'12
3:35 p.m.
After some more discussion, here's another concrete proposal...
Issue types:
------------
(go from top to bottom when deciding which to use)
Patch = A concrete code change that should be discussed/reviewed/tested
Unimplemented = Windows has this, we don't
Bug = Something is broken and should be fixed
Improvement = Something exists/works but can be made better, given more
features etc.
Task = Any work to be done that doesn't fit in the above
Components:
-----------
audio
applications
build system [cmake files, host tools]
crt [crt, msvcrt*, stlport, ...]
3dgraphics [directx, mesa/gallium]
drivers
filesystems [can maybe go into drivers]
freeldr
include [? ddk, ndk, xdk, psdk; not sure if needed]
networking [winsock, afd, ndis, dhcp, ...]
ntcore [rtl, ntdll, ntoskrnl, hal]
plugandplay [umpnpmgr, setupapi, newdev]
security [? lsa*, sam*, secur*]
services [services.exe, svchost, rpcss, spoolsv, ...]
shell [cmd, explorer, shell32, browseui, ...]
translation
uniata
usb
win32ss [win32k, user32, gdi32, csrss, ...]
wine [libwine, dlls]
rosdlls [advapi32, kernel32, vdmdbg, userenv]
(note that "module" is in planning as a separate field)
The uniata and translation components are mostly motivated by
"default assignee" thinking; so if that can be done manually or
independently, that should be reconsidered.
I think this layout would make a good mapping to "what areas are you
interested in". E.g. a kernel dev could choose ntcore, drivers,
filesystems to get a good default filter.