18:01:03 #startmeeting FESCO (2013-10-09) 18:01:03 Meeting started Wed Oct 9 18:01:03 2013 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:07 #meetingname fesco 18:01:07 The meeting name has been set to 'fesco' 18:01:12 #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh 18:01:12 Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:01:16 hello. 18:01:49 * notting is here. will have to leave just before the next hour, though 18:01:56 t8m regrets, can't attend today meeting 18:02:16 notting: don't worry, I'll be strict ;-) 20 minutes per topic 18:02:25 Hello 18:02:56 I'm around 18:03:34 * mattdm rushes in 18:03:42 that's six of us so far. 18:03:44 * tflink is trying to wrap up another meeting but is around 18:03:57 not that I'm needed for quorum :) 18:04:14 So we'll have quorum for one hour. 18:04:21 nirik: ? 18:04:22 well, 45 minutes. 18:04:24 so let's go. 18:04:37 #topic init process 18:04:38 pjones: No, if you leave, it's still 5. When notting leaves, that kills quorum :) 18:04:43 (oh, I guess you'll have quorom after I leave. sure.) 18:04:44 #topic #1178 Fedora 21 scheduling strategy 18:04:50 .fesco 1178 18:04:51 mmaslano: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178 18:05:56 tflink: Thank you very much for the detailed taskbot proposal. 18:06:14 Proposal: We're doing something new after F20. We know it's going to take some extra time to make sure everything is right, but we don't know the details yet. Postpone all post-F20 scheduling until after F20 release. 18:06:46 sgallagh: np, I've been needing to do write that stuff up for a while now :) 18:06:58 mattdm: I'm not going to agree to that without adding a minimum rider to it. 18:06:58 1, x, y, z? 18:07:16 tflink: seems cool. It's a real plan 18:07:18 i.e. I don't want us getting to the day after F20 release and deciding we have four months to F21 18:07:25 mattdm: that's what I said last time - put scheduling on hold 18:07:30 notting 1,2, y, z, x :) 18:07:35 That's not reasonable for any of rel-eng, qa, docs... 18:07:41 notting: the order of x, y and z aren't set so I didn't want to continue with numbers 18:07:43 jreznik I know, I'm putting it out there as a proposal now. 18:07:58 sgallagh: it would be definitely - hold and add at least 6 months after the decision is made 18:08:17 jreznik: I'd like to see that in the proposal, to be clear. 18:08:18 so no way to realize we have 4 months to rule the world 18:08:29 sgallagh: agree 18:08:57 Right, I'm assuming that we will aim for doing something big with the next thing, and that a short cycle won't help. 18:09:16 * sgallagh nods 18:09:34 * handsome_pirate waves from the Crows Nest 18:09:35 I also meant to invite mclasen today; I want to hear about Wayland 18:09:48 Because that's the elephant in the room this cycle 18:09:55 Let me see if he's around 18:10:10 "this cycle" = f21? 18:10:18 yes ;) 18:10:28 mattdm: Yes, sorry 18:10:33 jusssst being sure 18:10:50 sgallagh: well, I'd say - first decide what we want to do by Jan (so WGs output) and then schedule based on output of that, based on what changes we want (wayland...) 18:11:35 Well, I'm aware that upstream GNOME is at least planning for a full conversion to Wayland by GNOME 3.12. I wanted to know if they would feel better with an extra month or two 18:11:41 +1 jreznik 18:12:04 Remind me: do we have a deadline set for WG output yet? 18:12:06 sgallagh: while wayland is a big deal within the display stack, does it actually have that big an impact, or so much urgency, that we would want to modify the schedule (rather than adjust Wayland timing for the schedule)? 18:12:12 * sgallagh realizes this may be putting the cart before the horse 18:12:17 jreznik: ok +1 18:12:20 so, proposal: what I said before, but it will be at least a 6 month cycle, taking into account WG output plus needs from qa, releng, docs, etc. 18:12:29 sgallagh: we did set some date 18:12:50 mattdm: I'd be +1 for that 18:12:53 mitr: I contend that if we switch to a new Fedora Workstation product, having that be the delivery vehicle for the first fully-functional Wayland would be a headline-grabber 18:12:58 sgallagh, mmaslano we said "January" 18:13:09 sgallagh -- which would be good, right? 18:13:13 mattdm: +1 18:13:14 mattdm: as in it would be at least 6 months before f21 alpha? 18:13:14 mattdm: so the same thing we've always said then. 18:13:23 mattdm: Yes, I'm viewing that as a strong positive. 18:13:25 sgallagh: true [but optimizing for marketing is really not personally interesting to me] 18:13:29 Hence why I think it should have schedule impac 18:13:31 *impact 18:13:36 jreznik: I'm fairly skeptical about WGs producing output that could be used for anything close to feature-driven scheduling 18:13:41 tflink: at least 6 months to final + time to January from now 18:13:41 sgallagh: so we would like to see plan how much time it will take in either way 18:13:49 jreznik: We just don't have that kind of power over the contributors/manpower 18:13:54 mitr: Well, part of the purpose here is to reinvent ourselves, so marketing needs as much attention as anything else 18:14:17 jreznik: So, June minimum 18:14:32 pjones yes basically the same except we're not scheduling it from right now. 18:14:42 mattdm: at least 6 month cycle from f20 GA to f21 GA? 18:14:48 hi 18:14:58 mclasen: We're talking about you :) 18:15:03 notting: No, a schedule of 6 months from WG delivery to GA 18:15:05 tflink: Would this give you the 3 months you asked for? (Or, do you need to know now whether the schedule will give you the 3 months, or is it OK to know in January?) 18:15:07 notting: more from January output from WGs + 6 months 18:15:21 mclasen: Thanks for joining. 18:15:24 mitr: We'd prefer to know sooner 18:15:55 mitr: If we don't find out until January, we're not going to be so hot on the planning 18:16:08 handsome_pirate that seems reasonable :) 18:16:13 mitr: my plans until january will be similar whether we decide to delay now or not 18:16:13 mclasen: Quick catch-up: we're discussing extending the F21 schedule. I raised the point that F21's Fedora Workstation would be the delivery vehicle for the first complete Wayland solution. We wanted your input as to whether you could benefit from some additional time in the schedule to get that right 18:16:38 tflink: Aye, but we'd like to know before then how much time we'll have 18:16:46 tflink: So you're looking for more like an August or September F21 deliverable. Is that what I'm hearing? 18:16:51 handsome_pirate: well, you would have three months for free by January + at least another 6 months later (3 could be used for development) 18:16:57 handsome_pirate: sure but it's not required 18:17:11 sgallagh: depends on what f21 ends up being, I suppose 18:17:24 Assuming F21 ends up being the three products 18:17:34 sure, additional time is always useful 18:17:38 jreznik: How so? With F20 release cycle, we don't have three months 'free' 18:17:38 sgallagh: seems like people tend to it 18:17:41 we're operating with the gnome schedule currently, but getting everything done by march is going to be a bit of a challenge 18:18:25 mclasen gnome is march/september releases, right? 18:18:29 mclasen: do you have a timeframe with plan for all major components? 18:18:46 mattdm: yes, end of march 18:18:55 sgallagh: yeah, that would be 3 months + 6 month release cycle 18:19:00 it would be kind of nice to get back on an april/october fedora schedule _anyway_. 18:19:12 mmaslano: no, but I'll try to produce something like that this weekend 18:19:22 let's split it for now - put schedule on hold by January; and then discuss the rest (probably in January - we don't know the output would be to stick with 6 month scheduling) 18:19:35 great 18:19:50 jreznik: Well, we've got a number of people who have obvious benefits available to delay by a few months. 18:20:00 mattdm: obviously, I disagree with that statement. 18:20:15 pjones what do you prefer? 18:20:15 As long as we make it a one time thing 18:20:20 I'd like to suggest that we go with "No earlier than July" today, with the option to extend that after WG delivery 18:20:23 handsome_pirate yes, one time thing. 18:20:27 mattdm: I prefer a schedule based on a plan for what we want in the release. 18:20:34 sgallagh: but it's there... just I'm saying split it - if you want to say Jan + 9 months, it probably makes sense too (but this part could be changes by WGs) 18:20:35 * handsome_pirate wants to keep the six month schedule otherwise 18:20:58 jreznik: Yes, but I'd rather build some extra time in *now*, so people can be sure they're getting at least a little extra to work with. 18:21:04 pjones so, features based rather than cadence-based? 18:21:04 sgallagh: I'd be ok with that 18:21:09 pjones: Those tend to just stretch out and nothing gets released 18:21:12 If we say "6 months and it may extend", that's not helpful 18:21:22 mattdm: we've never managed to have either. 18:21:32 lol ouch. 18:21:54 pjones: We try for cadence, however 18:21:55 on the other hand - if done better, it's not bad idea to have combination of both 18:22:10 we've failed at cadence 19 times so far. 18:22:11 back to topic... 18:22:24 Hopefully we can manage something better like that with the Product plan, since the set of deliverables for each product will hopefully be more constrained 18:22:41 proposal: schedule on hold by January, then no earlier than July? 18:22:41 sgallagh: indeed. 18:22:43 So, if we base on features, what becomes the deciding factor of when we cut off, and what happens when someone raises Cain because their shiny toy doesn't make it? 18:22:48 jreznik: sure, +1. 18:23:05 jreznik: +1 18:23:09 handsome_pirate working group plans. 18:23:25 That guarantees at least one month of time for e.g. taskbot work, with an option to provide more. 18:23:26 jreznik: doesn't that leave open the possibility of starting the f21 dev cycle in january? 18:23:29 tflink, handsome_pirate does that proposal give you what you need to schedule? 18:24:00 mattdm: We want three months without release validation 18:24:02 tflink: well, in some sense, the f21 dev cycle has already started 18:24:05 tflink: Can taskbot not coexist with development, assuming that alpha freeze is a month later? 18:24:10 notting +1 18:24:15 mattdm: Do the WGs have any incentive to make limited plans, when including everything under the Sun would seem to make everybody happy? 18:24:19 there are already "f21" packages :) 18:24:21 sgallagh: the issue is people to work on taskbot more than anything 18:24:25 sgallagh: Not really, since release validation takes away too much dev time 18:24:31 mitr "success"? 18:24:39 the work can coexist but the people can't do two jobs at the same time 18:24:40 Sure, but release validation would start a month later, wouldn'it? 18:24:54 (Also, with an option to extend it out if the WGs say so in Jan) 18:25:09 handsome_pirate: if i'm understanding, it can coexist with *development*, but it can't coexist with freezes & validation. i.e., it's not an issue when dev cycle starts, it's an issue when it comes time to start making deliverables? 18:25:15 mattdm: Or to put another way, FESCo has never refused a feature somebody (said they) wanted to work on. Why would WGs be different? 18:25:16 tflink: I'm confused about which people would be doing two jobs in that time-period 18:25:21 sgallagh: That's the whole point is to have three solid months without having to do release validation 18:25:24 Ideally, we could go into january knowing what we can plan for, but we can work with the usual month between releases 18:25:29 mattdm: (I want them to be different, I can't see how it would happen) 18:25:31 we don't know yet how release validation would look like at all... so it's hard to plan it now 18:25:45 sgallagh: other qa folks that I'd like to have participating in devel if they're available 18:25:46 mitr we still won't refuse them but they might not impact the release schedule. 18:25:48 * mmaslano 20 minutes on topic 18:26:25 anyway I'm +1 for the proposal with the note that I'm going to vote for whatever it takes to get the qa automation stuff resourced. 18:26:33 especially up through phase y 18:26:37 tflink: Is the month immediately following the WG deliverable not enough bonus time? Or do you need it defined differently? 18:26:37 we should vote on someproposal, jreznik's? 18:26:42 sgallagh: Release validation takes up too much time for anyone to do both, and there aren't enough people to divide up labor 18:26:58 mattdm: I agree +1 18:27:10 sgallagh: We'd like two or three months; three would be better 18:27:12 mattdm: +1 I agree with that statement wholeheartedly 18:27:13 4 votes, more for proposal: schedule on hold by January, then no earlier than July? 18:27:40 mmaslano: Can we try s/July/August/, just to see how that vote goes? 18:27:40 +1. I'd much rather have a fixed schedule right now, but 1) that's what we''ll de facto do anyway, and 2) this lets us close the topic now 18:27:41 sgallagh: it might be enough time to get phase 1 done, other qa folks need to do f21 prep in that month as well 18:27:43 I'm +1 to Aug. 18:28:03 proposal: schedule on hold by January, then no earlier than August? 18:28:08 (I'm +1 to either, but I'd like to give QA what they want) 18:28:08 +1 to august too, given what I just said above :) 18:28:20 mmaslano: sure, +1. 18:28:22 mmaslano: Isn't July +5 alerady? 18:28:34 I'm fine with giving time to all parties 18:28:35 +1 18:28:37 mitr: no reason we can't vote to move it back if that would get more votes, though 18:28:48 pjones: sure 18:28:48 hm. i'm generally +1 to the idea. at a certain point, we're going to be shipping more stale bits the longer we push the release out 18:28:52 mitr: yeah it is 18:29:10 proposal: schedule on hold until after wg prds in january. Will include three months for qa and releng automation. 18:29:15 notting: Not really an issue for most components, since they'll likely just end up rebasing in F20 18:29:22 *F20 Updates 18:29:23 notting: Not really, since freeze will also be pushed back 18:29:26 -1 to August 18:29:36 #agreed schedule on hold by January, then no earlier than August (+5,-1,0) 18:29:43 sgallagh note that this is what happened in FC4 with the FC5 long ccycle and then FC4 was a debacle. :) 18:29:51 sgallagh: in terms of major desktops, you'll likely be shipping stale code. *shrug* only really a concern for one of the products 18:30:14 notting: Well, we will see how things progress in the WGs 18:30:19 to make sure that we all understand, that means that f21 will start no earlier than march 1, right? 18:30:29 Remember this is "no sooner than", not "fixed to this date" 18:30:35 tflink: what do you mean by 'start'? 18:30:44 tflink I'd rather not phrase it that way. As notting mentioned, f21 started when f20 branched. 18:31:02 notting: Release validation 18:31:03 tflink: Do you mean composes and TCs? 18:31:05 two months ago. :) 18:31:07 f21 branch 18:31:14 is a better way to phrase it 18:31:17 +1 18:31:20 notting: It's not like we are hurting for more and more desktop features; if anything, stability of the codebase is my bigger concern; so the value of shipping the very latest upstream major release doesn't seem that large to me 18:31:23 Yes, those should be offset by the amount of extra time we just granted. 18:31:23 f21 branch would then be no earlier than march 1 18:31:32 i.e. extra time pushes from the front, not the back 18:31:43 mitr: agreed 18:31:46 tflink ye. that's fine with me. 18:31:50 mitr: we're always shipping the very latest upstream major release. it's just a matter of how long it has been out when we shi 18:31:52 sgallagh: I'm just making sure I understand how much time that is - sound like 1 month for now and maybe more once WG output is in 18:31:55 mitr: *ship 18:32:02 notting: We start rolling TCs within a week of branch 18:32:14 tflink: No, I think we just gave two months, plus more once WG input 18:32:19 s/more/maybe more/ 18:32:39 Anyway we could go ahead and set a minumum date for branch? 18:32:51 sgallagh: we're saying the same thing just measuring differently, I think 18:32:51 s/minumum/minimum 18:33:11 1 month from feb 1, or 2 months from jan 1 18:33:33 I was thinking 2 months from Jan 1. 18:33:47 do we expect the release validation will be the same as now? even branching? not sure we know it today... 18:33:53 yeah, I was counting from feb 1 which is how I had phrased the proposal 18:34:10 tflink: Would you not be working on it in January? 18:34:14 * sgallagh is confused 18:34:22 tflink: With the F20 schedule there are 3 months between alpha change deadline and final release; so presumably the F21 alpha change deadline would be in around May 18:34:36 wouldn't be better to check on output of WGs and output of QA and relengs and create new schedule after that? 18:34:39 sgallagh: yes but I was assuming that january was a given and was doing delays from feb 1 18:35:12 mitr: yep, if done same way as today 18:35:22 tflink so all of the time estimates are assuming one month already? 18:35:26 Yes, let's not set the hard Freeze dates until WG output, please 18:35:41 mattdm: the scope was starting from feb 1 - that's in the proposal 18:35:45 mmaslano: unless something significantly changes in the governance mechanism I'm not in favor of feature-based releases 18:35:47 sgallagh: I said nothing of hard Freeze, just minimum 18:36:18 mattdm: so 0 month delay would be branch no later than feb1, 1 month would be no later than march 1 and 3 months would be no later than may 1 18:36:23 handsome_pirate: and we already set that minimum 18:36:23 tflink but it assumes some groundwork will be done in january too. 18:36:32 i'm not complaining just tryting to get this straight :) 18:36:39 mitr: I didn't say feature-base, I'm saying see how much time needs QA and releng to make 3 products ready 18:36:54 mattdm: yeah, I'm assuming that josef and I will be able to work on automation at least 75% of the time until january 18:37:10 mmaslano: I'd say the only way to find out is to try; perhaps I'm just ignorant 18:37:15 +1 mmaslano 18:37:25 mmaslano: We want time to work on automation in addition to figuring out 3 Products 18:38:01 mmaslano: I think we have a QA person on each of the Working Groups 18:38:07 mitr: I'm against half baked releases, it makes bad marketing 18:38:10 with the above agreed proposal, what extensions are we discussing here? or is this general discussion? 18:38:15 Well, at least I think so 18:38:31 handsome_pirate: It's sort of unofficial that we intend to have a QE rep selected to be part of the official WG, when that time comes. 18:38:33 I'm signed up for one, tflink another, Viking-Ice a third, etc 18:38:38 does anyone have any proposal? 18:38:41 handsome_pirate if we don't have a qa person on each one we will get one. 18:38:44 * sgallagh tried to make it official last meeting, but that part never got voted on 18:38:47 otherwise I'd like to move to next topic 18:38:57 sgallagh: do you wan to try now? 18:38:58 +1 to moving on 18:39:13 mmaslano: I'll get to it in Open Floor if we get there 18:39:27 i'm okay to move on. tflink, handsome_pirate we'll get you the time to make this happen. 18:39:37 mattdm: Thanks much 18:39:43 to make sure I'm clear, QA isn't commiting to anything more than phase 1 before f21 unless there is a longer delay 18:39:46 But frankly, I expect that it would be a formality. We're all sensible people who wouldn't want to leave QA out of this 18:39:51 we can revisit in january, though 18:40:07 tflink ack 18:40:15 ok, let's move on 18:40:18 #topic #1179 Interactions of the various Products 18:40:25 .fesco 1179 18:40:26 mmaslano: #1179 (Interactions of the various Products) – FESCo - https://fedorahosted.org/fesco/ticket/1179 18:41:11 any development here? 18:41:16 anything new to discuss? 18:41:34 Wasn't this supposed to be dropped from the meeting? 18:41:46 " 18:41:49 Agreed(+5): We do not necessarily need to define these interactions yet. 18:41:51 " 18:42:08 dropped or closed? 18:42:24 mmaslano: I think we were going to effectively defer it until the WGs are selected 18:42:29 ok 18:42:39 new business 18:42:41 #topic #1180 Build virt-preview in Koji 18:42:46 hello, crobinso is here too 18:42:47 .fesco 1180 18:42:48 mmaslano: #1180 (Build virt-preview in Koji) – FESCo - https://fedorahosted.org/fesco/ticket/1180 18:42:57 * crobinso waves 18:43:12 msuchy is not on Cc of the ticket, so I'm not sure he saw the last response 18:43:15 * pjones likes this and wishes the best of luck but also has to go. 18:43:48 grrr trac-- 18:43:49 mitr: then we should probably fix that 18:43:55 rwmjones: Shared COPRs are on the roadmap, but last I checked are not available at present. 18:43:58 I have earnestly looked at copr (it's ~10K of code) and AFAICT it does not support teams upstream at the moment 18:44:01 right 18:44:16 notting: right, that would imply "add cc, defer for a week" 18:44:16 I can answer part of it 18:44:19 However, we might be able to just create a shared FAS account as a short-term workaround. Just share the PW until that feature is added. 18:44:23 copr is planned really soon, in weeks 18:44:36 mmaslano: msuchy said "days rather than weeks" ? 18:44:43 documentation and time plan needs more work 18:45:00 he spoke about this month, it could mean end of month ;-) 18:45:01 copr doesnt have any arm nodes 18:45:06 I'm not so optimistic 18:45:16 rwmjones: Would a shared password be a sufficient short-term answer? 18:45:18 dgilmore: good point 18:45:42 in a related note, I am doing some work to enable RDO and some other projects to do thier upstream builds in koji 18:45:44 sgallagh: not sure I understand what's being proposed 18:45:50 and this kinda fits in with that 18:46:08 rwmjones: Create a new FAS account "virt-preview", set a password on it, give this account COPR access. 18:46:18 this is something that I want to enable to be done in koji 18:46:25 Give out the password to that account to trusted individuals who should be allowed to build there. 18:46:32 ok, I guess so 18:46:35 crobinso: ^? 18:46:42 enabling upstreams to do builds in koji on isolated hardware 18:46:50 fine by me, I don't anticipate many people needing access 18:46:52 dgilmore, mmaslano: Sounds like there "should" be a general consensus whether this kind of functionality should end up in koji, or copr (however copr is implemented). Isn't there a risk of building the same thing twice? 18:47:01 rwmjones: This is obviously a hack, but maybe "good enough"? 18:47:20 ok 18:47:44 * mattdm doesn't care too much about the implementation details but definitely wants to enable this kind of thing 18:48:11 mitr: I would prefer for such stuff copr, but I shouldn't vote on that 18:48:29 mmaslano: If you don't vote, we don't have quorum for a vote today :) 18:48:42 sgallagh: than copr it is 18:49:07 mitr: sure. I see it as a valuable service to the communities we work with and am happy to enable it as we see best 18:49:26 I always kind of assumed that COPR and Koji were eventually going to merge, since at least the builders function similarly 18:49:28 +1 dgilmore 18:49:37 dgilmore: 2 valuable services still add up to a wasted effort? 18:49:45 sgallagh: copr doesnt allow building for arm which is one thing rwmjones wanted 18:50:03 what's the reason that copr doesn't support arm? 18:50:14 just no one's done it, or there's some fundamental problem? 18:50:16 no one think about it probably 18:50:18 rwmjones: afaik its never been considered 18:50:21 dgilmore: seconded, especially with all the active upstream virt on arm work, enabling virt-preview for arm would be helpful 18:50:22 rwmjones it's implemented on openstack 18:50:24 I'll add it into ticket and ask tomorrow 18:50:32 dgilmore: Doesn't allow or hasn't yet implemented? 18:50:36 #action mmaslano will ask about arm in copr 18:50:50 sgallagh: its not even been looked at to see if its feasible 18:50:51 mattdm: It could still be done via qemu-arm 18:51:02 Slow, but possible (i'd think) 18:51:27 sgallagh: that would be plumbing in a build path that's not done anywhere else, though 18:51:46 Proposal: Short-term solution: get a new virt-preview FAS account created and added to the COPR ACL 18:52:09 * sgallagh feels like we're wandering afield of the original request 18:52:31 I'm fine with it ... however will wait until copr appears before doing anything 18:52:44 rwmjones: I've been using COPR (in beta) for some time 18:52:51 sgallagh: i'd be fine with that if the virt team is. and they can investigate other koji uses as they come online too 18:52:52 rwmjones: I'll poke it, I'll promise :) 18:53:43 mmaslano: Sidebar: any plans for having COPRs automatically produce repo config files? Because *needed* 18:54:35 #action mmaslano will ask about automatically produce repo config files by copr 18:55:18 sgallagh: I don't think there is plan not do it, just too much work with the whole thing now 18:55:30 Thanks 18:55:39 rwmjones: satisfied for now? can we move to another ticket? 18:56:04 sure 18:56:18 notting: BTW, Brownies on 9 :) 18:56:28 #topic Next week's chair 18:56:53 i will not be able to make next week (and on that note, i have to go to a different meeting now) 18:57:16 I'll cover next week. It's been a while 18:57:41 #action sgallagh will be chairman on 16th 18:57:48 #topic Open Floor 18:58:10 I think we lost quorum, so I'm not going to bother with the WG/QE vote. 18:58:15 abadger1999 is not here, so we can skip python3 feature, probably 18:58:46 mmaslano: It needs a week on the list first anyway 18:58:51 yeah 18:59:08 I'll close meeting at 21:00 18:59:12 um :) 18:59:17 in one minute 19:00:24 mmaslano: Thanks for chairing 19:00:37 #endmeeting