On Wed, Jan 21, 2009 at 12:00 PM, Albert Santoni <[email protected]> wrote: > > On 21-Jan-09, at 8:12 AM, Nick Guenther wrote: > >> On Tue, Jan 20, 2009 at 4:03 PM, Garth Dahlstrom <[email protected]> wrote: >>> >>> I have repaired cmetrics in Mixxx such that building with "scons >>> cmetrics=1" will now cause Mixxx to report back information to >>> metrics.mixxx.org. >>> >>> The messages are being saved, unparsed into a database... I started >>> writing code to parse it (since we don't have the original server-side >>> implementation), but decided it is a waste of effort until we can see >>> if the messages cmetrics sends are actually of any value to Mixxx >>> developers or the community at large. >>> >>> So if there are folks out there who would mind paricipating in this >>> kind of data collection you are welcome to build with cmetrics=1; I'm >>> thinking we can do a dump of the dataset for people to play with at >>> the end of a couple of weeks if people are interested in checking it >>> out. After that we can reevaluate if cmetrics is worth having >>> around/turned on. >>> >> >> IF we have a lot of data, then cmetrics is useful as a guideline. MS >> Word would have good data from such a thing. Mixxx? Probably not so >> much. It's probably way more effective to just point people at the bug >> tracker if they want their voice heard. >> > > The purpose of CMetrics was two-fold: > > 1) To give us better demographics data and information about our users > computers. Back when we were working on 1.6.0, we found that it was getting > difficult to make certain design decision without understanding the hardware > setups that our users have. Even in the short time that CMetrics was > working, we had some good stats that helped us target development more. (As > an example, the CMetrics data told us we needed to work on Hercules support > more.) > > 2) To help us track down bugs that are otherwise impossible for us to track. > Specifically, with 1.5.0, we encountered discovered a handful of "Mixxx > doesn't run for me on Windows" bugs, but we had no idea that they were there > because nobody was reporting them. In addition, we were unable to reproduce > most of these bugs because we didn't have backtraces, etc. We knew this was > still a major problem with 1.6.0 Beta 1, and now that 1.6.0 has been > released, it's clear that it's STILL an issue. I don't know how to > troubleshoot these bugs, because we have no data. CMetrics was able to > capture stack dumps on Windows, and John had it set up so that you could > load the stack dump into Visual Studio and debug Mixxx in the state that it > had crashed on someone else's computer. This seemed like the holy grail for > us, but our Windows development sort of died, so I'm not even sure if anyone > besides John ever tried to do this. (Regardless, we're still constantly > getting screwed over by these crash-at-startup bugs, so if a Win32 guru > knows how we can capture _useful_ debugging data on them, please share.) >
Ah okay, good reasons. I didn't think of any of that. Well then why not turn cmetrics on by default and just let the user opt-in at first run? -Nick ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
