Component list rewrite

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?

-- 
With best regards
Caemyr

[Thomas Faber]

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(a)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?

[Thomas Faber]

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.

[Timo Kreuzer]

Am 12.09.2012 17:35, schrieb Thomas Faber:
>   (note that "module" is in planning as a
> separate field) 
This one should be either a string that can contain multiple module 
names or even better something similar to labels.

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 

-- 
With best regards
Caemyr

[Timo Kreuzer]

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 

-- 
With best regards
Caemyr