[16:01] \o [16:01] kees, mdeslaur, slangasek: infinity sent his apologies; waiting for stgraber (he's supposed to chair today) [16:01] not that we'd have much of an agenda, except the dragged MAAS MRE [16:02] yep [16:02] cool [16:05] * stgraber waves [16:06] hola [16:06] hi stgraber [16:06] ça va stgraber [16:06] stgraber: and here we thought you were trying to skip out on your chairing duties :) [16:06] nah, just came back from the shop :) [16:07] #startmeeting Technical Board meeting [16:07] Meeting started Tue Sep 30 16:07:08 2014 UTC. The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [16:07] Available commands: action commands idea info link nick [16:07] #topic Action review [16:07] infinity to review and respond to MAAS SRU thread [16:07] well, infinity isn't around so I guess we'll just carry that one over [16:08] #topic Scan the mailing list archive for anything we missed (standing item) [16:08] mdeslaur got a response to the MAAS thread [16:08] or two in fact [16:08] do we really need to wait for infinity on that one? [16:08] but at this point I feel like we don't get any more useful answers [16:09] I still don't have the feeling that I know how they ensure backwards compatibility, but I could just be overly paranoid [16:10] mdeslaur: "legally" we don't, a single +1 is enough for an MRE, but some consensus is certainly prudent [16:10] they claim the API with the nodes will be stable, but don't mention how they plan on making sure of that [16:10] actually, I think I'll ask that as a follow up question [16:11] ok, so back to the ML for that one [16:11] that's the only thing I see in the ML history for September so I guess we didn't miss anything :) [16:11] #topic Check up on community bugs (standing item) [16:11] still nothing [16:11] #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) [16:12] that'd be infinity [16:12] #topic AOB [16:12] anything anyone? [16:12] nothing from me. [16:12] nothing from me either [16:13] nope [16:14] Re MAAS, they are currently pushing for invasive changes in psycopg. [16:14] It makes me wonder how they expect to support trusty. [16:15] well, if they only make that to trunk, not to the stable branches, that'd be ok? [16:15] ScottK: oh? do you know what changes those are, or where they've been discussed? [16:15] I'm not sure whether we are still talking about microreleases only, or new major releases; but I expect the latter (yay terminology) [16:15] Looking for the bug. [16:16] indeed, sorry, it explicitly said "new releases" [16:16] * pitti confused, sorry [16:16] anyway, there's precedent; newer python modules could be bundled into the new release [16:16] (which is fairly simple with python) [16:17] https://bugs.launchpad.net/ubuntu/+source/psycopg2/+bug/1366104 [16:17] thanks ScottK [16:18] hrm, interesting [16:19] pitti: though psycopg2 contains a C extension module, so still possible but not nearly as clean :) [16:19] but it uses a libpq 9.3 only api [16:20] I'm not sure how much pressure there is to also put new maas releases to 12.04 [16:20] the effort/gain ratio seems too big for me (but that's just gut feeling) [16:20] Which is why it's a much more invasive change than the sloc count indicates. [16:21] I'm assuming they decided not to care about 12.04 anymore. [16:22] their request to the tech board was for "latest LTSes" [16:22] Upstream pretty much said "you're on your own" re backport the change. [16:23] Then at least the libpq is there. [16:23] latest LTS seems reasonable [16:23] Agreed. [16:23] if you want changes in other packages, that's up to the SRU to decide whether they are acceptable or not [16:23] s/you/they/ [16:23] yeah, fixes are certainly okay [16:23] In this case I'll say not. [16:24] if they can't get the fixes they require, then it's up to them to work around them [16:24] like, fixing psycopg to get along with large files smells like a bug fix worth having in an LTS [16:24] The psycopg2 change is way more than a fix. [16:24] I didn't look into it in detail, just the description and some comments [16:25] but https://github.com/psycopg/psycopg2/pull/259/files looks reasonable at first sight [16:25] I'd say changing the libpq API you're using post-release is crazy. [16:25] (not sure if that's an ABI break due to teh changed types) [16:25] well, the code is condition and checks the version [16:25] conditional [16:26] Who knows what latent bugs exist in the new api. [16:26] anyway, putting that detail aside, if changes to other packages are not applicable as an SRU, there's always the bundling option, or working around it in another way [16:26] right [16:26] We'd get the new api on 14.04 since we'd build against 9.3. [16:27] right, and 14.04 is all we talk about, isn't it? [16:27] Yes. [16:27] Which is why backporting that patch concerns me. [16:28] 'Works with MAAS' doesn't really help. [16:28] It's everyone else I worry about. [16:29] yes, that's what I mean -- if that change is too intrusive for an SRU, there's other ways to get this for maas [16:29] (I didn't claim that the psycopg fix was fine for an SRU, just that it looks reasonable at first sight) [16:29] if the change gets NACKed by the SRU team, it's up to them to work around it somehow [16:29] So it'd be nice to consider the possibility they have to bundle stuff in any MRE approval. [16:30] yes, I think for some bits that's quite unavoidable [16:30] To bring us back to the topic. [16:30] e. g. if there's a new dependency which is in trusty universe we don't want to promote it post-release [16:30] (or binNEW it, etc.) [16:31] at least then both the effort and the impact of bundled stuff is restricted to maas itself and its devs [16:31] (or add a patch that's not SRU suitable) [16:31] and the latter will make sure that it doesn't happen too often [16:31] Yes. [16:31] ScottK: yeah, obviously [16:33] so, are we done for today then? [16:33] * pitti smells dinner, yummy :) [16:33] * kees waves [16:34] I think we are [16:34] * pitti waves good bye then, see you! [16:34] stgraber: *nudge* [16:34] * ScottK waves. [16:34] thanks! [16:40] oops :) [16:40] #endmeeting [16:40] Meeting ended Tue Sep 30 16:40:28 2014 UTC. [16:40] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2014/ubuntu-meeting-2.2014-09-30-16.07.moin.txt