request to change appdb message
Hi, since a few weeks the following message is displayed when you try to submit test results into appdb: Please DO NOT include crash or Wine debug output. Instead report the crash as a bug in the Wine bugzilla at http://bugs.winehq.org. We ask that you use bugzilla because developers do not monitor the AppDB for bugs. I'm not that happy with this message for a few reasons: 1. Most testers will not attach this to a bug, either because there isn't an entry for the app in bugzilla, or they don't bother to do so. 2. There are crashes like these that users attach: wine app.exe err:module:import_dll Library MSVBVM60.DLL (which is needed by L"C:\\app.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" failed, status c0000135 We don't want users to attach these things in bugzilla, we'd rather point them what to do in the email-field. If users don't attach crashes anymore to the testresults , i cannot by no means see anymore if a testresult is valid or not. I'd rather see something like: Please DO include crash or Wine debug output here, and report the crash as a bug in the Wine bugzilla at http://bugs.winehq.org. Any comments? --------------------------------- Yahoo! Answers - Get better answers from someone who knows. Tryit now.
Me and Chris Morgan changed it to this because we were sick of people pasting pages and pages of terminal output into the What works or What doesn't work boxes of the test data which is NOT where it belongs. The information in test data should be written in plain English, not pastes of lots of (mostly useless) terminal output which just looks awful and isn't any use to most users of the AppDB. I agree with point 2 but the problem is most AppDB submitters just... too stupid to be able to use some sense or judgement about what they are asked to actually put in the test reports. What you'd rather change it to would make the previous situation much, much worse so under no circumstances should it be changed to that though. Ben H. Louis. Lenders wrote:
Hi, since a few weeks the following message is displayed when you try to submit test results into appdb:
*Please DO NOT include crash or Wine debug output. Instead report the crash as a bug in the Wine bugzilla at http://bugs.winehq.org <http://bugs.winehq.org/>. We ask that you use bugzilla because developers do not monitor the AppDB for bugs.
I'm not that happy with this message for a few reasons:
1. Most testers will not attach this to a bug, either because there isn't an entry for the app in bugzilla, or they don't bother to do so.
2. There are crashes like these that users attach: wine app.exe err:module:import_dll Library MSVBVM60.DLL (which is needed by L"C:\\app.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" failed, status c0000135
We don't want users to attach these things in bugzilla, we'd rather point them what to do in the email-field. If users don't attach crashes anymore to the testresults , i cannot by no means see anymore if a testresult is valid or not.
I'd rather see something like:
**Please DO include crash or Wine debug output here, and **report the crash as a bug in the Wine bugzilla at http://bugs.winehq.org <http://bugs.winehq.org/>**.
Any comments? *
------------------------------------------------------------------------ Yahoo! Answers - Get better answers from someone who knows. Try it now <http://uk.answers.yahoo.com/;_ylc=X3oDMTEydmViNG02BF9TAzIxMTQ3MTcxOTAEc2VjA21haWwEc2xrA3RhZ2xpbmU>.
------------------------------------------------------------------------
Ben Hodgetts (Enverex <ben <at> atomnet.co.uk> writes:
Me and Chris Morgan changed it to this because we were sick of people pasting pages and pages of terminal output into the What works or What doesn't work boxes of the test data which is NOT where it belongs. The information in test data should be written in plain English, not pastes of lots of (mostly useless) terminal output which just looks awful and isn't any use to most users of the AppDB.
I agree with point 2 but the problem is most AppDB submitters just... too stupid to be able to use some sense or judgement about what they are asked to actually put in the test reports.
What you'd rather change it to would make the previous situation much, much worse so under no circumstances should it be changed to that though.
Ben
Then i would vote for a kind of extra field in which users can paste their crash/debug output , but that field wouldn't get sent into the appdb. Something like that should be possible i guess. Otherwise i fear in many cases i cannot really judge if the test result lots are valid or not......
On 6/28/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote:
Ben Hodgetts (Enverex <ben <at> atomnet.co.uk> writes:
Me and Chris Morgan changed it to this because we were sick of people pasting pages and pages of terminal output into the What works or What doesn't work boxes of the test data which is NOT where it belongs. The information in test data should be written in plain English, not pastes of lots of (mostly useless) terminal output which just looks awful and isn't any use to most users of the AppDB.
I agree with point 2 but the problem is most AppDB submitters just... too stupid to be able to use some sense or judgement about what they are asked to actually put in the test reports.
What you'd rather change it to would make the previous situation much, much worse so under no circumstances should it be changed to that though.
Ben
Then i would vote for a kind of extra field in which users can paste their crash/debug output , but that field wouldn't get sent into the appdb. Something like that should be possible i guess. Otherwise i fear in many cases i cannot really judge if the test result lots are valid or not......
How do you normally judge if the result is valid or not? What if the result says that everything works? It seems like any result could be faked, and we can't reject a test result from a user that had problems just because a handful of other users didn't. What else can we do with the issue you raised in #1? If users report their app doesn't work but don't report the crash data then at least we know the app doesn't work and thats valuable data. If it is too difficult to report bugs in bugzilla we should see if there are ways to assist with this. For instance we could have an option on the test submission page of the appdb where a user could submit a new bug by attaching the crash log and this bug would be linked to the application/version they were submitting the test results for and also noted in the text of the test result. Duplicating crash/bug reports in the appdb seems the opposite of where we should be heading. I'm not entirely sure what your point #2 is. You are arguing that we want to see crash results in test submissions because then we can reply with a suggestion about how to fix the issue? It seems like this is exactly the kind of thing we want in bugzilla since it reflects issues users have with Wine. In the example you used in #2 it seems like the issue is that the application wasn't installed under Wine. I'd recommend that in the cases where wine can't find dlls that we popup a dialog box and suggest that the user install the application under wine and that this should install the required dlls. If this dll is something wine needs to ship with then this is a legit bug and should go in bugzilla. I guess my point about #2 is that assuming the user didn't do something really crazy, the issues the user has tend to be deficiencies in wine or its documentation and these really are legitimate issues that should be addressed. Chris
Chris Morgan <chmorgan <at> gmail.com> writes:
How do you normally judge if the result is valid or not? What if the result says that everything works?
Basically i'm only talking about garbage test results. If the app is gold/platinum there's of course no need to paste debug output
It seems like any result could be faked, and we can't reject a test result from a user that had problem just because a handful of other users didn't.
Yeah, i agree, there's no way to solve that.
What else can we do with the issue you raised in #1? If users report their app doesn't work but don't report the crash data then at least we know the app doesn't work and thats valuable data. If it is too difficult to report bugs in bugzilla we should see if there are ways to assist with this.
I don't think it's too difficult, most users just don't bother to do this.
I'm not entirely sure what your point #2 is. You are arguing that we want to see crash results in test submissions because then we can reply with a suggestion about how to fix the issue? It seems like this is exactly the kind of thing we want in bugzilla since it reflects issues users have with Wine.
Unfortunately , if anyone would open a bug with the example
i gave in issue #2,it would be closed immediately with a comment "Invalid" -> "Closing".
I guess my point about #2 is that assuming the user didn't do something really crazy, the issues the user has tend to be deficiencies in wine or its documentation and these really are legitimate issues that should be addressed.
Yeah, so maybe we could add a list of "Common failures" to the documention, with the solution. I can live with that. Then we could point garbage test submitters to that page. That would be a nice work around. I'll have to figure out how wiki works, and then i could give it a shot lateron i guess. Something like: Problem: err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" failed,status c0000135 Solution: winetricks vcrun60 or Problem: wine app.exe err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:CoGetClassObject no class object {00000514-0000-0010-8000-00aa006d2ea4}could be created for context 0x5 Unhandled page fault etc......... Solution: winetricks mdac27 Would that be something useful? Cheers, Louis
On 6/29/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote:
Chris Morgan <chmorgan <at> gmail.com> writes:
How do you normally judge if the result is valid or not? What if the result says that everything works?
Basically i'm only talking about garbage test results. If the app is gold/platinum there's of course no need to paste debug output
It seems like any result could be faked, and we can't reject a test result from a user that had problem just because a handful of other users didn't.
Yeah, i agree, there's no way to solve that.
What else can we do with the issue you raised in #1? If users report their app doesn't work but don't report the crash data then at least we know the app doesn't work and thats valuable data. If it is too difficult to report bugs in bugzilla we should see if there are ways to assist with this.
I don't think it's too difficult, most users just don't bother to do this.
I'm not entirely sure what your point #2 is. You are arguing that we want to see crash results in test submissions because then we can reply with a suggestion about how to fix the issue? It seems like this is exactly the kind of thing we want in bugzilla since it reflects issues users have with Wine.
Unfortunately , if anyone would open a bug with the example
i gave in issue #2,it would be closed immediately with a comment "Invalid" -> "Closing".
I guess my point about #2 is that assuming the user didn't do something really crazy, the issues the user has tend to be deficiencies in wine or its documentation and these really are legitimate issues that should be addressed.
Yeah, so maybe we could add a list of "Common failures" to the documention, with the solution. I can live with that. Then we could point garbage test submitters to that page. That would be a nice work around. I'll have to figure out how wiki works, and then i could give it a shot lateron i guess.
Something like:
Problem: err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" failed,status c0000135
Solution: winetricks vcrun60
or
Problem: wine app.exe err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:CoGetClassObject no class object {00000514-0000-0010-8000-00aa006d2ea4}could be created for context 0x5 Unhandled page fault etc.........
Solution: winetricks mdac27
Would that be something useful?
This sounds like a good idea. What about this nutty implementation. Why not come up with some logic to scan the contents of test results that a user is attempting to submit to the appdb? We could pass them through the scanner and repost the test result with additional comments that would try to address the users issues or at least point them at the faq. This would require a minor amount of php hacking but if you wanted to help out on the php code for the logic and suggestions I could get the architecture in place. The logic portion should be pretty simple, compared to knowing where to integrate things. Also note that we use a test suite with the appdb that can be run from the command line. This would let us save several example pieces of text to test that we respond reasonably to different issues. What do you think? Chris
On 6/29/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote:
Yeah, so maybe we could add a list of "Common failures" to the documention, with the solution. I can live with that. Then we could point garbage test submitters to that page. That would be a nice work around. I'll have to figure out how wiki works, and then i could give it a shot lateron i guess.
Something like:
Problem: err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" failed,status c0000135
Solution: winetricks vcrun60
or
Problem: wine app.exe err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:CoGetClassObject no class object {00000514-0000-0010-8000-00aa006d2ea4}could be created for context 0x5 Unhandled page fault etc.........
Solution: winetricks mdac27
Would that be something useful?
Cheers, Louis
Well, yeah. But the maintainer should be doing that already using appdb notes based on his own knowledge or reading test reports. The maintainer already screens the reports. So I can't see why we need to be more automatic. However we should set up a wiki for common problems or procedures so the maintainer can link to them from the notes.
On 6/29/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote:
On 6/29/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote:
Yeah, so maybe we could add a list of "Common failures" to the documention, with the solution. I can live with that. Then we could point garbage test submitters to that page. That would be a nice work around. I'll have to figure out how wiki works, and then i could give it a shot lateron i guess.
Something like:
Problem: err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" failed,status c0000135
Solution: winetricks vcrun60
or
Problem: wine app.exe err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:CoGetClassObject no class object {00000514-0000-0010-8000-00aa006d2ea4}could be created for context 0x5 Unhandled page fault etc.........
Solution: winetricks mdac27
Would that be something useful?
Cheers, Louis
Well, yeah. But the maintainer should be doing that already using appdb notes based on his own knowledge or reading test reports. The maintainer already screens the reports. So I can't see why we need to be more automatic.
However we should set up a wiki for common problems or procedures so the maintainer can link to them from the notes.
Checking it automatically lets us skip the round trip of submission, review, rejection and resubmission. We can check the submission and report suggestions before the user even submits the test results, thus avoiding the problem where each of our 800+ maintainers knows about those problems. Chris
On 6/29/07, Chris Morgan <chmorgan(a)gmail.com> wrote:
On 6/29/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote:
On 6/29/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote:
Yeah, so maybe we could add a list of "Common failures" to the documention, with the solution. I can live with that. Then we could point garbage test submitters to that page. That would be a nice work around. I'll have to figure out how wiki works, and then i could give it a shot lateron i guess.
Something like:
Problem: err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" failed,status c0000135
Solution: winetricks vcrun60
or
Problem: wine app.exe err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:CoGetClassObject no class object {00000514-0000-0010-8000-00aa006d2ea4}could be created for context 0x5 Unhandled page fault etc.........
Solution: winetricks mdac27
Would that be something useful?
Cheers, Louis
Well, yeah. But the maintainer should be doing that already using appdb notes based on his own knowledge or reading test reports. The maintainer already screens the reports. So I can't see why we need to be more automatic.
However we should set up a wiki for common problems or procedures so the maintainer can link to them from the notes.
Checking it automatically lets us skip the round trip of submission, review, rejection and resubmission. We can check the submission and report suggestions before the user even submits the test results, thus avoiding the problem where each of our 800+ maintainers knows about those problems.
That last sentence should have been "where each of our 800+ maintainer has to know about those problems and common solutions". Chris
Chris Morgan wrote:
On 6/29/07, Chris Morgan <chmorgan(a)gmail.com> wrote:
On 6/29/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote:
On 6/29/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote:
Yeah, so maybe we could add a list of "Common failures" to the
documention,
with the solution. I can live with that. Then we could point garbage test submitters to that page. That would be a nice work around. I'll have to figure out how wiki works, and then i could give it a shot lateron i guess.
Something like:
Problem: err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" failed,status c0000135
Solution: winetricks vcrun60
or
Problem: wine app.exe err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:CoGetClassObject no class object {00000514-0000-0010-8000-00aa006d2ea4}could be created for context 0x5 Unhandled page fault etc.........
Solution: winetricks mdac27
Would that be something useful?
Cheers, Louis
Well, yeah. But the maintainer should be doing that already using appdb notes based on his own knowledge or reading test reports. The maintainer already screens the reports. So I can't see why we need to be more automatic.
However we should set up a wiki for common problems or procedures so the maintainer can link to them from the notes.
Checking it automatically lets us skip the round trip of submission, review, rejection and resubmission. We can check the submission and report suggestions before the user even submits the test results, thus avoiding the problem where each of our 800+ maintainers knows about those problems.
That last sentence should have been "where each of our 800+ maintainer has to know about those problems and common solutions".
Chris
I think the main problem is that there is a lack of maintainers and the ones that exist seem to be mainly inactive. If they were active then there would already be notes pointing to easy fixes for the apps like NoCD patches, d3dx9xx.dll files, etc. I agree a pre-parser for common issues would be nice, but probably quite a bit of coding work and likely to get many wrong hits. It's a messy situation really. Ben H.
On 6/29/07, Ben Hodgetts <ben(a)atomnet.co.uk> wrote:
Chris Morgan wrote:
On 6/29/07, Chris Morgan <chmorgan(a)gmail.com> wrote:
On 6/29/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote:
On 6/29/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote:
Yeah, so maybe we could add a list of "Common failures" to the
documention,
with the solution. I can live with that. Then we could point garbage test submitters to that page. That would be a nice work around. I'll have to figure out how wiki works, and then i could give it a shot lateron i guess.
Something like:
Problem: err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" failed,status c0000135
Solution: winetricks vcrun60
or
Problem: wine app.exe err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} not registered err:ole:CoGetClassObject no class object {00000514-0000-0010-8000-00aa006d2ea4}could be created for context 0x5 Unhandled page fault etc.........
Solution: winetricks mdac27
Would that be something useful?
Cheers, Louis
Well, yeah. But the maintainer should be doing that already using appdb notes based on his own knowledge or reading test reports. The maintainer already screens the reports. So I can't see why we need to be more automatic.
However we should set up a wiki for common problems or procedures so the maintainer can link to them from the notes.
Checking it automatically lets us skip the round trip of submission, review, rejection and resubmission. We can check the submission and report suggestions before the user even submits the test results, thus avoiding the problem where each of our 800+ maintainers knows about those problems.
That last sentence should have been "where each of our 800+ maintainer has to know about those problems and common solutions".
Chris
I think the main problem is that there is a lack of maintainers and the ones that exist seem to be mainly inactive. If they were active then there would already be notes pointing to easy fixes for the apps like NoCD patches, d3dx9xx.dll files, etc. I agree a pre-parser for common issues would be nice, but probably quite a bit of coding work and likely to get many wrong hits. It's a messy situation really.
It isn't all that complex. It would require someone to start to collect common debug output from users and then look at how we might look for particular dlls or errors to identify the particular issue. For someone with lots of experience it wouldn't seem to be all that difficult but it really depends on how generic some errors are. Chris
I think the main problem is that there is a lack of maintainers and the ones that exist seem to be mainly inactive.
Yeah, and it's quite a tedious task to submit test-results, new versions and new apps into appdb. Maybe we need a few more active ones.
If they were active then there would already be notes pointing to easy fixes for the apps like NoCD patches, d3dx9xx.dll files, etc. I agree a pre-parser for common issues would be nice, but probably quite a bit of coding work and likely to get many wrong hits.
I'll try to give it a shot later, something like a page with "commaon failures". Could take a while though...
It isn't all that complex. It would require someone to start to collect common debug output from users and then look at how we might look for particular dlls or errors to identify the particular issue. For someone with lots of experience it wouldn't seem to be all that difficult but it really depends on how generic some errors are.
I never played with appdb code so i'm afraid i'm of no help there :(
Chris
On 6/28/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote:
Ben Hodgetts (Enverex <ben <at> atomnet.co.uk> writes:
Me and Chris Morgan changed it to this because we were sick of people pasting pages and pages of terminal output into the What works or What doesn't work boxes of the test data which is NOT where it belongs. The information in test data should be written in plain English, not pastes of lots of (mostly useless) terminal output which just looks awful and isn't any use to most users of the AppDB.
I agree with point 2 but the problem is most AppDB submitters just... too stupid to be able to use some sense or judgement about what they are asked to actually put in the test reports.
What you'd rather change it to would make the previous situation much, much worse so under no circumstances should it be changed to that though.
Ben
Then i would vote for a kind of extra field in which users can paste their crash/debug output , but that field wouldn't get sent into the appdb. Something like that should be possible i guess. Otherwise i fear in many cases i cannot really judge if the test result lots are valid or not......
No, I don't agree. Bug reports should be filed when the user has a crash or problem and a log to go along with it. I started asking people a long time ago to not paste logs anywhere on my appdb pages. I don't want a scroll bar the size of a flea which can happen with just one poor log. Honestly, for a test report, a comment like: "X doesn't work correctly. Filed bug report: bug Y" would be wonderful. I've been slowly pruning all the comments with logs on my page too. Hope that doesn't upset anyone.
participants (6)
-
Ben Hodgetts -
Ben Hodgetts (Enverex)
-
Chris Morgan -
Jesse Allen -
Louis Lenders -
Louis. Lenders