QA/Meetings/20120618

Attendees

• 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)

Agenda

• 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

IRC Log

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 http://wiki.debian.org/MeetBot.	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 https://fedorahosted.org/fedora-qa/browser/QA%20git	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 http://git.fedorahosted.org/git/?p=fedora-qa.git	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	https://admin.fedoraproject.org/accounts/group/view/gitfedora-qa	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	https://admin.fedoraproject.org/accounts/group/view/gitfedora-qa	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	http://scotland.proximity.on.ca/arm-nightlies/	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 - https://fedoraproject.org/wiki/Fedora_17_QA_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 https://lh4.googleusercontent.com/-1Nhl9RzDQfA/T99TV9i152I/AAAAAAAAA0g/jBA_Gzb5mjc/s800/GEDC0340.JPG		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	http://4.bp.blogspot.com/_2u-weN31BFs/SJ8EEVM5sBI/AAAAAAAAAkc/87BYNgPz7BU/s400/hold-a-meeting.jpg	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 - https://admin.fedoraproject.org/accounts/ - 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 irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!