20:12 #startmeeting 20:12 Meeting started Mon May 12 20:12:26 2014 UTC. The chair is pitti. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 20:12 20:12 Available commands: action commands idea info link nick 20:12 (not that we have much of an agenda..) 20:12 #topic action review 20:12 can you help me out here? last report is from Apr 14, without loose ends 20:13 except "slangasek to work with SRU team to get a list of how the provisional MREs have/haven't been used ", but that now went to mail 20:13 was there anything from two weeks ago? 20:13 I think that's about the only outstanding thing we have. 20:13 I don't believe we had anything further 20:13 That and the meeting time. 20:14 there's also sabdfl's "matters approaching", but that rather sounds like taking some good time of thinking and replying by mail; objections? 20:15 nope 20:15 Yeah, I don't think we'll get anywhere discussing that via IRC just yet. 20:15 #topic MRE review 20:15 Some folks will be having heated debates about that in Malta soon. 20:15 (The sabdfl thing, not MREs) 20:16 so, TBH I don't feel like interactively discussing every single one, but we shoudl talk a bit about "in vs. out" criteria 20:17 for all except LibO it's not quite clear whether the "new errors reported" were actual regressions or people just happened to send the first report on the update 20:17 Right, and I think we need to know that. 20:17 but that's hard to automate, I guess we can just ask for a list and do some spot-checks 20:18 If it's a regresison, it's interesting, though we also expect, I think, that MRE's might introduce new bugs (new code has new bugs), and that needs to also be weighed against responsiveness of the people responsible for the MRE in responding to those. 20:18 We don't *want* them to introduce new bugs, but we may have to be realists too. 20:18 is there anything in the list that sticks out? 20:19 at least it seems that the entries on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions/ProvisionalStatus have all actually been used in practice 20:19 but that is perhaps only packages which actually *have* been updated; it's by far not the complete one from https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions 20:19 e. g. firefox is missing, and we update that all the time 20:19 ah sorry, no, these are *just* the provisional ones 20:20 The only thing that immediately jumps out at me is mesa, and it the stickiest one from the POV of "we need this for HWE" and "we know it's going to occasionally introduce new bugs". 20:21 e. g. bug 1316988 doesn't look like a regression 20:21 bug 1316988 in openvswitch (Ubuntu) "openvswitch-datapath-dkms 1.4.6-0ubuntu1.12.04.2: openvswitch kernel module failed to build" [Undecided,Confirmed] https://launchpad.net/bugs/1316988 20:21 infinity: yeah, that's pretty much the only one which makes me nervous, too 20:21 the OpenStack bits generally seem to keep their "we don't break stuff" promise 20:22 Well, the openstack bits also get installed on machines without errors submissions, so we're relying on manual LP bug submissions there. 20:22 e. g. ceph, heat, neutron etc. look exemplary 20:22 ah right 20:22 oh, right 20:22 Which is, eg, why vlc looks so bad. Lots of people use it, and all those people are on desktops with automagic error submission. 20:22 But I suspect almost none of the vlc errors are regressions in VLC. I'd have to go hunting to confirm that, mind you. 20:22 * pitti looks at bug 1189909 20:22 bug 1189909 in neutron "dhcp-agent does always provide IP address for instances with re-cycled IP addresses." [Undecided,In progress] https://launchpad.net/bugs/1189909 20:23 I can't be sure, but at least there's no comment that suggests a regression 20:23 FWIW, openvswitch is also an HWE issue. They're backporting new versions to be compatible with HWE kernels. 20:23 multimedia stuff crashes all over, it would probably be hard to figure out what are actually regressions 20:24 At the time, we argued that making the old version build would be preferable, but there were claims this ranged from difficult to impossible. 20:25 infinity: yeah, "new errors reported: 183" is almost surely because we dno't offer the LTS->LTS upgrade before releaseing the .1 20:25 #1316988 isn't a package regression, though, it's just a user who removed their headers. 20:25 infinity: right 20:26 So, none of this jumps out at me as either people who don't need their MRE (they're all being used) or people who are abusing them. 20:26 so, so far we don't really have proof that anything actually regressed (except for LibO, I didn't go through all these bugs yet) 20:26 and I'd rather do that ^ off-meeting 20:26 Other than LibreOffice, which is scary as crap. 20:27 yes, but this is also one of these packages which get bug reports all the time :) 20:27 But for mesa, I'd like to perhaps hunt down the desktop team and get some formal commitment from them for regression tracking. 20:27 Since I don't think we can ask them to stop updating mesa, but we don't want to blow up OpenGL desktops like GNOME and Unity. 20:27 bug 1134974 20:27 bug 1134974 in mesa (Ubuntu) "compiz and other display misbehavior on HD4000 after xatracker/mesa components upgraded to 9.0.2-0ubuntu0.1" [Undecided,New] https://launchpad.net/bugs/1134974 20:28 that almost surely is a regression 20:28 hrm 20:28 mesa | 9.0-0ubuntu1 | quantal | source 20:28 mesa | 9.0.3-0ubuntu0.4 | quantal-updates | source 20:29 and downgrading to 9.0-0ubuntu1 fixed this 20:29 so, one piece of (bad) proof 20:29 * pitti chuckles at bug 1070178 20:29 bug 1070178 in mesa (Ubuntu) "plz hlp compiz note working " [Undecided,New] https://launchpad.net/bugs/1070178 20:30 ... 20:30 but #1134974 is worrying -- it didn't get any triage etc. 20:31 Right. And it stops mattering in 4 days, but I don't want this to be a pattern. Those bugs need to be looked at. 20:31 and TBH for LTSes we have the backported stacks now, and for non-LTSes, who bothers -- do we really have OEM customers on 9-month releases? that sounds scary 20:32 so my gut feeling is that we need to inspect the LibO bugs further, revert the mesa one for the time being, and turn the others into "approved" ones 20:32 mdeslaur, infinity: WDYT? 20:32 pitti: The backport stacks have the same issue. How do you think they come to exist? :P 20:33 libgl1-mesa-dri-lts-quantal: 20:33 Installed: (none) 20:33 Candidate: 9.0.3-0ubuntu0.4~precise1 20:33 infinity: yes, but they don't affect existing systems 20:33 No, it's possible 9.0.3 fixed that bug (it was reported against 9.0.2), but no one's looked at it to see. 20:33 s/No/Now/ 20:33 if you install from a X.Y.2 image and have a broken system right away, that's much less of a pain than breaking a running productino system 20:33 pitti: They absolutely can affect existing systems. 20:33 pitti: by revert, you mean revoke it's status? 20:33 pitti: If you installed with an lts-q stack with mesa 9.0 and upgraded to a newer backport of the stack, boom. 20:34 infinity: yes, and I want this to stop (as that's the MRE, isn't it?) 20:34 the backported stacks have parallel packages 20:34 pitti: Erm. I think we're talking past each other? 20:35 as to what backported kernels and X.orgs do, they probably break loads of machines; but dist-upgrade won't automatically get those on existing systems 20:35 pitti: If we revoke the MRE for mesa, we're revoking it for backport stacks too. 20:35 pitti: Precise users would have absolutely gotten this breakage automatically. 20:35 infinity: how so? linux/xorg/etc. don't have an MRE either, and get backported 20:35 infinity: yes, *this* breakage from the bug above (when they upgrade precise to quantal-updates) 20:35 that's what I'd like to stop :) 20:35 pitti: mesa-lts-q started out in the "good" version and was later updated to match Q's new version. 20:36 infinity: ah, because the newer upstream release was backported again? 20:36 yes, that'd be the MRE again 20:36 Anyhow, we do new mesa microreleases for HWE reasons too. Waiting 6 months for a new backport stack doesn't help. 20:37 I don't think rejecting it outright is the answer, I think the answer is a better bug triage/followup commitment. 20:37 There's been no activity on that bug from the desktop team, nor any piling on "me toos" since 9.0.3 was released. 20:37 well, in order to avoid regressions, you'd have to test on all hw of teh world 20:37 My guess is that 9.0.3 fixed it, but we have no way to know, cause no one's bothered to look. 20:37 triaging bugs after releaseing to -updates is important, but then the damage is done already 20:37 *nod* 20:38 But, if you want to go the more conservative route here, you're an ex-desktopper, you probably have a better handle on what'll work. 20:38 well, it never really worked 20:38 Heh. 20:38 it's an eternal conflict between OEM always wanting teh latest and greatest and existing installs 20:38 (and not having an OEM archive to go on top of that) 20:39 I think about 99% of the things we do in the name of HWE are crazy, but we have to make some concessions for people who insist on buying new computers. 20:39 were those mesa srus done for oem's benefit, or where they to correct issues people were having? 20:39 I doubt it was for OEM. 20:39 Other than the part where OEM likes the latest crack. 20:40 But bringing in mlankhorst to the discussion would be helpful. 20:40 of course we also have -backports now which is enabled by default, so maybe that'd be a better route for these cases 20:40 pitti: Enabled, but you don't install from it. 20:40 pitti: Which, from an HWE perspective, is useless, and from a bugfixing perspective, is almost also so. 20:41 infinity: right, but we own our installer, so there's little which keeps the installer from picking mesa from -backports 20:41 but that again of course only works for the first update 20:41 every subsequent one will again break existing machines 20:41 so, back to square #1 20:42 but still, from a community/TB POV this is a fail 20:42 Right, I think we need to have a chat with Maarten, see why they think they need this MRE, if there's any way it can be done more safely, and if not, drop the whole thing. 20:43 I'll note a new micro-release of mesa landed in trusty-proposed 9h ago. :P 20:43 yay 20:43 heh 20:43 ack, so we need a follow up with the desktop team here 20:43 I'll do that, as a bit of an apology for missing the last few meetings 20:43 Shiny. 20:44 * pitti pitti to follow up with Maarten wrt. mesa MRE 20:44 Feel free to miss more in the future, if it leads to you taking all the actions. 20:44 can we review the LibO bugs offline and respond to the mail? 20:44 Yeah, I think LibO is too heavy to dive into on IRC. 20:44 and any objections for the other provisional MREs to become blessed ones? 20:44 not from me 20:45 And also doesn't have the "HWE" excuse going for it, so if it turns out to just completely suck, I doubt anyone would argue dropping the MRE. 20:45 I'm fine with the rest of the list. 20:45 ack 20:45 Maybe a quick scan through VLC crashes would be fun, but I bet it's mostly in underlying libraries and random corrupt media files, etc. 20:45 #agreed promote provisional MREs except LibO and mesa to permanent ones 20:45 Video playback software sucks. 20:45 (meh, neither all-caps nor #-ed ones work; go meetingology) 20:46 ah, right 20:46 I smell a volunteer 20:46 (I'll do the LibO ones in exchange) 20:46 Yeah, I'll have a hunt through a sampling of VLC crashes to confirm (or not) my suspicions there. 20:46 * pitti infinity to review the vlc MRE bugs 20:46 * pitti pitti to review the LibO MRE bugs 20:47 Did meetingology give up on life? 20:47 meetingology: wake up 20:47 mdeslaur: Error: "wake" is not a valid command. 20:47 #halp 20:48 Oh, that should be "#action " 20:48 I get nothign back in privmsg 20:48 #action pitti to follow up with Maarten wrt. mesa MRE 20:48 * meetingology pitti to follow up with Maarten wrt. mesa MRE 20:48 Etc. 20:48 yes, but #agreed didn't work either 20:48 anyway, I don't really use that; the real IRC log is fine 20:48 Heh. 20:48 #topic community bugs 20:48 zarro 20:49 Our community is bug-free? 20:49 nothing new on the ML either 20:49 I privmsg'ed kees about meeting time 20:49 #topic AOB 20:49 nothing from me; infinity, mdeslaur? 20:50 10 20:50 nope 20:50 5 20:50 I'm good. 20:50 0 :) 20:50 great 20:50 Not like we have quorum anyway. :P 20:50 so, c'est l'heure de dormier 20:50 thanks and good night! will do the reporting stuff tomorrow morning 20:51 thanks pitti, infinity! 20:51 err, "dormir" 20:51 français est trop difficile 20:51 #endmeeting