I'm done with one step of the changes.
See the following URLs for how things currently look: http://bugs.winehq.org/describekeywords.cgi http://bugs.winehq.org/describecomponents.cgi?product=Wine
Improvement suggestions are welcome.
Does anyone know how the CVS/GIT version is marked so that it gets selected on the new bug page and if that is also possible for the component?
Now for further improvements:
Changes which IMHO should not be done: wine-help -> hhctrl - Help viewer implementation help is currently not for the various help APIs but for user that want help. We should obsolete this component. We can create a new component for the help APIs if there is demand. (new) -> vdm - Wine 16-bit compatibility layer (new) -> win16 - Wine 16-bit compatibility layer vdm is part of the component dos, right? A win16 keyword is probably useful as win16 support is intertwined in quite some other DLLs and thus components.
Components that are marked as obsolete now, but where it's not sure how to replace them: multimedia Should we really replace this? Replace it with what? An mci and winmm component? console I didn't really made my mind up about this one yet... files ipc ports winelib Possibly replace each with a keyword, see below.
Changes to the keywords: conformance (delete) Delete this keyword, because it fits probably most wine bugs. testcase (new) Bugs that have a testcase attached, in source form but not necessarily integrated into the Wine test suite. win16 (new) Bugs in the win16 parts of Wine. dotnet (new) Bugs that appear in applications using dotNet and that are related to this dotNet useage. winelib (new) Bugs during winelib useage but not during useage through windows native executables. ports (new) Bugs regarding porting to specific platforms or OSs. FIXME needs clarification tasklet needs clarification tasklist needs clarification Abandoned? -> needmoreinfo This is currently discussed in another thread. filesystem (new) Do we want such a component? Is it maybe related with console? What exactly should it cover? Only things that possibly can destroy data? console (new) I didn't really made my mind up about this one yet...
Jan
On Jan 6, 2008 9:55 AM, Jan Zerebecki jan.wine@zerebecki.de wrote:
I'm done with one step of the changes.
See the following URLs for how things currently look: http://bugs.winehq.org/describekeywords.cgi http://bugs.winehq.org/describecomponents.cgi?product=Wine
Improvement suggestions are welcome.
Does anyone know how the CVS/GIT version is marked so that it gets selected on the new bug page and if that is also possible for the component?
Now for further improvements:
Changes which IMHO should not be done: wine-help -> hhctrl - Help viewer implementation help is currently not for the various help APIs but for user that want help. We should obsolete this component. We can create a new component for the help APIs if there is demand.
There is demand. Using the now _obsolete_help keyword, there are 7 bugs relating to the help APIs.
(new) -> vdm - Wine 16-bit compatibility layer (new) -> win16 - Wine 16-bit compatibility layer vdm is part of the component dos, right? A win16 keyword is probably useful as win16 support is intertwined in quite some other DLLs and thus components.
Components that are marked as obsolete now, but where it's not sure how to replace them: multimedia Should we really replace this? Replace it with what? An mci and winmm component?
Yes it should be replaced with the appropriate components, whichever Dlls they belong to. We can start arranging those and then remove the component when that's done.
console I didn't really made my mind up about this one yet...
Yes, the bug is either in wine-programs (wineconsole) or the console APIs, kernel32.
files ipc ports winelib Possibly replace each with a keyword, see below.
Changes to the keywords: conformance (delete) Delete this keyword, because it fits probably most wine bugs. testcase (new) Bugs that have a testcase attached, in source form but not necessarily integrated into the Wine test suite. win16 (new) Bugs in the win16 parts of Wine. dotnet (new) Bugs that appear in applications using dotNet and that are related to this dotNet useage. winelib (new) Bugs during winelib useage but not during useage through windows native executables. ports (new) Bugs regarding porting to specific platforms or OSs. FIXME needs clarification tasklet needs clarification tasklist needs clarification Abandoned? -> needmoreinfo This is currently discussed in another thread. filesystem (new) Do we want such a component? Is it maybe related with console? What exactly should it cover? Only things that possibly can destroy data? console (new) I didn't really made my mind up about this one yet...
Jan
On Sun, Jan 06, 2008 at 11:42:19AM -0700, James Hawkins wrote:
On Jan 6, 2008 9:55 AM, Jan Zerebecki jan.wine@zerebecki.de wrote:
Changes which IMHO should not be done: wine-help -> hhctrl - Help viewer implementation help is currently not for the various help APIs but for user that want help. We should obsolete this component. We can create a new component for the help APIs if there is demand.
There is demand. Using the now _obsolete_help keyword, there are 7 bugs relating to the help APIs.
_obsoletet_help is a component. Should we perhaps add a keyword "helpapis"?
Jan
On Jan 13, 2008 8:41 AM, Jan Zerebecki jan.wine@zerebecki.de wrote:
On Sun, Jan 06, 2008 at 11:42:19AM -0700, James Hawkins wrote:
On Jan 6, 2008 9:55 AM, Jan Zerebecki jan.wine@zerebecki.de wrote:
Changes which IMHO should not be done: wine-help -> hhctrl - Help viewer implementation help is currently not for the various help APIs but for user that want help. We should obsolete this component. We can create a new component for the help APIs if there is demand.
There is demand. Using the now _obsolete_help keyword, there are 7 bugs relating to the help APIs.
_obsoletet_help is a component. Should we perhaps add a keyword "helpapis"?
No, the winhelp API is in user32 and winhelp.exe is under programs. We do need an hhctrl.ocx component though.
-
Detlef Riekenberg -
James Hawkins -
Jan Zerebecki