2008/11/15 (``-_-´´) -- Fernando <[EMAIL PROTECTED]>: > Olá Stephan e a todos. > > On Thursday 13 November 2008 12:20:17 Stephan Hermann wrote: >> This task is not easy. There needs to be input from the users with the >> non-working hardware. Most likely, that this information can be gathered >> with some magic commands on CLI, which is also provided by a nice developer. > > I've seen this mention a few times, and if anyone looks at brainstorm, I bet > its already there: > Would it be of any interest having a tool (only on devel branches or the all > time) that would gather the entire HW listing with FULL detail and upload it > to some database? > Some improved version of hwtest-gtk, mixed with hwinfo and sysinfo (sysinfo > as a great user UI and could also teach/report to the user about supported > HW). > > Maybe hook up hwtest-gtk to system 1st runs and kernel upgrades, and notify > the user to run the tests, and send the report.
To addition to this - what we need is user's "field test" team, something like virtual voluntary hardware test lab. Say, user registers available computers with their hardware profiles (No need to have Ubuntu on it, Live CD for testing and getting hardware details should be fine). It comes into some db on Launchpad/Cannonical, and say, there is Jaunty with new kernel, which has significant changes on such and such hardware. Checking db - for example, we have 2 users with such hardware. Create task list for testing (because it is clearly not enough to test WiFi with just WPA or WEP), users do tests, and report back. In fact, this *already* happens in bug reports, but let's make it more organized. Also this db could contain list of *known* hardware issues with bug reports and people who you can contact with to test issue (if they are available and agree to help, of course). It would also give huge oversight to Cannonical and community in which fronts there are issues. Say, wifi still have lot of issues, or sound cards what causes most of trouble. It would also give Cannonical availability to print nice "Hardware issues" page so users would know what to expect. >> When I upgrade to a new release, I always think (or is it knowing): "Ok, >> for the next 4 hours I'll sit in front of this computer, and I expect >> something to break...because it's software made by people". If nothing >> breaks, then I'm really surprised and happy. But when something breaks, >> I already expected that. And when I find the cause for the breakage, >> I'll try to fix it, AND/OR file a bug report about that issue. >> >> Therefore, I don't upgrade my production machine without any real >> testing. But this won't help for everybody, I know. > > That's why I start testing in early development versions: so that stuff can > be detected and users on a stable release dont find all those many bugs. > I've already upgraded my laptop to Jaunty. With this I can keep up the > development, and help fix stuff before release There are some issues with that too - for example, my Intel wifi card was broken by updates only two weeks before final release. I would even say that those last minute updates are most dangerous, because they get introduced so close to finish line that it is really hard task to get update for it in release. Ubuntu really needs wider release testing window, when any functional and hardware updates are strictly forbidden unless it is really needed. Peter. -- Ubuntu-devel-discuss mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
