15:00:14 <adamw> #startmeeting fedora-qa
15:00:14 <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:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:20 <adamw> #meetingname fedora-qa
15:00:20 <zodbot> The meeting name has been set to 'fedora-qa'
15:00:22 <adamw> #topic Roll call
15:00:35 * tflink is here
15:00:39 * Cerlyn is here
15:00:51 * akshayvyas is here
15:00:58 <adamw> who be here for some swashbucklin'?
15:01:09 <adamw> darn, wait. that's my pirate swordfighting meeting. ALWAYS getting those mixed up.
15:01:37 * kparal arrives
15:01:47 * jskladan hides in shadows
15:01:55 * mkrizek is here
15:02:38 <adamw> mornin' folks
15:02:58 <adamw> if anyone wants to join the pirate swordfighting meeting instead, just mail the cheque to...
15:03:09 <brunowolff> I'll be here for about 25 minutes.
15:03:27 <adamw> alrighty, let's get going
15:03:36 <adamw> #topic Previous meeting follow-up
15:04:06 <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:35 <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:54 <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:05:13 <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:34 <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:06:15 <tflink> working on it - still hitting the occasional BZ proxy error but that's probably not a problem on my end
15:06:58 * pschindl is here (I was changing my laptop keyboard)
15:07:19 <adamw> i think i've seen one of two of those in interactive use
15:07:22 <adamw> so yeah, probably not you
15:07:23 <adamw> anyone else?
15:07:52 <tflink> the opinion in #fedora-admin is that it's due to load issues with bz
15:08:19 <adamw> ok
15:08:47 <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:09:01 <adamw> "tflink to set up QA git account" - we know that's done
15:09:21 <tflink> yep, done. I don't think there is much if anything in there but the repo does exist now :)
15:09:32 <adamw> kparal's scripts
15:10:29 <adamw> #info "tflink to set up QA git account" - this has been done, see https://fedorahosted.org/fedora-qa/browser/QA%20git
15:10:30 * j_dulaney waves
15:10:36 <adamw> hi dulaney
15:10:52 <j_dulaney> How do we get access to said git account?
15:11:28 <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:35 <adamw> er, i don't see that off the top of my head. kparal?
15:11:54 <j_dulaney> tflink:  That's what I meant
15:11:56 <kparal> #link http://git.fedorahosted.org/git/?p=fedora-qa.git
15:12:32 <adamw> ah, it's...oh, you beat me.
15:12:35 <brunowolff> Normally write access is controlled for fedorahosted stuff by being in a group.
15:12:52 <adamw> we still don't really have an active qa group in fas, but we could add one for git access i guess.
15:13:01 <j_dulaney> Hmm, reinstate the QA group?
15:13:12 <adamw> yeah, seems like a reasonable use for it if it comes up.
15:13:16 <kparal> https://admin.fedoraproject.org/accounts/group/view/gitfedora-qa
15:13:35 <adamw> oh right, one is automatically created
15:13:38 <brunowolff> Doesn't the group for access get created automatically (as part of the setup)?
15:13:43 <adamw> yeah.
15:13:44 <adamw> i forgot.
15:14:17 <tflink> you can apply for commit access through the gitfedora-qa FAS group
15:14:22 <tflink> https://admin.fedoraproject.org/accounts/group/view/gitfedora-qa
15:14:25 * j_dulaney just did
15:14:37 <adamw> alrighty, so that's covered.
15:15:08 <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:30 <adamw> #topic ARM as a primary arch
15:15:35 <adamw> #chair j_dulaney tflink kparal
15:15:35 <zodbot> Current chairs: adamw j_dulaney kparal tflink
15:15:46 <adamw> well, j_dulaney wanted this on the topic sheet, so here we go
15:15:51 <adamw> is there anything specific to discuss?
15:16:03 <j_dulaney> Well, at SELF, the topic came up
15:16:25 <j_dulaney> Specifically, QA's role
15:16:31 <j_dulaney> And I brought up hardware
15:16:58 <j_dulaney> It would seem that there is some budget that could be made available for hardware for us to test on
15:17:01 <adamw> i think we have quite a bit lying around at this point
15:17:06 <adamw> hands up who has ARM
15:17:18 * adamw has an XO 1.75 sitting on his desk and a trimslice in a box
15:17:19 * tflink has a 1st gen panda board
15:17:27 * j_dulaney has nothing, although a raspberry pi is supposed to be coming
15:17:37 * Cerlyn has several XO-1.75s
15:17:43 <adamw> kparal, anything over there?
15:18:07 <kparal> no ARM in Brno afaik
15:18:12 <tflink> I thought that most arm testing could be done with qemu
15:18:25 <kparal> I'd like to order some Raspberry once it is available again
15:18:40 <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:19:02 <j_dulaney> tflink;  the arm folks don't seem to like that
15:19:11 <Cerlyn> Fedora building cannot be done in qemu; I don't know if they plan to support qemu as a destination platform
15:19:36 <adamw> pandaboard, trimslice, highbank, beagleboard, kirkwood and Pi seems to be the crop.
15:19:42 <adamw> http://scotland.proximity.on.ca/arm-nightlies/
15:21:06 <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:23 <adamw> kirkwood is all those *plug systems - sheevaplug, dreamplug etc.
15:21:30 <j_dulaney> Like I said, I'm *supposed* to be getting a Pi
15:21:58 <tflink> yeah but it looks like most pi users are going to be using debian :-/
15:22:07 <j_dulaney> Okay, I'll ping nb to see about getting at least one example of each of the above
15:22:32 <tflink> doesn't mean that we can't run fedora on it, though :)
15:22:35 <j_dulaney> If we do get some hardware, how should it be distributed?
15:23:01 <adamw> good question. i mean, whoever goes to the work of getting it can obviously have some.
15:23:51 <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:24:40 <j_dulaney> As far as actual testing, most of the current test criteria should work for arm
15:25:13 <j_dulaney> I guess if arm goes primary, would we slip the whole release if arm is blocking?
15:25:41 <adamw> that's the idea, yeah.
15:25:49 <tflink> I think that would be a real possibility
15:26:02 <tflink> as always, it would depend on what the blocking issue is, I think
15:26:10 <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:18 <j_dulaney> That was the other question that came up during SELF
15:26:54 <j_dulaney> I guess the only question is if the blocker is specific to one arm hardware version?
15:27:15 <adamw> yeah, that could be a tricky situation.
15:27:19 <nb> j_dulaney, do we know where the hardware should go to?
15:27:33 <nb> j_dulaney, i will get with people to try to find budget somewhere
15:27:38 <tflink> I thought that they were in that situation now where there were kernel issues on the panda's omap
15:27:51 <nb> and what is highbank? I'm not finding anything obvious in google
15:27:53 <tflink> but to be honest, I haven't been following all that closely
15:28:05 <j_dulaney> nb:  We'll figure that out once we know we can get some h/w
15:28:30 <j_dulaney> tflink:  I think that is supposed to be fixed in 3.4
15:28:43 <j_dulaney> tflink:  I think the issue was with the 3.3 kernel
15:28:51 <j_dulaney> But, I could be mistaken
15:29:20 <adamw> nb: i didn't recognize that one either, the page just refers to it as highbank.
15:29:21 <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:47 <j_dulaney> Indeed
15:29:58 <j_dulaney> And that's the kind of thing we're going to have to hash out
15:30:06 <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:13 <adamw> that'd be my call anyhow.
15:30:23 * j_dulaney is on the fence about it
15:30:41 <j_dulaney> My preference would be to block in such situations
15:30:56 <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:31:04 * tflink thinks that the first release with ARM as primary is going to be interested :)
15:31:11 <tflink> interesting
15:31:13 <adamw> #info j_dulaney and nb believe there is budget available to get more hardware
15:31:13 <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:36 <adamw> sure, but we're experienced at ticking people off. =)
15:31:44 <j_dulaney> +1
15:31:50 <tflink> hopefully we won't have so many late issues if we're testing more
15:32:08 <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:15 <adamw> tflink: cos that works so well for x86 ;)
15:32:39 <tflink> adamw: exactly, we never have major test escapes
15:33:52 <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:52 <j_dulaney> adamw:  i almost wonder if that should be a FESCo or even board question?
15:34:17 <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:39 <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:57 <j_dulaney> adamw:  It wouldn't hurt to advance it to FESCo
15:35:07 <j_dulaney> adamw:  +1 on we would prefer to block
15:37:01 <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:10 <adamw> sure, that'd be a reasonable approach
15:37:45 <j_dulaney> If y'all want, I can file a ticket with FESCo
15:37:57 <j_dulaney> And we could all show up to that meeting
15:38:02 <adamw> probably not worth it as of yet, at least until arm is actually taken as a primary arch
15:38:06 <adamw> that hasn't happened yet afaik...
15:38: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:39:13 * j_dulaney is good
15:39:38 <adamw> okey dokey
15:39:40 <adamw> #topic Fedora 17 retrospective
15:40:09 <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:24 <adamw> so i wanted to run through those quickly
15:40:41 <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:48 <adamw> darn, i should've asked rbergeron along.
15:40:56 <adamw> rbergeron: ping, any chance you're here?
15:41:11 <rbergeron> there's a chance
15:41:20 <rbergeron> SMALL BUT THERE
15:41:28 <rbergeron> are we retrospectiving now? :)
15:41:33 <adamw> we are indeed
15:41:36 <rbergeron> epic
15:41:39 * rbergeron takes a seat
15:41:54 * j_dulaney notes that rbergeron as a Beefy Miracle was epic
15:42:11 <adamw> rbergeron: so do we have any definite plans for changing up the go/no-go and readiness meetings this cycle?
15:42:36 <rbergeron> not yet. Feedback on how we thought it went having go/no-go on thursday this time instead of wednesday?
15:42:36 <adamw> or should I try and kick start something?
15:42:51 <adamw> worked fine for me. we got an extra day. did anyone complain about it?
15:42:54 <rbergeron> (and final go/no-go has always been scheduled for tuesdays)
15:43:01 * nirik thinks thursday is fine and makes sense.
15:43:26 * j_dulaney liked Thursday
15:43:29 <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:57 <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:57 <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:44:49 <rbergeron> hrmmmm
15:44:51 * rbergeron thinks
15:45:15 <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:28 <tflink> adamw: I think that delay was for mirror propagation
15:45:49 <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:56 <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:46:22 <j_dulaney> Which makes sense
15:46:27 <nirik> it takes less time than it used to these days, but yes, there's still time needed to sync out.
15:46:29 <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:43 <rbergeron> For people to be getting the word that we're on (or that we're off).
15:48:04 <adamw> OK. it sounds like the general tenor is that the readiness->release lag is reasonable.
15:48:56 <adamw> so, on the other part of this question - for some reason we seem to schedule TC1s on tuesdays but RC1s on thursdays.
15:49:23 * j_dulaney reminds y'all that even the extra couple of days will wind up getting full up
15:49:25 <rbergeron> that could entirely be an artifact of my idiocy. Have we noticed if one works better than another? :)
15:49:47 <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:57 * j_dulaney thinks getting RCs out earlier = better
15:49:59 <rbergeron> adamw: yeah
15:50:11 <adamw> right, i was thinking something along the lines of simply saying that we roll the RC ASAP after change deadline'
15:50:26 <adamw> not sure how we can express that in the schedule, but it seems like the logical approach
15:51:00 <rbergeron> adamw: can you make a note of that in the meeting logs?
15:51:11 <rbergeron> I wonder if that's what dennis is doing anyway - i feel like it is
15:51:31 <adamw> well, we kinda schedule the RCs between us (qa and releng)
15:51:37 * 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:43 <adamw> but when we've rolled ahead of the date on the schedule people have brought it up
15:52:03 <adamw> does everyone agree with the goal of rolling RC ASAP after change deadline?
15:52:36 * j_dulaney is +1
15:52:47 <rbergeron> yes
15:53:12 <rbergeron> adamw: bad/evil TCs won't affect that in any way?
15:53:14 <tflink> yeah, that sounds good to me
15:53:20 <akshayvyas> yes
15:53:53 <adamw> rbergeron: er, evil TCs?
15:53:54 <rbergeron> ie; there's no threshhold of success to move from TC to RC
15:54:13 <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:30 <adamw> rbergeron: the requirements for an RC roll are a) freeze in place b) no blocker bugs
15:54:41 <adamw> the properties of the previous TC build do not in themselves matter at all
15:54:51 <rbergeron> okay, just making sure :)
15:54:54 <adamw> npnp
15:55:00 <adamw> okay, moving along quickly as we're taking up time...
15:55:10 <adamw> "Blocker bug meetings: should we move them from Fridays?"
15:55:32 <rbergeron> I feel like we've done a lot of ad-hoc blocker meetings.
15:55:37 <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:44 <adamw> rbergeron: this is about the regularly-scheduled ones.
15:56:00 <kparal> home or pub
15:56:04 <adamw> heh
15:56:05 <rbergeron> yes, but I feel like we're always doing ad-hoc because we're tinking "shit, friday is 4 days away"
15:56:20 <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:22 <rbergeron> do we get more bugs over weekends or during the week?
15:56:28 <adamw> off the top of my head i can't think of one
15:56:34 <tflink> rbergeron: I think we'd hit some of that no matter what day of the week we did it
15:56:44 <adamw> rbergeron: i don't think there's a definite trend, it mostly depends on when the candidates are built and stuff.
15:56:50 <j_dulaney> rberegeron:  I do most of my testing on weekend
15:56:53 <tflink> if it's only once per week, we'll be having some ad-hoc meetings
15:56:57 <j_dulaney> So, probably a mix
15:57:07 <j_dulaney> tflink:  +1
15:57:21 <adamw> right, i think the ad hoc meetings are inevitable
15:57:24 <j_dulaney> Fridays are the best days for me
15:57:41 <adamw> can anyone think of a schedule-related justification for any day in particular?
15:58:04 <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:06 <tflink> thursday to make it even throughout the week with the monday QA meetings?
15:58:06 <j_dulaney> Friday gives time after RC rolls
15:58:07 <akshayvyas> i think friday is good
15:58:28 <akshayvyas> or weekends
15:58:35 <tflink> on second thought, I like adam's reasoning for wednesday more
15:59:21 <j_dulaney> +1
15:59:30 <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:36 <adamw> akshayvyas: it'd be a lot of trouble persuading RH staff to show up on weekends, i can tell ya =)
15:59:54 <akshayvyas> adamw: agree
16:00:16 <akshayvyas> well then i say wednesday or friday
16:00:20 <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:34 <adamw> it sounds like we don't have a clear consensus here; discuss further on the list?
16:00:48 <jskladan> ^^ +1
16:00:52 <tflink> kparal: would doing it earlier in the day on Friday work?
16:01:05 <tflink> adamw: yeah, this'll probably be better on list
16:01:09 <kparal> well, what's earlier?
16:01:26 <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:43 <jskladan> tflink: 13:00 gmt, you say? :)
16:01:45 <tflink> kparal: same time as the QA meeting?
16:02:09 <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:24 <adamw> #action adamw to start a list thread for further discussion of the blocker review meeting time topic
16:02:43 <kparal> I don't think it's viable, it's Friday 5PM for us
16:02:51 <kparal> blocker bug meetings make take several hours
16:03:13 <adamw> OK, next thing on the list...
16:03:14 <kparal> I don't say I can't attend from time to time. but we just lose people this way
16:03:16 <j_dulaney> May?
16:03:20 <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:42 <adamw> so, this is one of bruno's ideas on the list which is interesting but pretty open-ended
16:03:50 <adamw> i thought we could kick it around a bit to see if we can generate any specific action items
16:04:08 <j_dulaney> See trends from release to release so that we know what to test more?
16:04:09 <adamw> brunowolff: is this something you were thinking of working on yourself? or just an idea you came up with in passing?
16:04:24 <adamw> j_dulaney: I guess. the bit inside the quote marks is the exact text bruno put on the retrospective page.
16:04:24 <tflink> something similar is on my list of stuff to look into if I have time
16:05:17 * tflink wanted to look into generating heat maps of bug urgency based on rate of bug change and sentiment analysis of comments
16:05:48 <adamw> zoiks.
16:06:08 <adamw> 'sentiment analysis' sounds like something you could be making much more money doing for facebook =)
16:06:26 <tflink> people already do it, AFAIK
16:06:31 <j_dulaney> tflink is using big words
16:06:43 <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:07:21 <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:25 <tflink> it's probably be good to bounce some ideas around
16:07:48 <tflink> s/it's/it would/
16:07:55 <adamw> ok
16:08:07 <tflink> adamw: it would be more interesting to look at timing and dependencies, I think
16:08:10 <adamw> #action adamw to start a list thread about ways to analyze the corpus of blocker bugs
16:08:15 <adamw> i can use fancy words too!
16:08:43 <adamw> ok, so let's round up quickly
16:08:46 <adamw> #topic AutoQA update
16:08:51 <adamw> tflink/kparal, what's the news?
16:09:03 * adamw brb, call of nature - do summarize and move on to open floor without me if necessary
16:09:23 <kparal> there is no update and won't be for a while I think
16:09:27 * tflink has nothing to report - have been working on other things
16:09:41 <kparal> I wouldn't make this a persistent meeting item
16:09:41 <tflink> that was quick :)
16:10:00 <kparal> #topic Open Floor
16:10:07 <kparal> so, what do you have?
16:12:57 * j_dulaney has https://lh4.googleusercontent.com/-1Nhl9RzDQfA/T99TV9i152I/AAAAAAAAA0g/jBA_Gzb5mjc/s800/GEDC0340.JPG
16:13:05 <j_dulaney> A Beefy Miracle
16:13:22 <Cerlyn> For ARM should we treat the different subarches like we treat x86 and x64?
16:13:27 <jskladan> http://4.bp.blogspot.com/_2u-weN31BFs/SJ8EEVM5sBI/AAAAAAAAAkc/87BYNgPz7BU/s400/hold-a-meeting.jpg
16:14:09 <j_dulaney> Cerlyn:  Something like that
16:14:15 <akshayvyas> well i got one request,need mentor for proven tester :)
16:14:20 <j_dulaney> jskladan:  Mine was better
16:14:45 <kparal> proven testers are now suspended
16:14:51 <j_dulaney> indeed
16:15:37 <akshayvyas> Kparal: so no mentors that means i can't test for fedora :-(
16:15:45 <jskladan> j_dulaney: but mine was true...
16:15:52 <kparal> you can test everything
16:16:10 <tflink> akshayvyas: not sure I follow you, there isn't really a purpose for proventesters right now
16:16:11 <kparal> we will help you, just ask on test list
16:16:20 <j_dulaney> akshayvyas:  You don't need to be proven tester to file karma/bug reports
16:16:21 <adamw> akshayvyas: you can still test just fine, it's just that being a proven tester doesn't change anything at present
16:16:46 <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:50 <akshayvyas> okay so you can test without joining anyyhing
16:16:56 <akshayvyas> anything
16:17:04 <kparal> sure
16:17:47 <akshayvyas> got ya :) thanks...
16:18:06 * jskladan goes home *wink wink* see you around, gang
16:18:06 <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:16 <adamw> i didn't realize you lived in the pub =)
16:18:32 <adamw> anything else for open floor?
16:18:38 <j_dulaney> jskladan:  Peace, brohipnal
16:18:46 <akshayvyas> adamw: i got FAS
16:19:13 <adamw> akshayvyas: then you're fine, just remember to log in before filing karma.
16:19:36 <akshayvyas> adamw: got ya thanks :)
16:20:15 <adamw> alrighty, looks like we're set, thanks for coming folks
16:20:34 * adamw sets the Quantum Fuse for a couple of minutes
16:20:45 <j_dulaney> Quantum Fuse?
16:20:57 <j_dulaney> Related to Flux Capacitors by any chance?
16:21:16 <adamw> it's the meeting fuse - you can never quite be sure exactly how long it is.
16:21:43 * kparal leaves
16:21:51 <j_dulaney> Ford Prefect probably knows
16:22:20 <adamw> #endmeeting