20:01 #startmeeting 20:01 Meeting started Mon Jul 22 20:01:39 2013 UTC. The chair is pitti. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 20:01 20:01 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 20:01 o/ 20:01 hey soren 20:02 #topic action review 20:02 kees to review outstanding provisional MREs -- as he doesn't seem to be here, I guess we defer this? 20:02 I don't see anything else, did I miss something? 20:03 #topic development series alias name 20:03 hi! here now 20:03 apparently this was being discussed last time, with: current proposals are "rolling" (preferred by Rick) and "next' (preferred by the TB). 20:03 still looking at mres 20:03 oh, hey kees! 20:03 kees: ok, so carrying over is ok? 20:04 yeah, thanks 20:04 OOI, does "preferred by the TB" mean that everyone else on the TB likes "next" better, or was it "just" a majority? 20:05 everyone preferred "next" 20:05 "rolling" seems to be more of a goal/promise still, while we might need to change "next" again in the future which would make the change pointless 20:05 Since the last meeting I sent in a request for extending the KDE MRE, does that get covered in kees' action or discussed separately? 20:05 ScottK: I think it's a separate discussion, kees' was only for the existing provisional MREs 20:05 pitti, it was unanimous among the TB 20:05 ScottK: I replied on-list 20:05 ScottK: separate, I was reviewing existing for their update histories 20:05 but we wanted rickspencer3 to have a chance to weigh in 20:05 is it time to discuss "rolling" vs. "next"? or was that a pre-amble? 20:05 OK. 20:05 rickspencer3: yes, please go 20:05 ok 20:05 rickspencer3, it is time 20:06 might need to change> could you elaborate? 20:06 mdz: (two more of your "no more re-election for me" mails on tb@, FYI; but I got the original alreadY) 20:06 cjwatson: I mean at a time when we actually drop the non-LTS releases 20:06 and have an actual rolling release 20:06 AFAIUI, this was merely deferred, not entirely rejected by sabdfl? 20:07 I am mostly neutral, i.e. mostly just want the discussion to be done 20:07 but "rolling" at this time is aiming a bit high indeed, although we do better than I initially feared 20:07 that will be a sad day (dropping non-LTS) 20:07 pitti, still zero on https://lists.ubuntu.com/archives/technical-board/2013-July/thread.html 20:07 with 9 months of support it's not that much of a release anyway 20:07 I had a very slight preference for next I suppose 20:07 kees, well, naturally I beg to differ 20:07 rickspencer3: :) 20:07 :) 20:08 I don't have a strong opinion, but I slightly prefer "rolling" as that's what the effect is for the user 20:08 i prefer the short stable to long stable 20:08 is this the time when I should make my case? 20:08 yes 20:08 rickspencer3: please, just speak up 20:08 ok, first, thanks for inviting me 20:08 the 6 month cadance, is to me, what makes ubuntu so great. 20:08 rickspencer3: (we don't have a formal "you have the mike" usually) 20:08 (if I could spell) 20:08 so, I think that "rolling" is much better than "next" 20:08 the "development" release is really usable every day, and has been since 12.04 20:09 this sym link will provide the experience of a rolling release, you are always on the tip, and it flips over when we release 20:09 I think "rolling" describes the experience quite well, and "next" does not describe this experience 20:09 I also think the notion of "next" is a result of thinking about Ubuntu development the way we used to do it 20:10 "rolling" to me implies a continuous flow, rather than stepwise upgrades 20:10 calling it "next" suggests that it will only be useful in the future 20:10 one of my concerns is that we still have DIF, and that there seems to be pressure against changing rust 20:10 mdz well, I think that's exactly what the sym link will provide 20:10 that 20:10 it's not a release, and I want there to be no confusion. "usable" does not mean "stable" which is what a release means to me. 20:10 kees, well, that's fine 20:10 mdz: and that's what it is, isn't it? 20:10 I'm not sure how to express it then 20:11 "next" is what it is. it's unfinished 20:11 and seems nicer than calling the symlink "usable" :) 20:11 kees, but that suggests that you are using something that will reach some point of completeness later 20:11 I find "next" a little unspecific -- the next what? 20:11 pitti, not to me. "rolling" is more like debian unstable or testing, with only incremental updates 20:11 what we're talking about here is a big batch of updates every 6 months 20:12 no? 20:12 err, do we? 20:12 mdz no 20:12 next ubuntu release is what it is. you're always running what's next. 20:12 ok, I'm confused then 20:12 what it would mean is that you were using what we would essentially call the "development version" 20:12 I thought right now {next,rolling} == saucy, and it would be t as soon as we release saucy 20:12 it's been a month and I hardly remember the discussion 20:12 i. e. "always the devel release" 20:12 then the day that version releases, the sym link gets moved to the next version 20:12 mdz: it's an alias like "sid" or "unstable" 20:12 we don't in practice roll for the last three months or so 20:12 ok 20:12 right, it sometimes flies and sometimes crawls 20:13 I don't really mind what it's called then 20:13 cjwatson, actually, I think we d 20:13 o 20:13 we so font 20:13 don't 20:13 all I remember is that hackles went up when "rolling release" was mentioned 20:13 gah swype 20:13 I'd prefer devel > rolling > next, but no strong opinion to argue about it for a long time 20:13 cjwatson, maybe I don't know what you mean 20:14 but it seems to me that I get lots of changes at the end of the cycle, sometimes big ones 20:14 * ScottK raises hands for hackles over rolling. It seems inaccurate. 20:14 right. it's not a release and "rolling" is already too associated with that concept. 20:14 we stop taking new upstreams routinely 20:14 cjwatson, true 20:14 that is what people expect from rolling 20:14 it slows down, but we take many big changes 20:14 from Canonical 20:14 we take a kernel, no? 20:14 The big changes at the end are because people can't keep a schedule, not because it's supposed to be that way. 20:15 not really from elsewhere 20:15 kernel is frozen almost before anything else 20:15 a bit, but I really do not think that is what people expect 20:15 ok 20:15 they want us to just keep going and not freeze 20:15 to me, the essence of "rolling" is really that you just subscribe to the sym link 20:15 you expect your desktop always works 20:16 and you get changes as fast as Ubuntu puts them in 20:16 I honestly don't think that's what everyone else means 20:16 and there never is a "release" 20:16 I am happy to make the symlink work and would like to 20:16 but it's not rolling 20:16 rickspencer3: i have no problem with the idea of the symlink. we all agreed that was great. just the name was the issue. 20:17 kees, sure, it;s fine 20:17 we don't have a good precedent for rolling to compare it against really 20:17 I was asked to come and explain why I liked "rolling" 20:17 I appreciate the opportunity 20:17 even sid isn't truly rolling in that sense, it had been frozen for over a year 20:17 I don't really like "next" at all 20:17 but, I am not on the TB 20:18 FWIW, I don't like "next" either, it doesn't tell me anything; I'd rather have "devel" then, as that's what it actually is -- the current development series 20:18 rickspencer3: we reviewed the suggested list from uds. if rolling is bad and next is bad, we need a new list, i think 20:18 I think I would prefer for the TB to make a decision 20:18 If it's arbitrary, then I would ask that you pick "rolling" 20:19 but if it's not, I really would support whatever 20:19 kees, does that make sense? 20:19 this is basically invisible to users, right? 20:19 who is the name important to? 20:19 sure 20:19 Except they'll have to opt in to it somehow 20:19 They'll be opting in to a name. 20:19 they will? 20:19 i don't want any mistake made about it being a release. that's my criteria 20:19 mdz yes 20:19 seems like we would have the opportunity to describe in prose what they're getting 20:19 it somehow needs to be exposed in software-properties 20:19 rather than just giving them a word 20:20 but we could describe the feature in the GUI however we wanted 20:20 so, you make a good point 20:20 it's doubly arbitrary 20:20 and yet it seems important to you and ScottK 20:20 kees: in that regard, terminology is already flawed; neither "rolling" nor "devel" are actual releases 20:20 they are precisely the series which are *not* released, after all :) 20:21 we were also going to let developers upload to it 20:21 "rolling" has alreadt been publically associated with being a release 20:21 If it wasn't already a package name, I'd suggest horizon, since no matter how long you go towards it, you never get there. 20:21 "devel" is accurate, but so many things are called devel 20:21 but how is "rolling" a release, in any sense of the word? 20:21 so it's not arbitrary,it will influence developer behaviour 20:21 and I'm 20:21 pitti: It's not and that was part of the problem with the proposal. We ought not mix this up with that. 20:22 concerned that it's incompatible with our current freeze processes 20:22 pitti: it is not pitti it wouldn't be in reality, but existing persepctions will confuse it 20:22 how about we agree to delegate to http://www.dotomator.com/web20.html 20:22 mdz fine "Voope" it is 20:22 I like "zoomdog" 20:22 "Thoughtpath" 20:22 ha 20:23 zoomdog. winnar 20:23 * ScottK got "Gabify". 20:23 I think that's what's going on right now. 20:24 I want to cry when I think of all the brain power that has already been absorbed by this question 20:24 so, as this is a rather classic bikeshedding argument and we could be here all night, how about we just vote on the existing proposals and get it done? or rickspencer3, would you like to discuss more? 20:24 rickspencer3: you don't like "next" but would be okay with it since it's not very visible? 20:24 pitti, I've said all I can say, I think 20:24 pitti, +1 on drawing to a quick conclusion 20:24 kees, I don't like "next", but I don't think me being "okay with it" is terribly apropos 20:25 I think this is a TB decision 20:25 and I won't quit Ubuntu if I don't get my way 20:25 ;) 20:25 so, our options are "next" and "rolling", or were there any others? 20:25 rickspencer3: well, I'd prefer something you're happy with 20:25 has "devel" even been on the table from the UDS discussin? 20:25 all things considered, we can't possibly consider all things 20:25 pitti: the list we looked at was from uds,but I can't find the url 20:25 kees, I don't see how we will get past this 20:26 in a way that makes everyone totally happy 20:26 devel was on it. 20:26 and it is such a small small thing in the scheme of things 20:26 I would prefer tofind something everyone likes, but that doesn't seem possible 20:26 kees: ah, ok; so in between rolling, next, and devel? 20:26 rolling it is! 20:26 good choice 20:26 next topic? 20:26 and things like head, master, tip, etc 20:27 I'm not vehemently against rolling, but I see definite problems with it 20:27 for counting I propose three separate votes, one for each name; multiple +1 allowed, the one with the most votes wins; ok? 20:27 sure 20:27 (I can't figure out CC at this time of the night) 20:28 but risks a tie 20:28 that's probably best 20:28 * rickspencer3 braces 20:28 at least it's fast 20:28 #vote series name for "always at development series" is: "rolling" 20:28 Please vote on: series name for "always at development series" is: "rolling" 20:28 Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me) 20:28 +1 20:28 +1 received from pitti 20:28 -1 20:28 -1 received from kees 20:28 +0 20:28 +0 received from mdz 20:28 -1 20:28 -1 received from stgraber 20:28 +0 20:28 +0 received from cjwatson 20:28 -1 (zoomdog ftw1) 20:28 -1 (zoomdog ftw1) received from soren 20:28 #endvote 20:28 Voting ended on: series name for "always at development series" is: "rolling" 20:28 Votes for:1 Votes against:3 Abstentions:2 20:28 Motion denied 20:28 #vote series name for "always at development series" is: "next" 20:28 Please vote on: series name for "always at development series" is: "next" 20:28 Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me) 20:28 +0 20:28 +0 received from mdz 20:28 -1 20:28 -1 received from pitti 20:28 +1 20:28 +1 received from kees 20:29 +1 20:29 +1 received from soren 20:29 +1 20:29 +1 received from cjwatson 20:29 +1 20:29 +1 received from stgraber 20:29 #endvote 20:29 Voting ended on: series name for "always at development series" is: "next" 20:29 Votes for:4 Votes against:1 Abstentions:1 20:29 Motion carried 20:29 #vote series name for "always at development series" is: "devel" 20:29 Please vote on: series name for "always at development series" is: "devel" 20:29 Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me) 20:29 +1 20:29 +1 received from pitti 20:29 +1 20:29 +1 received from cjwatson 20:29 +0 20:29 +0 received from kees 20:29 +1 20:29 +1 received from soren 20:29 +1 20:29 +1 received from stgraber 20:29 +1 20:29 +1 received from mdz 20:29 #endvote 20:29 Voting ended on: series name for "always at development series" is: "devel" 20:29 Votes for:5 Votes against:0 Abstentions:1 20:29 Motion carried 20:29 Wow. Unexpected. 20:29 wow 20:30 I demand a recount with condorcet voting 20:30 so we name the developmetn series ... "devel"? 20:30 lol 20:30 devel 20:30 mdz: if you know the procedure, please do 20:30 So we spend weeks debating about "next" vs "rolling" and end up choosing "devel". I love it. 20:30 pitti, kidding 20:30 ? 20:30 It's possible there was some strategic voting there. 20:30 It's no zoomdog, but hey. 20:30 Interestingly I just bought a condo in a small condo building. There is no storage, so no where to store my bike. So, in a couple of weeks I need to start a literal discussion about a bike shed. 20:30 red! 20:31 ScottK:not from me 20:31 rickspencer3, surely it will be names rolling? :) 20:31 ScottK: order shouldn't have mattered? 20:31 * ScottK was kidding (mostly) 20:31 i voted how I felt. devel over rolling, but not really FOR it 20:31 it's funny that we have so much trouble naming this "thing" 20:31 so, anyone who wants to propose something new, please start a new thread and try to convince people that it's really a lot better :) 20:32 The bikeshed is painted now. that's the main thing. 20:32 *phew* 20:32 rickspencer3: thanks for being at the meeting 20:32 #topic Discussion and vote on OpenSSL as a system library. Follow-up fro mthe last couple of meetings and ML discussion. 20:32 * ScottK thought that was voted on last time. 20:32 I thought this had already been concluded at the last meeting, according to mdz's summary? 20:32 that's settled 20:32 yes, I thought so too 20:32 I didn't get to updating the wiki 20:32 ack, thanks 20:32 I barely got the minutes out 20:33 #topic Xen MRE for upstream stable releases (Stefan Bader) 20:33 \o 20:33 if there have been good srus, I' for a provisional. it sounds like it gets good testing 20:33 I didn't reply because even from my years-long SRU time I can't remember a xen SRU 20:33 kees, not sure what exactly you mean by some good srus 20:34 smb have there been xen SRUs already? 20:34 pitti, Usually only cves 20:34 it seems a bit surprising that maintenance suddenly has gone up, but if it did, I'm fine with a provisional MRE as well 20:34 that didn't have regressions? 20:34 But since a while there is also upstream stable releases 20:34 (and probably none yet really looked there) 20:34 smb: right, but these aren't subject to SRU restrictions anyway 20:34 No, I started to think about it as 20:35 a) it is a bit like we already do with the kernel 20:35 b) security patches are based on the latest stable series 20:35 And the upstream stable releases go through reviews and afaik through regression testing 20:36 So it just seems a sensible approach to keep the version maintained even after release without too much more work 20:36 smb: what kind of testing do, or can we do, on proposed xen updates? like, running various existing test suites on various ubuntu releases under xen ? 20:37 smb: and what magnitude of changes do we talk about here? like, the occasional bug fix, or lots of reegineering? 20:37 (the latter would actually surprise me) 20:37 pitti, I am not sure there is really anything going on testing wise beyond the tests I do 20:38 and those are more manual by putting the updated hypervisor on two testboxes (amd and intel) and then fire up thy dom0 and pvm and hvm guest 20:38 pitti, And for magnitude, the number of check-ins may seem large but it is restricted to bugfixes and small contain improvements not re-engenieering 20:38 ah, reading the proposed diffs now, it's quite a list 20:39 pitti, mostly because I took the commit from git 20:39 so yeah, not quite possible to verify them all, we need some good regression testing there 20:39 I mean the short version oof commit ids 20:40 pitti, because we don't trust upstream? 20:40 i think we're better off with the fixes than without, so I'd likea provisional mre. if things stay smooth, it should get full mre quickly 20:41 smb: well, with that magnitude of changes it's not about trust, but about throwing more eyes on it, plus testing it in the ubuntu specific environment/binary build etc, which upstream can't do 20:41 smb: i. e. a newer xen package on precise might behave differently than what upstream tested on a different kernel? 20:42 pitti, I would always keep with the same minor version (so precise is xen 4.1.x and remains on that stream) 20:42 For raring it would be 4.2.x 20:42 smb: I think if we can define some regression testing, like "boot the last N releases/LTS default install and verify some list of things (networking, file system test suite, etc.)", we have some standard process which we can even automate 20:42 smb: right 20:43 pitti, Ah well ok. Though in some way I do those things but the question is how to document and have a tickoff list 20:43 so a comment like "Would like to see this as upgrading to 13.04/xen 4.2.1 broke pci-e passthrough for me but is fixed in 4.2.2." suggests that upstream microreleases are good to get in, but also that xen is not completely regression proof (which is certainly understandable between major releases) 20:43 smb: right, hence my question how we currently test them 20:43 smb: doing these manually sounds cumbersome 20:44 I agree to kees' "pro provisional MRE", we can discuss some verification strategy with the SRU team in these "update to x.y.z" bugs 20:45 cjwatson, soren, mdz, stgraber, any objections? ^ 20:45 yes 20:45 mdz: please go ahead 20:45 I'm fine with a provisional MRE 20:45 oh, sorry, I meant no 20:45 ah :) 20:45 no objections 20:45 yes I support a provisional MRE 20:46 great, that's settled; smb, thanks for joining 20:46 thanks 20:46 * smb goes back melting 20:46 #agreed provisional MRE for Xen, with defining more formal testing on the first SRU with the SRU team 20:46 #topic extending KDE MRE (ScottK) 20:47 I'm mostly +1 on this (as I said on the ML), with the exception of lightdm-kde where I would like to know first what kind of changes goes into it 20:48 * ScottK is researching that now 20:48 When was that sent tl the ML? 20:48 link would be good 20:48 my gut feeling is that we should be rather careful with this, and while it's certainly ok to update to new upstream microreleases, the individual changes ought to be reviewed more carefully than for the apps 20:48 stgraber: Wed Jul 17 15:37:22 2013 20:49 https://lists.ubuntu.com/archives/technical-board/2013-July/001666.html was ScottK's mail 20:49 hm, my response hasn't gotten to the archive yet 20:49 I got it though. 20:49 other than what I said above, I just said "I experienced several of those during my active ~ubuntu-sru time and 20:49 can confirm this." 20:49 those == KDE SRUs 20:49 hmm, must have missed this... and no access to email at the moment 20:50 We just finished doing 4.10.5 last week. 20:50 ScottK: yeah, the magic of CC: :) 20:51 list looks reasonable to me 20:51 * stgraber looks some more 20:52 to me as well, with the only "paranoia" bit that jumps out being lightdm-kde 20:52 although I guess that's mostly the chrome, not the plumbings 20:52 We don't have an immediate need for that as raring has the current release. 20:52 Yes, it should be just the front end bits. 20:54 lightdm-kde is a separate frontend for lightdm, so if it's maintained by the kubntu folks with the same process as other kde packages, I'm fine with it 20:54 yeah, I agree with pitti. looks good with questions about lightdm-kde. :) 20:54 and to be fair, I would have counted all of these as "KDE" as per https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions anyway .. 20:55 OK. We've been pretty strict about limiting it to the core KDE. 20:55 ok, so it seems no further questions/objections? 20:56 ScottK: so, seems we have a winner! 20:56 Great. 20:56 ScottK: do you want to keep lightdm-kde in the list, or rather put it back to reviewing individual changes? 20:57 TBH I don't have a really good idea how sensitive it would be to different hw/acceleration and the like 20:57 Let's wait until there's an update and then I'll bring it back with a concrete example in hand. 20:57 ack 20:57 #topic Scan the mailing list archive for anything we missed 20:58 nothing else that I can see 20:58 If the archive was up to date, there would be something. 20:58 my mailbox also doesn't have anything else 20:58 and mutt makes them stand out in green for me :) 20:58 Not that we expect the TB to act on it today, but Laney, on behalf of the TB, sent out a proposal on modifying PPU. 20:59 Message-ID: <20130722200701.GC22297@iota> 20:59 oh, in fact I just got it 20:59 (I got a copy via the TB list) 20:59 but it's longish, perhaps we could give us some time to digest 20:59 This is something to review and consider. 20:59 ah, hadn't seen that as I was looking at the archive 20:59 reading now 20:59 ah, yes, we're out of time anyway 20:59 I propose to carry? 20:59 Yes. I wanted to bring it to your attention to reivew. 20:59 thanks 20:59 Yes 20:59 #topic beer 20:59 err, I meant 20:59 #endmeeting