From Fedora Project Wiki

< QA‎ | Meetings


  • adamw (134)
  • j_dulaney (61)
  • tflink (38)
  • rbergeron (28)
  • kparal (19)
  • akshayvyas (13)
  • jskladan (6)
  • zodbot (4)
  • Cerlyn (4)
  • brunowolff (3)
  • nb (3)
  • nirik (2)
  • mkrizek (1)
  • pschindl (1)


  • Previous meeting follow-up
  • ARM as a primary arch
  • Fedora 17 retrospective
  • AutoQA update
  • Open floor

Previous meeting follow-up

  • adamw to review F17 retrospective and come up with an action plan - this is mostly complete and some parts will be discussed today
  • adamw to work with rbergeron to make sure housekeeping gets done for f16/f17/f18 - adam contacted robyn and spot, did not yet receive replies
  • tflink to fix up blocker bug page for new bugzilla, probably as fedora-hosted static HTML rather than in MW - work is in progress, hitting some 'proxy errors' from bugzilla but this is likely an error on the server end not in the script
  • tflink to set up QA git account - this has been done, see here

ARM as a primary arch

  • Supported ARM implementations are pandaboard, trimslice, highbank, beagleboard and kirkwood; currently QA has a pandaboard and a trimslice. Also an XO 1.75 and some Raspberry Pis on order, neither of which are yet officially supported
  • j_dulaney and nb believe there is budget available to get more hardware
  • With ARM as a primary arch, would we hold an entire release due to one ARM implementation being broken?

Fedora 17 retrospective

  • We liked doing go/no-go on Thursdays and would like to schedule it that way for F18
  • Group agrees that we should aim to roll RCs as soon as possible after change deadline rather than schedule a specific day for them
  • No clear agreement on whether blocker meetings should be moved, and if so, to when
  • Bruno was not around to discuss his blocker list analysis suggestion

AutoQA update

  • No news (Tim and Kamil have other tasks at present)

Action items

  • adamw to start a list thread for further discussion of the blocker review meeting time topic
  • adamw to start a list thread about ways to analyze the corpus of blocker bugs


adamw #startmeeting fedora-qa 15:00
zodbot Meeting started Mon Jun 18 15:00:14 2012 UTC. The chair is adamw. Information about MeetBot at 15:00
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00
adamw #meetingname fedora-qa 15:00
zodbot The meeting name has been set to 'fedora-qa' 15:00
adamw #topic Roll call 15:00
* tflink is here 15:00
* Cerlyn is here 15:00
* akshayvyas is here 15:00
adamw who be here for some swashbucklin'? 15:00
adamw darn, wait. that's my pirate swordfighting meeting. ALWAYS getting those mixed up. 15:01
* kparal arrives 15:01
* jskladan hides in shadows 15:01
* mkrizek is here 15:01
adamw mornin' folks 15:02
adamw if anyone wants to join the pirate swordfighting meeting instead, just mail the cheque to... 15:02
brunowolff I'll be here for about 25 minutes. 15:03
adamw alrighty, let's get going 15:03
adamw #topic Previous meeting follow-up 15:03
adamw "adamw to review F17 retrospective and come up with an action plan" - i done that! well, quite a lot of it, and some we'll need to discuss today as a group 15:04
adamw #info "adamw to review F17 retrospective and come up with an action plan" - this is mostly complete and some parts will be discussed today 15:04
adamw "adamw to work with rbergeron to make sure housekeeping gets done for f16/f17/f18" - i mailed robyn and spot but didn't get replies yet. 15:04
adamw #info "adamw to work with rbergeron to make sure housekeeping gets done for f16/f17/f18" - adam contacted robyn and spot, did not yet receive replies 15:05
adamw "tflink to fix up blocker bug page for new bugzilla, probably as fedora-hosted static HTML rather than in MW" - tim? what's the status on this? 15:05
tflink working on it - still hitting the occasional BZ proxy error but that's probably not a problem on my end 15:06
* pschindl is here (I was changing my laptop keyboard) 15:06
adamw i think i've seen one of two of those in interactive use 15:07
adamw so yeah, probably not you 15:07
adamw anyone else? 15:07
tflink the opinion in #fedora-admin is that it's due to load issues with bz 15:07
adamw ok 15:08
adamw #info "tflink to fix up blocker bug page for new bugzilla, probably as fedora-hosted static HTML rather than in MW" - work is in progress, hitting some 'proxy errors' from bugzilla but this is likely an error on the server end not in the script 15:08
adamw "tflink to set up QA git account" - we know that's done 15:09
tflink yep, done. I don't think there is much if anything in there but the repo does exist now :) 15:09
adamw kparal's scripts 15:09
adamw #info "tflink to set up QA git account" - this has been done, see 15:10
* j_dulaney waves 15:10
adamw hi dulaney 15:10
j_dulaney How do we get access to said git account? 15:10
tflink j_dulaney: the repo is public but if you want write access, ask adamw, kparal or I since we're the admins ATM 15:11
adamw er, i don't see that off the top of my head. kparal? 15:11
j_dulaney tflink: That's what I meant 15:11
kparal #link 15:11
adamw ah, it's...oh, you beat me. 15:12
brunowolff Normally write access is controlled for fedorahosted stuff by being in a group. 15:12
adamw we still don't really have an active qa group in fas, but we could add one for git access i guess. 15:12
j_dulaney Hmm, reinstate the QA group? 15:13
adamw yeah, seems like a reasonable use for it if it comes up. 15:13
kparal 15:13
adamw oh right, one is automatically created 15:13
brunowolff Doesn't the group for access get created automatically (as part of the setup)? 15:13
adamw yeah. 15:13
adamw i forgot. 15:13
tflink you can apply for commit access through the gitfedora-qa FAS group 15:14
tflink 15:14
* j_dulaney just did 15:14
adamw alrighty, so that's covered. 15:14
adamw #info to get write access to git, apply to the gitfedora-qa group in FAS, and probably let adamw/tflink/kparal know why you need it. 15:15
adamw #topic ARM as a primary arch 15:15
adamw #chair j_dulaney tflink kparal 15:15
zodbot Current chairs: adamw j_dulaney kparal tflink 15:15
adamw well, j_dulaney wanted this on the topic sheet, so here we go 15:15
adamw is there anything specific to discuss? 15:15
j_dulaney Well, at SELF, the topic came up 15:16
j_dulaney Specifically, QA's role 15:16
j_dulaney And I brought up hardware 15:16
j_dulaney It would seem that there is some budget that could be made available for hardware for us to test on 15:16
adamw i think we have quite a bit lying around at this point 15:17
adamw hands up who has ARM 15:17
* adamw has an XO 1.75 sitting on his desk and a trimslice in a box 15:17
* tflink has a 1st gen panda board 15:17
* j_dulaney has nothing, although a raspberry pi is supposed to be coming 15:17
* Cerlyn has several XO-1.75s 15:17
adamw kparal, anything over there? 15:17
kparal no ARM in Brno afaik 15:18
tflink I thought that most arm testing could be done with qemu 15:18
kparal I'd like to order some Raspberry once it is available again 15:18
j_dulaney Anyway, my thought is that we should figure out what we don't have that is officially supported and make requests for that 15:18
j_dulaney tflink; the arm folks don't seem to like that 15:19
Cerlyn Fedora building cannot be done in qemu; I don't know if they plan to support qemu as a destination platform 15:19
adamw pandaboard, trimslice, highbank, beagleboard, kirkwood and Pi seems to be the crop. 15:19
adamw 15:19
adamw so we're missing highbank, beagleboard, and kirkwood, apparently. i'm sure Pi will be covered, seeing how insanely popular it is. 15:21
adamw kirkwood is all those *plug systems - sheevaplug, dreamplug etc. 15:21
j_dulaney Like I said, I'm *supposed* to be getting a Pi 15:21
tflink yeah but it looks like most pi users are going to be using debian :-/ 15:21
j_dulaney Okay, I'll ping nb to see about getting at least one example of each of the above 15:22
tflink doesn't mean that we can't run fedora on it, though :) 15:22
j_dulaney If we do get some hardware, how should it be distributed? 15:22
adamw good question. i mean, whoever goes to the work of getting it can obviously have some. 15:23
adamw i guess it'd be good for rh's brno office to have some too, though we can always do that through rh channels... 15:23
j_dulaney As far as actual testing, most of the current test criteria should work for arm 15:24
j_dulaney I guess if arm goes primary, would we slip the whole release if arm is blocking? 15:25
adamw that's the idea, yeah. 15:25
tflink I think that would be a real possibility 15:25
tflink as always, it would depend on what the blocking issue is, I think 15:26
adamw and yeah, we've pretty much established that we'd use a restricted version of the existing criteria to test ARM. basically the Base criteria, i think. 15:26
j_dulaney That was the other question that came up during SELF 15:26
j_dulaney I guess the only question is if the blocker is specific to one arm hardware version? 15:26
adamw yeah, that could be a tricky situation. 15:27
nb j_dulaney, do we know where the hardware should go to? 15:27
nb j_dulaney, i will get with people to try to find budget somewhere 15:27
tflink I thought that they were in that situation now where there were kernel issues on the panda's omap 15:27
nb and what is highbank? I'm not finding anything obvious in google 15:27
tflink but to be honest, I haven't been following all that closely 15:27
j_dulaney nb: We'll figure that out once we know we can get some h/w 15:28
j_dulaney tflink: I think that is supposed to be fixed in 3.4 15:28
j_dulaney tflink: I think the issue was with the 3.3 kernel 15:28
j_dulaney But, I could be mistaken 15:28
adamw nb: i didn't recognize that one either, the page just refers to it as highbank. 15:29
tflink j_dulaney: yeah, that rings a bell but it was still an issue with blocker poential that was limited to specific HW within ARM 15:29
j_dulaney Indeed 15:29
j_dulaney And that's the kind of thing we're going to have to hash out 15:29
adamw i guess we'd have to say that if Fedora ARM's approach is to claim to 'support' specific implementations, all of those have to be working, but nothing else does. 15:30
adamw that'd be my call anyhow. 15:30
* j_dulaney is on the fence about it 15:30
j_dulaney My preference would be to block in such situations 15:30
adamw #info supported ARM implementations are pandaboard, trimslice, highbank, beagleboard, kirkwood and Raspberry Pi; currently QA has a pandaboard and a trimslice, and some Pis on order. Also an XO 1.75, which is not listed 15:30
* tflink thinks that the first release with ARM as primary is going to be interested :) 15:31
tflink interesting 15:31
adamw #info j_dulaney and nb believe there is budget available to get more hardware 15:31
j_dulaney However, it seems like it would tick everyone else off if we held the whole release on just one arm h/w implimentation 15:31
adamw sure, but we're experienced at ticking people off. =) 15:31
j_dulaney +1 15:31
tflink hopefully we won't have so many late issues if we're testing more 15:31
adamw #info question arises as to whether, with ARM as a primary arch, we hold an entire release due to one ARM implementation being broken 15:32
adamw tflink: cos that works so well for x86 ;) 15:32
tflink adamw: exactly, we never have major test escapes 15:32
adamw i suspect if the situation arose we'd have to let lots of people get their oars in, anyhow, to establish some precedent. 15:33
j_dulaney adamw: i almost wonder if that should be a FESCo or even board question? 15:33
adamw j_dulaney: right, it'd probably end up with lots of big guns at a blocker meeting. so i'm not sure if we can decide it in advance 15:34
adamw we could say QA's position is to push for a high-quality approach, though, i.e. tend towards blocking, if that's what we believe. 15:34
j_dulaney adamw: It wouldn't hurt to advance it to FESCo 15:34
j_dulaney adamw: +1 on we would prefer to block 15:35
j_dulaney adamw: My thinking is that if we do advance it to FESCo, tell them our prefered outcome (we block), the rest of the project can't get mad at us 15:37
adamw sure, that'd be a reasonable approach 15:37
j_dulaney If y'all want, I can file a ticket with FESCo 15:37
j_dulaney And we could all show up to that meeting 15:37
adamw probably not worth it as of yet, at least until arm is actually taken as a primary arch 15:38
adamw that hasn't happened yet afaik... 15:38
adamw we need to move on from this as we have retrospective stuff to discuss, i think we raised the appropriate issues at least, anyone want to make any definite decisions or bring up other areas before we move on? 15:38
* j_dulaney is good 15:39
adamw okey dokey 15:39
adamw #topic Fedora 17 retrospective 15:39
adamw so in working through the retrospective - - i found there were several things listed which set up more as questions for group discussion than simple 'action items' 15:40
adamw so i wanted to run through those quickly 15:40
adamw first one up: "RC schedule tinkering: should we aim for RC on Tuesday? What's the plan for Go/No-Go and Release Readiness meetings this cycle?" 15:40
adamw darn, i should've asked rbergeron along. 15:40
adamw rbergeron: ping, any chance you're here? 15:40
rbergeron there's a chance 15:41
rbergeron SMALL BUT THERE 15:41
rbergeron are we retrospectiving now? :) 15:41
adamw we are indeed 15:41
rbergeron epic 15:41
* rbergeron takes a seat 15:41
* j_dulaney notes that rbergeron as a Beefy Miracle was epic 15:41
adamw rbergeron: so do we have any definite plans for changing up the go/no-go and readiness meetings this cycle? 15:42
rbergeron not yet. Feedback on how we thought it went having go/no-go on thursday this time instead of wednesday? 15:42
adamw or should I try and kick start something? 15:42
adamw worked fine for me. we got an extra day. did anyone complain about it? 15:42
rbergeron (and final go/no-go has always been scheduled for tuesdays) 15:42
* nirik thinks thursday is fine and makes sense. 15:43
* j_dulaney liked Thursday 15:43
rbergeron I think for Final - my only concern from the FPL/marketing seat is that I have all the people at Red Hat hot on my ass about wanting to schedule press releases and talk to pressy-interviewers 15:43
adamw the other question is not just go/no-go _in relation to readiness_ but the absolute timing of them - do we actually need all that time between RR and release? do we have a specific list of everything that happens in that time and how long it takes? 15:43
rbergeron But I think we gneerally start having a reasonable feel for it - and i haven't encountered anything where it wound up destroying their plansfor another press release for someone else. 15:43
rbergeron hrmmmm 15:44
* rbergeron thinks 15:44
adamw #agreed there is a consensus that we liked doing go/no-go on Thursdays and would like to schedule it that way for F18 15:45
tflink adamw: I think that delay was for mirror propagation 15:45
adamw that's one of the things often cited, yeah. i don't know if we know whether it really takes that long. 15:45
rbergeron so WRT release readiness - I know that websites does quite a bit of work - I am not sure if there's an element there of not wanting to destroy people's weekends 15:45
j_dulaney Which makes sense 15:46
nirik it takes less time than it used to these days, but yes, there's still time needed to sync out. 15:46
rbergeron if we waited till, say, Friday - it's very late friday in some parts of the world - people may not be as responsive to email. (conversely, others may have more time available, but.) 15:46
rbergeron For people to be getting the word that we're on (or that we're off). 15:46
adamw OK. it sounds like the general tenor is that the readiness->release lag is reasonable. 15:48
adamw so, on the other part of this question - for some reason we seem to schedule TC1s on tuesdays but RC1s on thursdays. 15:48
* j_dulaney reminds y'all that even the extra couple of days will wind up getting full up 15:49
rbergeron that could entirely be an artifact of my idiocy. Have we noticed if one works better than another? :) 15:49
adamw rbergeron: I think it's probably because the change deadline is tuesday and it's assumed we need some time from change deadline to rolling an RC, but that isn't necessarily the case 15:49
* j_dulaney thinks getting RCs out earlier = better 15:49
rbergeron adamw: yeah 15:49
adamw right, i was thinking something along the lines of simply saying that we roll the RC ASAP after change deadline' 15:50
adamw not sure how we can express that in the schedule, but it seems like the logical approach 15:50
rbergeron adamw: can you make a note of that in the meeting logs? 15:51
rbergeron I wonder if that's what dennis is doing anyway - i feel like it is 15:51
adamw well, we kinda schedule the RCs between us (qa and releng) 15:51
* rbergeron notes she would really really like to see a fixed time for what exactly the change deadline is also, FWIW, though that's not entirely this meeting's problem 15:51
adamw but when we've rolled ahead of the date on the schedule people have brought it up 15:51
adamw does everyone agree with the goal of rolling RC ASAP after change deadline? 15:52
* j_dulaney is +1 15:52
rbergeron yes 15:52
rbergeron adamw: bad/evil TCs won't affect that in any way? 15:53
tflink yeah, that sounds good to me 15:53
akshayvyas yes 15:53
adamw rbergeron: er, evil TCs? 15:53
rbergeron ie; there's no threshhold of success to move from TC to RC 15:53
adamw #agreed group agrees that we should aim to roll RCs as soon as possible after change deadline rather than schedule a specific day for them 15:54
adamw rbergeron: the requirements for an RC roll are a) freeze in place b) no blocker bugs 15:54
adamw the properties of the previous TC build do not in themselves matter at all 15:54
rbergeron okay, just making sure :) 15:54
adamw npnp 15:54
adamw okay, moving along quickly as we're taking up time... 15:55
adamw "Blocker bug meetings: should we move them from Fridays?" 15:55
rbergeron I feel like we've done a lot of ad-hoc blocker meetings. 15:55
adamw kparal says that current blocker timing is bad for Europe, especially RH people in the brno office, as it's right at the time they very much want to be going home for the weekend 15:55
adamw rbergeron: this is about the regularly-scheduled ones. 15:55
kparal home or pub 15:56
adamw heh 15:56
rbergeron yes, but I feel like we're always doing ad-hoc because we're tinking "shit, friday is 4 days away" 15:56
adamw I pinged jlaska to ask, but i don't think he replied yet, if there's a specific reason we currently do the meetings on friday 15:56
rbergeron do we get more bugs over weekends or during the week? 15:56
adamw off the top of my head i can't think of one 15:56
tflink rbergeron: I think we'd hit some of that no matter what day of the week we did it 15:56
adamw rbergeron: i don't think there's a definite trend, it mostly depends on when the candidates are built and stuff. 15:56
j_dulaney rberegeron: I do most of my testing on weekend 15:56
tflink if it's only once per week, we'll be having some ad-hoc meetings 15:56
j_dulaney So, probably a mix 15:56
j_dulaney tflink: +1 15:57
adamw right, i think the ad hoc meetings are inevitable 15:57
j_dulaney Fridays are the best days for me 15:57
adamw can anyone think of a schedule-related justification for any day in particular? 15:57
adamw wednesdays make sense from a minor angle, if we're going to be always doing go/no-go on thursdays, it gives us a meeting ahead of the go/no-go to take stock 15:58
tflink thursday to make it even throughout the week with the monday QA meetings? 15:58
j_dulaney Friday gives time after RC rolls 15:58
akshayvyas i think friday is good 15:58
akshayvyas or weekends 15:58
tflink on second thought, I like adam's reasoning for wednesday more 15:58
j_dulaney +1 15:59
rbergeron yes, but I think wednesday also assumes we'll be doing ad-hoc - we don't want to only wait till wednesday and have it be filled with new bugs that can't be addressed - particularly if people in europe are going home for hte day, and the go/no-go is the next day 15:59
adamw akshayvyas: it'd be a lot of trouble persuading RH staff to show up on weekends, i can tell ya =) 15:59
akshayvyas adamw: agree 15:59
akshayvyas well then i say wednesday or friday 16:00
adamw rbergeron: well, the idea is to kill one reason for the ad hoc meetings, actually - we always wind up doing one ahead of go/no-go during panic times, to knock a few stubborn blockers off the list 16:00
adamw it sounds like we don't have a clear consensus here; discuss further on the list? 16:00
jskladan ^^ +1 16:00
tflink kparal: would doing it earlier in the day on Friday work? 16:00
tflink adamw: yeah, this'll probably be better on list 16:01
kparal well, what's earlier? 16:01
rbergeron I would think that doing it either earlier on Friday or Monday /tues would be good - i think that we'd maybe want more buffer to actually fix things if they're broken, but... :) 16:01
jskladan tflink: 13:00 gmt, you say? :) 16:01
tflink kparal: same time as the QA meeting? 16:01
adamw the current time is probably the earliest you can expect me to be fully functional. though of course the difference between 'essentially still asleep' and 'fully functional' is minute in my case. 16:02
adamw #action adamw to start a list thread for further discussion of the blocker review meeting time topic 16:02
kparal I don't think it's viable, it's Friday 5PM for us 16:02
kparal blocker bug meetings make take several hours 16:02
adamw OK, next thing on the list... 16:03
kparal I don't say I can't attend from time to time. but we just lose people this way 16:03
j_dulaney May? 16:03
adamw "How can we analyze the blocker bug lists for useful data? Bruno "I think it would be useful to review the blocker bugs to see if we can spot any trends. Just looking at the component counts might be useful. even if we don't do anything more." 16:03
adamw so, this is one of bruno's ideas on the list which is interesting but pretty open-ended 16:03
adamw i thought we could kick it around a bit to see if we can generate any specific action items 16:03
j_dulaney See trends from release to release so that we know what to test more? 16:04
adamw brunowolff: is this something you were thinking of working on yourself? or just an idea you came up with in passing? 16:04
adamw j_dulaney: I guess. the bit inside the quote marks is the exact text bruno put on the retrospective page. 16:04
tflink something similar is on my list of stuff to look into if I have time 16:04
* tflink wanted to look into generating heat maps of bug urgency based on rate of bug change and sentiment analysis of comments 16:05
adamw zoiks. 16:05
adamw 'sentiment analysis' sounds like something you could be making much more money doing for facebook =) 16:06
tflink people already do it, AFAIK 16:06
j_dulaney tflink is using big words 16:06
adamw well, if bruno's not around and no-one else has any specific bright ideas for this one, we can table it and i can ask on list 16:06
adamw i'm not sure the straightforward component counts idea is terribly useful as i think we could all make a pretty good guess right here and now - 80% anaconda and most of the rest in the kernel, infrastructure like systemd/udev, or gnome 16:07
tflink it's probably be good to bounce some ideas around 16:07
tflink s/it's/it would/ 16:07
adamw ok 16:07
tflink adamw: it would be more interesting to look at timing and dependencies, I think 16:08
adamw #action adamw to start a list thread about ways to analyze the corpus of blocker bugs 16:08
adamw i can use fancy words too! 16:08
adamw ok, so let's round up quickly 16:08
adamw #topic AutoQA update 16:08
adamw tflink/kparal, what's the news? 16:08
* adamw brb, call of nature - do summarize and move on to open floor without me if necessary 16:09
kparal there is no update and won't be for a while I think 16:09
* tflink has nothing to report - have been working on other things 16:09
kparal I wouldn't make this a persistent meeting item 16:09
tflink that was quick :) 16:09
kparal #topic Open Floor 16:10
kparal so, what do you have? 16:10
* j_dulaney has 16:12
j_dulaney A Beefy Miracle 16:13
Cerlyn For ARM should we treat the different subarches like we treat x86 and x64? 16:13
jskladan 16:13
j_dulaney Cerlyn: Something like that 16:14
akshayvyas well i got one request,need mentor for proven tester :) 16:14
j_dulaney jskladan: Mine was better 16:14
kparal proven testers are now suspended 16:14
j_dulaney indeed 16:14
akshayvyas Kparal: so no mentors that means i can't test for fedora :-( 16:15
jskladan j_dulaney: but mine was true... 16:15
kparal you can test everything 16:15
tflink akshayvyas: not sure I follow you, there isn't really a purpose for proventesters right now 16:16
kparal we will help you, just ask on test list 16:16
j_dulaney akshayvyas: You don't need to be proven tester to file karma/bug reports 16:16
adamw akshayvyas: you can still test just fine, it's just that being a proven tester doesn't change anything at present 16:16
adamw akshayvyas: as long as you have a FAS account you can file feedback on updates, and you can still follow the proven tester instructions (they're good for all testers, really) 16:16
akshayvyas okay so you can test without joining anyyhing 16:16
akshayvyas anything 16:16
kparal sure 16:17
akshayvyas got ya :) thanks... 16:17
* jskladan goes home *wink wink* see you around, gang 16:18
adamw akshayvyas: you need a FAS account - - for your karma to count, aside from that, you're good. 16:18
adamw i didn't realize you lived in the pub =) 16:18
adamw anything else for open floor? 16:18
j_dulaney jskladan: Peace, brohipnal 16:18
akshayvyas adamw: i got FAS 16:18
adamw akshayvyas: then you're fine, just remember to log in before filing karma. 16:19
akshayvyas adamw: got ya thanks :) 16:19
adamw alrighty, looks like we're set, thanks for coming folks 16:20
* adamw sets the Quantum Fuse for a couple of minutes 16:20
j_dulaney Quantum Fuse? 16:20
j_dulaney Related to Flux Capacitors by any chance? 16:20
adamw it's the meeting fuse - you can never quite be sure exactly how long it is. 16:21
* kparal leaves 16:21
j_dulaney Ford Prefect probably knows 16:21
adamw #endmeeting 16:22

Generated by 2.10.0 by Marius Gedminas - find it at!