/srv/irclogs.ubuntu.com/2014/01/06/#ubuntu-meeting.txt

=== freeflying_away is now known as freeflying
=== panda is now known as Guest88517
=== shuduo|afk is now known as shuduo
=== charles_ is now known as charles
jdstrandhi!16:32
tyhickshello!16:32
mdeslaur\o16:32
chrisccoulsonhi!16:32
mdeslaurhiya chrisccoulson!16:32
chrisccoulsonhi mdeslaur16:32
jjohansenhey16:32
jdstrand#startmeeting16:32
meetingologyMeeting started Mon Jan  6 16:32:59 2014 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology.16:32
meetingologyAvailable 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 #votesrequired16:32
jdstrandThe meeting agenda can be found at:16:33
jdstrand[LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting16:33
jdstrand[TOPIC] Announcements16:33
=== meetingology changed the topic of #ubuntu-meeting to: Announcements
jdstrandHappy new year! Welcome back and I hope everyone had a nice break :)16:33
mdeslaurhappy new year!16:33
jdstrandthanks to Jonathan Riddell (Riddell) provided debdiffs for precise-saucy for qt4-x11 (LP: #1259577)16:33
ubottuLaunchpad bug 1259577 in qtbase-opensource-src (Ubuntu Trusty) "Security: XML Entity Expansion Denial of Service" [Undecided,Fix released] https://launchpad.net/bugs/125957716:33
jdstrandthanks to Jonathan Riddell (Riddell) provided debdiffs for raring-saucy for qtbase-opensource-src (LP: #1259577)16:34
jdstrandthanks to Stefan Bader (smb) provided debdiffs for precise-saucy for xen16:34
jdstrandYour work is very much appreciated and will keep Ubuntu users secure. Great job! :)"16:34
=== sarnold_ is now known as sarnold
* Riddell bows16:35
jdstrandheh :)16:35
jdstrand[TOPIC] Weekly stand-up report16:35
=== meetingology changed the topic of #ubuntu-meeting to: Weekly stand-up report
jdstrandI'll go first16:35
jdstrandI'm apparently in the happy place this week. not sure how I got here, but I'll take it :)16:36
mdeslaurjdstrand: you won the dice roll :)16:36
chrisccoulsoncongratulations!16:36
jdstrandI have pending updates and work items, though most of the beginning of this week will be working on going through my holiday backlog16:36
jdstrand\o/16:36
jdstrandmdeslaur: you're next16:36
mdeslaurI'm on triage this week16:36
mdeslaurI have a couple of pending updates I'm testing which should get released this week16:37
mdeslaurlike puppet this afternoon probably16:37
mdeslaurI also have some catching up to do16:37
mdeslaurand I think I'm on patch piloting on friday16:37
mdeslaurthat's about it16:37
mdeslaursbeattie: you're up16:37
sbeattieI'm on apparmor again this week16:37
sbeattieI need to sync up with jjohansen on IPC stuff16:38
sbeattieI also need to review his dfa minimization patch (and the bug fix for the issue it exposed) as it gives a pretty big policy compilation win.16:38
mdeslauroh cool...do we know how big?16:39
jjohansenit varies with the dfa16:39
jjohansenbut there are several examples16:39
sbeattieanother 20%-ish gain, though for certain things like the evince profile with likewise-open variables added, it shaves 50-60% off of compilation time.16:40
jdstrandthat is the one that doesn't do much for the click apps, correct?16:40
mdeslauroh, nice!16:40
sbeattie(23 seconds down to 9 seconds or so)16:40
jdstrandor was that something else?16:40
sbeattie(on my laptop)16:40
jdstrandbtw, these compilation speedups are truly awesome :)16:40
sbeattiejdstrand: yeah, I didn't see much gain for the click profiles you posted to the list.16:40
jdstrandok16:40
jjohansenjdstrand: no, that is a different one, this one does a little more for the click apps16:41
jdstrandwe got big gains on them in the previously patches though16:41
jdstrandah16:41
jjohansenweather applet profile from ubuntu touch    0.618s   105673 bytes  to    0.432s   89300 bytes16:41
sbeattiejjohansen: oh? Maybe I'm confused.16:41
jdstrandwell, good :)16:41
* sbeattie kicks monday16:41
sbeattieanyway, I have some other stuff to catch up on as well.16:41
jjohansennot a huge improvement but better than the diff-encode which did almost nothin16:41
tyhicksthat improvement should be pretty nice on ARM :)16:41
jdstrandyeah16:42
jdstrandand the emulator16:42
tyhicksgood point16:42
sbeattieAnyway, that's all I have. tyhicks, you're up.16:42
tyhicksI'm playing catch up this morning16:42
tyhicksI was disconnected nearly the entire break16:43
tyhicksI've gotten through most email - the big thread that is coming up next is the kdbus thread16:43
tyhicksI've got to tie up some loose ends from before the holiday16:43
tyhicksbenchmarking ext4 and ecryptfs on ARM is done - I need to figure out how best to do a LUKS-based partition16:44
jdstrandnice16:44
mdeslaurtyhicks: good luck with the kdbus thread16:44
jdstrandso, since kdbus lit up over the holidays, it occurred to me that it might be wise to send up our apparmor patches to the dbus mailing list16:45
tyhicksjdstrand: that would be good16:45
jdstrandthat said, I am a few days our of date on said thread16:45
tyhicksI've kept them in an upstreamable form in our dbus package, so it shouldn't be much work for me to get them organized and sent out16:46
jdstrandwhile not completely unsurprised, the tenor of the mailing list discussion is considerably different than what I thought we had with kdbus upstream at plumbers16:46
tyhickswe only spoke with gregkh at plumbers and I don't think he's been involved in the thread16:47
jdstrandagain, I am out of date, but it seems clear we need to continue having these discussions16:47
tyhicksagreed16:47
jdstrand(and thanks to mdeslaur for responding over the holidays)16:47
tyhicksI'm a little blocked on sending out the yama and config patches for Touch because I don't have a device to run the autopilot tests on (and the emulator doesn't seem to work, either)16:47
jdstrandtyhicks: what devices do you need?16:48
tyhicksjdstrand: umm... any of the better supported devices16:49
jdstrandtyhicks: so, you have grouper? it tests ok there?16:49
tyhicksjdstrand: I have grouper but that's the old kernel that requires a complete yama backport, which I didn't do16:49
jdstrandah16:49
jdstrandso you need manta and mako, correct?16:50
tyhicksyes, those would be best16:50
jdstrandperhaps you could provide test instructions to jjohansen and chrisccoulson, and they can each do one?16:50
tyhicksok16:50
tyhicksI can do that16:51
jdstrandI have a mako and am running trusty, but it is my dogfood device so I'd rather not break it :) that said, if it is helpful, you can give me the instructions too16:51
tyhicksit will also probably be a bit of an issue for user data encryption16:51
tyhicksI'll follow up with the team when I have debs and instructions16:52
tyhicksthat'll probably keep me busy for this week16:52
tyhicksthat's it for me16:52
tyhicksjjohansen: you're up16:52
jjohansenwell it looks like I'll be testing for tyhicks this week ;)16:52
tyhicksjjohansen: you're the lucky guy with all the hardware :)16:53
jdstrandhopefully it will be nearly automatable16:53
jjohansenthere is some catch up to do from vacation and then its back to apparmor16:53
mdeslaur\m/ AppArmor rocks! \m/16:53
jdstrand\m/ *rock* \m/16:53
jjohansenI've got the rest of the dfa stuff I need to push out so that we can start build some new tests16:54
ogra_that gives metal as a service a totally new meaning16:54
mdeslaurhehe16:54
sarnoldgood idea!16:54
jjohansenhaha16:54
jjohansenand there is of course the outstanding ipc work16:55
jjohansenand coordination with sbeattie on tests there16:56
jjohansenand probably more bludgeoning of ones self against a certain thread16:56
mdeslaurhehe16:58
jjohansenI think thats it from /me sarnold your up16:58
jdstrandjjohansen: oh, thank you for also responding to the thread over the holiday16:58
jdstrandlike I said, I am behind and didn't see that part of the thread16:59
* jjohansen is only sorry he didn't get to it earlier, but then again Amanda would have made /me even sorrier to have responded earlier16:59
jdstrandheh16:59
jdstrandwe got some responses out-- I think we are ok :)17:00
sarnoldI'm on community this week, it's been a while since I've checked in on email, so I'll have a fair amount of digging-out to be done this week. but don't let that deter anyone from sending in patches :) I know there's some MIR audits needing attention, some old and some new, and iirc some apparmor patches needing review17:00
sarnoldI suspect that'll be the week, but it's getting around time to dust off the old objectives and see how those are going.17:01
sarnoldI think that's it for me, chrisccoulson?17:02
chrisccoulsonhi :)17:02
chrisccoulsonso, i left for vacation with a saucy build of oxide on arm which didn't work, and an attempted build for trusty which didn't succeed ;)17:02
chrisccoulsoni'm fixing those this week17:02
chrisccoulsoni started work over the holiday to remove the run-time dependency on X, which I need to do to make it work on ubuntu touch in any case17:03
chrisccoulsoni don't think there's anything else from me17:04
jdstrand[TOPIC] Highlighted packages17:04
=== meetingology changed the topic of #ubuntu-meeting to: Highlighted packages
jdstrandThe Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.17:05
jdstrandSee https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.17:05
jdstrandhttp://people.canonical.com/~ubuntu-security/cve/pkg/pyfribidi.html17:05
jdstrandhttp://people.canonical.com/~ubuntu-security/cve/pkg/graphite2.html17:05
jdstrandhttp://people.canonical.com/~ubuntu-security/cve/pkg/libjgroups-java.html17:05
jdstrandhttp://people.canonical.com/~ubuntu-security/cve/pkg/sleuthkit.html17:05
jdstrandhttp://people.canonical.com/~ubuntu-security/cve/pkg/mc.html17:05
jdstrand[TOPIC] Miscellaneous and Questions17:05
=== meetingology changed the topic of #ubuntu-meeting to: Miscellaneous and Questions
jdstrandDoes anyone have any other questions or items to discuss?17:05
jdstrandmdeslaur, sbeattie, tyhicks, jjohansen, sarnold, ChrisCoulson: thanks!17:08
jdstrand#endmeeting17:08
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology
meetingologyMeeting ended Mon Jan  6 17:08:39 2014 UTC.17:08
meetingologyMinutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-01-06-16.32.moin.txt17:08
meetingologyMinutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-01-06-16.32.html17:08
mdeslaurthanks jdstrand!17:08
tyhicksthanks!17:08
jjohansenthanks jdstrand17:09
sbeattiejdstrand: thanks!17:09
sarnoldthanks jdstrand !17:10
=== wendar_ is now known as wendar
* slangasek waves20:59
mdeslauro/21:00
infinity\o21:00
* stgraber waves21:00
slangasekso, ah - who's in charge? :)21:01
infinityNo idea!21:03
sabdflhello folks21:03
* slangasek waves to sabdfl 21:03
sabdflevening slangasek21:03
slangasekI nominate stgraber to chair, since he's here and knows the ropes :)21:03
stgraberwell, we haven't had a meeting in ages, so I think we lost track :)21:03
sabdfldefrost the book, shall we?21:03
stgraber#startmeeting Technical Board meeting21:03
meetingologyMeeting started Mon Jan  6 21:03:45 2014 UTC.  The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology.21:03
meetingologyAvailable 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 #votesrequired21:03
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board meeting | Current topic:
stgraber#topic Action review21:04
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board meeting | Current topic: Action review
stgraberThe last action we had was to get a new TB, which we now have, so I'll drop that one from the agenda!21:04
mdeslaur\o/21:04
stgrabernow as for meeting chair, I'd suggest we stick to what we used to do, which is to simply go through https://launchpad.net/~techboard/+members21:06
sabdflit's late in Cape Town, so i'll just say welcome to the new TB, and thanks21:06
stgraberso the next meeting chair (20th of January 21 London time) will be infinity21:06
infinityI'll be sure to hire a secretary before then.21:06
* stgraber tries updating the wiki, gives up (taking way too long) and gets back to the meeting21:07
stgraber#topic Review our current "provisional" Micro Release Exceptions21:08
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board meeting | Current topic: Review our current "provisional" Micro Release Exceptions
slangasekis there a current list?21:08
stgraberMy vague memory of this is that kees was taking a look at our list of privisional MREs on the wiki and suggesting which should be made permanent exceptions and which should be dropped (because of bad results or because they weren't used)21:08
stgraberhttps://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions21:09
slangasekok21:09
slangasekshould we carry this over, since kees isn't here?21:10
stgraberyep, I believe it was an ongoing thing anyway as it required input from some SRU team members and also from errors.u.c stats (bdmurray)21:10
stgraber#topic Requiring TB members to be Ubuntu core developers [micahg]21:10
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board meeting | Current topic: Requiring TB members to be Ubuntu core developers [micahg]
stgrabermicahg_: around by any chance?21:10
slangasekI know I saw discussion of this on list21:11
infinityThis would be slightly less contentious now that it happens to be true.21:11
slangasekwhich makes sense, it was a timely topic before the election, not so much now ;)21:11
* stgraber quickly reads the ML thread again21:12
slangasekinfinity: well, I think there was not consensus about this principle21:12
infinityslangasek: No, indeed, I can see the argument for people who prefer to recuse themselves to limit upload rights, etc.21:12
slangasekone of the points made was that if the developers at large hold someone who's not core-dev in such esteem that they choose to elect them to the TB, that it doesn't make sense to block them with a formal rule21:13
infinityThough, the spirit of the thing--if you're not qualified to be a core-dev, you're not qualified to be on the TB--is likely not contentious.21:13
slangasekright21:13
sabdfli think it was well intentioned but not a sensible constraint21:13
sabdflwe have good checks and balances in the nomination / voting process already21:14
slangasekI tend to agree - given that only core-devs were elected this time around (and, IIRC, only core-devs stood for election), this seems like a non-issue and we're better of keeping the status quo21:14
infinityI think what we're really looking for here is a veto to prevent accidentally electing incompetents, and Mark already holds that power.21:14
sabdfland i'd prefer to retain the flexibility that offers21:14
slangaseks/of/off/21:14
sabdflinfinity, as do the voting pool in case I make a bum nomination21:15
infinitysabdfl: ;)21:15
stgraberstatus quo seems reasonable to me. I think we should always ensure that the candidate pool is big enough that we don't end up in a situation where the voters have no choice but to elect a non-coredev (or non-developer) but I don't think we need to create policy around that21:15
sabdfli thought i replied to micah and cc'd the TB?21:16
mdeslaurI also agree to the status quo21:16
stgrabersabdfl: you did21:16
mdeslauryes, https://lists.ubuntu.com/archives/technical-board/2013-October/001741.html21:16
slangaseksabdfl: yes, you did, but then the TB dissolved and there was no formal decision so it was left on the agenda :)21:16
keeswhoops, here now.21:16
slangasekso, I +1 sabdfl's position21:16
infinity+1 here too, the status quo seems to be serving well.21:17
mdeslaur+121:17
slangasek(do we want an actual #vote?)21:18
kees+1. anyone who ends up on TB and isn't core-dev should probably go about getting it. :)21:18
mdeslaurwhoops :)21:18
stgrabersounds like we have an agreement both from those of the old TB who spoke up on the ML and the current TB to retain status quo, I don't see the need for a formal vote21:18
slangasekok21:18
infinityI've considered a similar topic from the POV of archive/sru teams (which I'll bring up another time), but that was more about archive rights, this isn't.21:18
infinity(If being on the TB automatically gave you rights to insert packages in the archive, then the core-dev argument would have weight)21:18
stgraberinfinity: being on the TB gives you the technical ability to grant any ACL you wish including any queue privileges and upload privileges21:19
infinityLet's pretend you didn't say that for now.21:20
mdeslaurheh21:20
sabdflbeing on the TB suggests you understand the responsibilities, including ACLs21:20
* infinity nods.21:21
slangasekok, what else?21:22
stgraberyep, and it's the same thing we have with the DMB where the DMB is the admin of ~core-dev but we used to have non-coredev members on the board.21:22
slangasekdo we want to double back on the MRE question now that kees is here?21:22
stgraberkees: hey, so I vaguely remember you were the one looking at those provisional MREs, do you have anything new to share? do we still have some to review at this point? or should that agenda item be dropped for now?21:23
keesanswer is "it's been very time-consuming to evaluate the history of MREs actually executed", and I've been very slowly working on it.21:23
keesmainly I wanted to do it to kick out any MREs that had 0 (or an arbitrarily small number of) SRUs21:23
sabdfldo we need a log of those, say a wiki page or set of them, to make such analysis easier in future?21:24
keesin theory, it should be possible to extract them from LP, and I have a script started to do it, but it had a lot of corner cases.21:24
infinity+publishinghistory for the source packages in question should be log enough.21:24
sabdfli.e. update the process to include a note on that page... ok21:24
keesinfinity: the trouble was ignoring security updates, etc21:25
sabdflautomated would be better, for sure21:25
slangaseksecurity updates should be automatically detectable by version number, I guess?21:25
stgraberand probably also dealing with renamed sources (we used to have a few X packages with provisional MREs)21:25
slangasek(it's only using the MRE if the upstream version number changes)21:25
keesslangasek: version number for security updates is the same as that for SRU21:25
infinitykees: Not the upstream part.21:25
keesslangasek: eh, that hasn't always been true I don't think.21:26
keesslangasek: but worth double-checking21:26
mdeslaurwell, it's likely a rare exception if it's happened before21:26
stgraberslangasek: hmm, someone could upload the same new upstream release as say the dev series and use ubuntu0.1 in that case21:26
stgraberslangasek: that'd still be a MRE and would have a security-like version number21:26
slangasekkees: really?  I would be very concerned with anyone using an MRE as a justification for cherry-picking patches instead of pulling a new upstream release21:26
stgraberthough indeed, detecting a bump of the upstream version number should work in most cases21:27
slangasekstgraber: yes, but the upstream version number in the SRU would be different than the version in the release pocket21:27
infinitystgraber: His point was that the upstream version changed in the series in question, you can ignore the Debian revision entirely.21:27
keeshere's what I put together: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/view/head:/scripts/pmre-report21:28
keeson top of just the SRU checking was how many errors/bugs were being filed21:29
kees(using errors.ubuntu.com)21:29
keesbut that doesn't seem to catch much server stuff21:29
mdeslaurlikely none at all :P21:29
keesright21:29
keesso answering the second question "is it causing more bugs?" has been tricky as well.21:29
mdeslaurif something introduced a bug that was serious enough to get fixed, you'd likely see another upload with the same upstream version number21:31
infinityNot fool-proof, as that could just be a regular SRU fixing a bug that's existed for years.21:31
mdeslauryes, agreed21:31
infinityBut a decent starting point to get a computer to do the grunt work.21:32
keesnow you all feel my pain. :)21:32
mdeslaurhehe21:32
keesI think for future pMREs, we should set a specific and trivially measureable "this MRE is working" measurement21:32
slangasekthat makes sense to me; why should the TB spend its time approving a provisional MRE if it's not going to be used21:33
keesyeah21:33
stgrabersounds reasonable21:33
slangasekso we ought to be able to follow up on each pMRE within a month or two of it being originally granted21:33
infinityPretty hard to measure.  Since the success of an MRE SRU is "it fixes more bugs than it introduces" and there may not be bugs for all the upstream issues it fixes.21:33
infinityBut if the MRE isn't being used at all, sure, that's clearly not a success.21:33
slangasekinfinity: hmm, I don't consider that the right metric for success21:34
stgraberkees: do you know or can easily check whether we have obviously unused pMREs? those would be obvious candidates for revocation at least21:34
keeswell, it's a measure of failure21:34
keesstgraber: I'll make that the new goal :)21:34
infinityslangasek: Well, the best possible outcome is "it introduces no new bugs", but I'm not that naive.21:34
slangasekI think MREs aren't different from regular SRUs because we delegate the QA to upstream, not because they're held to a different standard of correctness21:34
slangaseks/aren't/are/21:35
infinitySure, we hold them to the same level of quality, to a degree.  I'm just not naive enough to belive that thousands of lines of changes in mesa couldn't possibly cause a bug while fixing 10.21:35
slangasekso, I think any MRE that introduces new bugs is one that should be examined carefully - though I think I'm speaking now with my SRU team hat, and don't necessarily think the TB should have to worry about micromanaging this21:35
infinity(Those bugs should be fixed when found, but they'll be there because humans)21:36
keesanyway, I'll get a report of "unused MRE" together. that seems simpler.21:36
stgraberyep, that'd be a good start21:37
stgraber#action kees to get a list of unused provisional Micro Release Exceptions21:37
meetingologyACTION: kees to get a list of unused provisional Micro Release Exceptions21:37
stgraberI think we could probably solve a lot of our concerns by giving a strict period of time during which the provisional MRE is valid and contacting the SRU team about that MRE immediately after approval. If it's only provisional for say 3 months, SRU team members should be able to remember it and be able to give us some feedback when comes the time to make it a permanent MRE.21:39
keesseems reasonable. means we'll need SRU team involvement in TB meetings21:40
stgraberI don't want to offload the whole review process to the SRU team, but realistically they are the ones who see all uploads and get subscribed to all tracking bugs, so if we have a sufficiently short list of pMREs, it shouldn't be too hard for them to spot problems with those.21:40
slangasekkees: we sorta handled that with the last election ;P21:41
keesslangasek: heh, good point21:41
keesyay for power consolidation!21:41
infinityWCPGW?21:42
kees:)21:42
slangasekI'm assuming that's Canadian for "one ring to rule them all"21:42
infinityMore or less.21:43
keesWhat Could Possibly Go Wrong21:43
mdeslaurhehe21:43
stgraberanyway, let's move on :)21:43
stgraber#topic Scan the mailing list archive for anything we missed (standing item)21:43
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board meeting | Current topic: Scan the mailing list archive for anything we missed (standing item)
slangasekthe only thread I've spotted that seems like we might need to revisit is this one: https://lists.ubuntu.com/archives/technical-board/2013-November/001750.html21:44
slangasek(SmartScopes)21:44
slangasekthere's also the currently ongoing discussion of hibernate support, dunno if we should discuss that here or just continue on the list?21:44
sabdflsorry, forced reboot21:45
keesslangasek: I say leave hibernation on the list21:45
slangasekoh, also this one: https://lists.ubuntu.com/archives/technical-board/2013-October/001737.html21:45
stgraberhmm, I'll have to re-check but I think the libdrm, ... stuff was uploaded (possibly without the MRE)21:46
infinityI believe it was.21:46
keesyeah, if it was already done, I say give it a pMRE and recheck in 3 mon21:47
stgraberyeah, it was and I released some of those to -updates today.21:47
infinityI believe I pointed out that it didn't need a standing MRE to do a one-time update.21:47
keesas for smartscope, I don't think that has anything at all to do with the Ubuntu TB. That's all Canonical.21:47
slangasekinfinity, stgraber: right, so it seems RAOF was satisfied that the updates were of sufficiently low risk that he took them with his SRU hat on; no need for an MRE then AFAICS21:49
slangasekkees: so, you don't think the TB should have a response to the smartscopes question?21:50
stgraberyeah, in the past I've been granting one-time-use MREs for those (granted and removed from the wiki a couple of days later), so I don't think we have to do anything for those now that they were uploaded21:50
stgraber(as they are unlikely to get an upstream version bump again)21:50
slangasekthere is an Ubuntu governance question here, which is "is it ok to have features in Ubuntu that depend on closed server-side software"21:50
keesslangasek: I mean there's nothing TB can do but ask for source too.21:50
infinityIt's not really in the TB's mandate to dictate Canonical software licensing issues.21:50
infinityI suppose, yes, we could say the scopes aren't suitable for main because they depend on non-free services.21:51
kees+121:51
=== lhave is now known as lhavelund
kees(but everyone knows how I feel)21:51
mdeslaurso do we get rid of weather applets, the google search box, the flickr integration, etc too?21:52
slangasekI don't think that's what I would be inclined to say, any more than I would say that using google as the default search engine in the browser isn't suitable because it's a non-free service21:52
slangasekmdeslaur: right21:52
stgraberwell, the TB could potentially rule that it's not acceptable for core features of our desktop to depend on a closed server and then let Canonical choose to go without the feature or to make the server open source21:52
slangasekstgraber: (or get us vetoed by sabdfl ;)21:52
stgraberslangasek: or that :)21:52
infinitySure, I didn't mean we would say that, just that that's an option here.  Unlike dictating licensing, which is not an option.21:53
slangasekanyway, I think it would be better for us to answer that clearly rather than ignoring the question21:53
slangasekbut not in the next 7 minutes21:53
stgraberso is that something we should deal with on the list or does someone want to bring it up as an agenda item for the next meeting?21:54
slangasekI'd say list for now21:54
stgrabersounds good to me21:54
infinityI don't think there's anything inherently wrong about shipping clients for non-free services (we have tons of them), but it does seem a bit wrong to have them as part of the core desktop experience.21:54
stgraberok, moving on then21:55
stgraber#topic Check up on community bugs (standing item)21:55
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board meeting | Current topic: Check up on community bugs (standing item)
stgraber"21:55
stgraberThere are currently no open bugs.21:55
stgraber"21:55
infinity\o/21:55
stgraber#topic Select a chair for the next meeting21:55
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board meeting | Current topic: Select a chair for the next meeting
stgraberthat'll be infinity (and I've updated the agenda to hopefully make it clear as to how we choose the chair)21:56
stgraber#topic AOB21:56
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board meeting | Current topic: AOB
stgrabermaybe just one quick questions for the new members, does the current meeting time work for everyone? every two weeks on Monday at 21 London time (so we move with UK DST)21:57
infinityWorks well enough for me.21:57
infinityMonday is my "get no useful work done" day.21:57
slangasekit actually overlaps with a call for infinity and me21:57
slangasekwhich he seems to be casually trying to get out of ;)21:57
infinityWell, there's that call, yes.  But that won't last forever.21:57
mdeslaurwfm21:57
infinityWe could wiggle the TB meeting 30m later for a few months, if no one (nor the Fridge) objected.21:58
stgraberI suspect pitti would object as the current meeting time is already quite late for him21:59
mdeslaurhrm21:59
slangasekyeah, that makes it later for both sabdfl and pitti21:59
infinityWe had no problems forcing our previous call to 30m, I'm sure we can keep juggling those for a while until it stops.21:59
sabdfli am not a regular attendee so  don't block on me if that suits you better22:00
slangasektoday's call naturally ended 30m early with no prompting :)22:00
slangasekanyway, scheduling is hard22:00
slangasekso we can just keep the meeting where it is, with the knowledge that infinity and I may be late from time to time for the next couple of months22:01
infinityBut fashionably so.22:01
stgrabersounds good. We still have quorum without you two and while we shouldn't depend on it, I suspect you're both capable of multi-tasking a bit if needed :)22:02
mdeslaursounds good to me22:02
stgraberand with that settled22:02
stgraber#endmeeting22:02
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology
meetingologyMeeting ended Mon Jan  6 22:02:50 2014 UTC.22:02
meetingologyMinutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-01-06-21.03.moin.txt22:02
meetingologyMinutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-01-06-21.03.html22:02
slangasekstgraber: thanks for chairing22:03
infinityTa.22:03
stgrabernext meeting will be on the 20th at 21:00 UTC with infinity chairing (or kees if infinity doesn't make it on time)22:03
keesthanks!22:03
infinityWay to motivate me to be late.22:03
mdeslaurthanks!22:03
keesheh22:03

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