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