Re: request to change appdb message

[Louis Lenders]

> > >
> > 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
> 
> 

Re: request to change appdb message

[Chris Morgan]

On 6/29/07, Ben Hodgetts <[EMAIL PROTECTED]> wrote:

Chris Morgan wrote:
> On 6/29/07, Chris Morgan <[EMAIL PROTECTED]> wrote:
>> On 6/29/07, Jesse Allen <[EMAIL PROTECTED]> wrote:
>> > On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> 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 c135
>> > >
>> > > Solution:
>> > > winetricks vcrun60
>> > >
>> > > or
>> > >
>> > > Problem:
>> > > wine app.exe
>> > > err:ole:CoGetClassObject class
>> {0514--0010-8000-00aa006d2ea4}
>> > > not registered
>> > > err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
>> > > not registered
>> > > err:ole:CoGetClassObject no class object
>> > > {0514--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

Re: request to change appdb message

[Ben Hodgetts]

Chris Morgan wrote:

On 6/29/07, Chris Morgan <[EMAIL PROTECTED]> wrote:

On 6/29/07, Jesse Allen <[EMAIL PROTECTED]> wrote:
> On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> 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 c135
> >
> > Solution:
> > winetricks vcrun60
> >
> > or
> >
> > Problem:
> > wine app.exe
> > err:ole:CoGetClassObject class 
{0514--0010-8000-00aa006d2ea4}

> > not registered
> > err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
> > not registered
> > err:ole:CoGetClassObject no class object
> > {0514--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.

Re: request to change appdb message

[Chris Morgan]

On 6/29/07, Chris Morgan <[EMAIL PROTECTED]> wrote:

On 6/29/07, Jesse Allen <[EMAIL PROTECTED]> wrote:
> On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> 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 c135
> >
> > Solution:
> > winetricks vcrun60
> >
> > or
> >
> > Problem:
> > wine app.exe
> > err:ole:CoGetClassObject class {0514--0010-8000-00aa006d2ea4}
> > not registered
> > err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
> > not registered
> > err:ole:CoGetClassObject no class object
> > {0514--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

Re: request to change appdb message

[Chris Morgan]

On 6/29/07, Jesse Allen <[EMAIL PROTECTED]> wrote:

On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> 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 c135
>
> Solution:
> winetricks vcrun60
>
> or
>
> Problem:
> wine app.exe
> err:ole:CoGetClassObject class {0514--0010-8000-00aa006d2ea4}
> not registered
> err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
> not registered
> err:ole:CoGetClassObject no class object
> {0514--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

Re: request to change appdb message

[Jesse Allen]

On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> 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 c135

Solution:
winetricks vcrun60

or

Problem:
wine app.exe
err:ole:CoGetClassObject class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:CoGetClassObject no class object
{0514--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.

Re: request to change appdb message

[Chris Morgan]

On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> wrote:

Chris Morgan  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 c135

Solution:
winetricks vcrun60

or

Problem:
wine app.exe
err:ole:CoGetClassObject class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:CoGetClassObject no class object
{0514--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

Re: request to change appdb message

[Louis Lenders]

Chris Morgan  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 c135

Solution:
winetricks vcrun60

or

Problem:
wine app.exe
err:ole:CoGetClassObject class {0514--0010-8000-00aa006d2ea4} 
not registered
err:ole:create_server class {0514--0010-8000-00aa006d2ea4} 
not registered
err:ole:CoGetClassObject no class object
{0514--0010-8000-00aa006d2ea4}could be created for 
context 0x5
Unhandled page fault etc.

Solution:
winetricks mdac27

Would that be something useful?

Cheers, Louis

Re: request to change appdb message

[Jesse Allen]

On 6/28/07, Louis Lenders <[EMAIL PROTECTED]> wrote:

Ben Hodgetts (Enverex  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.

Re: request to change appdb message

[Chris Morgan]

On 6/28/07, Louis Lenders <[EMAIL PROTECTED]> wrote:

Ben Hodgetts (Enverex  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

Re: request to change appdb message

[Louis Lenders]

Ben Hodgetts (Enverex  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.. 

Re: request to change appdb message

[Ben Hodgetts (Enverex)]

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 
. 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 c135


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. Try it now 
. 





  

request to change appdb message

[Louis. Lenders]

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 c135

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.