14:05:03 #startmeeting Beakerlib + AutoQA 14:05:03 Meeting started Tue May 18 14:05:03 2010 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:05:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:05:14 #meetingname beakerlib-and-autoqa 14:05:14 The meeting name has been set to 'beakerlib-and-autoqa' 14:05:34 #topic Gathering 14:06:07 okay, I think we've got the expected participants 14:06:11 afri: kparal: psss 14:06:18 are we missing anyone? 14:06:20 * kparal here 14:06:51 * psss here as well... 14:06:57 * afri here 14:06:57 I don't think so, they would ask where the meeting is if they wanted to come 14:07:22 kparal: heh, okay ... let's get started 14:08:03 for anyone not familiar with MeetBot (http://wiki.debian.org/MeetBot), I encourage excessive use of #info, #action, #link, #idea and #help 14:08:12 #help 14:08:27 no help for me :) 14:09:01 #topic Check-in on package review status 14:09:12 "Counter-intuitively, this doesn't provide help on the bot" -- ah, sorry 14:09:21 afri: you want to take it away? sounds like good updates on the review request? 14:09:46 kparal: I think you just put out a general call for assistance :) People in black suits will be arriving shortly 14:09:59 #info beakerlib was approved for fedora 14:10:08 yupee 14:10:21 * jlaska extends thanks to nirik and afri 14:10:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=561470 14:10:30 Bug 561470: medium, medium, ---, kevin, ASSIGNED, Review Request: beakerlib - shell-level integration testing library 14:10:35 i'm not sponsored yet, it seems 14:11:04 I guess it will arrive in F13 updates then? 14:11:34 I don't want to be rude, so I'll wait for a while and then I'll try to poke 14:12:21 afri: so once you've got FAS sponsorship, you'll be able to submit to CVS and do a build? 14:12:32 * jlaska refreshing on the steps outlined at https://fedoraproject.org/wiki/Package_Review_Process 14:12:47 jlaska, yeah 14:13:05 your @ step#8 I think 14:13:57 anything else to discuss here? 14:14:12 once packages are built and available, we'll probably need to update the autoqa scripts that rely on beakerlib? 14:14:31 to install from Fedora proper, and not the l33t afri package repo 14:14:58 I'll let you know when this happens 14:15:35 so you can fix the scripts 14:15:43 jlaska: yes, but it should be trivial 14:16:17 afri: kparal: okay 14:16:32 good stuff, nice to see the review behind us! 14:16:35 next up ... 14:16:43 #topic Initscript tests 14:17:06 The original link I have describing this topic is -- https://fedorahosted.org/pipermail/autoqa-devel/2010-March/000276.html 14:17:08 * kparal misses jskladan 14:17:17 jskladan is out sick today, so not sure what updates we have 14:17:47 well I know he worked on adding several dozens more test cases into that test 14:17:59 all re-taken from baseos team 14:18:04 Also, the current set of initscript tests are working nicely ... https://fedorahosted.org/pipermail/autoqa-results/2010-May/020018.html 14:19:33 what slowed him down a little is the need to report deficiencies in those scripts to their maintainers 14:19:45 apart from that they should be soon committed into git I believe 14:19:48 aha, do you recall what kind of trouble he was running into? 14:19:55 anything major? 14:20:23 well just the common stuff, scripts that don't reset services to their original state, etc 14:20:33 afaik 14:20:38 aha, yeah that one will definitely be critical for us! :) 14:20:53 kparal: you are also virtual 14:21:00 ... jskladan today 14:21:04 :) 14:21:29 no way, missing his python expertise 14:21:31 #info jskladan working several initscript issues with original maintainers 14:21:48 #info expecting a new round of initscript tests landing in git soon 14:22:05 are we tracking the initscript work in any way, I don't think it's attached to an existing roadmap 14:22:08 should it be? 14:22:28 * kparal looking 14:22:48 we don't have a milestone for that, true 14:23:11 any preference on creating a new milestone vs adding to "Package Update tests"? 14:23:21 or option #3) no milestone 14:23:27 I see just one opened ticket against iniscripts: https://fedorahosted.org/autoqa/ticket/125 14:23:46 maybe we can put it into Package update tests 14:24:20 I would do it like that 14:24:20 kparal: okay, I can take that. I'll sync up w/ jskladan when he gets back to see if he's tracking any other initscript plans as well 14:24:26 okay 14:24:57 #info probably add initscripts tickets to Package Update Tests milestone 14:25:04 #action jlaska will add jskladan's initscript changes to Package Update Tests (https://fedorahosted.org/autoqa/milestone/Package%20update%20tests) 14:25:16 * kparal too active 14:25:19 cool, anything else on this topic? 14:25:56 that's all I think 14:26:27 okay, the spot light moves to kparal ... 14:26:34 and psss of course :) 14:26:37 * kparal waves 14:26:40 #topic Package Sanity Tests 14:27:02 looks like you both have been busy, how are things going? 14:27:05 so, I have added useful links to https://fedoraproject.org/wiki/QA:Package_Sanity_Test_Plan#Links so you can find everything relevant quickly 14:27:36 psss has provided a basic version of the sanity test -- the 'pst' script 14:27:50 and I have recently added an AutoQA wrapper 14:28:14 so you can easily run that like this "autoqa post-koji-build --name tzdata --kojitag dist-f12-updates --arch x86_64 tzdata-2010i-1.fc12 -t package_sanity" 14:28:24 actually, it works :) 14:28:49 kparal: you seem surprised! :) 14:28:49 there are still many issues to solve, see the tickets 14:29:18 currently all the tickets are intertwined, some are reported against pst script itself, some against the wrapper 14:29:26 but I guess it's not really a problem 14:29:49 looks like a few might also be tightly coupled with wwoods post-bodhi-update work too? 14:30:05 they sure are 14:30:20 well, I guess just one (https://fedorahosted.org/autoqa/ticket/139) 14:30:47 that's the basic problem we hit with every other package update test 14:31:02 yeah 14:31:04 once that is solved, it will close multiple tickets 14:31:46 psss is now really busy with some perl security errata (ugh!), so has some tickets pending for proposed pst modifications, but they are not so important right now 14:32:08 there are still lots of thing to do on the autoqa side, like experiment with testing in virtualized guests, etc 14:32:26 kparal: psss: outside of the ticket work, any next big hurdle you want to discuss, or track, in the meeting for PST? 14:33:21 two big hurdles: 1) we must test packages on machine with correct Fedora release installed or use virt guests 14:33:35 2) the famous updates-candidate testing problem 14:33:44 that are the main issues I believe 14:33:48 now _infamous_ :) 14:34:20 #info Next hurdles - #1 we must test packages on machine with correct Fedora release installed or use virt guests 14:34:26 #info Next hurdles - #2 the famous updates-candidate testing problem 14:35:02 psss: anything from your side? 14:35:40 nothing extra... once, i'm finished with the perl errata, i'll try to start work on the remaining pst tickets... 14:36:11 alright, thanks for the updates :) 14:36:15 if nothing else ... open discussion time 14:37:10 just a question, once the beakerlib is in Fedora, the BaseOS team is going to use that or will there be still some modified internal version? 14:37:35 * kparal not sure if anyone can answer that :) 14:37:37 #topic open discussion - beakerlib EPEL? 14:37:49 kparal: they could also just also build it for EPEL 14:37:58 but certainly up to them, I guess 14:38:57 afri: any thoughts here? 14:38:57 i guess we'll be using the same BL, just built for rhel + our internal plugin 14:39:10 I was just think about some incompatibilities between upstream beakerlib and internal one, like the path (/usr/share and /usr/lib) 14:39:14 *thinking 14:39:53 once we have 50 initscripts in autoqa, every change means it is more difficult to maintain :) 14:40:02 *initscripts tests 14:40:11 alright, fine, thanks 14:40:18 jlaska, we are using the identical beakerlib in RHTS, just rebuilt for RHEL5 14:40:31 about the paths: all new tests should use the new /usr/share path... 14:40:49 and perhaps the internal plugin will still have the backward compat link? 14:40:58 BL knows plugins, so we added a plugin rpm, which contains a RH internal stuff, as well as the compatibility symlinks 14:41:09 so we keep the incompatibilities just inhouse 14:41:42 but that also means that maintainers are not forced to fix the scripts for upstream :) 14:41:44 ah clever, are you planning on having that included in the fedora src.rpm, but just disabled from building in Fedora? 14:42:44 we will have to have some other session thinking about the collaboration between baseos initscript tests maintainers and our "upstream" versions 14:42:48 not planning to do so, it's a mess 14:43:16 I would prefer to do a massive scripted test-update 14:44:00 okay, so 2 topics discussed here 14:44:16 #info discussed how to update existing tests to use new paths (e.g. /usr/share/... instead of /usr/lib) 14:45:14 #info discussed future maintenance of beakerlib (how best to manage maintaining custom plug-ins and Fedora package) 14:45:53 kparal: afri: should we queue this up for a future topic? 14:46:26 yes, info 2 is not a hot issue now, but it will become once we have dozens of tests inside autoqa 14:46:48 so it's just a prospective topic 14:47:18 there are several packages that manage to have a single source housed in Fedora, but allow for extra plugins to build when built against RHEL 14:47:24 I think 'report' is a recent example 14:47:33 I don't think the maintenance of beakerlib is an issue 14:47:58 okay 14:48:18 #topic open discussion - 14:48:31 Anything else to discuss today? 14:48:33 I will maintain 1) fedora version 2) internal plugin - this doesn't make sense to be upstream, it contains some infrastructure details 14:48:53 afri: okay, sounds good 14:48:55 we generally try to have everything possible in fedora version 14:50:24 afri: yeah, I wasn't trying to tell you how to do it, just offering suggestions in case that makes the package maintenance any easier 14:50:36 but it sounds like you've got that well under control! 14:50:52 okay, no new topics ... let's end the meeting 14:51:01 #topic Next meeting 14:51:15 Any suggestions here? 14:51:38 I think just to review current status of all the stuff 14:51:39 we can stick to the usual schedule, email check-in next week, and another meeting on Tuesday, June 1 14:51:50 ah, the time 14:52:26 as you prefer, I'm good with it 14:52:43 okay, we'll check-in over email next week ... and see how things go from there 14:53:10 afri: psss: any preference ... more frequent, less frequent? 14:53:31 jlaska, I'm ok with current way 14:53:47 usual time/schedule fine for myself 14:53:53 okay, thanks folks 14:54:12 #info 2010-05-25 - Check-in over email (perhaps autoqa-devel@ list) 14:54:39 #info 2010-06-01 - Celebrate the first of June with another in-person meeting 14:54:45 Okay, that's all I've got 14:54:47 thanks everyone 14:54:51 #endmeeting