While we ponder broader process and infrastructure improvements, would it be possible to make an improvement to the triage screen to handle the case of a non-actionable error report due to hidden stack frames? Currently, what I do is check "this is (may be) a bug" option and add the following text:
"This issue appears to be caused by a third-party plugin. Due to current privacy rules, we are unable to determine the identity of this plugin, so unfortunately this report is not actionable. We are working on a process improvement to be able to handle reports like this one in the future." Perhaps we could have a checkbox to do this in one gesture, ideally also accessible from quick actions menu. Thanks, - Konstantin -----Original Message----- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch Sent: Saturday, July 25, 2015 2:55 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code > Am 25.07.2015 um 15:32 schrieb Konstantin Komissarchik > <konstantin.komissarc...@oracle.com>: > > > is opening and extending automated error reporting to > > non-eclipse.org plugins, e.g. to member companies, worth these efforts? > > In my opinion, it’s the only way to achieve the goals you set out to achieve > at the beginning of this project. Users view Eclipse as a whole that > encompasses third-party plugins and we need to act accordingly to remain > competitive. I appreciate your view point and foresight on this. I agree to your assessment that knowing about errors (and fixing them) is important to remain competitive. Just a minor correction about the goals I set out: My goal was to help Eclipse projects to quickly see where their code breaks during the Mars milestone builds (cf. my first email on error reporting [1]). Later, and with support of the Eclipse Foundation, we extended the scope and kept the error reporter in Mars release. Still, the goal then was to help Eclipse projects to learn where their code breaks in the (larger) field. As a community we achieved impressive 360 FIXED bugs - alone 85 in the last month. But there is still a lot work to do. If we want to broaden the scope to the whole Eclipse ecosystem, we’d need to get serious about how much work this will cause. To be sustainable, the Foundation would need to allocate resources for such a service for a longer period and the system needs continuous improvement and maintenance to scale properly with the new demands. If we go down that road (assuming we get legal right at some point), this can’t continue as someone’s side project. It needs a commitment. How can we ensure this project will stay healthy? Marcel [1] https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10902.html _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
