Hiya
We had a little discussion tonight, regarding changes in component list. It is obvious that current list is illogical, unplanned and requires urgent changes, with Jira update this is the best oportunity. Initial plan was to base upon Timo's Layout rewrite. We had just a small trimming done - below is the result:
audio applications directx (or rather 3d graphics which would allow also mesa/gallium in) host-tools networking ntcore sdk shell usb winedlls win32core + rosdlls( | | advapi32 | | kernel32 | | crtdll | | lsasrv | | msvcrt | | msvcrt20 | | msvcrt40 | | samlib | | samsrv | | secur32 | | security | | fmifs | | vdmdbg | | userenv | | uext2 | | ufat | | ufatx | | untfs)
The problem is what to do with some ill-fitting to the current scheme, like:
| nls | services | eventlog | rpcss | services.exe | svchost | umpnpmgr | spoolsv
and more. Do you see need for more components?
Hey,
some random thoughts: - bugs are sometimes related to the build system (e.g. patches for cmake files), so that might be a more generalized version of host-tools - shell seems rather broad if it's supposed to include both explorer (+dlls) and cmd - services.exe, svchost, and actual service implementations might work in a generalized "services" component - umpnpmgr feels like it should go in a category with setupapi & newdev - translations or localization in general might be useful as a separate component -- seeing how they're usually handled by different people than code changes are - what about drivers that don't fall under usb or networking? Storage/FS might also be an interesting extra category; and perhaps uniata would even make sense separated (seeing its possible default assignee) - Rtl stuff would go under ntcore? What about CRT?
Sorry for the messy list ;)
-Thomas
On 2012-09-11 01:19, caemyr@myopera.com wrote:
Hiya
We had a little discussion tonight, regarding changes in component list. It is obvious that current list is illogical, unplanned and requires urgent changes, with Jira update this is the best oportunity. Initial plan was to base upon Timo's Layout rewrite. We had just a small trimming done - below is the result:
audio applications directx (or rather 3d graphics which would allow also mesa/gallium in) host-tools networking ntcore sdk shell usb winedlls win32core
rosdlls( | | advapi32 | | kernel32 | | crtdll | | lsasrv | | msvcrt | | msvcrt20 | | msvcrt40 | | samlib | | samsrv | | secur32 | | security | | fmifs | | vdmdbg | | userenv | | uext2 | | ufat | | ufatx | | untfs)
The problem is what to do with some ill-fitting to the current scheme, like:
| nls | services | eventlog | rpcss | services.exe | svchost | umpnpmgr | spoolsv
and more. Do you see need for more components?
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.
Module is intended to be a separate, label-like field.
Regarding UNIATA - i`m concerned about this, since its a module more than component. Automatic assigning is in my opinion rather a problem than bonus - Alter should be assigned to verified bugs only, not to every of which reporter picks Uniata from the list. He should not be hindered by bug verification, this is our task. To sum up:
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] rosdlls [advapi32, kernel32, vdmdbg, userenv] security [? lsa*, sam*, secur*] services [services.exe, svchost, rpcss, spoolsv, ...] shell [cmd, explorer, shell32, browseui, ...] translation usb win32ss [win32k, user32, gdi32, csrss, ...] wine [libwine, dlls]
On Wed, Sep 12, 2012, at 07:02 PM, Timo Kreuzer wrote:
This one should be either a string that can contain multiple module names or even better something similar to labels.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
What about making the Component field editable like the labels field, so that devs can add entries on the fly and then putting modules in there as well? Maybe we can achieve to have them sorted in a way, that Uppercase names are on top (for users to select from) and lowercase names for modules below. The advantage is one field less. We should avoid adding too much stuff. The bugreport should be small, quick and easy. Not like the bugzilla crap. One field can make the difference between needing to scroll when opening a new bug or not needing to scroll.
Regards, Timo
That will block us from using a static component list. How a reporter is going to know what to put there?
On Thu, Sep 13, 2012, at 11:14 AM, Timo Kreuzer wrote:
What about making the Component field editable like the labels field, so that devs can add entries on the fly and then putting modules in there as well? Maybe we can achieve to have them sorted in a way, that Uppercase names are on top (for users to select from) and lowercase names for modules below. The advantage is one field less. We should avoid adding too much stuff. The bugreport should be small, quick and easy. Not like the bugzilla crap. One field can make the difference between needing to scroll when opening a new bug or not needing to scroll.
Regards, Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
caemyr＠myopera.com -
Thomas Faber -
Timo Kreuzer