=== bryce_ [n=bryce@71.237.200.28] has joined #ubuntu-x | ||
=== mvo [n=egon@p54A6769C.dip.t-dialin.net] has joined #ubuntu-x | ||
bryce_ | tepsipakki: btw, one thing I'm hoping to work towards with our xorg packaging, is to improve testing | 08:55 |
---|---|---|
tepsipakki | yes, you mentioned that briefly.. | 08:55 |
tepsipakki | what do you mean by that? | 08:55 |
bryce_ | before I started with ubuntu/xorg, I used to maintain a large automated testsuite for nfsv4, and I'm hoping to reuse some of those approaches for xorg | 08:56 |
tepsipakki | testing the code itself? | 08:56 |
bryce_ | well, I haven't 100% determined what would serve us best yet | 08:56 |
bryce_ | possibly | 08:56 |
bryce_ | there's a lot of different ways to test things | 08:56 |
bryce_ | the key is to test for things we can actually do stuff about | 08:57 |
bryce_ | so like, just running xorg performance tests probably wouldn't gain us much | 08:57 |
bryce_ | (although it might not be a bad thing to do) | 08:57 |
bryce_ | the particular thing I've been looking at is just plain old "startup" tests | 08:57 |
bryce_ | e.g., given a new (proposed) xorg package, install it on a test machine, and try starting xorg on that machine | 08:58 |
tepsipakki | that would need a lot of hardware :) | 08:58 |
bryce_ | yup | 08:58 |
tepsipakki | but sounds good | 08:58 |
bryce_ | which is why I've been accumulating hardware ;-) | 08:58 |
tepsipakki | heh | 08:59 |
bryce_ | I've got 4 working test systems, plus 3 more on the way | 08:59 |
bryce_ | (I call test systems 'sut's - Systems Under Test) | 08:59 |
bryce_ | anyway, I bring this up because if you know of or can think of other tests that would be worth running, let me know | 09:00 |
bryce_ | oh, aside from just having a lot of hardware, it can also be useful to run the same test with different parameters | 09:00 |
bryce_ | e.g. on an intel system, testing against -i810 and -intel, or with an ati or nvidia system, testing against both open and binary drivers | 09:01 |
tepsipakki | can't think of anything, but I'll keep that in mind | 09:01 |
bryce_ | another thing to think about, is when you manually test something, to try to think, "how could I achieve this same test, but in a completely automated way" | 09:02 |
bryce_ | as we go, anything we can script, we can turn into a cheap test for using in the future | 09:02 |
tepsipakki | manual testing don't scale well :) (but OTOH it doesn't need to be run _that_ often) | 09:03 |
bryce_ | yup | 09:03 |
bryce_ | where automated testing can prove useful is when we're doing a release and want to have as many extra checks as possible | 09:04 |
bryce_ | obviously, those checks don't need to be automated, | 09:04 |
bryce_ | but it can eliminate a lot of questions if it's scripted to the extent that it could be 100% automated | 09:04 |
tepsipakki | of course, scripting helps, it's just tricky to write good scripts for that purpose :) | 09:05 |
bryce_ | yup | 09:06 |
tepsipakki | I'm wondering if I should create a git branch for our xorg in git.d.o and push the changes one by one.. | 09:07 |
bryce_ | I think that would be really, really, really useful and a very good idea | 09:08 |
bryce_ | I can set up my test system to auto-pull from git when there are changes, and automatically run tests against that | 09:08 |
tepsipakki | the metapackage has most of the changes, rest of the components just use patches so they are pretty trivial to keep for now | 09:08 |
bryce_ | I used to run this automated test system for carl worth for doing cairo testing, using exactly that approach | 09:09 |
tepsipakki | jcristau: you awake yet?-) | 09:09 |
tepsipakki | cool | 09:09 |
bryce_ | so I was thinking resurrecting that would be handy, so we'd have something at the application level to test | 09:09 |
bryce_ | but a lot of what you and I care about is going to be more at the integration/packaging layer | 09:10 |
tepsipakki | upgrades are also nice to test beforehand | 09:10 |
bryce_ | another thing I've thought about is hooking this in with vmware, so on a given hardware I can test against feisty as well as gutsy | 09:10 |
bryce_ | exactly | 09:11 |
bryce_ | I've used this test framework (aka crucible) with xen, but not with vmware | 09:11 |
tepsipakki | ah, build tests | 09:12 |
bryce_ | yeah | 09:12 |
tepsipakki | it's silly to upload and then notice that the build fails for whatever reason :) | 09:12 |
bryce_ | also, I don't know if we care, but I've done some testing work with cross compilers | 09:12 |
bryce_ | honestly, I don't think anyone is going to care if we get errors/warnings on arm, solaris, etc. ;-) but that's something else we could test if we wished | 09:13 |
tepsipakki | I believe debian will test those :) | 09:14 |
bryce_ | yup | 09:14 |
tepsipakki | AIUI they are going to keep experimental as close to upstream git master as possible to make testing easier | 09:15 |
bryce_ | the thing I've learned with testing is that the key is in reviewing and following up on test results | 09:17 |
bryce_ | you can automate all the tests in the world and generate terabytes of results, but if no one follows up on the results, it's all worthless | 09:17 |
tepsipakki | right | 09:17 |
bryce_ | so the trick is to try to only run tests that actually matter, that you actually care about | 09:18 |
bryce_ | so that's where I can really use your help and advice | 09:18 |
bryce_ | just because we *can* run a test, the real question is if we care | 09:19 |
bryce_ | anyway, it'll probably be a few weeks before I have anything worthwhile to look at. But when I do, please be critical - if it looks un-useful to you, say so :-) | 09:22 |
tepsipakki | ok, I will :) | 09:22 |
tepsipakki | testing itself is a gray area for me, but I know how costly it is to leave testing for the end users | 09:23 |
bryce_ | cool, well this'll be a good thing to learn. It's actually a pretty simple thing, it just seems strange and mysterious from the outside | 09:24 |
bryce_ | testing mostly is just useful for catching goofs | 09:25 |
bryce_ | but we all make goofs from time to time ;-) | 09:26 |
tepsipakki | yep :) | 09:26 |
=== seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-x | ||
jcristau | tepsipakki: now i am | 11:10 |
jcristau | (my sleep pattern is kinda fucked up, these days) | 11:10 |
tepsipakki | hehe | 11:12 |
tepsipakki | I was wondering if it makes sense to create a new branch for xorg and to apply the ubuntu changes there one by one | 11:13 |
jcristau | i'm fine with that | 11:13 |
tepsipakki | ok, I've just started with it | 11:14 |
tepsipakki | I guess it's easier to pull changes then | 11:14 |
ubotu | New bug: #20584 in xserver-xorg-video-trident (main) "xv output garbled [not regr] " [Medium,Needs info] https://launchpad.net/bugs/20584 | 11:15 |
=== cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-x | ||
ubotu | New bug: #118208 in libxinerama (main) "Context Menu display cutoff" [Undecided,Unconfirmed] https://launchpad.net/bugs/118208 | 12:08 |
ubotu | New bug: #53878 in xorg-server (main) "Screen is distorted for a few seconds at X startup shutdown" [Medium,Needs info] https://launchpad.net/bugs/53878 | 12:25 |
=== seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-x | ||
=== mvo [n=egon@p54A67049.dip.t-dialin.net] has joined #ubuntu-x | ||
=== seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-x | ||
=== mvo [n=egon@p54A65B4C.dip.t-dialin.net] has joined #ubuntu-x | ||
=== brycerr [n=bryce@71.237.200.28] has joined #ubuntu-x | ||
ubotu | New bug: #96213 in xorg (main) "won't install on Dell 640m with 1400x900 screen" [Undecided,Needs info] https://launchpad.net/bugs/96213 | 07:22 |
ubotu | New bug: #42607 in xserver-xorg-video-via (main) "Ubuntu Dapper on VIA EPIA-MS with LVDS; no video after installation" [Medium,Needs info] https://launchpad.net/bugs/42607 | 08:01 |
ubotu | New bug: #45418 in xkbutils (main) "Restart of X gdm and freezing" [Medium,Confirmed] https://launchpad.net/bugs/45418 | 09:10 |
=== mvo [n=egon@p54A667F8.dip.t-dialin.net] has joined #ubuntu-x | ||
ubotu | New bug: #41404 in xserver-xorg-video-via (main) "OpenGL stuff freezes on AMD64" [Medium,Needs info] https://launchpad.net/bugs/41404 | 09:36 |
=== mvo_ [n=egon@p54A67E71.dip.t-dialin.net] has joined #ubuntu-x | ||
ubotu | New bug: #46352 in xresprobe (main) "Panel resolution not detected" [Medium,Needs info] https://launchpad.net/bugs/46352 | 09:50 |
ubotu | New bug: #32152 in linux-restricted-modules-2.6.15 (restricted) "Wireless networking suddenly broken" [Medium,Needs info] https://launchpad.net/bugs/32152 | 10:00 |
=== mvo_ [n=egon@p54A673E6.dip.t-dialin.net] has joined #ubuntu-x | ||
ubotu | New bug: #68319 in xorg (main) "Right button and middle click on mouse are swapped" [Undecided,Unconfirmed] https://launchpad.net/bugs/68319 | 10:51 |
ubotu | New bug: #49115 in xresprobe (main) "Max resolution not detected properly for IBM G78" [Undecided,Rejected] https://launchpad.net/bugs/49115 | 11:11 |
ubotu | New bug: #36525 in linux-restricted-modules-2.6.15 (restricted) "bcm43xx Driver only works @ 11Mb/s" [Low,Confirmed] https://launchpad.net/bugs/36525 | 11:33 |
brycerr | tepsipakki, I posted a patch to bug 42553 for conditionalizing wacom in dexconf, with explanation of why we aren't doing it based on mjg59's comments | 11:44 |
ubotu | Launchpad bug 42553 in xorg "wacom input devices enabled by default, why?" [Medium,Confirmed] https://launchpad.net/bugs/42553 | 11:44 |
tepsipakki | brycerr: yeah, uploading with that change would be a regression for some wacom users, so probably not worth it | 11:54 |
tepsipakki | we'll see how the input-hotplug progresses.. | 11:54 |
ubotu | New bug: #103497 in linux-restricted-modules-2.6.20 (restricted) "IPW2200 proccess 100% cpu ussage with no configured network in the area" [Undecided,Needs info] https://launchpad.net/bugs/103497 | 12:00 |
ubotu | New bug: #72705 in linux-restricted-modules-2.6.17 (restricted) "kernel panic, system freeze on shutdown, vmware hangs..." [Medium,Confirmed] https://launchpad.net/bugs/72705 | 12:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!