16:02:26 <jlaska> #startmeeting
16:02:34 <f13> jlaska: you're doing it wrong
16:02:43 <jlaska> story of my life Jesse
16:02:44 <f13> jlaska: your #startmeeting command needs the subject as an argument
16:02:46 <jlaska> it doesn't matter
16:02:49 <adamw> as the vicar said to the nun
16:02:57 <f13> otherwise the /topic will look all weird
16:03:03 <jlaska> #meetingtopic Fedora QA meeting
16:03:06 <Viking-Ice> not the nun said to vicar
16:03:07 <jlaska> #topic Gathering people
16:03:13 <f13> ah, guess that will work too
16:03:15 <jlaska> okie dokie ... sorry for the noise
16:03:21 * f13 
16:03:57 <jlaska> okay, so far I've got adamw, f13, poelcat, Viking-Ice, $me
16:04:22 <jlaska> I should say we have .5 Viking-Ice
16:04:34 * sdziallas waves to jlaska for sugar related stuff (ping me if needed)
16:04:49 <jlaska> sdziallas: welcome!  I've added your open discussion topic
16:05:02 <sdziallas> jlaska: awesome, thanks! :)
16:06:07 <jlaska> I suspect we have wwoods lurking ... and I don't see dpravec just yet ... hopefully he can join later
16:06:34 <jlaska> #topic Previous meeting follow-up
16:06:51 <jlaska> I feel like there was more to capture from last week ... but my notes scrubbing only has 2 items
16:06:59 <jlaska> so feel free to chyme in with any updates
16:07:15 * jlaska working off of proposed agenda - https://www.redhat.com/archives/fedora-test-list/2009-July/msg00438.html
16:07:33 <jlaska> a few quick ones ...
16:07:34 <jlaska> # [jlaska] - Notify team list (fedora-test-list) to solicit volunteers for help with Debugging pages
16:08:00 <jlaska> posted something in my blog about this last week ... inviting contributions
16:08:07 <jlaska> http://jlaska.livejournal.com/5693.html
16:08:34 <adamw> what might be a bit tricky about this is finding out what the necessary info _is_ in the cases where we want debugging pages
16:08:44 <jlaska> adamw: yeah, I was wondering if a template might help?
16:08:47 <adamw> i was looking at writing one or two yesterday, but i don't actually know what the required info is, for the three desired pages
16:08:56 <adamw> no, that's not the problem, laying out the page is easy
16:09:06 <adamw> the question is what actual information is needed for, say, a bug in rpm
16:09:22 <Viking-Ice> That's not the test list :) and no pr0n on your blog to attract crowd...
16:09:34 <adamw> we probably need to co-ordinate with maintainers on that, unless we have someone who knows
16:09:48 <adamw> Viking-Ice: what, you haven't been following jlaska's adult entertainment career?
16:09:56 <jlaska> adamw: we're not going there :)
16:09:58 <adamw> Real Men Do It In Red Hats is a modern classic
16:10:04 <jlaska> LOL!
16:10:15 <adamw> yay, i scared him off =)
16:10:19 <f13> adamw: when you picture that with the Red Hat Society, that's very very wrong
16:10:25 * jlaska purges
16:10:37 <adamw> hehe
16:10:38 <jlaska> adamw: do you have any thoughts on connecting with maintainers ...
16:10:46 <adamw> send 'em an email? :)
16:10:51 <jlaska> is that something to add as guidlines for 'how to get started' kind of deal?
16:10:54 <jlaska> yeah
16:11:57 <jlaska> to me, it seems like a good activity awaiting contributors who already have skills in a particular area
16:12:11 <jlaska> but you are right ... the point of hte exercise is to make processing bugs easier for maintainers
16:12:40 <jlaska> I've had no takers on the volunteer offer yet ... but will certainly point folks in the right direction :)
16:12:52 <jlaska> okay next up ... (another quickie)
16:12:53 <jlaska> # [jlaska] - Create a QA:Meeting matrix similar to [[Bugzappers_meeting_matrix]] to determine best fit for meeting slots
16:13:00 <jlaska> done ... See https://fedoraproject.org/wiki/QA_Meeting_Matrix
16:13:09 <jlaska> and thanks folks for adding your availability to the matrix
16:13:21 <Viking-Ice> as said before existing maintainers can be pinged to provide this info and new components and their maintainers being introduced into fedora should provide this info
16:13:36 <adamw> if this ever comes up again, btw, i came across an awesome system someone on the docs team used
16:13:42 <jlaska> Viking-Ice: right on ... I agree
16:13:58 <adamw> http://whenisgood.net
16:14:18 <jlaska> cute!
16:14:20 <adamw> it sets up the matrix for you, and automatically gives everyone who uses it their local time
16:14:34 <jlaska> seems to support more TZ's than timeanddate.com
16:14:50 <f13> I think the best way to do it is to invite the maintainer/developer to do an interview style session, where we get them to just brain dump about things and then we pour over it later to get it into the wiki pages.
16:14:53 <Viking-Ice> honestly not seeing how this solves anything
16:15:00 <f13> asking them to fill in the wiki pages will not be as successful.
16:15:07 <f13> oh sorry, new topic.
16:15:32 <jlaska> f13: that's not a bad idea tbh
16:15:56 <jlaska> I was thinking about it as an activity that any QA contributors could engage in if looking to "get involved"
16:16:34 <jlaska> hopefully that's not wishful thinking, I like having some things out there that are worthwhile and don't require a huge investment
16:17:30 <jlaska> #idea Host developer/maintainer interviews to identify what information is required for good bug reports
16:17:41 <jlaska> okay ... any other items from last weeks follow-up that weren't covered yet?
16:18:27 <jlaska> okay ... let's dive in ...
16:18:34 <jlaska> #topic QA Meeting time change
16:18:56 <Viking-Ice> Monday's at 16:00 UTC
16:18:59 <jlaska> thanks to everyone who updated availability in https://fedoraproject.org/wiki/QA_Meeting_Matrix
16:19:14 <jlaska> the top candidates seem to be what Viking-Ice noted ... and
16:19:24 <jlaska> * Mon 16:00 UTC (12 PM EDT)
16:19:34 <jlaska> * Thu 15:00 UTC (11 AM EDT)
16:19:44 <jlaska> * Fri 15:00 UTC (11 AM EDT)
16:20:02 <f13> I'd prefer the first
16:20:25 <f13> the first will cut into my cycling time for part of the year, the others will cut into my sleep time
16:20:41 <adamw> yeah, i like the first, but i can live with any of them
16:20:59 <jlaska> I was secretly hoping to get out of hte 16:00 UTC hour
16:21:09 <jlaska> but can do all of the above
16:21:35 <Viking-Ice> I prefer monday's as well + https://fedoraproject.org/wiki/Meeting_channel either has been changed or we did mistakes there's nothing schedualed at 17:00 which allows for extended of the meetings since we have been slipping over our meeting time from time to time..
16:22:04 <adamw> good point, a spare hour after the meeting is always nice
16:22:11 * jlaska shudders at the thought
16:22:43 <jlaska> alrighty ...
16:22:48 <jlaska> #agreed the new meeting time will be on Monday at 16:00 UTC (12 PM EDT)
16:23:01 <jlaska> next topic ...
16:23:14 <jlaska> just some brief news updates
16:23:17 <jlaska> #topic Alpha blocker bug day#2
16:23:30 <jlaska> I believe we are scheduled for another blocker bug day this Friday
16:23:37 * poelcat notes change of time to 11 AM EDT
16:23:49 <poelcat> to avoid clash w/ fesco meeting
16:23:55 <jlaska> ah good stuff
16:23:58 <f13> ah
16:24:07 <f13> let me update my phone
16:24:10 * nirik asks someone to update the meeting channel page for the new meeting time.
16:24:10 <jlaska> would anyone like to volunteer sending ou the announcement?
16:24:37 <jlaska> Viking-Ice: do you mind updating the meeting channel wiki page?
16:24:42 <poelcat> nirik: it meets on #fedora-bugzappers... does that still apply?
16:24:46 <Viking-Ice> sure
16:24:54 <nirik> poelcat: no, I meant the qa meeting time... ;)
16:24:54 <jlaska> Viking-Ice: thanks!
16:25:56 <jlaska> we've got a few prep tasks for the blocker bug day ...
16:25:58 <jlaska> * send out announcements
16:26:02 <jlaska> * take notes and send summary
16:26:03 <jlaska> 
16:26:09 <jlaska> anyone interested in either?
16:26:23 <jlaska> btw ... thanks to adamw for providing a summary from last week (https://www.redhat.com/archives/fedora-test-list/2009-July/msg00347.html)
16:26:38 <f13> sorry I can't take on any of that :/
16:26:44 <adamw> I can do them if necessary
16:26:59 <Viking-Ice> doen
16:27:02 <Viking-Ice> mean done
16:27:04 * jlaska would like to give others the opportunity
16:27:07 <jlaska> Viking-Ice: thx :)
16:27:22 <jlaska> adamw: you want to swap duties this week?
16:27:31 <jlaska> you take the announcement and I'll do the summary?
16:27:39 <adamw> sure
16:27:46 <adamw> any combination is fine for me
16:28:00 <jlaska> cool, thanks
16:28:39 <jlaska> any other things we should be thinking about for blocker bug day#2?
16:28:59 <f13> would be good to have some rawhide testing done by then
16:29:10 <f13> of course I think rawhide is in cannot install, full stop mode right now :/
16:29:20 <jlaska> f13: yeah ... I've kicked the tires on that a little and asked lili to bump up the install testing in response to your requests
16:29:27 <jlaska> we've got a few blocker bugs on the list now to work with
16:29:34 <jlaska> and you and clumens seem to be working the networking issue now
16:29:38 <jlaska> good stuff!
16:29:59 <f13> sortof.
16:30:02 <f13> it's a head scratcher
16:30:10 <adamw> which issue is this?
16:30:18 <jlaska> f13: yeah it had be lost ... but that doesn't take much ;)
16:30:32 <jlaska> 513020
16:30:56 <adamw> ah
16:31:25 <adamw> jlaska: i am impressed by your painstaking reproduction of the ascii failure dialog =)
16:31:34 <jlaska> cut'n'paste my friend
16:31:38 <jlaska> thank the newt gods
16:32:01 <jlaska> dpravec: welcome!
16:32:06 <dpravec> hello, i am sorry for being late
16:32:23 <jlaska> dpravec: no worries ... we've just agreed earlier to move the meeting time to Monday @ 16:00 UTC
16:32:31 <dpravec> hurray
16:32:33 <jlaska> okay ... next update ...
16:32:41 <jlaska> #topic Alpha test compose
16:33:06 <jlaska> the F12 Alpha schedule has a test compose being handed off next week (2009-07-29)
16:33:41 <jlaska> Liam started the ball rolling on coordinating install testing ... so if you'd like to pitch in ... give a gander to https://www.redhat.com/archives/fedora-test-list/2009-July/msg00429.html
16:34:21 <f13> I have some issue with that
16:34:25 <f13> 1) he called it a candidate.
16:34:39 <f13> 2) he's inviting the world to participate, but we're not delivering it to the world.  It's not being mirrored.
16:35:00 <dpravec> and is it installable?
16:35:09 <dpravec> i was not the only one to try... and we all failed
16:35:16 <Viking-Ice> that's what we are trying to find out :=
16:35:18 <jlaska> yeah I think #1 is just a minor goof ... we can correct the wording
16:35:26 <adamw> yeah, that's what i was thinking...we seem to have a complete blocker bug on installation atm, don't we? so what install testing can we do?
16:35:48 <jlaska> adamw: great point ... so if we fail to hit the 07-29 target ... things move
16:36:16 <adamw> there _is_ an updates.img for the blocker bug, so we should be testing that, i guess
16:36:19 <jlaska> Liam is just getting the pages and coordination started ... so this is good fedback
16:36:28 <f13> right, we have to fix the current issue by then
16:36:43 <f13> but we're still not going to be able to deliver those trees to very many people.
16:36:44 <jlaska> f13: to your second point ... I think that's an area where QA needs a clever solution
16:36:56 <Viking-Ice> 3) should have provided this link :) https://fedoraproject.org/wiki/Anaconda/BugReporting
16:37:00 <Viking-Ice> as well
16:37:11 <jlaska> Viking-Ice: feel free to add that link to Liam's announcement
16:38:42 <dpravec> btw few hours ago i filled my disk, getting 'rpmdb open failed'  later  ->which is really 'fun'. luckily i solved this one, but this should not happen...
16:38:43 <jlaska> f13: do you have concerns that the server hosting the ISO images won't be able to hold up to testers downloading the images?
16:38:52 <f13> yes
16:39:03 <f13> jlaska: it happens every time the location leaks when I'm trying to deliver stuff to QA
16:39:08 <f13> via Fedora infrastructure
16:39:08 <dpravec> so should we use bittorrent?
16:39:18 <wwoods> bittorrent doesn't work for this.
16:39:24 <jlaska> f13: is there something we can reach out to for help from the infrastructure guys?
16:39:27 <Viking-Ice> more bandwith..
16:39:33 <Viking-Ice> the iso's are not the only problem..
16:39:36 <f13> jlaska: theyr'e going to tell us to use the mirror system
16:39:42 <dpravec> why is bittorrent not the way to go?
16:39:42 <f13> which we don't really have time to do
16:39:47 <jlaska> so let's use the mirror system?
16:39:47 <wwoods> we tried before - demand isn't high enough, so there aren't enough peers/seends
16:39:48 <Viking-Ice> testerst should all be using the same bits for testing instead of relying on outdated mirrors..
16:39:54 <f13> dpravec: lots of little files, very few seeders
16:40:06 <wwoods> so nobody ever manages to finish the image before it's obsoleted.
16:40:12 <f13> jlaska: we don't have the 3 or 4 days it would take for the mirrors to sync up
16:40:23 <jlaska> okay, so we have ISO's ... and people want to download and test them
16:40:24 <dpravec> ah, ic
16:40:29 <jlaska> but we can't keep up with that demand?
16:40:30 <f13> this was supposed to be a compose delivered to a few high bandwidth testers
16:40:48 <f13> jlaska: the problem is you get a lot of pile on downloaders who provide no actual feedback
16:40:49 * poelcat thinks this issue should be opened in a ticket with infrastructure... let the experts handle this problem
16:41:05 <f13> they just jump on teh bits because it's there, and use up all the resources
16:41:05 <dpravec> hmm arent those 2 problems? i would use bittorrent for isos
16:41:11 <wwoods> right, the test composes aren't intended for a worldwide audience, only people with enough bandwidth to get the images quickly
16:41:12 <jlaska> f13: sure ... that's a valid concern .. and something QA should be thinking about right?
16:41:14 <wwoods> and enough brains to know what they're doing
16:41:21 <poelcat> we've wasted days arguing about this here and on the mailing lists
16:41:21 <jlaska> the test composes are for testers
16:41:35 <dpravec> you can have one 'seeder' on server...
16:41:42 <f13> I guess a simple solution is to password protect the directory and rsync
16:41:48 <f13> or FAS protect it or something
16:41:56 <jlaska> ooh
16:42:03 <jlaska> perhaps a tie-in now with the FAS QA groups?
16:42:11 <jlaska> that's not a bad idea
16:42:14 <wwoods> right, we've talked about that before. private mirror for QA only.
16:42:32 <jlaska> cool, yeah let's take this offline and see if we can get something actionable out of this
16:42:37 <wwoods> except that reduces to the "what do you have to do to prove yourself worthy of QA team membership" problem
16:42:38 <jlaska> since I don't think we'll figure it out in 18 minutes
16:43:10 * Viking-Ice thinks we are heading down the wrong road restrict access to those img..
16:43:26 <jlaska> it's _a_ solution to a bandwith problem
16:43:29 <Viking-Ice> we want to expose testing to as many as possible...
16:43:42 <wwoods> we're not restricting access, we're preventing overload
16:43:55 <wwoods> a subtle but important difference
16:44:02 <jlaska> f13: do you want to reach out to the infrastructure guys ... or should I?
16:44:05 <wwoods> you're still welcomed and encouraged to spread those images as far and wide as you want
16:44:10 <jlaska> you may have already done this ... so it's possible I'm just late to the party
16:44:11 <wwoods> they're for everyone who can get them
16:44:24 * mchua listens
16:44:27 <wwoods> *but*, in order to guarantee that our *testers* can get them, we need to give the testers priority accecss
16:44:30 <jlaska> mchua: hey there :)
16:44:34 <dpravec> hmm but still, bittorent can work if we will have stable seeders (clients which we will run on servers)
16:44:37 <wwoods> otherwise everyone hammers the server and *nobody* gets them
16:44:40 <Viking-Ice> wwoods: ofcourse
16:44:47 <dpravec> at least for iso images
16:44:59 <wwoods> and then, by allowing access to *more* people we end up with *less* testing
16:45:09 <wwoods> which is unacceptable.
16:45:28 <jlaska> wwoods: all valid points ... I think there is a solution out there
16:45:40 <jlaska> perhaps adding value to what it means to be in the QA group is one way
16:45:53 <jlaska> okay ... going to table this for now
16:46:10 <jlaska> if anyone would like to take an action item to talk to the infrastructure folks to see what we can work out ... let me know
16:46:32 <jlaska> otherwise, I'll plan to talk with them
16:46:35 <wwoods> dpravec: sure, we could combine both approaches - private mirror for testers, but all testers *must* seed the torrent
16:46:53 <adamw> to be enforced how?
16:47:03 * jlaska looks for the lid to the can of worms
16:47:20 <dpravec> you can cut them from the bittorent server if they do not seed enough
16:47:22 <adamw> i don't think anyone wants to have the 'Bittorrent Police' job title
16:47:22 <f13> jlaska: I've got too much on my plate as it is, can you?
16:47:28 <jlaska> f13: you got it
16:47:34 <jlaska> f13: err ... meaning I got it
16:47:34 <jlaska> ;)
16:47:38 <adamw> dpravec: see above
16:47:45 <adamw> dpravec: who wants to spend their time checking on that?
16:47:51 <dpravec> can be automated
16:47:53 <adamw> and dealing with the inevitable emotional appeals?
16:47:55 <adamw> ^^
16:48:00 <dpravec> there are such servers imho
16:48:10 <jlaska> okay gang ... let's continue the bittorrent part when we hear back from infrastructure
16:48:13 <wwoods> fine, s/must/are urged to/
16:48:20 <adamw> yeah, it's a tactic commonly used by, ahem, pirate sites =)
16:48:25 <jeff_hann> personally I don't think restricting access is a good idea. MHO
16:48:45 <dpravec> adamw: not only pirates...
16:48:47 <Viking-Ice> people the problem is lack of bandwith so let's fix that problem let's get this iso's on edu bandwith!
16:48:52 <wwoods> we tried unrestricted access and nobody could get the bits in time for them to be useful
16:48:55 <jlaska> jeff_hann: that's certainly an area we need to be in tune with
16:48:57 <wwoods> so maybe think again.
16:49:09 <Viking-Ice> selective testers on edu bandwith offer the iso's
16:49:09 <poelcat> jlaska: what is the next topic?
16:49:12 <dpravec> put the iso on some really accessible mirros?
16:49:15 <jlaska> #topic Dracut gone raw
16:49:46 <jlaska> Viking-Ice: you had asked for some discussion around the incoming rawhide dracut changes?
16:49:54 <Viking-Ice> yes
16:50:08 <Viking-Ice> we dont have any implementation plan from the maintainer
16:50:20 <Viking-Ice> no goals to see if they are made before the switch
16:50:38 <jlaska> I spoke w/ harald this morning about the open questions in the feature page
16:50:42 <Viking-Ice> what's needed to be done for a successful switch ( feed back etc )
16:50:55 <jlaska> https://fedoraproject.org/wiki/Talk:Features/Dracut
16:51:04 <jlaska> harald correctly pointed out some bozo used the wrong rpm options
16:51:08 <jlaska> where bozo == $me
16:51:23 <jlaska> so to the first point, the `rpm --whatrequires mkinitrd` list is empty
16:51:48 <jlaska> as for a contingency plan ... Harald suggested looking at the [[Dracut]] page that Viking-Ice created
16:52:03 <jlaska> but I think this could use someone to follow-up with Harald on
16:52:29 <jlaska> at least it wasn't clear to me, in the event we need to pull out this change ... what are the high level changes anticipated
16:52:36 <jlaska> Viking-Ice: do you know more here?
16:52:50 <Viking-Ice> We are still missing some kind of implementation plan that should have milestones which we can then keep track on and test to see if they are met..
16:53:30 <adamw> so, to summarize, you both agree we don't have test details or a contingency plan, and we need to ask the feature owners to deal with this
16:53:38 <jlaska> adamw: you got it
16:54:14 <adamw> and by 'we' i mean 'one of you two'
16:54:14 <adamw> :D
16:54:37 <jlaska> harald pointed out some areas of testing concern for when this lands in rawhide (real soon now)
16:54:37 <jlaska> http://fpaste.org/paste/19555
16:54:37 <jlaska> I suspect these will be strong candidates for the future test day
16:54:47 <jlaska> ha!
16:55:07 <jlaska> I'm approaching full ...  Viking-Ice do you think you can get some chat with w/ Harald in the next few days?
16:55:08 <Viking-Ice> Are we rolling live iso' s with dracut ?
16:55:23 <jlaska> for the test day, we plan to
16:55:32 <jlaska> but for rawhide ... there are none planned afaik
16:56:43 <jlaska> anyone interested in taking an action item to chat w/ harald about Dracut ... which can be used to help outline the dracut test day plan?
16:56:46 <Viking-Ice> so sugar kde gnome xfce contain dracut img ?
16:56:53 <Viking-Ice> live spins
16:57:18 <jlaska> Viking-Ice: that's my understanding ... that new-kernel-pkg would be using dracut (instead of mkinitrd)
16:57:42 <Viking-Ice> if they are built using our build system which brings us to another topic
16:58:34 <Viking-Ice> I'm sure that those that are "locally" (DE people ) building iso's arent using dracut
16:58:47 <jlaska> Viking-Ice: is this something you can help with ... in terms of getting more info for QA around dracut?
16:59:09 <jlaska> or should I leave it open to an interested tester
16:59:21 <Viking-Ice> I can ping harald about this sure
16:59:32 <Viking-Ice> try to gather some info
16:59:37 <Viking-Ice> etc..
16:59:53 <jlaska> Viking-Ice: awesome, I appreciate it ... I spoke to harald briefly but I know you're well invested into the [[dracut/*]] wiki pages so it will make more sense to you!
17:00:18 <jlaska> #action Viking-Ice will check-in with Dracut maintainers to get additional feedback to guide testing
17:00:28 <jlaska> okay changing gears now ...
17:00:32 <jlaska> #topic AutoQA update
17:00:43 <jlaska> wanted to give wwoods and dpravec a chance to talk about updates on the autoqa space
17:00:52 <jlaska> wwoods: you want to go first?
17:02:41 <jlaska> while we wait for wwoods ...
17:02:52 <jlaska> dpravec: I know you got to feel the rawhide burn last week
17:02:54 <dpravec> i was talking to some people in brno today, and some of them think that we should go work on beaker
17:03:08 <dpravec> that autotest might be just waste of time in the long run
17:03:20 <jlaska> yeah it's a bit confusing
17:03:30 <jlaska> but when beaker is live ... we'll just be using autotest with beaker
17:03:55 <jlaska> we've been in talks with the beaker developers to make sure that the solution we have now will be viable when beaker has a working implementation
17:03:56 <dpravec> my testing installation still have some issues, i am sorry i cant report much this time, should be much better from me on monday
17:07:00 <wwoods> sorry, back now
17:07:24 <wwoods> so I've automated the first 4 test cases on https://fedoraproject.org/wiki/QA:Rawhide_Acceptance_Test_Plan
17:07:31 <wwoods> and have them running under autotest
17:07:37 <jlaska> dpravec: okay ... let's walk through the autotest packaging issues tomorrow so we can get f13 some feedback in the ticket
17:08:16 <dpravec> jlaska: thanks, i will need few more hours to make it
17:08:30 <wwoods> https://fedorahosted.org/autoqa/browser/rawhide_acceptance
17:08:36 <wwoods> working on the installation tests now
17:08:41 <jlaska> dpravec: you can get your system back to an F11 laptop ... and we can go from there with the virt stuff
17:09:13 <adamw> wwoods: are the results of the first automated tests going anywhere public yet?
17:09:14 <dpravec> yes i already did, my laptop is becoming useable again
17:09:24 <wwoods> adamw: no.
17:09:39 <wwoods> they'll go public eventually
17:09:42 <adamw> k
17:09:48 <wwoods> if you want to run the test yourself it works outside autotest
17:10:17 <wwoods> right now I'm just focusing on actually automating the agreed-upon test cases
17:10:26 <wwoods> getting the testing and results public will happen later
17:11:28 <jlaska> wwoods: cool stuff, I've got your updated tests packaged into autoqa and running on another private autotest server
17:11:35 <wwoods> jlaska: excellent
17:11:58 <wwoods> we're gonna need to set up separate ppc/x86_64/i386 hosts for some tests
17:12:14 <wwoods> not sure how we're going to test ppc in the absence of virt on those systems
17:12:17 * jlaska makes a note on ppc
17:12:27 <jlaska> it's possible ... just not using virt-manager/libvirt
17:12:35 <jwb> shame
17:12:42 <wwoods> yeah, it's not hard to start the test, just hard to recover when the test fails
17:12:59 <wwoods> when a virt guest dies, well, you're watching on its serial console
17:13:05 <wwoods> and you can just delete it and mark it failed
17:13:27 <wwoods> when an actual machine dies you need to automatically reinstall. somehow.
17:13:46 <jlaska> wwoods: cobbler now has this support ... which is what I use for normal install testing
17:14:01 <jlaska> that's a bit more formal than using just libvirt ... but it's an option in the future if we need it
17:14:17 <wwoods> I'm not enthusiastic about requiring a cobbler server to run the rawhide tests, but if that's the only way I'm sure we can make it work
17:15:11 <f13> wwoods: how hung up are we on install testing?
17:15:24 <f13> if we threw out install testing and went back to just repo level testing, could we have something useful quicker?
17:16:34 <jlaska> f13: yeah that's a possibility wwoods discussed a while back ... if it comes to it
17:16:51 <f13> I feel we're falling short of "do something useful ASAP"
17:16:55 <f13> and taking too much on again
17:17:29 <adamw> i dunno, it sounds like useful stuff is being done already
17:17:32 <jlaska> f13: hmm, we are slightly behind the schedule set forth ... but I'm not too concerned yet
17:17:39 <adamw> the four tests wwoods has automated already are repo-level testing
17:17:49 <wwoods> yes.
17:17:56 <f13> adamw: yes, and we don't have them happening in public, automated, reportable way
17:18:10 <jlaska> all of the tests are public
17:18:23 <jlaska> and we have stuff "in the works" for getting the server and client systems open
17:18:25 <f13> jlaska: the original schedule was 3 weeks after last FUDCon Boston  (:
17:18:43 <jlaska> f13: the original schedule is here https://fedorahosted.org/autoqa/milestone/israwhidebroken.com
17:18:52 <jlaska> where we set a date of Aug 18
17:19:23 <f13> jlaska: that's the current iteration of this automated QA effort.
17:19:38 <jlaska> f13: right on, that's the plan we are working
17:19:45 <f13> however this whole thing started back at FUDCon Boston with the idea of doing something useful in 3 weeks, useful in 3 months, useful in 3 quarters
17:19:53 <wwoods> that's great
17:19:59 <adamw> nothing we can do now is magically going to make that happen.
17:20:08 <f13> so I feel that I've failed miserably in delivering something useful to our maintainers based on those timelines.
17:20:19 <adamw> the point is we actually started working on a concrete plan to do this stuff relatively recently, and as far as i've seen, progress has been pretty rapid
17:20:23 <wwoods> we have a plan. we are following the plan. if you would like to help, feel free.
17:20:30 <jlaska> f13: if you set the criteria for success at 3 weeks, then yes we missed that target
17:20:35 <f13> wwoods: I've been trying to help, but the targets keep moving
17:20:36 <adamw> i just listen to the updates from wwoods each week, but from those he seems to be making solid strides each week
17:21:07 <f13> I thought we were very close to having something useful with autoqa, then we threw that out for autotest and I lost a few weeks to trying to package that up
17:21:09 <f13> (still not done)
17:21:16 <f13> now we may be throwing that out for beaker?
17:21:19 <adamw> just a few weeks ago we had nothing, now we have a full set of test cases, a full test plan, and four automated tests; i think that's indicative of substantial progress. the fact that it took a long time to get to the starting gate is something we can't do anything about now
17:21:19 <wwoods> no.
17:21:21 <jlaska> f13: you're keeping it honest ... the israwhidebroken.com plan doesn't match up with the FAD dates
17:21:30 <jlaska> f13: nope we are not changing for beaker in the short term
17:21:43 <wwoods> beaker is inventory / system provisioning. it currently lacks a test harness and scheduler
17:21:53 <f13> adamw: we had automatible tests months ago
17:21:58 <wwoods> autotest is a scheduler and test harness. it currently lacks provisioning capabilities.
17:22:39 <wwoods> as for the autoqa stuff
17:22:45 <wwoods> both autoqa tests we had before
17:22:49 <wwoods> are being run under autotest already
17:22:58 <wwoods> and now we're writing new tests
17:23:00 <f13> this isn't directed at anybody, I'm just frustrated that we still don't have a simple tool doing a simple test and sending out a simple email
17:23:10 <wwoods> and actually having those results reported somewhere we can look at 'em
17:23:12 <f13> something I felt we could have had 3 weeks after FUDCon if that's what we actually targeted
17:23:27 <jlaska> f13: I hear ya ... you have valid concerns.  I can tell you now that we are on schedule with our plan and things are progressing
17:23:31 <wwoods> but yeah, it's not sending out email anymore
17:24:00 <f13> I'm also frustrated because my window for helping out is rapidly closing, because Alpha is coming, then snapshots, then beta, then release
17:24:30 <f13> in fact, I don't think I have any time left, since I need to get signing server finished and maybe enact some of the FAD proposals
17:24:31 <jlaska> okay ... we can keep tabs on this, but let's close it out for today
17:24:54 <jlaska> f13: that's okay ... the only action item you have is the autotest packaging help
17:25:04 <jlaska> and that's looking good ... and dpravec will have some more information there if needed
17:25:11 <jlaska> if time runs out ... we can reassign that task if needed
17:25:27 <jlaska> okay ... diving into open discussion in a moment ...
17:25:45 <jlaska> #topic Open discussion
17:26:16 <jlaska> sdziallas: you mentioned back at the top of the meeting about plans around a 'sugar on a stick' test day
17:27:15 * mchua listening
17:27:28 * jlaska seeks to lubricate the discussion
17:27:33 <sdziallas> jlaska: yup, that's true. I've been doing the Sugar on a Stick work for Sugar Labs lately, which is basically a rebranded Fedora base system with the Sugar packages on top. We're really interested in maintaining a good connection to the Fedora community (given that I started as a Fedora guy, too)... and would also like to test the Sugar implementation in Fedora
17:27:33 <dpravec> i was talking with people and it seems to me that best what we can do to improve quality of releases is to make some smoother rawhide repository, which will contain only packages without serious bug or dependency problems. similar to debian unstable/testing...   this would enourage people to test latest (or week old) packages.
17:28:00 <f13> #topic Sugar on a stick testing
17:28:05 <f13> d'oh (:
17:28:15 <jlaska> :)
17:28:23 <jlaska> #topic open discussion [sugar on a stick test day]
17:28:51 <f13> dpravec: we're going to get essentially that if my no frozen rawhide proposal goes though
17:28:58 <jlaska> adamw: you and I discussed this a while back as well ... I suggested to sdziallas that it might make sense to use the test day SOP to host a sugar test day event
17:29:04 <jlaska> https://fedoraproject.org/wiki/User:Adamwill/Draft_test_day_SOP
17:29:14 <adamw> yes
17:29:19 <adamw> which i still haven't moved out of draft yet
17:29:19 <adamw> le sigh
17:30:00 <jlaska> sdziallas: is there information you need to help get things started with self-hosting?
17:30:20 <sdziallas> I think that might be an interesting way of realizing a Sugar / Sugar on a Stick test day...
17:30:26 <jlaska> sdziallas: we also mentioned some of the work Adam Miller is doing with XFCE weekly spins
17:30:29 <dpravec> another thing we can do is to provide tools for developers/testers to test LATEST or custom packages on some test servers using gui (vnc, nx...)
17:30:40 <Viking-Ice> ?
17:30:40 <jlaska> dpravec: one sec ...
17:30:45 <dpravec> just today i was talking to openjdk developer who would be happy to have this...
17:31:02 <jlaska> dpravec: I've got your points down ... just want to finish the sugar topic first
17:31:15 <sdziallas> jlaska: heh, well... we're looking to get some weekly rawhide spins for a sugar spin, too, so this might help.
17:32:00 <sdziallas> jlaska: I think it would be good to pick a date soonish to have something we can plan with... (so that we don't have two test days at the same date or so)
17:32:36 <adamw> schedule's at https://fedoraproject.org/wiki/QA/Fedora_12_test_days
17:32:43 <adamw> you can take any of the open slots on the left hand side
17:33:25 <sdziallas> adamw: well, if this is going to follow the SOP proposal, will it still be one of the usual test day dates then?
17:33:41 <adamw> don't see why not
17:33:55 <adamw> there's no reason test days on the main schedule have to be organized by members of the cabal ;)
17:33:56 <jlaska> if the expertise at hosting the event are outside of fedora QA proper ... we might wnat to use a different track
17:34:27 <jlaska> that was my only concern
17:35:11 <adamw> i don't think we need a zillion tracks
17:35:14 <sdziallas> adamw, jlaska: imo, something around (if not even that date) the September 3 slot would be great...
17:35:27 <adamw> a track makes sense for fit and finish because they have a sequence of events that are part of a clearly defined project
17:35:31 <adamw> this is a single event, aiui
17:35:39 <jlaska> adamw: track is a poor use of terms on my part
17:35:41 <adamw> makes sense to just stick it in the main schedule, for me
17:35:59 <jlaska> to me, that means Fedora QA owns the event, is that wrong?
17:36:10 <jlaska> owns in terms of coordinating, announcing, etc...
17:36:35 <adamw> i don't see that it has to.
17:36:42 <jlaska> sdziallas: is that stuff you and mchua can offer help in ... e.g. test plans/cases
17:36:47 <adamw> but i don't think it's terribly important, let's just stick a date on the damn thing and we can argue the semantics later
17:36:55 <adamw> sept 3 looks fine to me
17:36:56 <jlaska> heh ... semantics
17:37:04 <jlaska> adamw: so you're saying sept 3?
17:37:04 <jlaska> ;)
17:37:13 <jlaska> a'ight .. . we've got a date
17:37:20 <jlaska> I'll bring the flowers
17:37:34 <sdziallas> jlaska: we had some plan originally in the SugarLabs wiki, but I can certainly help (and maybe mchua or others, too)
17:37:35 <sdziallas> :)
17:38:03 <mchua> jlaska: if it would help to simultaneously use this as a live test of what we're trying to do with smw, that can be arranged
17:38:17 <jlaska> mchua: yeah that'd be a nice tie-in
17:38:41 <mchua> jlaska: we've got a concrete test case case to set up for on tuesday then
17:39:09 <jlaska> mchua: you got it
17:39:19 <jlaska> okay, so we'll follow-up as we get closer to Sept 3
17:39:40 <sdziallas> awesome!
17:39:43 <jlaska> okay, back to dpravec ...
17:39:49 <jlaska> #topic open discussion [rawhide testing]
17:40:12 <jlaska> dpravec: you had some ideas ... were there any things you wanted to walk through in the meeting?
17:40:57 * jlaska has to wrap things up here
17:41:03 <jlaska> stomach digesting itself
17:41:27 <jwb> jlaska, sounds like a hot new diet fad
17:41:36 <jlaska> jwb: no kidding
17:41:37 <dpravec> hmm users keep telling me that they really need to have useable fresh packages. having rawhide broken makes it hard for them to even try it
17:41:41 * adamw hasn't had his fricking breakfast yet
17:41:59 <adamw> usable and fresh are so often mutually exclusive. this is the problem with development branches.
17:42:07 <dpravec> this week is rawhide full of problems, uninstallable... broken
17:42:19 <Viking-Ice> the ususal
17:42:20 <jlaska> dpravec: I think the proposal f13 pointed to is aiming to address some of your concerns
17:42:40 <dpravec> yes i will read details of those and comment there if appropriate
17:42:53 <jlaska> please do, I know you have experience with the deb stable/unstable model
17:43:11 <dpravec> even debian experimental is more stable than rawhide is
17:43:20 <f13> dpravec: the biggest change with my proposals is that we wouldn't even be making install images for rawhide
17:43:31 <jeff_hann> dpravec, I beg to differ
17:43:33 <f13> we'd only make install images after we've branched after feature freeze
17:43:43 <f13> so "rawhide" would just be a repo of packages, just like Debian unstable
17:43:43 <jeff_hann> I used Debian, all branches
17:43:45 * jlaska senses rat hole
17:43:48 <dpravec> jeff_hann:  :)
17:44:00 <dpravec> well i just tried rawhide on my desktop
17:44:01 <f13> you'd have to start with something more stable, like the branched Fedora or the previous release, and then yum update to rawhide versions of packages
17:44:07 <dpravec> and compared to debian unstable, its unusable
17:44:10 <Viking-Ice> if they are going to run developing components on a stable product the package maintainer needs to setup up repo for example on his people page and build those developing package for F11 like the virtualization team did..
17:44:14 <f13> so we'd lose the expectation that rawhide is "installable"
17:44:18 <jeff_hann> compared to unstable, yes
17:44:35 <f13> dpravec: that's an unfair comparison, because you can't directly install Debian unstable.  You have to start out on something else, and then /update/ to unstable
17:44:44 <dpravec> f13: yes you can
17:44:58 <f13> dpravec: I don't recall there being nightly install images made from Debian unstable
17:45:04 <dpravec> there are daily /weekly install images
17:45:06 <dpravec> and live images
17:45:07 <jlaska> okay gang ... I'm sensing a great discussion topic for after the meeting :)
17:45:18 <jlaska> let's call end of meeting
17:45:19 <f13> and really, comparing us to debian is jokes
17:45:22 <Viking-Ice> or on next meeting..
17:45:28 <f13> different goals, different methodologies
17:45:31 <dpravec> anaconda is big problem, its very complex
17:45:34 <jlaska> and we can take follow-up to the debian/rawhide discussion to hte list or #fedora-qa
17:45:39 <dpravec> f13: ic :)
17:45:48 <jeff_hann> :)
17:45:59 <f13> right, anaconda is complex, because it has lots of useful features
17:46:02 <dpravec> i would love to get to the situation that users will not be afraid to install fedora 'unstable'
17:46:08 <f13> testing those features before they're ready to be tested is a mistake and useless
17:46:10 <f13> so lets not do it
17:46:29 <jlaska> thanks folks for your time ... today was quite a long one!
17:46:41 <f13> dpravec: I'd love to get to the situation where the only install images we provide of Fedora 'unstable' are ones that we know are ready and useful to be tested
17:46:52 <jlaska> #endmeeting