To whom should error messages be written?

[Ryan Schmidt]

On Jul 16, 2008, at 12:35, Jordan K. Hubbard wrote:

> On Jul 15, 2008, at 11:43 PM, Ryan Schmidt wrote:
>
>> I think we should write error messages to the end user, not the
>> portfile developer. I think we should also have a new page in the
>> wiki called ErrorMessages, where we can list the error messages that
>> MacPorts might print along with explanations of what the portfile
>> author should do about them. We would describe mtree violations and
>> ineffectual reinplaces and checksum failures (the checksum failure
>> discussion would move to this new page from the FAQ).
>
> I think you've highlighted an important point ("what audience are
> these messages for?") but I don't necessarily see this as an either/or
> scenario.  Both types of messages are important, depending on the
> context, we've just done a poor job of segregating them and allowing
> the user or developer to select which types they want.  I think
> there's enough goop being generated at this point that it would be a
> fine (and comparatively easy) project to add some classification
> attributes to each messages and then enhance the port command to allow
> messages to be emitted by classification (with, of course, some good
> defaults for naive users).

Or we could print no messages that attempt to explain the error  
situation, other than a URL to the FAQ entry for that error message.  
Don't advise "fix the portfile" or "file a ticket" but link to the  
explanation of what the problem is. The FAQ entry can have two  
sections for each entry: one for end users, one for port developers.

> This is the ASL approach, and while it's
> taken awhile for ASL to gain traction in MacOSX, people are already
> using it to do some rather sophisticated log generation and
> scraping.   I understand that these are not log messages, but they're
> close enough in spirit and form that we should take a page from ASL's
> book when it comes to attributes and uniform structure of each
> message.

What is ASL?

> This would be particularly helpful for debugging messages,
> where we've currently dumped so much stuff into one big "debug bucket"
> that it becomes increasingly more difficult to read the output of port
> -d.

I agree our debug bucket is overflowing.