16:03:07 #startmeeting qa meeting 2010-01-25 16:03:07 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:03:28 good $TIMEZONE_APPROPRIATE_GREETING everybody 16:03:33 #topic gathering 16:03:36 who's around? 16:03:49 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 hey beland 16:05:46 alright then, let's get started with last week's review 16:05:57 #topic followup: xfce test day / 4.8 update 16:06:04 maxamillion: got anything for us on this? 16:06:27 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 well in a meeting context! 16:07:17 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 errr... concept of the 2 month release slip is being thrown around, but not definite yet 16:08:07 sorry ... trying to listen to $dayjob meeting while typing, I apparently didn't do that well 16:08:33 so the 2 month slip would be from when to when? 16:08:35 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 adamw: just a sec, lemme get a link 16:09:34 adamw: http://fedoraproject.org/wiki/Features/Xfce48 <--- if they have the 2 month slip, we will miss Fedora 13 16:09:58 it is currectly an agressive time line just to make F13 with them being on time 16:10:32 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 i guess the main issue for QA group is the test day, so planning on that has not advanced much? 16:11:40 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 so we'll be testing something, whether it's 4.8 or 4.6 will be decided later? 16:12:55 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 because in the world of xfce .. not a whole lot has changed 16:13:15 that's fine; you can just have a 'is everything still working okay' test day 16:13:23 nothing wrong with that 16:13:30 adamw: sounds good to me 16:13:44 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 oh yeah, definitely ... I was just hoping to have shiny new xfce features to test :D 16:14:13 =) 16:14:16 ok, thanks maxa 16:14:20 anything else on xfce anyone? 16:14:31 nothing from me 16:14:38 alrighty 16:14:59 #topic followup - bug documentation 16:15:06 jlaska / beland, this is yours 16:15:15 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 i think i missed that one... 16:15:24 yeah, I had an email in progress, but beland beat me to it :) 16:15:40 oh, just yesterday evening, haven't read it yet 16:15:43 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 I seemed to have a hard time deciding how to address documentation issues during previous releases 16:16:57 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 Just read James' reply...I guess it would be useful to hear opinions on whether the CommonBugs keyword is useful. 16:17:12 I don't hear any complaints, so I gather not 16:17:26 well james and I use it ourselves a lot, i dunno if it really gets used beyond that 16:17:47 I also use it to know when changes to a bug should get echoed back to the common bugs page... 16:17:57 Any particular reason you don't just add links to the wiki page instead? 16:18:53 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 beland: for what purpose? 16:19:37 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 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 s/or to in/or too in/ 16:20:14 Sounds like it's useful enough to justify the extra complication, then. 16:20:33 We should add links to the queries jlaska pointed out in his email, then. 16:21:24 beland: where would you prefer seeing those links, on the Common_Bugs wiki page? 16:21:38 Yeah. 16:22:06 If no objections, I can add those links at the end of #My_bug_is_not_listed 16:22:25 sounds good 16:22:39 damn sorry been forgetting my #info's, here we go 16:22:41 #action jlaska to add bugzilla shared query links to Common_Bugs wiki page 16:22:51 #info jlaska and beland working on the topic 16:23:02 jlaska: i don't think I chaired you, hand on 16:23:06 #action jlaska to add bugzilla shared query links to Common_Bugs wiki page 16:23:08 #chair jlaska 16:23:08 Current chairs: adamw jlaska 16:23:16 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 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 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 if anyone else would, great 16:24:22 No, I wouldn't include Common Bugs there. 16:24:26 oh, kay. 16:24:31 Just "formal documentation" that's off-wiki. 16:25:09 (stuff on docs.fedoraproject.org) 16:25:29 #info beland thinks filing bug reports to request notes be added to formal documentation is the best procedure 16:25:43 alright, so basically the update for this topic is that it's in progress and discussed on-list 16:25:56 is there anything else we need to discuss in the meeting context? 16:26:12 I don't think so, that's all I have on the topic 16:26:14 thanks beland :) 16:26:33 #action jlaska and beland to keep working on the process 16:27:01 #topic privilege escalation policy 16:27:11 okay, this one is me. so, as you probably saw on-list, I sent out a draft policy 16:27:22 and everyone has got involved in explaining why it sucks :) 16:27:40 i'll keep re-drafting until everyone agrees with more or has been bored into submission 16:27:45 s/more/me/ 16:28:09 once we have a good draft i'll take it back up to fesco 16:28:13 Whee! 16:28:21 is that process ok with everyone? 16:28:23 kudos for taking on this task ... its definitely a big one 16:28:39 I'm not fully up to speed on the updates over the weekend, but it seems to be moving forward 16:28:45 or does anyone feel they want to be more involved is this exciting and highly rewarding endeavour? :P 16:28:49 i read over it and have no objections 16:28:51 i haven't done squat over the weekend 16:29:00 but i'll pick up the latest mails today and send out a new draft 16:30:27 #info adamw still working on re-drafting the policy with much group feedback on mailing list 16:31:06 #topic followup: rawhide page update 16:31:24 this is for nirik, if you're around 16:31:37 I'm around... 16:31:39 nirik was planning to update the rawhide wiki page to reflect the changes to getting On The Bus 16:31:42 I'm waiting for the subpackage to land. 16:31:52 #link http://fedoraproject.org/wiki/Releases/Rawhide 16:32:06 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 I'll write it when it does. ;) 16:32:55 If someone else wants to, feel free. ;) 16:33:42 alrighty! 16:33:53 #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 okay, the only other thing on the agenda is a giant autoqa topic 16:34:27 #topic autoqa: packaging/deployment 16:34:33 jlaska: can you give us a quick packaging update before you go? 16:34:59 adamw: sure ... 16:35:10 the latest updates are on the wiki ... 16:35:48 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 jlaska: did you get the pointers from akurtakov? 16:35:53 into a single package 16:36:13 so with that in mind, that helps shift the focus over to the BuildRequires tasks ... 16:36:22 which is what adamw mentioned 16:36:45 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 #link https://fedoraproject.org/wiki/User:Jlaska/gwt 16:37:13 I'll be processing that feedback this week and hopefully removing the ''uncertain'' table altogether 16:37:25 once that's done ... it's package time 16:37:27 akurtakov being someone who actually knows stuff about java :) 16:38:07 so that's where things are on the packaging front 16:38:15 alrighty, thanks jlaska 16:38:35 #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 #topic autoqa: dependency checking 16:39:00 wwoods: take it away! where are we on depcheck? 16:40:31 it's, uh 16:40:31 ... 16:40:34 it's a thing 16:40:36 ooh there he is. 16:41:06 wheels are turning, but it's a complex problem with a lot of different possible approaches 16:41:37 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 to avoid writing (and thus having to maintain) a totally duplicate copy of the depsolving algorithm in my own code 16:42:39 that would suck. 16:42:53 anyway the code I needed for the post-bodhi-update hook is apparently in bodhi now (thanks lmacken!) 16:42:56 i realize this is probably me being stupid, but can't you just re-use yum's code? 16:43:04 adamw: no. that's part of the problem. 16:43:23 I mean. Parts of it, yes, but not all of it, and not directly.. it's complicated 16:43:55 okay, that's good enough for me! 16:43:59 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 so this task doesn't really line up easily with any of the stuff that yum currently provides. 16:44:45 #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 is there anything anyone can help you with here? 16:44:58 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 besides being a genius and going 'no, you fool, you should do it THIS way!'? 16:45:22 mostly I'm bugging skvidal (and will probably bother ffesti/panu/other rpm hackers) about how depsolving works/should work 16:45:51 unfortunately there's no obvious bit of this I could break off and ask someone to help with 16:46:11 #info bodhi code required for the post-bodhi-update hook is now in bodhi 16:46:20 oh actually - if someone wants to look into the post-bodhi-update hook/watcher, that might be good 16:46:25 #info wwoods working with skvidal and other rpm hackers to try and solve the depcheck problem 16:46:43 also if anyone has experience using rpmfluff (?) (maybe kparal?) to generate fake RPMs for test cases 16:46:43 #info someone else could help take the load off wwoods by doing the post-bodhi-update hook 16:46:46 any volunteers? 16:46:48 that would be really useful 16:47:13 wwoods: I have created a few simple rpms, it was quite easy 16:47:23 kparal: is that code in the autoqa repo? 16:47:41 wwoods: actually I think it is. rpmguard_test.py 16:48:09 #info kparal has code for generating fake RPMs for testing in git as rpmguard_test.py 16:48:28 nice. I'll check that out. 16:48:33 adamw: it's not even worth an info :) 16:48:37 heh! 16:48:48 nah, you're the first one to claim to know about it 16:48:53 now you're the resident expert! 16:48:58 congratulations! 16:49:13 you still haven't figured out how this stuff works, have you kparal? :DD 16:49:16 never volunteer! 16:49:20 heh 16:49:22 :D 16:49:33 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 anyway yeah, depcheck progress is slowish but it's a big problem 16:49:52 #topic autoqa: rpmguard and autoqa results collection 16:49:53 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 so that's the goal: KILL IT DEAD 16:50:18 alright, kparal - take it away, what's happening in the rpmguard world 16:50:58 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 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 here's the link: https://fedorahosted.org/pipermail/autoqa-devel/2010-January/000143.html 16:53:02 congrats kparal! 16:53:23 #info kparal discovered some packages can be missed by the rpmguard test 16:53:25 the big step ahead would be the results database, what do you think, wwoods? 16:54:26 a results database would be really, really useful 16:54:34 but it's a pretty significant engineering effort 16:54:36 right, that's under this topic too 16:54:50 database...and associated server? 16:54:59 not only useful but I think necessary, if we want to leverage the results somehow in the future 16:55:14 and yes, it's certainly not an easy task 16:55:18 right. the tricky part is making it general enough to be useful for all our tests 16:55:26 but specific enough to hold all the info you need for every test result 16:55:36 it's a really tough problem to solve 16:55:37 #info kparal and wwoods agree that an autoqa results database+server would be very useful 16:55:48 we should certainly talk more about design ideas 16:56:07 I definitely agree we need some way of aggregating/reviewing test data 16:56:23 #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 #action wwoods and kparal to talk about design ideas 16:56:50 this feels like something you may want more people for, to me 16:56:56 you're both pretty busy already 16:57:16 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 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 I think we can talk about design goals now without getting too bogged down in implementation details 16:57:57 err, "now" meaning "in this timeframe" not "during this specific meeting" 16:58:30 yes, our "now" is not really exactly now :) 16:58:31 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 the JFDI methodology is useful here 16:59:05 and it helps make better plans if you've actually tried to build something similar before 16:59:05 * kparal googling 16:59:11 heh - "just fucking do it" 16:59:20 alrighty we'll await next week's update with interest 16:59:25 finally before open discussion: 16:59:31 #topic autoqa: installation automation 16:59:46 this is lili / rhe stuff - does someone have an update from them? 17:00:03 adamw: it's on the wiki I suppose 17:00:22 well, not exactly 17:00:33 2 bullets 17:01:00 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 #info lili has continued to update the automated installation script, jlaska will ask him to upload the current work somewhere public 17:04:54 okay 17:04:58 i think that's everything on the agenda 17:05:01 #topic open discussion 17:05:11 bring yer topics here! anyone have anything else to discuss? 17:06:33 ...i guess not 17:06:54 oh ... rawhide acceptance testing ... 17:07:33 * jlaska grabs a link 17:07:43 #topic open discussion: rawhide acceptance testing 17:07:50 oh yes that was going to happen last week 17:08:05 #info there was supposed to be an installer image drop for rawhide testing on 2010-01-21 17:08:06 right jlaska? 17:08:35 yup, so jkeating was able to pull an install source together and work around the glibc bug 17:08:48 with that ... I launched some rats_install tests at the new tree 17:08:50 it happened, and we foudn bugs 17:08:51 http://jlaska.fedorapeople.org/rats-20100121.png has the latest results 17:09:34 #link http://jlaska.fedorapeople.org/rats-20100121.png is all the shiny results 17:09:44 so it sort of failed a bit! excellent. 17:09:55 yeah fail :( 17:10:30 we found an immediate issue, and then Hans from the installer team fixed it 17:10:33 [Bug 557588] File "/usr/lib/anaconda/iw/filter_gui.py", line 634 17:10:47 I pulled that fix into an updates.img and was testing again, but ran into some other issues 17:11:15 the link to alt.fp.org is also much slower after the move, so I need to check-in with infrastructure. 17:11:31 infra has provided us with a second download site 17:11:34 that syncs from alt 17:11:38 #info installer team is working to fix the bugs exposed by the test 17:11:57 Oxf13: oh, so I should be using a different url? 17:12:00 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 jlaska: we'll try next time 17:12:10 Oxf13: okay 17:12:19 Oxf13: same as last time, shall I submit a ticket to rel-eng for the compose 17:12:20 infra is aware of the poor performance and has opened a ticket internally to RHT regarding this 17:12:22 ? 17:12:23 yep 17:12:26 cool 17:12:33 releng now has an SOP for how to deal with those tickets 17:12:35 thanks to poelcat 17:12:58 excellent 17:13:01 any other business? 17:13:02 adamw: so that's all I had, just wanted to let folks know what happened, and the plan for this week 17:14:16 alrighty then 17:14:19 it's gavel-bangin' time 17:14:30 thanks for coming everyone 17:14:51 adamw: thanks for driving :) 17:14:55 #endmeeting