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