On 6/29/07, Ben Hodgetts ben@atomnet.co.uk wrote:
Chris Morgan wrote:
On 6/29/07, Chris Morgan chmorgan@gmail.com wrote:
On 6/29/07, Jesse Allen the3dfxdude@gmail.com wrote:
On 6/29/07, Louis Lenders xerox_xerox2000@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