Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] Adding a error log collector to Mars milestone builds?

How about something very simple instead… Don’t filter anything. See an error in the log, pop a dialog showing the full content of the stack that will be sent and asking for permission. If the text box is editable, the user can redact as appropriate for their needs. Then, “yes”, “no” or “no and don’t bother me for [select interval]”.

 

The approval of the two councils, as Wayne has outlined, seems to me like an unnecessary step. It’s not required for other projects, so why should it be required here? We need legal review, which should be able to commence now. We need EMO decision on infrastructure. We need approvals from various package maintainers.

 

In terms of tracking to show effectiveness of the service, it would be very helpful if the reporting portal had “open a bug” link that embedded a keyword in the bug. This would make it easy to query bugzilla six months or a year from now to determine if the service is useful and the backend should continue to be maintained.

 

Thanks,

 

- Konstantin

 

 

From: epp-dev-bounces@xxxxxxxxxxx [mailto:epp-dev-bounces@xxxxxxxxxxx] On Behalf Of Gunnar Wagenknecht
Sent: Tuesday, August 12, 2014 2:51 PM
To: Eclipse Packaging Project
Subject: Re: [epp-dev] Adding a error log collector to Mars milestone builds?

 

 

Am 12.08.2014 um 23:29 schrieb Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx>:



Let’s trim the messages after 140 chars. There can’t be much source code in it, right?

 

I guess Wayne’s concern are message like "your password to my.secret.server is wrong". It’s impossible to capture them all. But I think it’s also un-reasonable that this concern should prevent any progress.



Or if you still have concerns: let’s skip the message completely. the stacktrace is what we need anyways to fix issues.

 

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

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

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

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

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

 

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.

 

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

 

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

 

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.

 

-Gunnar

 

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx



 


Back to the top