#title #ubuntu-meeting Meeting Meeting started by mdz at 21:14:27 UTC. The full logs are available at http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-23-21.14.log.html . == Meeting summary == ''LINK:'' https://wiki.ubuntu.com/TechnicalBoardAgenda (mdz, 21:14:32) ''LINK:'' https://wiki.ubuntu.com/TechnicalBoardAgenda (mdz, 21:14:35) *Action review *Mythbuntu LTS *MRE request for VLC (bdrung) *Mesa provisional MRE ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2012-July/001352.html (mdz, 21:26:55) *MRE request for VLC (bdrung) *stable updates exception policy *closing business Meeting ended at 22:05:30 UTC. == Votes == == Action items == * (none) == People present (lines said) == * mdz (97) * bdrung (31) * kees (30) * ScottK (7) * stgraber (6) * Daviey (6) * meetingology (3) * czajkowski (2) * LordOfTime (2) * ubottu (2) == Full Log == 21:14:27 #startmeeting 21:14:27 Meeting started Mon Jul 23 21:14:27 2012 UTC. The chair is mdz. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 21:14:27 21:14:27 Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired 21:14:32 #link https://wiki.ubuntu.com/TechnicalBoardAgenda 21:14:35 https://wiki.ubuntu.com/TechnicalBoardAgenda 21:14:44 #topic Action review 21:14:52 soren to continue brainstorm review 21:15:03 I have no idea about this and soren doesn't seem to be around. anyone know? 21:15:12 kees to ping LP advocate about LP: #252368 21:15:20 soren's task: I haven't seen any email about it, so I assume it's continuing 21:15:30 I've asked, and it's in limbo. 21:15:39 there doesn't seem to be a sensible way to unlimbo it, either. 21:15:56 already advocated bugs aren't seeing any attention, so it's unlikely this one will either. 21:16:21 so you asked the advocate about it, and they said there's nothing they can do? 21:16:47 basically, yes. 21:16:59 that sounds...less than ideal 21:17:09 is there an escalation path? 21:17:27 the LP team says that to fix bugs, people should do it themselves. 21:17:32 that's not clear. 21:17:50 I'll continue the discussion. 21:18:04 I could raise it with debian-derivatives 21:18:13 that might work too 21:18:36 I'm not sure what the barrier to entry is like these days for LP development 21:18:40 but this sounds pretty non-trivial to implement 21:18:43 yeah 21:18:50 sounds like LP development has stopped? 21:19:05 even the stakeholders don't know where to escalate to. 21:19:46 I'll send an email about it 21:19:51 but it sounds like there's no next action for this particular bug 21:19:52 yeah, LP is in maintenance-only mode... any feature work should be done outside of the LP team, though one LP squad is usually available for code reviews and helping people contribute 21:19:55 Is this really a pressing matter ? 21:20:06 kees, can you put a comment on the bug with the latest update? 21:20:09 sure 21:20:23 Daviey, it is pressing enough to warrant some action within 4 years :-) 21:20:38 its 4th anniversary is coming up 21:20:45 It seems to me that the barrier of creating a LP account is so low, that the bother to implement this is crazy use of resources. 21:21:20 Daviey, that would be a reasonable position for the Launchpad project to take 21:21:31 and if they took that position, I think we would probably accept it 21:21:44 but that's a different thing from just letting the request sit 21:22:03 anyway, moving on 21:22:03 right 21:22:04 #topic Mythbuntu LTS 21:22:17 it looks like this got three +1s on the mailing list 21:22:20 and no opposition 21:22:23 flacoste,mrevell or cztab is probably the escalation path, 21:22:25 so I think it's done 21:23:02 I'm not sure who put it on the agenda 21:23:12 I think it just needs a rubber stamp 21:23:23 Daviey: sup 21:23:27 unless anyone disagrees, I'll follow up to the mailing list and stamp it 21:23:48 czajkowski, do you have a highlight for cztab? :-) 21:23:54 kees, stgraber, you OK with that? 21:24:00 mdz: oddly enough I do :) 21:24:17 mdz: I'm fine with that 21:24:30 ok 21:24:40 #topic MRE request for VLC (bdrung) 21:25:05 bdrung, hi 21:25:39 (/me is fine too) 21:25:42 Daviey: When it's come up, it was important to a number of DD's. It's socially important in our relationships with our primary upstream. Technically less so. 21:25:55 (sorry, missed the discussion earlier) 21:26:00 bdrung, are you there? 21:26:45 we'll skip ahead 21:26:51 #topic Mesa provisional MRE 21:26:55 #link https://lists.ubuntu.com/archives/technical-board/2012-July/001352.html 21:27:07 this is from RAOF 21:27:41 mdz: hi 21:27:58 bdrung, hi, we'll come back to your topic in a moment 21:28:06 kees, stgraber, thoughts on the Mesa request? 21:28:25 if piglet can get run on several HW types, I'd be happy with the MRE 21:28:29 (run and pass, that is) 21:28:53 quickly reading the e-mail again, I remember thinking it was a reasonable testing plan 21:29:30 yes, I think the important thing is that the regression test suite passes, and running it in the proper environment (where that's not the buildd) is a no-brainer 21:29:46 OK, I'll follow up and ack it 21:30:06 #topic MRE request for VLC (bdrung) 21:30:13 right, +1 from me with the plan that the regression test runs on all the hardware combination in the lab 21:30:13 bdrung, go ahead 21:30:57 VLC has a maintenance branch (currently 2.0.x) where they mainly apply bug fixes 21:31:42 i like to get a MRE that allows getting new 2.0.x versions into precise 21:32:26 bdrung, what's the regression testing story? 21:32:30 the 2.0.2 release closes 9 Launchpad bugs and many more bugs that were not reported on Launchpad 21:32:39 wow, 9. 21:33:13 kees: IIRC the 1.1.0 release held the record 21:33:23 I bet :) 21:34:01 mdz: the good story: we have a daily PPA for the upstream maintenance branch 21:34:47 the bad story: the package has a test suite that is currently not run on compile time (it succeeds locally, but one test fails in the chroot) 21:35:26 the test suite is very small and does not cover much of the program 21:35:28 can that test be removed from the suite for the builds? it would be nice to have those tests work in the build 21:35:31 oh 21:35:35 is the failure a regression, or has it failed before? 21:35:37 ah 21:35:42 so the test suite is not very relevant 21:36:17 bdrung, you mentioned the branch includes "mainly" bug fixes...how "mainly"? :-) 21:36:35 an MRE would usually imply that their policy is at least as strict as ours 21:37:15 upstream makes sure that they keep their ABI stable in their maintenance branch 21:38:33 they apply bug fixes, update translations, add new translations 21:39:22 that seems fine 21:39:34 yes 21:39:36 their NEWS files only states fixes 21:39:48 bdrung, has it been SRUd many times before? 21:40:05 the updated libraries and Mac OS changes are irrelevant for us 21:40:18 mdz: at least once 21:40:47 what's the rationale for a standing exception, as opposed to just doing an SRU for 2.0.2? 21:41:49 the maintenance branch get security fixes too and it will fix more bugs 21:42:22 seems like a win to me. have there been reports of regressions in past SRUs? 21:42:47 i like to get all 2.0.x releases into precise to have a version with no security hole and less bugs 21:43:12 kees: i can't remember a regression 21:43:27 without a regression testing plan/suite, there is certainly a higher risk of regressions 21:43:36 but the impact of a regression in vlc is smaller than in many other packages 21:43:55 such as, say, Mesa :-) 21:43:57 right 21:43:57 oh wait. there was a pulseaudio output plugin change that causes some trouble 21:44:34 this change revealed some pulseaudio/driver bugs IIRC 21:44:59 were we able to fix the regression promptly? 21:45:11 or did we have to roll back the whole thing? 21:46:21 i think it was bug #805807 21:46:23 Launchpad bug 805807 in vlc (Ubuntu Natty) "Sound is not synchronised with the video" [Undecided,Confirmed] https://launchpad.net/bugs/805807 21:48:12 that looks like it's...still open in natty? 21:48:38 did we regress it and then not fix the regression? 21:49:28 no, it was an upstream regression from one release to another. 21:50:29 I don't follow 21:51:26 the initial problem was bug #743323 21:51:27 Launchpad bug 743323 in vlc (Ubuntu Natty) "vlc memory leak" [High,Fix released] https://launchpad.net/bugs/743323 21:51:28 the bug reads like a regression in a stable update 21:52:39 so far it seems like in favor we have: relatively low impact package, bugfix-only branch 21:52:44 yes, seems so 21:53:03 and against: not much in the way of regression testing 21:53:16 stgraber, kees, thoughts? 21:53:18 I would be happy to grant a provisional MRE 21:53:42 the pulseaudio plugin was rewritten to fix the memory leak, introduces a regression and was later fixed 21:53:44 if the regression stuff repeats, then I'm not sure we can safely do MREs on VLC, even though it fixes so much stuff 21:54:01 and if regressions do get fixed, that's a good sign. 21:54:10 provisional sounds reasonable, we can see how ti goes after we get one or two upstream point release in. If we get any regression, we might have to consider more QA before pushing something to updates 21:54:23 if I were considering whether it makes sense to SRU 2.0.2, I would probably say yes, go for it, and if it regresses, we can just roll it back 21:54:41 but since I'm supposed to consider whether it should get a standing exception, I'm not so sure 21:55:03 1.1.10 contained the fix and 1.1.12 fixes the regressions 21:55:09 wow. push something out, and roll back if it regresses? O_o 21:55:51 As an emergency, great.. but as a /plan/? 21:56:26 Daviey, I'm open to other opinions 21:56:53 but I don't think it makes sense to apply a blanket approach to all packages 21:57:07 the fallout from regressions is very severe in some cases, and very little in others 21:57:28 if the sound in VLC is out of sync for a few days, that's a pretty limited impact 21:57:38 compared to, say, a graphics driver hang 21:57:53 i got two bug reports against the daily-stable PPA package that i could fix (otherwise these bugs could have entered the archive later) 21:58:31 my only other idea would be to come up with a manual regression testing plan 21:58:37 which covers the most common/important functionality 21:58:51 play some streams in various formats, check that it works as expected, that sort of thing 21:59:16 i do test the package with some video files, but that do not cover much of vlc 21:59:36 interesting that it didn't catch the audio sync issue 21:59:51 it was connected to the underlying hardware 21:59:55 ah 22:00:02 only some soundcards triggered it 22:01:30 the policy is that a provisional MRE can be approved by any TB member 22:01:42 and two have expressed support, so I think there's nothing more to discuss on this specific request 22:01:52 what should be done if a new upstream release fixes security bugs? 22:02:07 I defer to the security team on that 22:02:20 anything else on this topic before we move on? we're out of time 22:02:23 get it SRUed and then copied to -security or a separate fix for -security? 22:02:38 bdrung: IME ask the security team and they'll tell you. 22:02:44 k 22:02:51 #topic stable updates exception policy 22:02:52 bdrung: you can ask security questions to the security team in #ubuntu-hardened if you want, they might be able to answer 22:02:56 (sorry for butting in ) 22:03:05 based in part on the discussions in this meeting, I'd like to propose a small clarification 22:03:15 replace: 22:03:15 * regression tests are enabled in the package's build 22:03:16 with: 22:03:20 * regression tests are always run on the update before it is released (e.g. by being enabled in the package's build) 22:03:31 kees, stgraber, OK with that? 22:03:42 That's not always feasible. 22:03:59 There are packages that have tests that require a network. 22:04:11 ScottK, it's a noop for that case 22:04:30 this is only broadening the criteria, not restricting them further 22:04:38 mdz: +1 22:04:43 * kees nods 22:04:44 OK. 22:04:44 +1 22:04:50 done 22:04:55 #topic closing business 22:05:02 who's next for chair? soren? 22:05:05 mdz: I understand now. I read it backwards. Thanks. 22:05:19 I think so, yes. can you email him to remind him? 22:05:24 (since he's not here?) 22:05:27 will do 22:05:29 thanks all 22:05:30 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)