macports error reporting, stack traces

[Scott Haneda]

On Nov 8, 2009, at 10:03 AM, Jeremy Lavergne wrote:

> Should we add the typical steps for producing debug error logs to  
> the output of the standard trace during a failure?
>
> There are often tickets where people simply place the standard  
> output and not the debug output.  Would supplying the steps to do  
> this directly in the standard reporting help users figure this out?

Simply put, yes.  When in non debug, this message would be seen, and  
more than likely would be followed.  People are not going to read all  
the docs on how to post a proper report.  Hell, I have been around  
here long enough, and my port bug reports are far from perfect :)

I like the idea.

If my trac searching was better, I would go read and look over the  
issue to log the errors to a file, so it is even easier to generate a  
bug report.

When an error is hit, a file should be made that contains whatever  
suitable data is needed to allow the user to provide a good report.   
If that means a system profiler, uname, actual -d, and whatever else,  
it should be there.

There never should be a case in trac where the question of "Can you  
run -d and provide us that data", and "what os, how much ran, what  
architecture", etc, those should not be burdens on the user, and those  
should not stall a trac ticket waiting for the answer.

No user burden, and no developer/maintainer/manager burden needs to be  
a goal.  Fix bug, not waste time getting to the point where you can  
maybe start to consider fixing a bug.

People on the dev list get this, but a normal non dev user list user;  
in my opinion, we are lucky they even made it to the mailing list, let  
alone to trac.

My ideal situation:
Oops, looks like you ran into a build bug, please click this link, and  
a report will be auto entered into our trac system.  This will take  
them to a page where if they have an account, they can login, and the  
report will be connected to their account. Or they can "post bug  
anonymously".

They key is to get the data into the system, with as much detail as  
possible, and as little end user friction as possible.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *