=== ScottK is now known as kitterma === kitterma is now known as ScottK === tsimpson_ is now known as tsimpson [16:59] * pitti waves [16:59] \o [17:01] * mdeslaur waits for others [17:02] hi kees [17:03] hola! [17:04] hey kees, how are you? [17:04] good, you? [17:05] quite fine, thanks! /me waves from South Africa [17:07] ooh! never been. :) [17:07] my first time too [17:08] no response from slangasek and infinity, and stgraber send apols [17:08] hrm [17:08] so maybe we just start [17:08] ok [17:08] #startmeeting [17:08] Meeting started Tue Dec 9 17:08:45 2014 UTC. The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [17:08] Available commands: action commands idea info link nick [17:08] [topic] Apologies [17:08] stgraber couldn't make it [17:08] [topic] Action review [17:09] infinity to review and respond to MAAS SRU thread [17:09] hrm, don't think he did that, so carried over [17:09] mdeslaur to gather facts on Docker versions and respond to the thread [17:09] I did respond to the thread [17:09] done [17:09] that's it for actions [17:09] [topic] Mailing list archive [17:10] "Freetype patent problem" - https://lists.ubuntu.com/archives/technical-board/2014-December/002047.html [17:10] not a patent holder, so ... nothing to respond to, IIUC? [17:10] yeah [17:10] we already discussed subpixel rendering on the TB many years ago [17:10] yep [17:11] and back then it was the same thing: not a patent owner, not upstream, not interested [17:11] it's the only reasonable thing to do [17:11] well, I think we should respond, with pretty much that [17:12] I don't know whether we have our patent policy written down somewhere [17:12] hah, https://wiki.ubuntu.com/PatentPolicy [17:12] https://wiki.ubuntu.com/PatentPolicy says "While the Ubuntu project wishes to be responsive to patent infringement claims, we cannot commit to the assessment and review of claims made by anyone other than the registered rights holder. " [17:12] that seems pretty clear :) [17:13] I'm not sure what is expected of the "Developers" section at the bottom of that page though [17:14] I think that's "upstreams" [17:14] ah! that would make sense [17:15] ok, I'll respond to the thread again [17:15] [action] mdeslaur to respond to freetype thread [17:15] ACTION: mdeslaur to respond to freetype thread [17:16] does anyone have anything else to add to the freetype thread? [17:16] if not, next item: [17:16] "MRE for KDE Frameworks" - https://lists.ubuntu.com/archives/technical-board/2014-November/002043.html [17:16] I'm quite nervous about this TBH [17:17] pitti: for what reasons? [17:17] if you essentially stop having a stable branch, you get all sorts of refactoring and other new bits into it, and I highly doubt that upstreams test extensively on old KDE versoins [17:17] usually upstreams run trunk for everything [17:18] they are promising a stable ABI and API though [17:18] well yes, but that conceptually that doesn't really work [17:18] I'm not sure how this is different from other MREs [17:18] Thing is, exisiting API is covered by unit tests [17:18] (with having only one trunk) [17:18] new API is only harmful if apps use it [17:18] since we're not updating apps, this is not a problem [17:19] yes, but if you don't have stable branches, refactoring etc. will also be there [17:19] *plus* we now have extensive QA mechanisms on Kubuntu CI [17:19] pitti: sure, but test coverage should ensure things don't break [17:19] well, I think ultimately it's KDE's decision, but these are certainly not "microreleases" [17:19] pitti: KF5 has unstable branches for unstable stuff [17:19] this is now the same class as landscape and juju [17:19] it doesn't go into master until it's stable [17:19] pitti: yes, they most certainly can't be called microreleases [17:21] so, I'm not really convinced that this will actually work better, but I don't veto a preliminary exception and then see how it goes with a few updates [17:21] as usual, if you want to do this then we should figure out a "how", not outright "no you can't" [17:22] pitti: ofcourse, and I think all of us in the Kubuntu team are more than willing to introduce measures to make sure things don't break [17:23] FWIW we have QA measures being taken over here : http://kci.pangea.pub/ [17:23] shadeslayer: do you have some ideas for that? [17:23] pitti: yes, see http://kci.pangea.pub/ [17:23] pitti: there are a couple of things we do, at its core, check for ABI breaks , file moves, and make sure packages are generally installable [17:24] shadeslayer: can we run app/other component's tests against an updated framework? [17:24] ( this happens every single day btw ) [17:24] pitti: I don't see why not, we already integrate Plasma 5 against Framework 5 from git, which is the biggest consumer of KF5 [17:24] are these the same as we already run as autopkgtest, OOI? [17:25] no, autopkgtests can't be run unfortuantely, I'm trying to figure out how to solve those with Harald, so we'll have a solution soon, but these are basically build tests, and then installing and updating Plasma 5 from git to make sure things work [17:25] actually, if we can get autopkgtests for PPA's that would be a big help [17:26] a log like https://launchpadlibrarian.net/192137245/buildlog_ubuntu-vivid-amd64.konversation_1.5.50%2Bgit20141209.0010%2B15.04-0ubuntu0_UPLOADING.txt.gz seems to be a lot like those, anyway [17:26] otherwise, I can setup some infrastructure on our end to do this [17:26] shadeslayer: we'll be able to with the new cloud-based airline [17:26] \o/ [17:27] not with the currnet infrastructure I'm afraid; it's squeaking under the load already :( [17:27] anyway, separate topic [17:27] yeah I can understand :) [17:27] pitti: what else would you like to see btw? [17:27] reverse dependency testing for sure; automatic tests as we have them (that's essentially what's on that jenkins, right?) [17:28] ( me and Harald are more or less exclusively working on this full time at the moment, so would be nice to have suggestions ) [17:28] but also some manual testing, at least starting the desktop, checking for visual oddities, and checking that you can get up to the package updater again [17:28] pitti: done every friday [17:28] i. e. we must never break the graphical package updater, so that we can clean up after a regression [17:29] ^ that for SRUs, I mean [17:29] ah right ofcourse [17:29] (not for upstream/vivid developmetn of course) [17:30] shadeslayer: i. e. if we make sure that we don't completely break a desktop with an SRU (and the automatic tests don't catch it), and we always have a way out through another update, I'd be happy [17:30] *nod* [17:30] That's totally reasonable, and actually, what should be expected [17:30] shadeslayer: do you want to do this for LTS, or for the "intermediate" releases too? [17:31] it seems to be quite a lot of effort, and these days the non-LTSes are comparatively fairly uninteresting IMHO [17:31] for now only for utopic [17:31] after the next LTS we can review that but yeah it would be effort [17:31] Riddell: ah, conceptually, or because it's a more appropriate "test run"? [17:31] pitti: because only utopic has kf5 in for now, in trusty it would be all new packages, dunno if the qt version is enough etc [17:32] after the next LTS we can judge the demand I guess [17:32] Riddell: ah, of course; so say, we have 16.04 LTSes, would you then only do that for LTSes, or only for the latest release, or something else? [17:32] ok [17:32] I'd say we would try to update Frameworks with our best effort [17:32] still for the latest releases, maybe for LTS if we're feeling generous but probably not [17:32] ok, interesting [17:32] and if upstream bumps Qt version, then it's a problem ofcourse [17:32] which shouldn't really happen .. [17:33] I have a feeling that the vast majority of users just stay at LTS these days [17:33] but yes, then let's give this some test runs on utopic [17:33] and see how it goes, how much effort it is, etc. [17:33] *nod* [17:34] ok, so provisional exception? [17:34] ok for me, if we have some test plan to go along with it [17:35] kees ? [17:35] yeah, that's fine by me [17:35] actually, I guess we just need one, so pitti can you respond to that thread? [17:36] "need" yes, but always good to collect opinions :) [17:36] mdeslaur: yes [17:36] [action] pitti to respond to MRE for KDE frameworks thread [17:36] ACTION: pitti to respond to MRE for KDE frameworks thread [17:36] cool [17:36] thx :D [17:36] I believe that's it from the mailing list [17:36] [topic] Community bugs [17:36] None [17:36] [topic] Next chair [17:37] Looks like it's pitti [17:37] pitti: congrats :P [17:37] docker in 14.04? [17:37] they haven't responded to our questions [17:37] we can discuss it if you'd like [17:38] yeah, I really don't like the "package every version" [17:38] but indeed, let's wait for a response, and f'up via mail [17:38] ok [17:39] * kees autocompletes "f'up" not to "follow up" [17:39] Does anyone have anything else to discuss? [17:39] kees: oops, sorry :) [17:39] lol [17:39] :) [17:39] yes -- where to go to dinner :) [17:39] and here I thought it was just me :) [17:39] (most folks already left, and urging us to leave too) [17:39] mmm food [17:39] it's 19:39 here already [17:39] pitti: have a nice dinner! [17:39] #endmeeting [17:39] Meeting ended Tue Dec 9 17:39:52 2014 UTC. [17:39] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2014/ubuntu-meeting-2.2014-12-09-17.08.moin.txt [17:39] thanks! [17:40] * pitti waves, thanks! [17:40] thanks everyone [17:41] shadeslayer, Riddell: thanks for coming! [17:43] de nada [20:30] always a pleasure :) [20:30] though I kind of panicked when Riddell went "Ubuntu tech board meeting! now!" across the desk from me