16:02 <stgraber> #startmeeting Ubuntu Technical Board meeting
16:02 <meetingology> Meeting started Tue Aug  5 16:02:27 2014 UTC.  The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
16:02 <meetingology> 
16:02 <meetingology> Available commands: action commands idea info link nick
16:02 <rbasak> I noticed sinzui (Curtis - Juju upstream QA lead) also joined, but he's mostly unavailable AIUI.
16:02 <stgraber> #topic Action review
16:02 * pitti checks where https://lists.ubuntu.com/archives/technical-board/2014-July/001985.html went to, I never got that mail
16:02 <stgraber> infinity and mdeslaur to read and comment on juju policy
16:02 <stgraber> did that happen?
16:03 <rbasak> I've been working with Curtis on QA plans for SRUs, so I can try and answer questions about that.
16:03 <mdeslaur> I read it, and I'm ok with it...the further clarifications to the questions pitti asked satisfied me
16:03 <mdeslaur> my only concern is how fast the testing can be implemented
16:03 <pitti> Curtis' reply from July 28 was finally what I was looking for
16:03 <pitti> so my question is whether this can be exercised for SRU testing already (even if manually)
16:04 <pitti> i. e. testing newer juju clients against existing installs (done with older juju clients and servers)
16:04 <rbasak> I can't answer for sinzui on this, but I don't intend to mark verification-done until this has happened.
16:05 <rbasak> I think we'd be OK for you to make this a requirement.
16:05 <rbasak> (I mean manually, at a minimum)
16:05 <pitti> that's the main point of SRU verification, so I'd like to
16:05 <pitti> yes, it's not a blocker to automate this
16:05 <stgraber> yeah, that sounds reasonable to me
16:05 <pitti> although I guess there's enough motiviation to do so anyway :)
16:06 <stgraber> anything else for juju or should we move on to MAAS?
16:06 <rbasak> I've been looking at trying to get verification to happen before the package is to land in -proposed.
16:06 <rbasak> By doing a PPA build and a binary copy or something.
16:06 <pitti> I think I'm +1 on a provisional MRE for juju now, with that assumption
16:06 <mdeslaur> do we need to vote to make it official?
16:06 <rbasak> So that upstream doesn't even actually release until we've verified in ubuntu.
16:07 <pitti> we don't have quorum, but MREs only require one +1 anyway; but any objections from mdeslaur or stgraber?
16:07 <rbasak> So yes - we're trying hard to make it happen :)
16:07 <mdeslaur> no objection from me
16:07 <sinzui> pitti, We can test minior to minor server to client combinations  manually . I certainly will to assure myself my results match the test we ware writing. We wont have this done for 2 weeks though
16:07 <kees> \o
16:07 <stgraber> I don't think we need a vote on this unless there are objections, MREs only need a single member's approval
16:07 <mdeslaur> I keep forgetting that :)
16:07 <pitti> hey kees, how are you?
16:08 <pitti> mdeslaur: yeah, and I'm still not sure whether that was intended or some typo in writing the wiki :)
16:08 <stgraber> pitti: so if you're happy with things, please add the entry to the wiki with any required clarification wrt testing
16:08 <pitti> stgraber: ack
16:08 <pitti> (plus mail followup)
16:08 <kees> good, slightly late, sorry!
16:08 <rbasak> Thanks all!
16:08 <stgraber> moving on to MAAS then
16:08 <mdeslaur> pitti: hehe :)
16:08 <stgraber> #topic MAAS (and curtin) SRU Policy - https://lists.ubuntu.com/archives/technical-board/2014-July/001985.html
16:08 * pitti needs a minute to read, I only just fished these out of my spam filter
16:09 <pitti> all that kinky MAAS stuff :)
16:09 <pitti> or too many TLAs or something
16:11 <pitti> no MIRs for stables please, if we can at all avoid it
16:11 <stgraber> agreed
16:12 <pitti> so, TBH I don't really know much how maas works, but AFAIK it's mostly a kind of installer, no?
16:12 <pitti> or does it control already deployed machines forever?
16:12 <rbasak> It controls a bunch of physical hardware, and provides API access to them.
16:12 <pitti> i. e. what's the regresssion potential here, do we need to worry about any kind of compatibility to already deployed machines?
16:13 <stgraber> it's not technically impossible to promote something in a stable release and we've done it in the past when absolutely needed but typically only when the version in the stable release matches (same binaries) the one in the current development release and the package in the development release has already been promoted
16:13 <rbasak> When a machine is released via the API, it can be redeployed via the API, at which point it will be reinstalled.
16:13 <mdeslaur> and backwards compatibility for configuration files will be maintained?
16:13 <pitti> rbasak: ah, so it's not just an installer, but more similar to juju, i. e. "once maas, always maas"?
16:14 <ScottK> In the past, (for opencloud for example) we've used embedded libs for SRUs to avoid the need to propagate change beyond the package we were interested in.
16:14 <rbasak> pitti: yeah - MAAS pretty much owns the machines it manages.
16:14 <rbasak> It maintains IPMI control, for example.
16:14 <pitti> ok, then I guess <broken record>I'd like to know how we ensure that newer major versions work against already deployed machines
16:15 <stgraber> ScottK: right and I'd absolutely be against bumping any of MAAS' dependencies as part of an SRU.
16:15 <rbasak> To be clear, I'm just clarifying what MAAS does as I'm still here and I'm familiar with it.
16:15 <rbasak> I'm not sure I can speak for roaksoax or this particular request here - I'm not so well connected to MAAS upstream nowadays - other people on my team deal with it more than me.
16:17 <pitti> ok, might be better to reply to the mail for further QA information?
16:17 <rbasak> Looking at the email, he's said that they'll do upgrade testing, and provide an upgrade path that "just works".
16:18 <rbasak> Yes - I guess roaxsoax is at the company sprint that's on this week.
16:18 <pitti> right, I'd just like to know how that's done
16:18 <rbasak> Sorry I can't help more on the MAAS side of things.
16:19 <stgraber> ok, so let's continue discussing that by e-mail then
16:19 <stgraber> and onto the next topic then
16:19 <stgraber> #topic Kindly request update on Ubuntu MATE Remix thread. -- AlanPope
16:19 <popey> o/
16:19 <pitti> rbasak: no worries, thanks for your help with the juju topic!
16:20 <popey> So we're really keen to fulfil whatever requirements are needed to become an official flavour.
16:20 <popey> One notable missing thing is having a core dev on the team
16:20 <popey> Martin will apply for package maintainer for the mate packages, if that's appropriate?
16:21 <pitti> yes, more than appropriate
16:21 <pitti> from the POV of "needed for a flavor lead" (I didn't sponsor things for him, so I can't say whether he's ready to do taht)
16:22 <ScottK> Having a core-dev isn't required, is it?
16:22 <ScottK> MATE isn't going to be in main.
16:22 <stgraber> One or more developer with upload rights.
16:22 <stgraber> so no, no core dev
16:22 <stgraber> but they need a packageset and someone with upload rights to the set
16:22 <pitti> yeah, I wouldn't see why it needs to be a "core dev"; "can upload" is quite enough
16:23 <popey> https://wiki.ubuntu.com/RecognizedFlavors are the guidelines we're looking at.
16:23 <ScottK> IIRC Ubuntu Kylin was recognized before they had a packageset/dedicated developer.
16:23 <stgraber> right, which is what I've copy/pasted from, those guidelines never mention coredev
16:23 <popey> Sorry, my mistake.
16:23 <stgraber> ScottK: yeah, I remember that and I'm not particularly willing to repeat the experience...
16:24 <ScottK> Of course Kylin had a Canonical push behind it.
16:24 <stgraber> for Kylin it only really worked because members of the Ubuntu Foundations team were directly asked to help out with the packaging and getting things into place
16:25 <ScottK> Right, so a volunteer to help out until things are in place should be sufficient.
16:25 <popey> Should we seek such a volunteer out?
16:25 <pitti> so for this we need some sign-off from IS that we have sufficient space on cdimage, and we have Martin's commitment to become an uploader
16:25 <stgraber> right, if a couple of people with upload rights at the moment are willing to help MATE, then that meets the requirements and they can apply to become a flavour
16:26 <pitti> until then, things can go through the sponsoring queue (but having some dedicated volunteers certainly can't hurt)
16:26 <pitti> happy to help out a bit with sponsoring, too
16:26 <popey> Thank you.
16:26 <stgraber> so in any case, Martin can apply for PPU to the MATE set of packages which if approved will make him an uploader, regardless of the status of the flavour
16:27 <popey> Ok.
16:27 <stgraber> once he's got upload rights or if you find someone else who's got upload rights and is willing to be responsible for uploads until Martin has upload rights, then you can apply to become an official flavour
16:28 <stgraber> and indeed, we need someone to figure out whether we have enough space for those builds and publishing
16:28 <popey> and we need to contact IS about cdimage?
16:28 <popey> right.
16:28 <popey> happy to file an RT and follow up on that.
16:29 <stgraber> we've had some space issues on nusakan lately (cdimage builder) and Launchpad is also having space issues, so having IS look into it is probably a good idea
16:29 <pitti> (FTR, I don't think that'll be a problem, but still better to get sign-off)
16:29 <popey> Ok, I'll take an action to do that?
16:30 <stgraber> pitti: nusakan ran out of disk space twice in the past month and the LP librarian is almost out of disk space too. I don't know about the cdimage frontends, but the rest of the infrastructure is very very loaded at the moment (there are plans to fix that but not moving as quickly as hoped...)
16:30 <pitti> ah
16:30 <pitti> popey: thanks
16:31 <stgraber> anything else for MATE?
16:31 <popey> I think that was it from my side.
16:31 <stgraber> cool
16:31 <popey> I know what we need to do now. Thank you.
16:31 <pitti> so it sounds like in general we are all pro that proposal, just needs some steps from teh checklist?
16:31 <mdeslaur> yep, I'm for the proposal
16:32 <stgraber> yeah, I think we're all happy with it, just need to make sure everything's in place before we stamp it
16:32 <stgraber> #topic Scan the mailing list archive for anything we missed (standing item)
16:33 * pitti doesn't see anything else, barring more spam filter accidents
16:33 <stgraber> looking at the past month, I'm not seeing anything that went unnoticed
16:33 <mdeslaur> I don't see anything else either
16:33 <stgraber> #topic Check up on community bugs (standing item)
16:33 <stgraber> There are currently no open bugs.
16:33 <stgraber> #topic Next chair
16:33 <stgraber> according to the wiki, that'd be mdeslaur
16:33 <mdeslaur> yep
16:34 <stgraber> not sure how that ordering works though
16:34 <stgraber> isn't alphabetical based on name, nor irc nicknames, kinda confused :)
16:34 <stgraber> anyway, something to figure out at the next meeting :)
16:34 <stgraber> #topic AOB
16:34 <pitti> stgraber: it's in order of https://launchpad.net/~techboard/+members, but you got carried twice
16:35 <stgraber> pitti: ok, makes sense then
16:35 <pitti> next would be mdeslaur, I think
16:35 <czajkowski> pitti: see pm when you have a moment please.
16:35 <pitti> czajkowski: I suppose you can just ask that here, too?
16:35 <pitti> it fits right in
16:36 <czajkowski> pitti: wasnt sure if it had been discussed elsewhere
16:36 <czajkowski> but I sent a mail a few weeks ago re catching up with the CC
16:37 <czajkowski> will follow up again on mail once I find the mail
16:38 <pitti> I'm afraid I don't have that anywhere either (or it was too long ago and I already replied)
16:38 <pitti> I still faintly remember the previous CC+TB meeting maybe half or one year ago
16:38 <czajkowski> np
16:38 <pitti> stgraber: anyway, thanks! so I'll follow up with the two MREs, can you follow up with the steps for MATE?
16:39 <stgraber> pitti: sure
16:39 <stgraber> #endmeeting