When Bug-Buddy starts it will check if it needs to update its configuration files. It does this maximum once per day by checking the time of three XML files on bugzilla.gnome.org.
From the bugzilla.gnome.org webservers logs I grepped the hits to one of these files. Each hit will contain the gnome-vfs version that was used to access it. A pretty safe assumption is that the gnome-vfs version is the same as the GNOME version.
Per GNOME (gnome-vfs) version I now have the number of hits generated during a month of data. Again, Bug-Buddy only checks once a day and the hit is only done when someone starts Bug-buddy (eg app crashes and you click the ‘Inform Developers’ button).
It’s interesting, but hard to extrapolate much from this data. As I see it, the two main pieces of information you could get out of this data are:
1) which versions of GNOME have more crashing bugs
2) which versions of GNOME are more commonly installed currently
Unfortunately, the two are intertwined in the data such that you can’t actually determine either one.
Are these unique IPs? Or just totals?
[BTW, it would be cool if this was discussed on bugsquad@ 🙂
Just totals. I also combined it per GNOME version at http://www.gnome.org/~ovitters/bug-buddy-usage-combined.svg.
Is there no data before 2.7.92 on version? (I forget when it moved to gnome-vfs for the web stuff.) As the other poster points out, this data is inextricably tied into stability as well as usage, so it isn’t perfect, but still interesting.
Wondered about this, but it is due to the way I grepped the logs. I only looked for HEAD requests. Seems that before that 2.7.92, bug-buddy/gnome-vfs always used GET. I did find a few hits from that version after I double checked.
Currently making a graph based upon unique IP address, I’ll add that tomorrow.
Ok, using unique ips:
http://www.gnome.org/~ovitters/bug-buddy-usage-uniq.svg
And combined:
http://www.gnome.org/~ovitters/bug-buddy-usage-combined-uniq.svg
For the combined-uniq I assumed I could add the figures from the first graph together. So if someone upgraded from 2.14.0 to 2.14.1 within that month above graph will incorrectly add it twice.
I’d interpret this as “Our user base keeps growing”.
Murray: How about “our user base keeps upgrading”?
The only thing I find interesting is that we have nearly 30K of unique people getting the bug-buddy XML files in approx. one month. As they are starting Bug-Buddy I’d expect them to file a bug. 30K in one month is about 1000 bugs per day.
We do not nearly get that amount of bugreports per day. We couldn’t even handle that amount of bugreports.
I can guess at some causes;
– The need for sendmail
– Port 25 not being blocked by the ISP/company
– The requirement for an email address (which I will never change)
– Difficulty of using bug-buddy
A few of those will be fixed in an upcoming Bug-Buddy version. That will support XML-RPC to submit bugs, it will support proxies (bypassing most firewalls) and simplify the bug-buddy interface a lot.
This will remove a lot of the reasons I can think of why we are not getting a 1000 bugreports a day. So I have to wonder what happens when 2.16.0 is released with the perfect Bug-Buddy.
There are a few more ideas to make filing bugreports easier. What happens if those are implemented? Will Bugzilla still be usable?
I do not like that crashers are filed in Bugzilla. I rather have that done (optionally) anonymously using some system that shows top crashers. The system should also add the debug information in some way (Fer has some thoughts on this). That would be far better then having all these dupes.
However, very soon the new Bug-Buddy version will be released. It is needed, and it will be released. I just wonder about what happens after that…