Closed GoogleCodeExporter closed 9 years ago
This should be recategorized as a feature request - not a bug
Original comment by tim.ju...@gmail.com
on 8 Jan 2011 at 7:04
I'll investigate what services FogBugz provides and will decide if CrashRpt
should support it. The first thing I see is that FogBugs is a commercial
service, not an open-source software. Why should an open-source software
support a commercial service?
Original comment by zexspect...@gmail.com
on 9 Jan 2011 at 5:51
The company (fogcreek) provides free service/hosting for one and two person
companies/projects, as well as free for students (and I believe for
not-for-profits).
I use it for two of my own projects (for free).
But if there is policy of not supporting commercial projects then I understand.
Perhaps if crashrpt just supported an open back end interface to allow
reporting to other entities that would suffice, then anyone could write their
own? I think that is a reasonable.
Original comment by tim.ju...@gmail.com
on 9 Jan 2011 at 2:45
Ok, I'll try to implement this feature in the near future. I think supporting
such third-party services will attract more users to CrashRpt.
Original comment by zexspect...@gmail.com
on 9 Jan 2011 at 4:13
I think the decision is a great idea.
I think that you are right about it helping attract users. I would also imagine
that FogCreek would mention the tool if/when the interface is working. Not
sure how much promoting they would do but they do note other tools that work
with their software.
They are users and producers of open source - for example the Kiln, mercurial
project, as well as CoPilot. Note that they also publish the source code for
FogBugz.
Original comment by tim.ju...@gmail.com
on 9 Jan 2011 at 4:19
I have found some info on how Microsoft does error report bucketing. Generally,
the bucketing is very complex, and contains a lot of rules (heuristics). It can
be devided into two stages: error labeling (client-side) and further error
classifying (server-side).
The error is labeled by WER client code. The label is used to group similar
error reports and consists of program name, program verion, program timestamp,
module name, module offset, offset in module and so on. The label is sent to
the server, and the server decides if to request report data transfer or just
to increment error counter. The label assignment is not enough to guarantee the
bucket contains just one bug, further analysis is required.
When the server decides that the label is new, it requests report data and
creates a new bucket. Then it passes the data to a job server that performs
further analysis (stack trace recoverying and so on). The analysis requires PDB
files. The analysis may assign the error new label, the ultimate goal is that
each bucket contain single bug.
The summary is the following. CrashRpt can assign a label to an error report to
perform initial bucketing, and then send the data to FogBugz. But this is the
first step only. The further analysis should be performed on FogBugz
infrastructure and require that users upload PDB files to FogBugz. So I'm not
sure FogBugz is suitable as a back-end for error reporting.
Original comment by zexspect...@gmail.com
on 13 Jan 2011 at 2:44
I wrote about a potential issue with FogBugz integration above - analysis
should be performed on FogBugz infrastructure and require that users upload PDB
files to FogBugz.
Another potential problem is authentication - if a user can steal password, he
can have full control over the ticket database.
So, I decided not to implement support of FogBugz XML API because of those two
reasons.
Original comment by zexspect...@gmail.com
on 1 Feb 2011 at 1:41
Original issue reported on code.google.com by
tim.ju...@gmail.com
on 8 Jan 2011 at 7:03