18:02:05 #startmeeting FESCO (2012-03-12) 18:02:05 Meeting started Mon Mar 12 18:02:05 2012 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:02:06 ah, got it 18:02:14 #meetingname fesco 18:02:14 The meeting name has been set to 'fesco' 18:02:23 loads of fun for all involved. 18:02:25 #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher 18:02:25 Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m 18:02:39 #topic init process 18:02:46 Hi all 18:02:55 Afternoon 18:03:03 * limburgher here 18:03:03 * nirik waves 18:03:05 Hello 18:03:15 * notting is here 18:03:47 mmaslano is I think away today 18:04:12 and sgallagh is _afk 18:04:20 sgallagh_afk, around? 18:04:37 t8m: He sad on #fedora-devel he won't be able to make it 18:04:46 OK, then we can start 18:04:53 with followups 18:05:03 #topic #699 Proposal to remove the package "tzdata" from Critical Path 18:05:04 .fesco 699 18:05:05 t8m: #699 (Proposal to remove the package "tzdata" from Critical Path) – FESCo - https://fedorahosted.org/fesco/ticket/699 18:05:44 So do we want to exempt tzdata from all testing? 18:05:46 so, the request is to have a special case in bodhi that exempts it from any and all checking? 18:05:47 I'm fine with not having it in the critpath. 18:05:56 I am NOT fine with allowing it to go direct to stable. ;) 18:06:15 notting, seems so 18:06:15 notting: allowing it to push to stable directly. (which no other package can do currently) 18:06:30 That's a bit like having a surge protector on everything but your dialysis machine. 18:06:44 How about treating it like prerelease updates? 18:07:21 I also agree that to allow direct push to stable just for tzdata is not desirable. 18:07:44 I imagine it should be possible to automate all relevant tzdata tests, then a direct push might be considered 18:07:55 limburgher: per-package timeout configurability? not sure it's worth that level of bodhi hackery just for this 18:08:41 The original request was pretty clearly for an exemption from all testing 18:08:53 I'm against further special casing for this one package. 18:09:10 And we approved it at the time 18:09:14 notting: If it's a lot of trouble, then I agree. 18:09:25 mjg59: and it still makes a lot of sense, tbh 18:09:41 If tzdata is not critpath, the maintainer can still set stable karma to "1" and then +1 it himself, can't he? 18:09:49 * nirik doesn't remember us agreeing to that. 18:09:56 I think we said "how about just making it not critpath" 18:10:08 nirik, +1 18:10:20 nirik, I do not remember special casing it either 18:10:36 just removing from critpath 18:11:03 We really didn't talk about it much 18:11:12 Most of the discussion was about what would have to be done in bodhi 18:11:35 mjg59, that was discussion about the critpath list 18:11:46 Merely removing it from critpath does little to deal with the issues that were raised in the original request 18:11:59 mjg59: the discussion seemed all about the removal from critpath, though 18:12:22 the title of the ticket is somewhat misleading. ;) 18:12:33 Yeah, the title doesn't help things 18:12:52 I see little real risk of a tzdata update being pushed that manages to break things 18:13:02 http://meetbot.fedoraproject.org/teams/fesco/fesco.2011-11-21-18.00.log.html#l-115 18:13:35 I see little real reason not to treat multiple other packages the same way as would be desirable for tzdata 18:13:54 If we have a class of packages we think should be ok to push to stable with 0 testing, we should consider that... I think adding _another_ special case in bodhi for one package is not a reasonable use of developer time. 18:13:59 t8m: tzdata is only useful if it reflects the real world 18:14:05 And the real world keeps changing 18:14:21 t8m: well, very few of them are data-only and change at the whim of governments constantly in the spring and autumn. 18:14:22 nirik, +1 18:14:45 t8m: and in a very real way, this same problem is why we split it out from glibc in the first place. 18:15:01 An analogy might be that people keep changing the root DNS servers with 36 hours of notice, and if you don't get an update your bind stops working 18:15:12 nirik: I think we should first discuss whether we want the requirements (i.e. find a tester or wait 3 days). If we do want to relax them, it probably can be done manually without extending bodhi again 18:15:17 do we exempt bind from testing? ;) 18:15:27 I think tzdata should be eempted from testing 18:15:47 mitr, manually how? 18:15:54 mjg59: Funny that you mention that, RHEL had a sort of dizaster with a root server update a few years ago 18:16:00 For the dual reasons that it has a very low risk of causing regressions while also being in the unfortunate position of actually having to reflect rapidly changing reality 18:16:00 t8m: set "required karma" to 1 and self-+1 ? 18:16:13 mitr, but would it really work? 18:16:14 * mitr is a typo generator today 18:16:20 nirik: no, but if we actually had the analogous problem, we might separate out name.ca and have this policy for that 18:16:23 * nirik thinks it should go via testing... and get +1 karma from a actual tester. 18:16:23 t8m: I don't know. Anyone? 18:16:38 yes, it does, but it's not supposed to. 18:16:53 nirik: point being, root nameservices are at least somewhat responsible with that sort of thing - awesomely countries don't seem to be very responsible at all when it comes to the time of day. 18:17:03 yeah, sadly true. 18:17:21 What would the reasons for not exempting it be? 18:17:36 Risk of regressions, technical issues with special-casing? 18:17:56 yeah. 18:18:09 our bodhi logic is already too complex. 18:18:26 (IMHO) 18:18:31 I think that's a question we should put to the bodhi maintainer rather than worrying about ourselves 18:18:37 I don't think that having pmachata just asking one another person (for example from his Brno colleagues) to install the update and say that he does not see any problems during the install is a real problem. 18:18:43 everyone fat-fingers things sometimes,even for something like tzdata 18:18:47 in 2.0 the update logic is config... in 1.0 it's part of the app, so you have to add code and push our a new version. 18:18:52 t8m: The issue isn't for current, it's for previous releases 18:19:25 t8m: If there _is_ a new problem, such a testing is rather unlikely to catch it - there are too many timezones for that 18:19:26 so, perhaps we vote? or do we want more info from bodhi maintainer? (who is at pycon this week) 18:19:35 notting: For tzdata the real risk would seem to be that it's broken in a subtle way - as long as the maintainer actually installs the package, anything grossly wrong is going to be obvious 18:20:11 mitr, I mean not testing the changes just to see if the system does not explode after installing the package 18:20:16 notting: And if it's a subtle breakage there's no real expecation that testing is going to pick it up - we just get daylight savings time in Indonesia wrong for years before 1976 or something 18:20:29 t8m: What if it explodes, but not in .cz? 18:20:40 mitr, we can't catch this anyway 18:21:01 mjg59: That would probably break connecting to my VPN from my DeLorean, but that's unsupported anyway. 18:22:23 So, proposal: FESCo is fine with tzdata not having another tester or waiting for 3 days if every new package goes through an automated test that involves at least 1) (TZ=$foo date) working for foo being each shipped timezone, 2) determining the date range that is changed for each timezone, and manual review of these changes. (This proposal doesn't talk about how would that be achieved in bodhi.) 18:22:38 mjg59: no testing policy has nothing to verify 'maintainer installed the package and didn't screw it up' 18:23:00 s/these changes /these date ranges/ 18:23:41 #proposal FESCo is fine with tzdata not having another tester or waiting for 3 days if every new package goes through an automated test that involves at least 1) (TZ=$foo date) working for foo being each shipped timezone, 2) determining the date range that is changed for each timezone, and manual review of these changes. 18:24:04 Can we define what "not having another tester" means? 18:24:10 proposal: require tzdata to follow normal testing process for now, ask bodhi maintainer how hard it would be to except or if it would be possible in 2.0 to configure this. 18:24:16 mitr, I am afraid this is too complex 18:24:29 mjg59: 'not having to reach the normal karma threshold', presumably? 18:24:40 #proposal Exempt tzdata from karma requirements in bodhi 18:24:46 notting: let's define what it does have to do instead of what it doesn't, then? 18:24:55 "not having to reach the normal karma threshold by the ordinary process" :) 18:25:59 t8m: Would s/with.*if/with tzdata going to stable if/ help, or do you mean the condition? 18:26:38 mitr, I mean the condition 18:26:43 * nirik is -1 for mitr and mjg59's. 18:26:56 * t8m is -1 for both as well 18:27:53 -1, I think rounding up a few people to smoketest a tzdata package should be simple enough. 18:27:53 0 to mitr (it's too complex). although if someone can rig up that tests, they can also apply karma 18:28:05 * limburgher meant for both. 18:28:12 What is the current status of AutoQA? 18:28:24 limburgher: The maintainer has explicitly said that it's not simple enough 18:28:31 * limburgher will be AFK for up to 30 minutes, will catch up upon return. 18:28:47 it can do dep tests and nvr-upgrade tests... it can run rpmlint and various stuff. 18:29:05 notting: Right... so that boils down to "no exceptions" after all 18:30:05 i'd be +1 to nirik's proposal, which is an implicit -1 to mjg59, i guess 18:30:07 well, it's not in critpath at least, so it can push to stable after N 18:30:11 I think it would be nice if we could have a group of packages defined in bodhi for which AutoQA tests would be sufficient to get to stable. 18:30:34 currently autoqa is just advisory... 18:30:55 There was no proposal to just refuse the request? 18:31:16 nirik, yes, it would just gradually move it to 'allowing' for specified group of packages 18:31:46 mitr: guess not. I'd be +1 on that too. 18:32:00 mitr, well if we do not agree with the exception we implicitly refuse the request 18:32:03 I think it would be good to consider packages like this for bodhi 2.0 tho 18:32:28 nirik: "like this" is exactly what? time-sensitive and unlikely to be tested correctly? 18:32:42 It seems to me that the set is pretty small 18:32:57 mitr, I'd rather like time-sensitive and autoqa tested 18:33:05 mitr: time sensitive and brokenness doesn't really affect much 18:33:56 mitr: time sensitive and something you could write a plugin to do near-100% testing of? 18:34:13 An out of date tzdata means that there's a window where we're shipping an OS that is entirely useless to segments of our userbase 18:34:37 time being off is 'entirely useless'? 18:34:38 mjg59, strange definition of useless 18:35:04 t8m: Having all your timestamps be wrong is pretty crippling 18:35:25 We're all in the favourable position of living in places where time changes occur rarely and with advance notice 18:35:34 mjg59: happens about once a week currently to me, until chronys corrects it... and it seems everything survives 18:35:37 *shrug* Proposal: refuse the request; the maintainer can set karma threshold to 1, and find one person to do minimal sanity testing and/or run an automated test. We can discuss AutoQA when it is relevant (i.e. "we will spend >30 minutes of the FESCo meeting on tzdata in a year again") 18:35:42 -1 18:35:54 +1 18:36:00 mitr, +1 18:37:49 Anybody else votes? 18:37:58 * nirik waits for votes. considers getting coffee. 18:38:05 definitely -1 to that proposal 18:38:31 pjones, note that this is implicit resolution anyway 18:38:38 effectively you're telling the maintainer "sorry you can't find testers, suck it up" 18:39:10 pjones: No, I'm pretty sure that somebody around here can be found if necessary. 18:39:17 I think it's more "sorry, you're not that special, please follow the process everyone else does for now" 18:39:23 nirik, +1 18:39:31 mitr: The maintainer has said that somebody can't be found 18:39:46 mitr: you think the maintainer is lying, or what? 18:39:48 (the primary goal of this proposal is to clarify whether we want to grant an exception at all or not - it's not clear to me) 18:40:07 pjones: I must have missed that 18:40:31 I think pmachata just does not believe real testing can be done. 18:40:34 specific quote? (note that originally it was "proventester", I'm not claiming that a proventester can be found) 18:40:38 * nirik notes we have been on this 40min so far. 18:40:53 "On the other hand, older or even too new Fedora releases take a long time to get the karma necessary for auto-push. Or even the first karma point that I need for manual marking." 18:41:53 OK, I did miss that. 18:42:33 but he doesn't need that first karma point for manual makring now 18:43:09 notting: still, what's the point of us making him manually mark it every time if we know (and basically encourage) that's what he's going to do? 18:43:25 pjones: not having to worry about bodhi functionality for a single package? 18:43:44 I'm touched by the concern we're all having for Luke 18:44:01 But maybe we should ask him whether he thinks that it's going to be a problem in bodhi or not, rather than making that decision for him?> 18:44:10 mitr: can we please talk about the policy here instead of holding up bodhi as a strawman? 18:44:55 pjones: what we're asking is for an exception for a specific maintainer's processes of how he builds and stages his update. i'm against certifying that in policy 18:44:57 sure, we could ask and defer to next week if folks want. 18:45:11 but I really don't see why we are special casing this one package. 18:45:14 I have no problem with adding functionality to bodhi I have a problem with doing it for one single package. 18:45:27 notting: honestly I think this has more to do with the nature of the data than with the maintainer. 18:45:30 not to lob a grenade in here, but is this whole discussion taking place under the assumption that tzdata updates can't possibly break anyting? 18:45:37 adamw: no. 18:45:41 okay, cool. 18:45:52 well, that *was* the reasoning presented in the ticket, yes. 18:46:04 "Besides, I argue that it's not likely that tzdata actually breaks the system in the first place." 18:46:16 It's unlikely, yes 18:46:20 notting: well, I was holding adamw's phrasing as intentionally stronger than that. 18:46:29 tzdata is clearly different to other packages 18:46:31 right, i'm okay with that kind of qualified side note. 18:46:42 no problem here, i'll be quiet. 18:46:50 We have very little in the distribution that's time sensitive 18:48:04 another 15 minutes passed 18:48:59 so, gather more info and defer? finish voting? 18:49:21 Well, do people think that this exception is justified? 18:49:27 (Ignoring bodhi completely) 18:49:32 Because, if not, there's no point in deferring 18:50:28 i don't think a direct-to-stable path is justified without some step to catch a bad package. given that the only such check in this proposal is the goodwill that the maintainer did such testing, i'm -1 to the exception. 18:51:02 * nirik nods. what notting said 18:51:13 if there's a problem getting +1s on tzdata updates, i can possibly do something about that, if i'm asked. it could be the case that people are not +1ing it because they think they need to do more than just check nothing explodes when they boot with it. 18:51:28 -1 for the same reasons as notting and also because I'd really like to see a generalized exception if we'd like to give one 18:52:33 So we're at -3 to an exception. Does that mean we're at +5 to one? 18:52:43 Or has everyone just died? 18:52:49 Oh, limburgher was afk 18:53:09 I think it certainly needs something other than the process it currently gets. 18:53:22 The impression I get is that we don't actually care about this enough to even agree whether or not we care about it 18:53:22 mmaslano is not here. so... an exception can't pass at ths point. 18:53:42 mjg59: That's where I ended up 18:53:44 So I'd suggest we defer it 18:53:54 OK, deferred. 18:54:04 ack tp deferring and moving on 18:54:09 Um, what does deferring solve? 18:54:17 Nothing 18:54:22 mitr: I guess we might have more people next week to vote? 18:54:26 #info Deferred to next meeting 18:54:28 right 18:54:29 #topic #800 Feature Freeze exception: JBoss AS 7 18:54:30 .fesco 800 18:54:32 t8m: #800 (Feature Freeze exception: JBoss AS 7) – FESCo - https://fedorahosted.org/fesco/ticket/800 18:55:16 * limburgher is back, sorry. 18:55:18 Feature freeze exception for something that's still unstable? 18:55:29 Well, I guess there'd be no point otherwise 18:55:45 the feature page is at 75% 18:55:46 So, eh, +1 18:56:13 the fact that legal issues have been resolved doesn't say anything about the current status from a 'is it in' perspective 18:56:37 These are new packages, so what does us +1'ing or -1'ing affect? release notes only? 18:56:41 +1 I suppose 18:56:49 I've seen movement on packaging in the last few days, but I'm not sure what %. 18:56:52 http://fedoraproject.org/wiki/JBossAS7 has the packaging status 18:56:54 sure, +1 18:57:04 sure, +1 18:57:05 +1 18:57:14 looks like about 13 packages. 18:57:21 mitr: Yeah, only outcome would be dropping it from the release notes 18:57:36 +1 18:57:41 sure, I guess if it doesn't affect anything else... +1 18:57:42 #agreed The feature freeze exception for JBoss AS 7 is granted. 18:57:48 however, the feature page should be adjusted. 18:58:10 Now for the new business 18:58:13 #topic #820 Feature Freeze exception: Mingw-w64 cross-compiler 18:58:14 .fesco 820 18:58:15 t8m: #820 (Feature Freeze exception: Mingw-w64 cross-compiler) – FESCo - https://fedorahosted.org/fesco/ticket/820 18:58:41 "All this work has been completed now, so the MinGW-w64 feature itself is 100% implemented in Fedora 17. " 18:58:45 given that, +1 18:58:46 So, this is again relnotes only? 18:59:00 * mitr would be very -1 to starting these changes (rebuild with different toolchain) now 18:59:19 Yeah, just renamed package blocking to go. 18:59:23 As the percentage of completion is 100% anyway 18:59:25 +1 18:59:28 sure, +1 18:59:29 +1 18:59:36 +1 18:59:48 +1 18:59:58 * t8m wonders if we do not set some wrong expectations with these exceptions for future. 19:00:28 +1 19:00:47 #agreed The feature freeze exception for Mingw-w64 cross-compiler is granted 19:00:54 t8m: Not with these exceptions, but with failing to notice and/or complain about the change happening 13 days ago 19:01:40 mitr, I'm not quite sure that is a business of Fesco to explicitly look at every update happening on the release 19:01:45 #topic #707 Updates to language on FESCo Election page 19:01:45 .fesco 707 19:01:49 t8m: it's not 19:01:52 t8m: #707 (Updates to language on FESCo Election page) – FESCo - https://fedorahosted.org/fesco/ticket/707 19:02:06 +1 19:02:16 This one is older but it did not have the meeting keyword. 19:02:26 But I added it nevertheless 19:02:38 i am fully in favor of making the wiki reflect reality. +1 19:02:44 * nirik didn't recall seeing this one. 19:02:46 +1 19:02:55 +1 for the first change, +1 to dropping the reminder email 19:02:55 +1 19:03:34 +1 yeah 19:04:14 #agreed The updates to the FESCo Election page as described in the ticket are approved. 19:04:45 I suppose toshio can update the page or would someone else do it? 19:04:51 anyone can 19:05:36 OK I'll do it. 19:05:39 +1 19:05:45 #action t8m will update the page 19:06:03 #topic #819 Please review our determination of IPv6 issue blocker status 19:06:03 .fesco 819 19:06:04 t8m: #819 (Please review our determination of IPv6 issue blocker status) – FESCo - https://fedorahosted.org/fesco/ticket/819 19:06:33 +1 is fine with this change. 19:07:03 +1 19:07:10 +1 19:07:12 +1 Absolutely. Agreed, and logically arrived at. 19:07:24 +1 19:07:25 +1 19:07:54 #agreed FESCo agrees with the IPv6 issue blocker status. 19:07:55 the phrase "IPv6-only networks are becoming a configuration sufficiently important" strikes me as bizarre wishful thinking, but nevertheless I agree that the bug should be a release blocker, so +1 19:08:21 #topic #808 Unretiring policy (or Fedora policies in general) needs a "common sense" clause 19:08:21 .fesco 808 19:08:23 t8m: #808 (Unretiring policy (or Fedora policies in general) needs a "common sense" clause) – FESCo - https://fedorahosted.org/fesco/ticket/808 19:08:44 More controversial topic. 19:09:14 -1 to "use common sense", because common sense isn't. 19:09:33 completely with agreement on notting there. was about to type almost exactly the same thing. 19:09:34 notting: Except when it is. :) 19:09:40 I think the biggest problem is that the announcement of the retiring is not being read by people who will be affected by it. 19:09:45 Unretiring packages that were accidentally retired, or right after it's noted that they were needed is fine with me. 19:09:53 but waiting 3 weeks and complaining about it isn't. ;) 19:10:01 t8m: devel@ is wrong? should it go to devel-announce as well? 19:10:02 In theory I'm absolutely fine with the idea that we should be able to skip re-review on recently orphaned packages, but there's an obvious argument over what "recently" would mean here 19:10:08 * mitr would +1 "unretiring within a month is fine _for packages that were ever properly reviewed_", but that's too complex, so -1 19:10:09 notting, perhaps 19:10:23 also, 'recently' isn't exposed anywhere sanely to make such a determination 19:10:31 notting: I think it's more that it's difficult for owners of dependent packages to notice 19:10:34 other than guessing from the git log 19:11:14 How about "Packages may be unretired without review up to a month after retirement providing that the package has ever previously been reviewed" 19:11:25 Ideally, owners of about-to-be-kicked packages and their dependers would be directly emailed, but really devel should be enough. 19:12:08 mjg59: a month seems long, but I guess... 19:12:27 mjg59, I'd like to see a shorter time than month 19:12:42 2 weeks? 19:12:56 Blue. 19:13:02 Lemon curry. 19:13:05 So yeah sure 2 weeks 19:13:13 Anyone? 19:13:14 #proposal Packages may be unretired without review up to 2 weeks after retirement providing that the package has ever previously been reviewed 19:13:16 t8m: I think the risk is not in the one month between retiring and unretiring, but in the ~1 year the package had been FTBFS (... and presumably not being updated for guidelines) 19:13:31 mitr, hmm that's true 19:13:40 mitr: But since that's true for packages that are nominally actively maintained too, it seems an odd distinction to make 19:13:51 right, but someone unretiring it has incentive to get it to build. ;) 19:13:58 mjg59: often. 19:14:00 hopefully 19:14:01 nirik: One would hope. :) 19:14:20 so, +1 to proposal, thats fine. 19:14:30 yeah, I think I can be +1 to that. 19:14:41 we should note that this should be a rel-eng ticket, not random email to someone or irc or mention on a list. 19:14:48 * mitr is +1, and would be +1 to a month as well 19:14:51 +1 Does this mean the onus is on the unretiring owner to get someone to do it? 19:14:51 I suppose unretiring it doesn't get it back from the old collections in koji 19:15:02 limburgher: it would be anyway. 19:15:07 +1, with the 'via ticket to rel-eng caveat' 19:15:14 notting: indeed 19:15:18 ... but on the whole, sorting the list of dependent package in the "retiring packages" mail by owner would do more good I think. Now only to find someone to code it. 19:15:27 pjones: Oh. Duh. :) Sorry, one of those days. 19:16:35 I suppose given the last week discussion we will see some objections from dgilmore? 19:17:27 * nirik shrugs. I doubt it. 19:17:52 I think the review (old one) would be necessary for having the bug where to place the git request for revival 19:18:18 so yes I am +1 as well 19:18:20 we should update the orphaning page with this info. 19:18:24 and possibly announce it. ;) 19:18:36 t8m: Unless it's positively ancient, in which case it really needs a re-review anyway. 19:19:00 #agreed Packages may be unretired without review up to 2 weeks after retirement providing that the package has ever previously been reviewed 19:19:21 Anyone wants to take the action 19:20:40 #action t8m will update the orphaning page and announce it on devel 19:21:26 thanks t8m 19:21:55 Now, to make people read their email. 19:21:58 We have new features for F18 from package wrangler but I suppose we should postpone them to next week. 19:22:09 limburgher: thanks for volunteering for that. 19:22:09 given the length of today's meeting 19:22:21 pjones: /me shoots self 19:22:44 i'm ok either way 19:22:51 * nirik is too. 19:23:23 I'm a bit busy but can probably go either way if everyone else can. 19:23:24 +1 to postponing 19:23:26 t8m: i dont object as long as the package is taken care of 19:23:33 dgilmore, nice 19:23:47 I've got some other work I need to do in the next hour or so, so I'd just as soon not do that today 19:24:08 #topic Next week chair 19:24:24 Anybody volunteers? 19:24:34 do we want to move the meeting for daylight savings time? or keep it at the same time? 19:24:46 I can chair. 19:24:50 nirik: *shrug*. 19:25:03 Can we move it one week later - we are still at standard time here 19:25:04 I say leave it unless someone needs to move it. 19:25:05 * nirik also doesn't care, just wants to ask. 19:25:07 I actually like 2pm a bit better in general, but it really depends on the people in europe 19:25:35 I would have no problem with not moving it either 19:26:04 1PM works better for my schedule 19:26:42 as i have a once-a-month or so conflict at 2/2:30 19:26:51 notting, do you care if we move it after Europe changes DST? 19:26:57 t8m: no. 19:27:23 #action limburgher will be the next week chair 19:28:01 So let's discuss the meeting time change next week again. 19:28:11 for now keeping the 18:00 UTC 19:28:24 #topic Open floor 19:28:53 Anybody has anything for the open floor? 19:29:13 No. 19:29:42 * nirik has nothing. 19:30:32 not i 19:30:35 * t8m will close this meeting in a minute if nobody speaks up. 19:31:23 #endmeeting