[00:35] I agree with JanC, I'm not sure if we can do much better than the defaults [01:28] RAOF, I'm looking at https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions with the thought of one day potentially being able to do mesa point release updates. It sounds like one of the prerequisites to achieving that is to have a test suite hooked in and running as part of the build process. [01:29] RAOF, do you think it is at all feasible to have piglit run as part of the mesa build process? I know not all the tests will pass, so am guessing it'd prevent us from doing this. But what do you think? [01:29] That's not really something that's appropriate for mesa. [01:30] Although I guess we *could* test the software rasteriser it's not actually something that we care about. [01:30] Having automated piglit runs would be useful, but we can't do them on the buildds. [01:31] It's reasonably easy to determine whether there's been a regression on a piglit test; that's what we'd want to hook up to. [01:33] Or, rather, have a set of machines in the QA lab hook up to :) [01:34] yeah, true [01:38] well, I gather the intent is to have a way to force the tests to always run and prevent a build going through if failed, and not sure even if we had machines in the QA lab if we could construct something like that [01:42] * bryce crosses "post-release mesa point release updates" off the list [01:56] We *could* test the software rasteriser (now that ajax has basically fixed the X side of it ☺); I guess that would pick up a seriously bad build. [03:12] bryce: Actually, how does the kernel team do it? They've got a shiny process for testing the proposed kernel somewhere, I know. [03:24] RAOF, well, they don't have it hooked into their build process but they do have a lot of testing tools like the usb key boot testing stuff that'd be nice to tie into [03:25] They've essentially got blanket SRU, too, right? [03:25] RAOF, sort of; they're not part of the MicroReleaseExceptions stuff though [03:25] And mesa is very much in the same boat (although with less historical capacity for non-deadly stable updates). [03:25] the SRUs they put out are like SRU bugfix collections [03:26] They're on a bi-weekly stable kernel release cadence, aren't they? [03:26] right [03:27] we'd be in the same boat were we doing bunches of mesa cherrypicks wrapped up together [03:27] Yeah. [03:27] but figuring out what changes from the mesa tree are worth cherrypicking is non-trivial [03:28] So I think we should be modelling the mesa stable updates on the kernel, because mesa's much more like the kernel than any other package on the MicroReleaseExceptions page. [03:28] I tend to agree [03:29] Well, *if* mesa started with a serious really-only-bugfixes stable branch then cherrypicking would be much more obvious; we'd just pull the most recent stable branch. [03:29] I'm not sure that'd make it more obvious [03:29] some of the patches are pretty tersely described, and few have bug refs [03:30] Ah, I'm thinking of a different problem. [03:30] You're thinking of ‘how do I match up these commits with LP bugs to fix’, I'm thinking of ‘how do I avoid patches we shouldn't pull’. [03:31] but if they did have a really-only-bugfixes stable branch, where we're confident it's going to be regression free, then it does start to look more like firefox and the other packages, where we could just check that piglit passes and roll the whole thing out, without needing to individually sign off on each patch in the set [03:31] right; the former is what we have to do for SRUs right now [03:32] Which would be like what I understand the kernel's stable kernel update process is; pull in the latest stable release, plus any cherry-picks/patches to fix specific bugs. [03:32] Where only the extra cherry-picks need much individual scrutiny. [03:36] in any case, sort of moot until mesa does proper stable point release updates [03:37] Yeah :) [03:38] btw, speaking of the mesa stable branch, there's a bunch of interesting patches that went in post 7.10.2; a git snapshot might be nice... [03:38] at least up thru a8032483ecc8750ad58d89c4d96af6ef82a475e2 would get the new radon chip id's [03:39] radeon [03:40] up to that release would also include some of the sandybridge work [03:40] (possibly the stuff people are complaining that fedora has but we lack?) [03:43] I'll fold that into the next mesa upload. [03:47] for a second there I thought you meant a mesa master snapshot, that's going to be a huge beast with the tls fix not working and the new libglapi1-mesa package :P [03:48] Damnit, I don't think I can make -intel's copy_fb patch nice enough to upstream. [03:48] https://wiki.ubuntu.com/KernelTeam/KernelUpdates [03:49] Sarvatt, no, there's plenty enough on the 7.10 branch to be scared of ;-) [03:50] problem is there's lots of mesa changes that look sane and good, but linking them to a reported bug or reproducible test case is pretty non-obvious [07:58] git hate xserver-xorg-video-intel [08:04] there, there.. [08:08] Combining the two favourite hate targets! git and -intel! [08:23] heh [08:32] Hm. That was rather stupid. [08:38] So, it's difficult to tell in oneiric if copy_fb is actually working. It is, however, now plausible *and* X actually starts! [13:09] bryce: Can I hand bug #791596 off to you when you get up? I'm off to sleep, but it looks like we should revert 503_fix_masked_valuators from the natty-updates X server. [13:09] Launchpad bug 791596 in xorg-server (Ubuntu Oneiric) (and 2 other projects) "Odd Pointer Behavior After Recent Xserver SRU in Natty (affects: 2) (heat: 14)" [Critical,Incomplete] https://launchpad.net/bugs/791596 === ara_ is now known as ara === Tux is now known as Guest78361 === yofel_ is now known as yofel === Sarvatt_ is now known as Sarvatt