16:01:27 <adamw> #startmeeting Fedora QA meeting
16:01:27 <zodbot> Meeting started Mon Feb 25 16:01:27 2013 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:31 <adamw> #meetingname fedora-qa
16:01:31 <zodbot> The meeting name has been set to 'fedora-qa'
16:01:35 <adamw> #topic roll call
16:01:43 * adamw is here, also an idiot.
16:01:46 * tflink is here ... in both channels :)
16:01:49 * satellit_e listening
16:01:50 * mkrizek is here
16:02:06 * j_dulaney sends more fail to adamw
16:02:34 * Martix smells dead shark
16:02:39 <Martix> meat
16:02:50 <nb> hi
16:03:23 * jreznik is around, idiot as always :)
16:03:48 * adamw is also on a bus to whistler and phoning this one in
16:03:50 <adamw> alrighty!
16:03:50 * pschindl is here
16:04:51 <adamw> #topic Previous meeting follow-up
16:05:10 <adamw> note on this one - we may want to go a little more in depth on each of these, as they're kinda topics in their own right
16:05:38 <adamw> "adamw to write a second draft (of the automatic blocker proposal) with andre's proposed changes and stronger explanation not to put 'grey area' bugs in the automatic blocker list"
16:05:49 <adamw> so I did that, and sent it to the list; not much further feedback, does that mean everyone's OK with it?
16:06:02 <tflink> yeah
16:06:12 <adamw> https://lists.fedoraproject.org/pipermail/test/2013-February/113909.html
16:07:07 <adamw> cos if no-one yells, I'm gonna go ahead and put it live
16:07:12 <robatino> i was wondering if the boot criteria is hardware-specific and if that will cause problems
16:07:42 <robatino> since it may fail to boot only on some platforms
16:08:17 * j_dulaney is +1
16:08:21 * Viking-Ice joins in
16:08:46 <adamw> robatino: i tried to word it quite specifically
16:09:03 <Viking-Ice> ship igt
16:09:15 <Viking-Ice> mean ship it
16:09:15 <Viking-Ice> ;)
16:09:17 <adamw> robatino: 'conditional failure is not an automatic blocker' basically means 'if it boots for anyone, it's not an automatic blocker'
16:09:27 <adamw> i could try and make that wording less legalistic :)
16:09:53 <robatino> ok, but if it fails to boot for one person they'll have to check with others before making it an automatic blocker
16:10:11 <robatino> which seems to make it similar to the situation with regular blockers
16:10:15 <j_dulaney> Comment to that affect?
16:10:22 <adamw> robatino: we can see how it shakes out in practice; what i'm thinking is that, usually, we get a pretty good handle on the actual cause of major bugs quite quickly
16:10:35 <Viking-Ice> yup
16:10:46 <tflink> yeah, that sounds like a plan to me
16:10:49 <adamw> it should be pretty clear if we know the actual cause of a bug whether it's a 'total DOA' or not
16:10:59 <adamw> you know, if the cause is 'we left vmlinuz off the image', then...:)
16:11:36 <adamw> #info "adamw to write a second draft (of the automatic blocker proposal) with andre's proposed changes and stronger explanation not to put 'grey area' bugs in the automatic blocker list" - this was done: https://lists.fedoraproject.org/pipermail/test/2013-February/113909.html
16:11:48 <adamw> #agreed second draft is ready to go
16:11:57 <adamw> #action adamw to push 'automatic blocker' proposal to production
16:12:01 <adamw> okay, on to:
16:12:11 <adamw> "adamw to draft up changes to the blocker bug meeting SOP for 3-hour hard limit, no-reviews-during-qa-meetings, and a dedicated channel for meetings, send to list for further discussion"
16:12:31 <adamw> I also did that: https://lists.fedoraproject.org/pipermail/test/2013-February/113910.html
16:12:52 <adamw> only really got one reply so far, from jaro: I was expecting more discussion
16:13:50 * j_dulaney votes to put it into effect
16:14:08 * tflink should have replied on-list but is +1 on the changes
16:14:53 <adamw> i'd feel more confident with a bit more list feedback, but hey
16:15:38 <Viking-Ice> sorry I've been to busy here in brno to catchup in what's been happening on all the mailing list but then again I'm kinda obvious +1 to those changes ;)
16:15:39 <tflink> I think that the only changes we haven't already been doing is the channel for meetings and the no-blocker-stuff-during-qa-meetings
16:16:00 * nirik thinks all those make sense.
16:16:10 <jreznik> adamw: consider it as my +1, I don't really see a need for further discussion
16:16:12 <tflink> but we can wait another week for comments, it's not like we have a blocker meeting this week
16:16:16 <jreznik> and we can always revisit...
16:16:22 <adamw> tflink: true
16:16:38 <adamw> #info "adamw to draft up changes to the blocker bug meeting SOP for 3-hour hard limit, no-reviews-during-qa-meetings, and a dedicated channel for meetings, send to list for further discussion" - this was also done, https://lists.fedoraproject.org/pipermail/test/2013-February/113910.html
16:17:01 <adamw> #info j_dulaney, tflink, viking-ice, jreznik all vote +1 on blocker process changes
16:17:15 <adamw> #action adamw to try and gather a bit more feedback on blocker process changes this week
16:17:35 <adamw> "viking-ice to discuss the 'smoke test for spins' idea further with nirik and cwickert" - viking, nirik, did you guys get anywhere with this?
16:18:21 <nirik> nope.
16:18:27 <adamw> concise!
16:18:43 <adamw> maybe we should have a trac ticket so we don't lose the idea, or something
16:19:07 <Viking-Ice> Well I actually met with cwickert here in brno but this topic eluded our discussion
16:19:21 <Viking-Ice> yeah we should add it the trac so it wont get lost
16:19:54 <adamw> #action viking-ice or adamw to file a trac ticket for the smoke-test-for-spins idea
16:20:03 <adamw> an action item to file a trac ticket...mmm, I can smell the bureaucracy
16:20:16 <adamw> #topic Call for Test Days
16:20:41 <adamw> so, many thanks to martix for taking charge of test days for this cycle
16:21:00 <adamw> #chair tflink viking-ice
16:21:00 <zodbot> Current chairs: adamw tflink viking-ice
16:21:03 <adamw> (forgot)
16:21:08 <Martix> your welcome :-)
16:21:22 <adamw> martix sent out the call for test days: https://lists.fedoraproject.org/pipermail/test/2013-February/113900.html
16:21:35 <adamw> we have quite a few submitted and planned already, it looks like, but did anyone have any ideas lying around to add to the list?
16:22:05 <Martix> I just went through proposals and trying to fit them in schedule right now
16:22:25 <adamw> #info martix is working proposals into the schedule at present
16:22:28 <tflink> upgrade might be interesting - a bit difficult to do with timing, though
16:23:13 <adamw> #info tflink suggests an upgrade test day, but notes issues with timing
16:23:29 <adamw> we could see if will has a timetable for fedup changes for f19 and try to co-ordinate
16:23:39 <Martix> 4/04 Printing
16:23:40 <Martix> 4/11 l10n
16:23:42 <Martix> 5/02 i18n
16:23:42 <adamw> the package set is usually stable enough for testing upgrades at least by beta
16:23:43 <Martix> 5/23 FreeIPA
16:23:45 <Martix> 5/30 Virtualization
16:23:46 <Martix> 6/06 SSSDImproveADIntegration
16:24:03 <j_dulaney> In theory
16:24:05 <Martix> that list of new proposals
16:24:10 <Martix> *thats
16:24:11 <tflink> adamw: true, the only variable then becomes which repos are being used
16:24:23 <adamw> we can fiddle with that for a test day
16:24:30 <adamw> sort of thing a test day lets you do, in fact
16:24:39 <adamw> any other ideas?
16:24:55 <Viking-Ice> I'm still of the notion we should get rid of that schedule
16:25:03 <j_dulaney> Is networking on the list
16:25:04 <j_dulaney> ?
16:25:11 <adamw> j_dulaney: i believe it's already arranged
16:25:16 <j_dulaney> Okay
16:25:16 <adamw> Viking-Ice: how do you mean?
16:26:05 <Viking-Ice> adamw, instead of fixed schedule with explicit dates available we simply note down the time people want to host test day
16:27:00 <adamw> Viking-Ice: personally i still kinda like the idea of going mainly with thursdays just to help people fit it in to their schedules
16:27:01 <Martix> j_dulaney: I can extend "Network Manager Test Day" to "Networking Test Week"
16:27:18 <adamw> Martix: only if the networking folks feel it's needed,
16:27:42 <Martix> adamw: right, if they will come with this
16:28:31 <j_dulaney> Martix:  It shouldn't be necessary
16:29:02 <Viking-Ice> adamw, the down side of that is that people look at a schedule and see the "thursday" they are free is occupied by some other component
16:29:04 <j_dulaney> The biggest thing I can think of off the top of my head with NM is the arrival (finally!) of a cli
16:29:13 <adamw> Viking-Ice: yeah, it's a cost/benefit thing indeed
16:29:41 <Viking-Ice> adamw, hence the schedule is a bad thing and hosting it only on thursday is even worse
16:29:45 <adamw> Viking-Ice: we should probably make that a separate topic for another meeting though, still two to get through here
16:29:46 <Viking-Ice> from my pov
16:29:48 <Martix> j_dulaney: nmcli testing is alredy planned for NM Test Day
16:30:22 <j_dulaney> Indeed
16:30:41 <adamw> welp, seems like that's all the ideas...
16:30:59 <adamw> as a heads-up, i may pop off for a few minutes in 5 mins or so, switching internet connections. anyhow
16:31:14 <adamw> #topic Trac tickets CCed to list
16:31:46 <adamw> so there's been some discussion lately about how it may not be good to have lots of development-related tickets CCed to test@
16:32:02 <adamw> this is happening because we're using the QA trac instance for tool development
16:32:24 <adamw> i'm packaging a trac plugin which would allow us to direct the mails for different components to different places, which is one way of addressing the problem
16:32:39 * nirik can build the epel version and get it installed later today
16:32:40 <j_dulaney> Maybe have a qa-devel list?
16:32:45 <adamw> another suggestion is to set up another trac instance for tooling, or turn the autoqa trac instance into a more general qa-dev one
16:32:57 <adamw> nirik: i did a build, didn't submit an update though
16:32:58 <Viking-Ice> <shrug> plugs +1 to separate qa-devel trac instance for qa related development work
16:33:02 <Martix> my apologize, I just closed bunch of previous Test Day tickets :-)
16:33:18 <j_dulaney> No, that's not devel
16:33:24 <adamw> i think either approach would work, i don't really mind which - i figure tflink and martix and kparal maybe get the biggest say in what fix to pick, as they're the ones doing most of that work
16:33:28 <j_dulaney> Martix:  That happens
16:33:33 <adamw> Martix: that's fine, those tickets are appropriate for the list
16:33:34 <Viking-Ice> fedora-qa was never supposed to be used for anything else but request from the community
16:33:51 * tflink doesn't care a whole lot either way about where the tickets live
16:33:54 <adamw> #info viking-ice says the qa trac was originally intended solely as a 'qa task management' thing, not for devel
16:34:12 <nirik> which doesn't mean it can't be used for other things now.
16:34:14 <Viking-Ice> yes an request tracker not bug tracker
16:34:16 <nirik> anyhow, whatever works.
16:34:18 <adamw> i don't really see a huge difference between the two approaches in the end, they'd achieve the goal, and either is pretty easy to do.
16:34:32 <tflink> but I'm +1 to at least discussing a qa-devel@ list - it's been on my list of things to propose
16:35:01 <adamw> #info tflink is provisionally +1 to at least a separate mailing list for qa-devel
16:35:37 * j_dulaney is also +1
16:35:38 <Viking-Ice> +1 to seperated mailing list and a trac instance
16:35:57 <adamw> i can see that a line between 'community tasks' and 'tool development' is a reasonable line to draw between two separate tracs, and it's not like trac instances cost money, so maybe we can just go with that
16:36:10 <tflink> if we move the blocker tracking app's tickets, I'd rather move to a separate instance instead of to autoqa trac, though - more granularity in ticket assignment
16:36:13 <adamw> nirik: is there a process you can point to for setting up a new trac instnace? just file a ticket with releng?
16:36:24 <adamw> er, admin
16:36:26 <nirik> adamw: file a ticket with infras
16:36:27 <tflink> yeah, the biggest cost would be my time in configuring stuff and moving tickets
16:36:35 * j_dulaney can do that
16:37:00 <nirik> a new trac will cost eleventy million dollars! (well, ok, not really, just file a ticket. ;)
16:37:03 <adamw> tflink: best do it early when there isn't a lot of work to do then i guess
16:37:12 <Viking-Ice> tflink, well arent you the one that's causing this mess in the first place with all your development ;)
16:37:13 <adamw> #info to get a new trac instance we just file a ticket with websites
16:37:22 <adamw> tflink: yes, damnit, stop making awesome tools ;)
16:37:24 <tflink> j_dulaney: if you're talking about the ticket moving and configuration, I'd rather have myself or mkrizek do that since we'll be the ones using it most for now
16:37:35 <j_dulaney> No, I meant file the ticket
16:37:43 <j_dulaney> And sit on nirik to do it :)
16:37:49 <adamw> whoops, i've gotta drop out briefly, back in ~5
16:37:50 <tflink> Viking-Ice: I suppose that's one way to think of it :-P
16:37:53 <adamw> tflink and viking can drive
16:38:08 <tflink> less tool work means more time for other tasks :-D
16:38:40 <tflink> anywho, I'm fine with whichever approach as long as we decide sooner than later
16:39:10 <tflink> trac is trac for the most part - migrating will mess up a few minor things relating to ticket numbers but these are small issues
16:39:37 <Viking-Ice> Well I'm +1 to seperated mailing list and a trac instance
16:39:41 <nirik> you could try the cc thing and if it doesn't work do a new one?
16:39:48 * nirik doesn't have a horse in the race
16:40:47 <tflink> nirik: did agilo ever get back into fedorahosted or is there still a conflict with another plugin?
16:40:51 <Viking-Ice> So I propose that we create qa-devel mailing list and qa-devel trac instance
16:40:58 <nirik> tflink: it conflicts. ;(
16:41:23 <tflink> Viking-Ice: if we do that, I'd like to combine that mailing list with autoqa-devel
16:41:54 <tflink> but I also want to send that proposal out to the list (autoqa-devel@) before actually doing it
16:42:00 <Viking-Ice> tflink, what does the autoqa people think about that ?
16:42:15 <Viking-Ice> same thoughts
16:42:30 <Viking-Ice> so we should postpone until feedback from them?
16:42:45 <tflink> there have been some small discussions around it - the conclusion was mostly "let's see how many other things qa-devel related have much discussion"
16:42:50 <j_dulaney> Combine auto-qa list and qa-devel list, but keep seperate tracs for the two
16:43:11 <tflink> yeah, I'm strongly -1 on moving the blocker tracker app tickets to the autoqa trac
16:44:28 <Viking-Ice> these project are hosted on fedorahosted right
16:44:40 <tflink> either way, it might be better to float a proposal on test@ before making changes
16:44:45 <Viking-Ice> and there they do have their own bug trac right so why not use those then?
16:44:58 <tflink> Viking-Ice: depends on what's requested
16:45:12 <tflink> you don't have to request 1:1 trac:repo/project
16:45:41 * adamw back
16:45:42 <Viking-Ice> tflink, I see well perhaps that's the problem then
16:45:50 <tflink> Viking-Ice: how so?
16:45:57 <adamw> tflink: do you want to take an action item to look into the options and make a proposal on what new stuff to create?
16:46:17 <Viking-Ice> tflink, missing trac instance for those projects
16:46:23 <Viking-Ice> like upstream bugzillas
16:46:35 <tflink> eh, I specifically didn't request one
16:46:56 * tflink is not thrilled about another trac instance to admin
16:47:08 <adamw> yeah, i think one trac for all qa tools might be the best option
16:47:14 <adamw> trac is kind of a pita to admin
16:47:25 <tflink> adamw: if we were talking about another bug tracker, maybe
16:47:34 <tflink> trac isn't really set up to do multiple projects well, IMHO
16:47:42 <adamw> okay
16:47:44 * j_dulaney just thought he saw abadger1999 out of the corner of his eye, but it was someone that looked remarkably like him
16:47:54 <abadger1999> heh
16:48:17 <adamw> i think we're at the point where it'd be best for someone to go look at the issue and come up with a broader proposal...i think all the stuff to consider has been raised
16:48:24 <adamw> okay if i give that to you tflink?
16:48:25 <tflink> yeah, I can do that
16:48:50 <adamw> #action tflink to take a look at the question of tracking qa tool discussion and bugs/tickets and make a broad proposal about what to do
16:49:06 <adamw> we can discuss tflink's proposal next week (or when it gets done)
16:49:10 <adamw> that'll give us more detail to chew on
16:49:30 <adamw> #agreed everyone agrees in general that having the bugs in QA trac and the discussion spammed to test@ is a bad idea
16:49:46 <adamw> #topic  Open floor
16:49:50 <adamw> so, anything for open floor, folks?
16:50:23 <Viking-Ice> audio in desktop criteria
16:50:37 <Martix> updated https://fedoraproject.org/wiki/QA/Fedora_19_test_days with new proposals
16:51:52 <Viking-Ice> so how do people feel that we add audio to the desktop criteria you know press play and actually get sound of speaker ?
16:52:11 <adamw> i think we already have that
16:52:26 <tflink> it's in the test cases, not 100% sure about criteria
16:52:44 <adamw> Beta #19
16:52:45 <adamw> " In most cases, the installed system must be able to play back sound with gstreamer-based applications (see Blocker_Bug_FAQ) "
16:52:52 <adamw> if anything i think Beta is a bit early, but it's in there.
16:53:06 <Viking-Ice> alriiighhhty then ;)
16:53:06 <tflink> nvm, then
16:53:24 <adamw> 'gstreamer-based applications' is a bit desktop team-specific - that's one of the ones that came straight from desktop team back at FUDCon Whatever and never got 'abstracted'
16:53:37 <adamw> i can improve that as part of the criteria revision stuff. which i'm still working on.
16:53:38 <Viking-Ice> I just got asked here in BRNO about that but was unsure if we actual had that
16:53:45 <adamw> well, there ya go :)
16:54:04 <tflink> aren't most audio things using gstreamer, anyways?
16:54:36 <tflink> I didn't think that was gnome-specific
16:54:49 <adamw> tflink: oh, right, i think KDE defaults to gstreamer backend these days too
16:55:03 <adamw> they have an abstraction layer on top of gstreamer because, you know, yo dawg i heard you liked audio abstraction
16:55:15 <tflink> it's maintained outside of the gnome project, anyways
16:56:17 <Viking-Ice> yup anything else anyone?
16:56:42 * adamw sets fuse for 9am
16:56:44 <adamw> i have snow to abuse
16:57:19 * j_dulaney thinks anyone that actually *likes* snow is clinicaly insane
16:57:43 <adamw> i certainly am clinically insane, but i don't think the diagnosis was made on the basis of fondness for snow ;)
16:57:48 <tflink> j_dulaney: tell that to the huge ski/snowboard industry :)
16:57:57 <tflink> or ice fisherman
16:58:00 <misc> adamw: not only on that
16:58:13 <adamw> misc: they let me out of the institution on weekends!
16:59:12 <misc> adamw: that's not because everyone is crazy there that you should your employer "the institution"
16:59:18 * j_dulaney would much rather it be 100 F
16:59:28 <adamw> misc: haha.
16:59:37 <tflink> j_dulaney: and you call me crazy ...
16:59:37 <adamw> Red Hat: Keeping Crazy Engineers Off The Streets Since 1998
16:59:57 <adamw> alrighty, thanks for coming everyone
17:00:00 <adamw> same time next week
17:00:03 <adamw> #endmeeting