16:03:07 <adamw> #startmeeting qa meeting 2010-01-25
16:03:07 <zodbot> Meeting started Mon Jan 25 16:03:07 2010 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:28 <adamw> good $TIMEZONE_APPROPRIATE_GREETING everybody
16:03:33 <adamw> #topic gathering
16:03:36 <adamw> who's around?
16:03:49 <jlaska> I'll be around for the start of the meeting now
16:03:49 * kparal is
16:04:10 * maxamillion is semi-here ... in a $dayjob meeting with my laptop
16:05:36 <adamw> hey beland
16:05:46 <adamw> alright then, let's get started with last week's review
16:05:57 <adamw> #topic followup: xfce test day / 4.8 update
16:06:04 <adamw> maxamillion: got anything for us on this?
16:06:27 <maxamillion> adamw: well, yes and no ... I think I talked to you about this in the #fedora-qa channel but not in a meeting because I missed last week
16:06:53 <adamw> well in a meeting context!
16:07:17 <maxamillion> we're following the Xfce 4.8 development cycle pretty closely and there's apparently the concept of a 2 month release slip happening so we're monitoring that to decide what we should do for a QA Test Day
16:07:40 <maxamillion> errr... concept of the 2 month release slip is being thrown around, but not definite yet
16:08:07 <maxamillion> sorry ... trying to listen to $dayjob meeting while typing, I apparently didn't do that well
16:08:33 <adamw> so the 2 month slip would be from when to when?
16:08:35 <maxamillion> but other than that, there's not much to report ... its mainly a waiting game on our end but I also know we need to start planning out a Test day
16:08:42 <maxamillion> adamw: just a sec, lemme get a link
16:09:34 <maxamillion> adamw: http://fedoraproject.org/wiki/Features/Xfce48 <--- if they have the 2 month slip, we will miss Fedora 13
16:09:58 <maxamillion> it is currectly an agressive time line just to make F13 with them being on time
16:10:32 <adamw> if you're looking for advice i'd say not to risk it, then, it's a very bad idea to depend on an upstream project being precisely on time =) but anyway
16:10:35 * wwoods appears
16:10:43 <adamw> i guess the main issue for QA group is the test day, so planning on that has not advanced much?
16:11:40 <maxamillion> adamw: well the plan for me is to pick a date for the xfce test day, and pick a "if we don't have a pre release on time, then we revert to 4.6 testing" date
16:12:08 <jlaska> so we'll be testing something, whether it's 4.8 or 4.6 will be decided later?
16:12:55 <maxamillion> jlaska: right, but my fear is that if we don't get to move forward to 4.8, then we won't really have much new to add to the last test day
16:13:07 <maxamillion> because in the world of xfce .. not a whole lot has changed
16:13:15 <adamw> that's fine; you can just have a 'is everything still working okay' test day
16:13:23 <adamw> nothing wrong with that
16:13:30 <maxamillion> adamw: sounds good to me
16:13:44 <adamw> even if nothing changed in xfce itself, lots of underlying code has changed, you'll want to be sure xfce bits still work okay with it
16:14:09 <maxamillion> oh yeah, definitely ... I was just hoping to have shiny new xfce features to test :D
16:14:13 <adamw> =)
16:14:16 <adamw> ok, thanks maxa
16:14:20 <adamw> anything else on xfce anyone?
16:14:31 <maxamillion> nothing from me
16:14:38 <adamw> alrighty
16:14:59 <adamw> #topic followup - bug documentation
16:15:06 <adamw> jlaska / beland, this is yours
16:15:15 <adamw> agenda notes 'beland sent email to fedora-test-list (Re: 2010-01-11 @ 16:00 UTC (11am EST) - Fedora QA Meeting Recap) '
16:15:23 <adamw> i think i missed that one...
16:15:24 <jlaska> yeah, I had an email in progress, but beland beat me to it :)
16:15:40 <adamw> oh, just yesterday evening, haven't read it yet
16:15:43 <jlaska> so discussion started in response to last week's meeting recap (see http://lists.fedoraproject.org/pipermail/test/2010-January/088137.html)
16:16:29 <jlaska> I seemed to have a hard time deciding how to address documentation issues during previous releases
16:16:57 <jlaska> I think that's cleared up for me now, but I'm not sure if it would be beneficial to others to spell it out as well
16:17:02 <beland> Just read James' reply...I guess it would be useful to hear opinions on whether the CommonBugs keyword is useful.
16:17:12 <jlaska> I don't hear any complaints, so I gather not
16:17:26 <adamw> well james and I use it ourselves a lot, i dunno if it really gets used beyond that
16:17:47 <adamw> I also use it to know when changes to a bug should get echoed back to the common bugs page...
16:17:57 <beland> Any particular reason you don't just add links to the wiki page instead?
16:18:53 <jlaska> I use it quite a bit for tagging issues that come up during test ... just to make sure that adamw or I get a chance to later review the issue appropriateness (word?) for the common_bug wiki
16:19:20 <adamw> beland: for what purpose?
16:19:37 <jlaska> beland: the only reason I don't add it directly to the wiki, is that the bug might be too new (or to in flux) that the details needed to properly document aren't yet fleshed out
16:19:51 <adamw> beland: you can't put 'placeholders' on the wiki page, it's a production page for people to read; putting them in the source is too easy to miss; and a backlink from the wiki to the bug doesn't help you know the page needs updating when you're reading the *bug*
16:19:51 <jlaska> s/or to in/or too in/
16:20:14 <beland> Sounds like it's useful enough to justify the extra complication, then.
16:20:33 <beland> We should add links to the queries jlaska pointed out in his email, then.
16:21:24 <jlaska> beland: where would you prefer seeing those links, on the Common_Bugs wiki page?
16:21:38 <beland> Yeah.
16:22:06 <jlaska> If no objections, I can add those links at the end of #My_bug_is_not_listed
16:22:25 <adamw> sounds good
16:22:39 <adamw> damn sorry been forgetting my #info's, here we go
16:22:41 <jlaska> #action jlaska to add bugzilla shared query links to Common_Bugs wiki page
16:22:51 <adamw> #info jlaska and beland working on the topic
16:23:02 <adamw> jlaska: i don't think I chaired you, hand on
16:23:06 <adamw> #action jlaska to add bugzilla shared query links to Common_Bugs wiki page
16:23:08 <adamw> #chair jlaska
16:23:08 <zodbot> Current chairs: adamw jlaska
16:23:16 <beland> I think the idea of "if you want to add a note to formal documentation about a bug, file a bug report against the documentation" is good advice, even if it's not the most efficient workflow in the world.
16:23:53 <beland> I'm not sure where that should be documented for QA-type people to find, though. It would be nice if it were clearly documented for everyone in the Docs Project wikispace, but ::sigh::
16:24:03 <adamw> personally i honestly don't think i'd consistently wade through a bunch of 'bug reports against documentation' to find stuff to add to common_bugs
16:24:07 <adamw> if anyone else would, great
16:24:22 <beland> No, I wouldn't include Common Bugs there.
16:24:26 <adamw> oh, kay.
16:24:31 <beland> Just "formal documentation" that's off-wiki.
16:25:09 <beland> (stuff on docs.fedoraproject.org)
16:25:29 <adamw> #info beland thinks filing bug reports to request notes be added to formal documentation is the best procedure
16:25:43 <adamw> alright, so basically the update for this topic is that it's in progress and discussed on-list
16:25:56 <adamw> is there anything else we need to discuss in the meeting context?
16:26:12 <jlaska> I don't think so, that's all I have on the topic
16:26:14 <jlaska> thanks beland :)
16:26:33 <adamw> #action jlaska and beland to keep working on the process
16:27:01 <adamw> #topic privilege escalation policy
16:27:11 <adamw> okay, this one is me. so, as you probably saw on-list, I sent out a draft policy
16:27:22 <adamw> and everyone has got involved in explaining why it sucks :)
16:27:40 <adamw> i'll keep re-drafting until everyone agrees with more or has been bored into submission
16:27:45 <adamw> s/more/me/
16:28:09 <adamw> once we have a good draft i'll take it back up to fesco
16:28:13 <beland> Whee!
16:28:21 <adamw> is that process ok with everyone?
16:28:23 <maxamillion> kudos for taking on this task ... its definitely a big one
16:28:39 <jlaska> I'm not fully up to speed on the updates over the weekend, but it seems to be moving forward
16:28:45 <adamw> or does anyone feel they want to be more involved is this exciting and highly rewarding endeavour? :P
16:28:49 <maxamillion> i read over it and have no objections
16:28:51 <adamw> i haven't done squat over the weekend
16:29:00 <adamw> but i'll pick up the latest mails today and send out a new draft
16:30:27 <adamw> #info adamw still working on re-drafting the policy with much group feedback on mailing list
16:31:06 <adamw> #topic followup: rawhide page update
16:31:24 <adamw> this is for nirik, if you're around
16:31:37 <nirik> I'm around...
16:31:39 <adamw> nirik was planning to update the rawhide wiki page to reflect the changes to getting On The Bus
16:31:42 <nirik> I'm waiting for the subpackage to land.
16:31:52 <adamw> #link http://fedoraproject.org/wiki/Releases/Rawhide
16:32:06 <adamw> fair enough - waiting as in you have the change ready to go when it does, or waiting as in you'll write it when it does? :)
16:32:48 <nirik> I'll write it when it does. ;)
16:32:55 <nirik> If someone else wants to, feel free. ;)
16:33:42 <adamw> alrighty!
16:33:53 <adamw> #info nirik waiting on actual commit of the rawhide package change before updating the wiki
16:33:54 * jlaska joins another meeting ... lurking here
16:34:13 <adamw> okay, the only other thing on the agenda is a giant autoqa topic
16:34:27 <adamw> #topic autoqa: packaging/deployment
16:34:33 <adamw> jlaska: can you give us a quick packaging update before you go?
16:34:59 <jlaska> adamw: sure ...
16:35:10 <jlaska> the latest updates are on the wiki ...
16:35:48 <jlaska> I spent last week playing around with repackaging the current autotest-client package.  Long story short, I think it makes sense now to combine autotest and autotest-client
16:35:50 <adamw> jlaska: did you get the pointers from akurtakov?
16:35:53 <jlaska> into a single package
16:36:13 <jlaska> so with that in mind, that helps shift the focus over to the BuildRequires tasks ...
16:36:22 <jlaska> which is what adamw mentioned
16:36:45 <jlaska> Adam reached out to akurtakov for help identifying what's up with the remaining unknown bundled JAR files in the gwt package
16:36:52 <jlaska> #link https://fedoraproject.org/wiki/User:Jlaska/gwt
16:37:13 <jlaska> I'll be processing that feedback this week and hopefully removing the ''uncertain'' table altogether
16:37:25 <jlaska> once that's done ... it's package time
16:37:27 <adamw> akurtakov being someone who actually knows stuff about java :)
16:38:07 <jlaska> so that's where things are on the packaging front
16:38:15 <adamw> alrighty, thanks jlaska
16:38:35 <adamw> #info jlaska planning to combine autotest-client and autotest into one package this week, and continue to clean up the gwt packaging plan so we can get started on it
16:38:53 <adamw> #topic autoqa: dependency checking
16:39:00 <adamw> wwoods: take it away! where are we on depcheck?
16:40:31 <wwoods> it's, uh
16:40:31 <adamw> ...
16:40:34 <wwoods> it's a thing
16:40:36 <adamw> ooh there he is.
16:41:06 <wwoods> wheels are turning, but it's a complex problem with a lot of different possible approaches
16:41:37 <wwoods> and so I've got one mostly-functional prototype that I'm realizing has some shortcomings and I may need to try a different approach
16:42:04 <wwoods> to avoid writing (and thus having to maintain) a totally duplicate copy of the depsolving algorithm in my own code
16:42:39 <adamw> that would suck.
16:42:53 <wwoods> anyway the code I needed for the post-bodhi-update hook is apparently in bodhi now (thanks lmacken!)
16:42:56 <adamw> i realize this is probably me being stupid, but can't you just re-use yum's code?
16:43:04 <wwoods> adamw: no. that's part of the problem.
16:43:23 <wwoods> I mean. Parts of it, yes, but not all of it, and not directly.. it's complicated
16:43:55 <adamw> okay, that's good enough for me!
16:43:59 <wwoods> the yum API is designed to accomplish a certain set of tasks easily and efficiently - mostly, y'know, processing updates and removing packages and such
16:44:10 * adamw has terrifying visions of half-hour explanations he doesn't understand
16:44:24 <wwoods> so this task doesn't really line up easily with any of the stuff that yum currently provides.
16:44:45 <adamw> #info wwoods still not sure how to tackle the complex question of actual depcheck code: has one mostly-working prototype but making it fully-working is hard and may require a new approach
16:44:55 <adamw> is there anything anyone can help you with here?
16:44:58 <wwoods> it may turn out that I'll be adding some bits to yum, or it may turn out that I need to use the rpmlib stuff directly, or maybe I just need some yum code and some glue
16:45:06 <adamw> besides being a genius and going 'no, you fool, you should do it THIS way!'?
16:45:22 <wwoods> mostly I'm bugging skvidal (and will probably bother ffesti/panu/other rpm hackers) about how depsolving works/should work
16:45:51 <wwoods> unfortunately there's no obvious bit of this I could break off and ask someone to help with
16:46:11 <adamw> #info bodhi code required for the post-bodhi-update hook is now in bodhi
16:46:20 <wwoods> oh actually - if someone wants to look into the post-bodhi-update hook/watcher, that might be good
16:46:25 <adamw> #info wwoods working with skvidal and other rpm hackers to try and solve the depcheck problem
16:46:43 <wwoods> also if anyone has experience using rpmfluff (?) (maybe kparal?) to generate fake RPMs for test cases
16:46:43 <adamw> #info someone else could help take the load off wwoods by doing the post-bodhi-update hook
16:46:46 <adamw> any volunteers?
16:46:48 <wwoods> that would be really useful
16:47:13 <kparal> wwoods: I have created a few simple rpms, it was quite easy
16:47:23 <wwoods> kparal: is that code in the autoqa repo?
16:47:41 <kparal> wwoods: actually I think it is. rpmguard_test.py
16:48:09 <adamw> #info kparal has code for generating fake RPMs for testing in git as rpmguard_test.py
16:48:28 <wwoods> nice. I'll check that out.
16:48:33 <kparal> adamw: it's not even worth an info :)
16:48:37 <wwoods> heh!
16:48:48 <wwoods> nah, you're the first one to claim to know about it
16:48:53 <wwoods> now you're the resident expert!
16:48:58 <wwoods> congratulations!
16:49:13 <adamw> you still haven't figured out how this stuff works, have you kparal? :DD
16:49:16 <adamw> never volunteer!
16:49:20 <wwoods> heh
16:49:22 <kparal> :D
16:49:33 <adamw> okay i'm gonna cut you off there so we can get through everything else
16:49:37 * kparal is learning by mistakes
16:49:38 <wwoods> anyway yeah, depcheck progress is slowish but it's a big problem
16:49:52 <adamw> #topic autoqa: rpmguard and autoqa results collection
16:49:53 <wwoods> it seems that nobody else has stuck to it long enough to finish it off
16:50:06 * adamw applies glue to wwoods
16:50:06 <wwoods> so that's the goal: KILL IT DEAD
16:50:18 <adamw> alright, kparal - take it away, what's happening in the rpmguard world
16:50:58 <kparal> as for rpmguard, there is nothing truly new for the last week. I was attending the RHCT course (and passed :)), but didn't have time to improve rpmguard
16:51:47 <kparal> we have just found out that some packages can fly under our radar and not to be compared, but I don't know if that's not more than week old news
16:52:29 <kparal> here's the link: https://fedorahosted.org/pipermail/autoqa-devel/2010-January/000143.html
16:53:02 <adamw> congrats kparal!
16:53:23 <adamw> #info kparal discovered some packages can be missed by the rpmguard test
16:53:25 <kparal> the big step ahead would be the results database, what do you think, wwoods?
16:54:26 <wwoods> a results database would be really, really useful
16:54:34 <wwoods> but it's a pretty significant engineering effort
16:54:36 <adamw> right, that's under this topic too
16:54:50 <adamw> database...and associated server?
16:54:59 <kparal> not only useful but I think necessary, if we want to leverage the results somehow in the future
16:55:14 <kparal> and yes, it's certainly not an easy task
16:55:18 <wwoods> right. the tricky part is making it general enough to be useful for all our tests
16:55:26 <wwoods> but specific enough to hold all the info you need for every test result
16:55:36 <wwoods> it's a really tough problem to solve
16:55:37 <adamw> #info kparal and wwoods agree that an autoqa results database+server would be very useful
16:55:48 <wwoods> we should certainly talk more about design ideas
16:56:07 <wwoods> I definitely agree we need some way of aggregating/reviewing test data
16:56:23 <adamw> #info wwoods notes it would take significant engineering effort and also requires solving the problem of being general enough to useful for all possible autoqa tests but also handle all info for each specific test
16:56:44 <adamw> #action wwoods and kparal to talk about design ideas
16:56:50 <adamw> this feels like something you may want more people for, to me
16:56:56 <adamw> you're both pretty busy already
16:57:16 <wwoods> but there's a lot to consider - does it need to be able to link with/talk to bugzilla? trac? upstream bug trackers? get info from CVS/git? do we want this to wait for the QA Message Bus?
16:57:40 <kparal> I think we start to have useful tests in autoqa, the next problem would be to use the data collected. so I suppose we slow down now on test engineering effort and start working on this results database
16:57:41 <wwoods> I think we can talk about design goals now without getting too bogged down in implementation details
16:57:57 <wwoods> err, "now" meaning "in this timeframe" not "during this specific meeting"
16:58:30 <kparal> yes, our "now" is not really exactly now :)
16:58:31 <wwoods> there's a lot of planning work to do - but don't let that stop you from designing/setting up a prototype system
16:58:46 <wwoods> the JFDI methodology is useful here
16:59:05 <wwoods> and it helps make better plans if you've actually tried to build something similar before
16:59:05 * kparal googling
16:59:11 <wwoods> heh - "just fucking do it"
16:59:20 <adamw> alrighty we'll await next week's update with interest
16:59:25 <adamw> finally before open discussion:
16:59:31 <adamw> #topic autoqa: installation automation
16:59:46 <adamw> this is lili / rhe stuff - does someone have an update from them?
17:00:03 <kparal> adamw: it's on the wiki I suppose
17:00:22 <kparal> well, not exactly
17:00:33 <kparal> 2 bullets
17:01:00 <jlaska> I got a link to lili's latest script today, I'm going to reply with some feedback and encourage getting the content posted somewhere (git repo or branch)
17:01:53 <adamw> #info lili has continued to update the automated installation script, jlaska will ask him to upload the current work somewhere public
17:04:54 <adamw> okay
17:04:58 <adamw> i think that's everything on the agenda
17:05:01 <adamw> #topic open discussion
17:05:11 <adamw> bring yer topics here! anyone have anything else to discuss?
17:06:33 <adamw> ...i guess not
17:06:54 <jlaska> oh ... rawhide acceptance testing ...
17:07:33 * jlaska grabs a link
17:07:43 <adamw> #topic open discussion: rawhide acceptance testing
17:07:50 <adamw> oh yes that was going to happen last week
17:08:05 <adamw> #info there was supposed to be an installer image drop for rawhide testing on 2010-01-21
17:08:06 <adamw> right jlaska?
17:08:35 <jlaska> yup, so jkeating was able to pull an install source together and work around the glibc bug
17:08:48 <jlaska> with that ... I launched some rats_install tests at the new tree
17:08:50 <Oxf13> it happened, and we foudn bugs
17:08:51 <jlaska> http://jlaska.fedorapeople.org/rats-20100121.png has the latest results
17:09:34 <adamw> #link http://jlaska.fedorapeople.org/rats-20100121.png is all the shiny results
17:09:44 <adamw> so it sort of failed a bit! excellent.
17:09:55 <jlaska> yeah fail :(
17:10:30 <jlaska> we found an immediate issue, and then Hans from the installer team fixed it
17:10:33 <jlaska> [Bug 557588] File "/usr/lib/anaconda/iw/filter_gui.py", line 634
17:10:47 <jlaska> I pulled that fix into an updates.img and was testing again, but ran into some other issues
17:11:15 <jlaska> the link to alt.fp.org is also much slower after the move, so I need to check-in with infrastructure.
17:11:31 <Oxf13> infra has provided us with a second download site
17:11:34 <Oxf13> that syncs from alt
17:11:38 <adamw> #info installer team is working to fix the bugs exposed by the test
17:11:57 <jlaska> Oxf13: oh, so I should be using a different url?
17:12:00 <Oxf13> next time we do a drop we're going to measure the lag time of that second download site getting the content to gage whether or not this is a solution
17:12:03 <Oxf13> jlaska: we'll try next time
17:12:10 <jlaska> Oxf13: okay
17:12:19 <jlaska> Oxf13: same as last time, shall I submit a ticket to rel-eng for the compose
17:12:20 <Oxf13> infra is aware of the poor performance and has opened a ticket internally to RHT regarding this
17:12:22 <jlaska> ?
17:12:23 <Oxf13> yep
17:12:26 <jlaska> cool
17:12:33 <Oxf13> releng now has an SOP for how to deal with those tickets
17:12:35 <Oxf13> thanks to poelcat
17:12:58 <adamw> excellent
17:13:01 <adamw> any other business?
17:13:02 <jlaska> adamw: so that's all I had, just wanted to let folks know what happened, and the plan for this week
17:14:16 <adamw> alrighty then
17:14:19 <adamw> it's gavel-bangin' time
17:14:30 <adamw> thanks for coming everyone
17:14:51 <jlaska> adamw: thanks for driving :)
17:14:55 <adamw> #endmeeting