search

jirentabu / crashrpt

Automatically exported from code.google.com/p/crashrpt
0 stars 0 forks source link

Add FogBugz XML API interface as back end reporting #73

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Please provide any additional information below.

We'd like to add an additional back end reporting mechanism: Fogbugz XML API. ( 
http://www.fogcreek.com/FogBugz/docs/70/topics/advanced/API.html )

If it helps, I have set up an example Fogbugz account for testing.  

For more information see this project:

http://fogbugzpp.codeplex.com/

Original issue reported on code.google.com by tim.ju...@gmail.com on 8 Jan 2011 at 7:03

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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