David Henningsson [2013-02-28 21:49 +0100]: > But still, a word of caution here. Every piece of code even remotely > related to the hardware, not only the Linux kernel but also most of > the plumbing layer, is quite difficult (or even impossible) to > automate testing for. Even if we would set up robots in our lab > looking at the screen for artifacts, talking into the microphone and > so on, we wouldn't cover the world's hardware. > > Hardware becomes increasingly complex, diverse, and so testing it > takes a lot of time. You can't go test thousands of machines to see > if their headphone outputs stopped working every single day. > > Do we have a plan to deal with those types of bugs?
I fully agree, and this is not even limited to the kernel. There are other kinds of "major transitions" like switching to a new X.org server, preparing a new major Qt or GNOME release, new eglibc, etc. Or we want to do a complex transition such as moving from ConsoleKit to logind. For those we'll need temporary staging areas which are not put into the RR yet until they get a sufficient amount of testing; these could be "topic PPAs" which interested people would enable and develop in, which get landed into the RR when everything is ready? Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel