Re: [epp-dev] Adding a error log collector to Mars milestone builds?

[Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx>]

Am 12.08.2014 um 23:50 schrieb Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>:

Keep in mind that org.eclipse code might be called from 3rd party code.

IMHO it’s fine if we apply the following filters (note, I’m assuming you hook into ILog (ILogListener) and analyze the full IStatus):

I do.

- the originating plug-in id starts with org.eclipse

That’s how it is implemented ATM.

- every source info in the stack frame starts with org.eclipse

That’s how it (was planned to be) implemented. An „Anonymize stacktraces“ checkbox is in progress.

- there is no other trace of 3rd pacrty information (in this and any nested IStatus children, etc.)

That’s how it will be implemented.

- stopword list (blacklist) of message content (to be maintained on the server as static list and updated once in a while)

Hmm. Not sure about this one.

stop words work for well known cases only (like Wayne’s suggestion for „—— SOURCE BEGINS HERE ——„ ) Maybe there will be a few more clever heuristics but let me see which data I produce to determine what else we could do.

I was thinking about black-/whitelisting pairs of "plugin-id+error-code“ taken from IStatus. If a committer confirms that a certain log event is „save“, we could submit the message - or the other way around. Unfortunately, 50% of all errors I submitted do not use any error code. The rest uses the error code number „4“. Well not all 50% but 45%… Maybe we could get people to make use of error codes some time in the future.

You could then compute a hash and submit this for a server-side duplication check (this should increase a hit-count on the server so that we at least know about dups). If the dup check is negative, I think you can submit it.

If there is a lot of traffic, this will make sense. I’ll keep in the list of things we could do...

But before anything is actually submitted, you have to bring up a dialog which allows users to review the information to be submitted and recorded and to pick from yes/no/never/always (opt-in model).

That’s how it’s implemented.

If all that is met, the efforts to protect privacy and sensitive information sounds reasonable to me. 

We’ll come up with a improved version in a week or so.

Oh, you might want to include a detection for message patterns rather soon than later. Quite a few messages are a result of formatting with different argument. Would be great if group those together (for dup detection and/or anonymize argument). Especially if one of the argument is a local temp folder path.

Many error messages use single quotes. File paths and URLs can be spotted easily as well. Sometimes, however, this is the information we actually need.

But I currently favor a solution where the user can decided whether he wan’t to send messages. IMHO, I’d recommend plugin developers to create stacktraces for every error log entry which will later help them to track the execution path of an error message. I think, this will be in many cases more useful then the actual message. But that’s something to proof…

Thanks for your comments.

-Gunnar

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx

_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev