/srv/irclogs.ubuntu.com/2011/06/02/#ubuntu-x.txt

cndI agree with JanC, I'm not sure if we can do much better than the defaults00:35
bryceRAOF, 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:28
bryceRAOF, 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
RAOFThat's not really something that's appropriate for mesa.01:29
RAOFAlthough I guess we *could* test the software rasteriser it's not actually something that we care about.01:30
RAOFHaving automated piglit runs would be useful, but we can't do them on the buildds.01:30
RAOFIt'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:31
RAOFOr, rather, have a set of machines in the QA lab hook up to :)01:33
bryceyeah, true01:34
brycewell, 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 that01:38
* bryce crosses "post-release mesa point release updates" off the list01:42
RAOFWe *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.01:56
RAOFbryce: Actually, how does the kernel team do it?  They've got a shiny process for testing the proposed kernel somewhere, I know.03:12
bryceRAOF, 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 into03:24
RAOFThey've essentially got blanket SRU, too, right?03:25
bryceRAOF, sort of; they're not part of the MicroReleaseExceptions stuff though03:25
RAOFAnd mesa is very much in the same boat (although with less historical capacity for non-deadly stable updates).03:25
brycethe SRUs they put out are like SRU bugfix collections03:25
RAOFThey're on a bi-weekly stable kernel release cadence, aren't they?03:26
bryceright03:26
brycewe'd be in the same boat were we doing bunches of mesa cherrypicks wrapped up together03:27
RAOFYeah.03:27
brycebut figuring out what changes from the mesa tree are worth cherrypicking is non-trivial03:27
RAOFSo 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
bryceI tend to agree03:28
RAOFWell, *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
bryceI'm not sure that'd make it more obvious03:29
brycesome of the patches are pretty tersely described, and few have bug refs03:29
RAOFAh, I'm thinking of a different problem.03:30
RAOFYou'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:30
brycebut 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 set03:31
bryceright; the former is what we have to do for SRUs right now03:31
RAOFWhich 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
RAOFWhere only the extra cherry-picks need much individual scrutiny.03:32
brycein any case, sort of moot until mesa does proper stable point release updates03:36
RAOFYeah :)03:37
brycebtw, 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
bryceat least up thru a8032483ecc8750ad58d89c4d96af6ef82a475e2 would get the new radon chip id's03:38
bryceradeon03:39
bryceup to that release would also include some of the sandybridge work03:40
bryce(possibly the stuff people are complaining that fedora has but we lack?)03:40
RAOFI'll fold that into the next mesa upload.03:43
Sarvattfor 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 :P03:47
RAOFDamnit, I don't think I can make -intel's copy_fb patch nice enough to upstream.03:48
brycehttps://wiki.ubuntu.com/KernelTeam/KernelUpdates03:48
bryceSarvatt, no, there's plenty enough on the 7.10 branch to be scared of ;-)03:49
bryceproblem 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-obvious03:50
RAOFgit hate xserver-xorg-video-intel07:58
tjaaltonthere, there..08:04
RAOFCombining the two favourite hate targets!  git and -intel!08:08
bryceheh08:23
RAOFHm.  That was rather stupid.08:32
RAOFSo, it's difficult to tell in oneiric if copy_fb is actually working.  It is, however, now plausible *and* X actually starts!08:38
RAOFbryce: 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
ubot4`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/79159613:09
=== ara_ is now known as ara
=== Tux is now known as Guest78361
=== yofel_ is now known as yofel
=== Sarvatt_ is now known as Sarvatt

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!