macports error reporting, stack traces

[Jeremy Lavergne]

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?

_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[shdjsahwkjq ehwq kehwkq h]

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

_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Jordan K. Hubbard]

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?

That certainly sounds like something that should be documented, though one would almost wish to then render that documentation obsolete by dumping debug output on error.  In other words, ui_debug would always generate debug information, the Debug flag merely indicating what the output fd was.  If not set, it's set to some temporary file which has already been unlinked (the open, unlink truck) but has a fd that can be rewound and copied to stderr on error, and if it's set then the fd points directly to stderr.  Whatever routine catches errors for a port build would be responsible for dumping the error log.  Sounds like an excellent Tcl / MacPorts base beginner's project. :)

- Jordan

_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Joshua Root-8]

On 2009-11-9 14:13, Jordan K. Hubbard wrote:
> 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?
>
> That certainly sounds like something that should be documented, though one would almost wish to then render that documentation obsolete by dumping debug output on error.  In other words, ui_debug would always generate debug information, the Debug flag merely indicating what the output fd was.  If not set, it's set to some temporary file which has already been unlinked (the open, unlink truck) but has a fd that can be rewound and copied to stderr on error, and if it's set then the fd points directly to stderr.  Whatever routine catches errors for a port build would be responsible for dumping the error log.  Sounds like an excellent Tcl / MacPorts base beginner's project. :)

That is exactly what the gsoc09-logging branch does.

- Josh
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Jordan K. Hubbard]

On Nov 9, 2009, at 4:03 AM, Joshua Root wrote:

> On 2009-11-9 14:13, Jordan K. Hubbard wrote:
>> 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?
>>
>> That certainly sounds like something that should be documented, though one would almost wish to then render that documentation obsolete by dumping debug output on error.  In other words, ui_debug would always generate debug information, the Debug flag merely indicating what the output fd was.  If not set, it's set to some temporary file which has already been unlinked (the open, unlink truck) but has a fd that can be rewound and copied to stderr on error, and if it's set then the fd points directly to stderr.  Whatever routine catches errors for a port build would be responsible for dumping the error log.  Sounds like an excellent Tcl / MacPorts base beginner's project. :)
>
> That is exactly what the gsoc09-logging branch does.

Even more awesome!   When's that scheduled for completion and merge with trunk? :-)

- Jordan
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Bryan Blackburn-4]

On Mon, Nov 09, 2009 at 11:21:45PM -0800, Jordan K. Hubbard said:

>
> On Nov 9, 2009, at 4:03 AM, Joshua Root wrote:
>
> > On 2009-11-9 14:13, Jordan K. Hubbard wrote:
> >> 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?
> >>
> >> That certainly sounds like something that should be documented, though one would almost wish to then render that documentation obsolete by dumping debug output on error.  In other words, ui_debug would always generate debug information, the Debug flag merely indicating what the output fd was.  If not set, it's set to some temporary file which has already been unlinked (the open, unlink truck) but has a fd that can be rewound and copied to stderr on error, and if it's set then the fd points directly to stderr.  Whatever routine catches errors for a port build would be responsible for dumping the error log.  Sounds like an excellent Tcl / MacPorts base beginner's project. :)
> >
> > That is exactly what the gsoc09-logging branch does.
>
> Even more awesome!   When's that scheduled for completion and merge with trunk? :-)

In r60372, now that I figured out the oddity from svn merge with a few files
with their own svn:mergeinfo properties...

'port help log' is a good place for people to start with it.

Bryan


>
> - Jordan
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev