On 2012.10.12 17:42, Sean McBride wrote: >> The reasoning is that issues that are not tied to hardware >> access, such as compilation breaking on a specific platform or even >> breakage of apps such as usbutils and OpenOCD, are going to be reported >> fairly extensively compared to ones tied to a specific hw conf or type >> of hw access > > Yes, but reported when? With a nightly build/test system you find out the > next day, not after someone bothers to try RC4 (for example).
Well, if you can automate the builds for libfti/OpenOCD, usbutils, brltty and all the software we can pick that relies on libusb/libusbx I'm all for it... as long as you don't divert resources that are already in short supply to do just so. My point was: since we have limited resources, and provided nobody volunteers to produce automated tests (because I know I really won't have the time to look into that any time soon), then we can afford not to test what we know is going to be tested for breakage regardless, by our users. In other words, if we have a resource issue, then we can try to tap into leveraging our users. And please understand I'm not saying that this is an ideal situation, however we also need to be realistic with regards to how we can spread the workload. Now, if you can automate reports for daily builds of the software above, I'm obviously all for it. Regards, /Pete ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
