== Meeting information == * #ubuntu-meeting: Technical Board meeting, 06 Jan at 21:03 — 22:02 UTC * Full logs at [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-01-06-21.03.log.html]] == Meeting summary == === Action review === The discussion about "Action review" started at 21:04. === Review our current "provisional" Micro Release Exceptions === The discussion about "Review our current "provisional" Micro Release Exceptions" started at 21:08. * ''LINK:'' https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions === Requiring TB members to be Ubuntu core developers [micahg] === The discussion about "Requiring TB members to be Ubuntu core developers [micahg]" started at 21:10. * ''ACTION:'' kees to get a list of unused provisional Micro Release Exceptions === Scan the mailing list archive for anything we missed (standing item) === The discussion about "Scan the mailing list archive for anything we missed (standing item)" started at 21:43. === Check up on community bugs (standing item) === The discussion about "Check up on community bugs (standing item)" started at 21:55. === Select a chair for the next meeting === The discussion about "Select a chair for the next meeting" started at 21:55. === AOB === The discussion about "AOB" started at 21:56. == Vote results == == Action items == * kees to get a list of unused provisional Micro Release Exceptions == Action items, by person == * kees * kees to get a list of unused provisional Micro Release Exceptions == People present (lines said) == * stgraber (52) * slangasek (47) * infinity (36) * kees (32) * mdeslaur (16) * sabdfl (12) * meetingology (4) == Full Log == 21:03 #startmeeting Technical Board meeting 21:03 Meeting started Mon Jan 6 21:03:45 2014 UTC. The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 21:03 21:03 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:04 #topic Action review 21:04 The 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 \o/ 21:06 now 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/+members 21:06 it's late in Cape Town, so i'll just say welcome to the new TB, and thanks 21:06 so the next meeting chair (20th of January 21 London time) will be infinity 21:06 I'll be sure to hire a secretary before then. 21:07 * stgraber tries updating the wiki, gives up (taking way too long) and gets back to the meeting 21:08 #topic Review our current "provisional" Micro Release Exceptions 21:08 is there a current list? 21:08 My 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:09 https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions 21:09 ok 21:10 should we carry this over, since kees isn't here? 21:10 yep, 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 #topic Requiring TB members to be Ubuntu core developers [micahg] 21:10 micahg_: around by any chance? 21:11 I know I saw discussion of this on list 21:11 This would be slightly less contentious now that it happens to be true. 21:11 which makes sense, it was a timely topic before the election, not so much now ;) 21:12 * stgraber quickly reads the ML thread again 21:12 infinity: well, I think there was not consensus about this principle 21:12 slangasek: No, indeed, I can see the argument for people who prefer to recuse themselves to limit upload rights, etc. 21:13 one 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 rule 21:13 Though, 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 right 21:13 i think it was well intentioned but not a sensible constraint 21:14 we have good checks and balances in the nomination / voting process already 21:14 I 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 quo 21:14 I think what we're really looking for here is a veto to prevent accidentally electing incompetents, and Mark already holds that power. 21:14 and i'd prefer to retain the flexibility that offers 21:14 s/of/off/ 21:15 infinity, as do the voting pool in case I make a bum nomination 21:15 sabdfl: ;) 21:15 status 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 that 21:16 i thought i replied to micah and cc'd the TB? 21:16 I also agree to the status quo 21:16 sabdfl: you did 21:16 yes, https://lists.ubuntu.com/archives/technical-board/2013-October/001741.html 21:16 sabdfl: yes, you did, but then the TB dissolved and there was no formal decision so it was left on the agenda :) 21:16 whoops, here now. 21:16 so, I +1 sabdfl's position 21:17 +1 here too, the status quo seems to be serving well. 21:17 +1 21:18 (do we want an actual #vote?) 21:18 +1. anyone who ends up on TB and isn't core-dev should probably go about getting it. :) 21:18 whoops :) 21:18 sounds 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 vote 21:18 ok 21:18 I'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 (If being on the TB automatically gave you rights to insert packages in the archive, then the core-dev argument would have weight) 21:19 infinity: being on the TB gives you the technical ability to grant any ACL you wish including any queue privileges and upload privileges 21:20 Let's pretend you didn't say that for now. 21:20 heh 21:20 being on the TB suggests you understand the responsibilities, including ACLs 21:21 * infinity nods. 21:22 ok, what else? 21:22 yep, 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 do we want to double back on the MRE question now that kees is here? 21:23 kees: 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 answer 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 mainly I wanted to do it to kick out any MREs that had 0 (or an arbitrarily small number of) SRUs 21:24 do we need a log of those, say a wiki page or set of them, to make such analysis easier in future? 21:24 in 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 +publishinghistory for the source packages in question should be log enough. 21:24 i.e. update the process to include a note on that page... ok 21:25 infinity: the trouble was ignoring security updates, etc 21:25 automated would be better, for sure 21:25 security updates should be automatically detectable by version number, I guess? 21:25 and probably also dealing with renamed sources (we used to have a few X packages with provisional MREs) 21:25 (it's only using the MRE if the upstream version number changes) 21:25 slangasek: version number for security updates is the same as that for SRU 21:25 kees: Not the upstream part. 21:26 slangasek: eh, that hasn't always been true I don't think. 21:26 slangasek: but worth double-checking 21:26 well, it's likely a rare exception if it's happened before 21:26 slangasek: hmm, someone could upload the same new upstream release as say the dev series and use ubuntu0.1 in that case 21:26 slangasek: that'd still be a MRE and would have a security-like version number 21:26 kees: really? I would be very concerned with anyone using an MRE as a justification for cherry-picking patches instead of pulling a new upstream release 21:27 though indeed, detecting a bump of the upstream version number should work in most cases 21:27 stgraber: yes, but the upstream version number in the SRU would be different than the version in the release pocket 21:27 stgraber: His point was that the upstream version changed in the series in question, you can ignore the Debian revision entirely. 21:28 here's what I put together: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/view/head:/scripts/pmre-report 21:29 on top of just the SRU checking was how many errors/bugs were being filed 21:29 (using errors.ubuntu.com) 21:29 but that doesn't seem to catch much server stuff 21:29 likely none at all :P 21:29 right 21:29 so answering the second question "is it causing more bugs?" has been tricky as well. 21:31 if something introduced a bug that was serious enough to get fixed, you'd likely see another upload with the same upstream version number 21:31 Not fool-proof, as that could just be a regular SRU fixing a bug that's existed for years. 21:31 yes, agreed 21:32 But a decent starting point to get a computer to do the grunt work. 21:32 now you all feel my pain. :) 21:32 hehe 21:32 I think for future pMREs, we should set a specific and trivially measureable "this MRE is working" measurement 21:33 that makes sense to me; why should the TB spend its time approving a provisional MRE if it's not going to be used 21:33 yeah 21:33 sounds reasonable 21:33 so we ought to be able to follow up on each pMRE within a month or two of it being originally granted 21:33 Pretty 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 But if the MRE isn't being used at all, sure, that's clearly not a success. 21:34 infinity: hmm, I don't consider that the right metric for success 21:34 kees: do you know or can easily check whether we have obviously unused pMREs? those would be obvious candidates for revocation at least 21:34 well, it's a measure of failure 21:34 stgraber: I'll make that the new goal :) 21:34 slangasek: Well, the best possible outcome is "it introduces no new bugs", but I'm not that naive. 21:34 I 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 correctness 21:35 s/aren't/are/ 21:35 Sure, 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 so, 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 this 21:36 (Those bugs should be fixed when found, but they'll be there because humans) 21:36 anyway, I'll get a report of "unused MRE" together. that seems simpler. 21:37 yep, that'd be a good start 21:37 #action kees to get a list of unused provisional Micro Release Exceptions 21:37 * meetingology kees to get a list of unused provisional Micro Release Exceptions 21:39 I 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:40 seems reasonable. means we'll need SRU team involvement in TB meetings 21:40 I 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:41 kees: we sorta handled that with the last election ;P 21:41 slangasek: heh, good point 21:41 yay for power consolidation! 21:42 WCPGW? 21:42 :) 21:42 I'm assuming that's Canadian for "one ring to rule them all" 21:43 More or less. 21:43 What Could Possibly Go Wrong 21:43 hehe 21:43 anyway, let's move on :) 21:43 #topic Scan the mailing list archive for anything we missed (standing item) 21:44 the 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.html 21:44 (SmartScopes) 21:44 there's also the currently ongoing discussion of hibernate support, dunno if we should discuss that here or just continue on the list? 21:45 sorry, forced reboot 21:45 slangasek: I say leave hibernation on the list 21:45 oh, also this one: https://lists.ubuntu.com/archives/technical-board/2013-October/001737.html 21:46 hmm, I'll have to re-check but I think the libdrm, ... stuff was uploaded (possibly without the MRE) 21:46 I believe it was. 21:47 yeah, if it was already done, I say give it a pMRE and recheck in 3 mon 21:47 yeah, it was and I released some of those to -updates today. 21:47 I believe I pointed out that it didn't need a standing MRE to do a one-time update. 21:47 as for smartscope, I don't think that has anything at all to do with the Ubuntu TB. That's all Canonical. 21:49 infinity, 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 AFAICS 21:50 kees: so, you don't think the TB should have a response to the smartscopes question? 21:50 yeah, 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 uploaded 21:50 (as they are unlikely to get an upstream version bump again) 21:50 there 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 slangasek: I mean there's nothing TB can do but ask for source too. 21:50 It's not really in the TB's mandate to dictate Canonical software licensing issues. 21:51 I suppose, yes, we could say the scopes aren't suitable for main because they depend on non-free services. 21:51 +1 21:51 (but everyone knows how I feel) 21:52 so do we get rid of weather applets, the google search box, the flickr integration, etc too? 21:52 I 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 service 21:52 mdeslaur: right 21:52 well, 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 source 21:52 stgraber: (or get us vetoed by sabdfl ;) 21:52 slangasek: or that :) 21:53 Sure, 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 anyway, I think it would be better for us to answer that clearly rather than ignoring the question 21:53 but not in the next 7 minutes 21:54 so 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 I'd say list for now 21:54 sounds good to me 21:54 I 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:55 ok, moving on then 21:55 #topic Check up on community bugs (standing item) 21:55 " 21:55 There are currently no open bugs. 21:55 " 21:55 \o/ 21:55 #topic Select a chair for the next meeting 21:56 that'll be infinity (and I've updated the agenda to hopefully make it clear as to how we choose the chair) 21:56 #topic AOB 21:57 maybe 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 Works well enough for me. 21:57 Monday is my "get no useful work done" day. 21:57 it actually overlaps with a call for infinity and me 21:57 which he seems to be casually trying to get out of ;) 21:57 Well, there's that call, yes. But that won't last forever. 21:57 wfm 21:58 We could wiggle the TB meeting 30m later for a few months, if no one (nor the Fridge) objected. 21:59 I suspect pitti would object as the current meeting time is already quite late for him 21:59 hrm 21:59 yeah, that makes it later for both sabdfl and pitti 21:59 We had no problems forcing our previous call to 30m, I'm sure we can keep juggling those for a while until it stops. 22:00 i am not a regular attendee so don't block on me if that suits you better 22:00 today's call naturally ended 30m early with no prompting :) 22:00 anyway, scheduling is hard 22:01 so 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 months 22:01 But fashionably so. 22:02 sounds 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 sounds good to me 22:02 and with that settled 22:02 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)