16:00:14 <jlaska> #startmeeting Fedora QA Meeting
16:00:14 <zodbot> Meeting started Mon Mar  1 16:00:14 2010 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:18 <jlaska> #meetingname fedora-qa
16:00:19 <zodbot> The meeting name has been set to 'fedora-qa'
16:00:32 <jlaska> #topic Gathering critical mass
16:00:49 * tk009 listens in
16:00:54 * kparal 
16:01:09 <jlaska> greetings tk009 and kparal
16:02:00 <jlaska> maxamillion: howdy
16:02:26 <jlaska> is adamw coherent after yesterday?
16:02:43 * Viking-Ice takes a break from his daily activate from securing world domination and drops in..
16:02:51 <jlaska> Viking-Ice: welcome
16:03:03 <Viking-Ice> and by activate I activity
16:03:19 <Viking-Ice> ken lee strikes again..
16:03:34 <jlaska> wwoods around?
16:03:59 <jlaska> I see jskladan lurking too
16:04:08 * jskladan here
16:04:22 <maxamillion> jlaska: hi hi
16:04:31 <jlaska> greetings gents
16:04:44 <jlaska> alright, hopefully adamw and wwoods will join ... let's get started
16:05:00 <jlaska> #link http://lists.fedoraproject.org/pipermail/test/2010-March/088873.html
16:05:04 <Viking-Ice> adamw is probably wasted somewhere wearing the Canadian mascot uniform with empty keg and the gold..
16:05:07 <jlaska> that's the proposed agenda
16:05:14 <jlaska> Viking-Ice: hopefully not passed out in a street somewhere :)
16:05:23 <jlaska> #topic Previous meeting follow-up
16:05:51 <jlaska> well, the hot news last week was the Alpha, so that may impact the items we were tracking
16:05:58 <jlaska> maxamillion, you're first up
16:06:02 <jlaska> #info maxamillion to draft up some proposed policy docs for qa FAS group membership
16:06:18 <maxamillion> ok, so I kinda ran with this a little ...
16:06:23 <jlaska> any progress or challenges on this front?
16:06:37 <maxamillion> I'm proposing calling those who are members of the group be called "Critical Path Wranglers"
16:06:49 <maxamillion> http://lists.fedoraproject.org/pipermail/test/2010-February/088824.html <--- I sent this email last Friday
16:07:05 <maxamillion> https://fedoraproject.org/wiki/QA/JoinCriticalPathWranglers:Draft <--- here is my proposal (in *very* rough draft form)
16:07:15 <jlaska> nice!  that totally slipped under my mail radar
16:07:42 * jlaska hopes meetbot includes those links
16:07:51 <maxamillion> I think you have to #link them
16:08:08 <jlaska> #link http://lists.fedoraproject.org/pipermail/test/2010-February/088824.html
16:08:14 <jlaska> #link https://fedoraproject.org/wiki/QA/JoinCriticalPathWranglers:Draft
16:08:20 <maxamillion> :)
16:08:46 <jlaska> maxamillion: great stuff!  Thanks for taking the lead, I'll queue that up for feedback on my end
16:08:55 <jlaska> maxamillion: anything you wanted to call out in the meeting?
16:09:07 <maxamillion> jlaska: nothing specific, just looking for feedback :)
16:09:10 <tk009> I'd like to ask a questions
16:09:16 <tk009> I see pick a entor
16:09:16 <maxamillion> tk009: fire away
16:09:19 <tk009> mentor
16:09:28 <tk009> do you already have entors lined up?
16:09:33 <tk009> grr m key
16:09:51 <tk009> mentors lined up that should have read
16:10:01 <maxamillion> tk009: no, that's the parth is FIXME ... I think we need to discuss that actually
16:10:39 <tk009> mentors can be hard to come by but make a huge difference
16:10:51 <maxamillion> I think that any member of the QA FAS group or "Critical Path Wranglers" should be a potential mentor but it will simply be a "case by case" situation ....
16:11:28 <jlaska> maxamillion: do some groups document mentor responsibilities?
16:11:44 <maxamillion> jlaska: uhmm.... honestly not sure
16:11:53 <maxamillion> but that would be something we would probably need to outline
16:12:00 <tk009> there is a fedora mentor group I think
16:12:04 <Viking-Ice> So we are going to reactivate the QA group (:
16:12:21 <maxamillion> Viking-Ice: yeah, its part of the no frozen rawhide bit
16:12:30 <jlaska> Viking-Ice: yeah, we now have a reason too
16:13:08 <jlaska> maxamillion: so should we keep this on the agenda for next week ... and work feedback on the list in the meantime?
16:13:41 <maxamillion> jlaska: I think that's a good idea and I think I might follow up this week with asking for some input from the http://fedoraproject.org/wiki/Mentors group
16:14:02 <jlaska> #info mailing list feedback throughout the week
16:14:29 <jlaska> #action maxamillion seeking input from the http://fedoraproject.org/wiki/Mentors group for guidance on mentor responsibilities
16:14:37 <jlaska> maxamillion: just an idea, I dunno if that's a requirement or not
16:14:55 <jlaska> nice work, thanks again for owning this
16:15:01 <maxamillion> jlaska: I think its a good path to follow, none better to ask for input than those who currently do :)
16:15:12 <maxamillion> thanks, np!
16:15:23 <jlaska> okay next item ...
16:15:36 <jlaska> #info jlaska / maxamillion to co-ordinate with sectool test day hosts tmraz, mbarabas and pvrabec who may be able to contribute
16:15:53 <jlaska> maxamillion: I'll fire this off after the meeting today ... apologies for delay
16:15:59 <maxamillion> jlaska: no worries
16:16:32 <maxamillion> I unfortunately admit that it slipped my mind :/
16:16:59 <jlaska> maxamillion: I'll pull them in to see if they have any thoughts to share from their sectool work
16:17:24 <jlaska> alright ... that's all I had from last week
16:17:26 <maxamillion> sounds good!
16:17:34 <jlaska> anything else to cover before talking about F-13-Alpha?
16:17:49 <maxamillion> not that I can think of ....
16:18:04 <jlaska> alrighty ... moving on, stop me if there's more to discuss
16:18:12 <jlaska> #topic F-13-Alpha-RC4 test status
16:18:12 <maxamillion> will do
16:18:22 * maxamillion queues up things to throw at jlaska
16:18:28 <maxamillion> :)
16:18:36 <jlaska> maxamillion: aim high please
16:18:40 <maxamillion> lol
16:18:50 <jlaska> maxamillion: and don't ask Viking-Ice to shoot ... he's too accurate
16:19:07 <jlaska> #info Alpha RC#4 is available for testing. Instructions for downloading and providing feedback available on the wiki at ...
16:19:13 <jlaska> #link https://fedoraproject.org/wiki/Test_Results:Fedora_13_Alpha_RC4_Install
16:19:17 <jlaska> #link https://fedoraproject.org/wiki/Test_Results:Fedora_13_Alpha_RC4_Desktop
16:19:22 <maxamillion> on the topic of the F-13-Alpha-RC4 stuff, I had some internet troubles at home this weekend and wasn't able to pull down an image to do some testing on for Xfce but am going to try and get that done today
16:19:53 <jlaska> maxamillion: much appreciated, I see we have some KDE results now also
16:20:15 <jlaska> a hardy thank you to everyone for pitching in on testing last week (and prior)
16:20:49 <jlaska> An Alpha test summary should be going out later this week ... but my view of the blocker list shows 2 items
16:21:08 <jlaska> .bug 567346
16:21:11 <zodbot> jlaska: Bug 567346 gpk-update-viewer does not display changelogs nor updates packages - https://bugzilla.redhat.com/show_bug.cgi?id=567346
16:21:14 <jlaska> and ...
16:21:16 <jlaska> .bug 569377
16:21:19 <zodbot> jlaska: Bug 569377 CDROM install unable to eject disc - storage: error ejecting cdrom sr0: (5, 'Input/output error') - https://bugzilla.redhat.com/show_bug.cgi?id=569377
16:21:45 <jlaska> with regards to 567346 - kparal and jskladan noted that this might only occur when there are deps issues present in the repos?
16:22:05 <kparal> jlaska: just testing it now. and I believe so
16:22:19 <jlaska> kparal: that's a great data point
16:22:33 <jlaska> I'll try that after the meeting as well
16:22:55 <jlaska> #action continued testing of bug#567346 to further isolate the failure conditions
16:23:26 <kparal> jlaska: I have today added two bugs into the matrix: https://fedoraproject.org/wiki/Test_Results:Fedora_13_Alpha_RC4_Desktop
16:23:30 <jlaska> With regards to bug#569377, I've only hit this on bare metal CDROM installs, which technically affect the Beta criteria
16:23:32 <kparal> jlaska: but didn't mark them as blockers
16:23:40 <jlaska> kparal: okay, let's review them ...
16:23:47 <kparal> https://bugzilla.redhat.com/show_bug.cgi?id=569352
16:23:51 <kparal> https://bugzilla.redhat.com/show_bug.cgi?id=569355
16:24:00 <jlaska> .bug 569352
16:24:02 <zodbot> jlaska: Bug 569352 Broken dependencies for 1:openoffice.org-langpack-en-3.2.0-12.7.fc13.x86_64 - https://bugzilla.redhat.com/show_bug.cgi?id=569352
16:24:11 <jlaska> .bug 569355
16:24:13 <zodbot> jlaska: Bug 569355 Broken dependencies for 2:gimp-2.6.8-4.fc13.x86_64 - https://bugzilla.redhat.com/show_bug.cgi?id=569355
16:24:39 <jlaska> kparal: I wonder if that first issue is something funky with the langpack plugin?  I was experiencing similar funkiness during last weeks langpack test day
16:24:56 <kparal> jlaska: I will try to disable the plugin
16:25:14 <jlaska> the gimp bug seems to be fixed already, that was fast
16:25:35 <kparal> should we mark the first one as blocker?
16:25:53 <Viking-Ice> I installed the depended oo-core --nodeps from koji then updated without a hitch
16:26:12 <jlaska> kparal: according to the Alpha criteria, deps and conflicts issues are limited to the media kit
16:26:30 <jlaska> eeew --nodeps ... bad Viking-Ice :
16:26:31 <jlaska> :)
16:26:31 <kparal> alright then
16:26:38 <Viking-Ice> hehe
16:26:56 <jlaska> kparal: but if it's something more pervasive with yum-langpack ... that might change things ... let's keep working it
16:26:58 * skvidal sighs - I have a dream of a world where the rpmdb records when people do stuff like that
16:27:14 <jlaska> skvidal: and emails their personal information to a public mailing list?
16:27:22 <skvidal> jlaska: or just threatens their pets
16:27:30 <skvidal> :)
16:27:32 <jlaska> skvidal: fine choice
16:27:39 <Viking-Ice> skvidal: already shoot mine
16:27:55 <skvidal> everytime you use --nodeps we kick your dog
16:28:09 <jlaska> we'll save continued discussion on this topic for #fedora-peta
16:28:15 <Viking-Ice> thank good it aint my balls..
16:28:26 <skvidal> yes
16:28:30 <skvidal> sorry for the interruption
16:28:35 * skvidal goes back to lurking
16:28:38 <jlaska> hehe
16:28:54 <jlaska> kparal: thanks for the updated bugs
16:29:02 <jlaska> those are all the issues on the radar at this time
16:29:12 <jlaska> any other Alpha show stoppers folks want to bring up?
16:29:21 <Viking-Ice> there was an install issue with anaconda
16:29:31 <Viking-Ice> next next done
16:29:38 <jlaska> Viking-Ice: ?
16:29:46 <Viking-Ice> failed custom worked..
16:29:53 <jlaska> got a bz or mailing list link?
16:29:54 * Viking-Ice goes looking for the bug report
16:29:57 <jlaska> okay
16:31:28 <Viking-Ice> .bug 567840
16:31:30 <zodbot> Viking-Ice: Bug 567840 LVMError: lvdeactivate failed for lv_swap: LV VolGroup/lv_swap in use: not deactivating - https://bugzilla.redhat.com/show_bug.cgi?id=567840
16:31:43 <jlaska> Viking-Ice: ah
16:32:04 <jlaska> Viking-Ice: that is marked as resolved in RC#4, are you still hitting it?
16:32:38 <jlaska> Viking-Ice: there is an unresolved bug affecting partitioning on a system that already has encrypted partitions
16:32:42 <jlaska> .bug 565848
16:32:43 <zodbot> jlaska: Bug 565848 LVMError: lvactivate failed for lv_root: Skipping volume group vg_test1148 - https://bugzilla.redhat.com/show_bug.cgi?id=565848
16:32:52 <jlaska> that's on the list for F13Beta at the moment
16:33:26 <Viking-Ice> .bug 567840 sorry wrong number..
16:33:26 <wwoods> is that the "LVM + 512MB = kaboom" bug
16:33:28 <zodbot> Viking-Ice: Error: '567840 sorry wrong number..' is not a valid integer.
16:33:35 <Viking-Ice> .bug 567840
16:33:37 <zodbot> Viking-Ice: Bug 567840 LVMError: lvdeactivate failed for lv_swap: LV VolGroup/lv_swap in use: not deactivating - https://bugzilla.redhat.com/show_bug.cgi?id=567840
16:33:51 <wwoods> ah 'kay
16:34:01 <Viking-Ice> sorry it's the same number lol
16:34:19 <jlaska> wwoods: oh good call, that might be
16:34:31 <maxamillion> jlaska: I have to run, I'll catch the rest on the mailing list from the minutes
16:34:58 <Viking-Ice> I need to retest with anaconda-13.32-1.fc13
16:35:03 <jlaska> maxamillion: thanks!
16:35:33 <jlaska> I can't find the bz at the moment ... but 512M (and even 768M) of memory are no longer sufficient for x86_64 installs
16:35:49 <jlaska> .bug 559290
16:35:53 <zodbot> jlaska: Bug 559290 LVMError: lvcreate failed for VolGroup/lv_root - 512M insufficient for Fedora install - https://bugzilla.redhat.com/show_bug.cgi?id=559290
16:36:07 <jlaska> Viking-Ice: okay, we'll stay tuned to the blocker list for updates on that
16:36:11 <kparal> I have installed RC4 64bit with 768M
16:36:26 <jlaska> kparal: I've had luck with 768M also
16:36:39 <jlaska> I think adamw might have had issues w/ 768M in a live install ... not sure
16:37:01 <kparal> yes, the live install will probably need more
16:37:03 <Viking-Ice> well my laptop is i686 and has gig memory
16:37:13 <jlaska> definitely the previous documented minimum is insufficient  (http://docs.fedoraproject.org/release-notes/f12/en-US/html/index.html#sect-Release_Notes-Hardware_Requirements)
16:37:24 <jskladan> and i have RC4 64 bit up&running in KVM with 512M RAM :-D lucky me i guess :)
16:37:31 <jlaska> jskladan: using LVM?
16:37:41 <jskladan> but i did not install from livecd, thats true
16:37:58 <jskladan> i think so, i just went next next finish in installer
16:38:05 <jlaska> jskladan: wow, you are lucky then! :D
16:38:19 <jlaska> alright gang, we'll stay tuned to the blocker list for more updates
16:38:39 <jlaska> wanted to highlight a BugZappers meeting item ...
16:38:48 <jlaska> #topic Development/13 bug closure
16:38:53 <jlaska> tk009: still around?
16:38:55 <tk009> yes
16:39:14 <tk009> adamw was leading this item
16:39:17 <jlaska> tk009: Hey!  I just wanted to highlight what you guys discussed in last weeks bugZappers meeting
16:39:25 <tk009> however
16:39:26 <tk009> =)
16:40:06 <jlaska> it looks like adamw has some follow-up items, but the decision was to close Fedora 13 bugs (aka development/13) as CLOSED ERRATA right?
16:40:24 <tk009> correct
16:40:36 <tk009> and we are going to rebase all rawhide bugs to f13
16:40:48 <tk009> it should have been done already
16:40:49 <jlaska> excellent!
16:41:08 <jlaska> so for any questions or concerns, please join the BugZappers meeting tomorrow
16:41:23 <jlaska> #link https://fedoraproject.org/wiki/BugZappers/Meetings
16:41:34 <tk009> however fail on mine and adamws part. I will get with poelcat today once the wiki stuff is done to get with redhat eng for the rebase
16:41:34 <jlaska> #info the decision was to close Fedora 13 bugs (aka development/13) as CLOSED ERRATA
16:41:51 <jlaska> #info going to rebase all rawhide bugs to f13
16:42:04 <jlaska> #info Continued discussion during next BugZappers meeting
16:42:16 <jlaska> tk009: nice, thanks for the updates
16:42:46 <jlaska> alright, last planned topic was a brief check-in with everyone on autoqa ...
16:42:49 <jlaska> #topic AutoQA updates
16:43:09 <jlaska> wwoods, I've got you up first for your patch/devel policy thread
16:43:24 <jlaska> #info wwoods posted a development/patch policy proposal - https://fedorahosted.org/pipermail/autoqa-devel/2010-February/000224.html
16:43:45 <wwoods> ah, okay. yes, I sent a mail to autoqa-devel with some proposed guidelines for autoqa development
16:44:16 <wwoods> the summary: 1) hooray for git, 2) if you have small patches, send them with git-send-email if possible
16:44:39 <wwoods> 3) if you have bigger changes, either clone the repo and send a patch set from your local branch
16:44:52 <wwoods> or ask and we'd be happy to help you make a personal branch in the public repo
16:45:13 <wwoods> and 4) wwoods is the maintainer/patchmaster for the 'master' branch, which represents our current production code
16:45:41 <wwoods> (although I happily delegate responsibility for applying patches to jlaska + kparal sometimes)
16:46:34 <wwoods> there hasn't been much controversy about the plan - and I've talked about it a bit with some folks who are more familiar with git-based development (e.g. kernel guys)
16:46:34 <jlaska> wwoods: you okay with being the master patch delegator?
16:46:35 <kparal> which was my question, if the delegation happens according to your (e.g. time) needs or we can judge by ourselves
16:46:54 <wwoods> kparal: assume that I'll handle all the patches, but if I get swamped I'll ask for help
16:47:11 <wwoods> at the same time, feel free to poke me if I seem to have dropped/lost an important patch
16:47:21 <kparal> wwoods: ok. I don't have a problem with the policy, I just want to understand it, so not to break it from the start :)
16:47:57 <wwoods> I'll freely admit that I'm probably going to forget or drop patches at some point, and I'd therefore like to be reminded of them if they're important
16:48:16 <jlaska> I see ping's on anaconda-devel-list for that sort of thing from time to time
16:48:17 <wwoods> probably it'll be like: "dude will you forgot this patch and it's really important"
16:48:19 <kparal> wwoods: and second suggestion was about private branches, imho it's easier if people create their own and publish it on e.g. fedorapeople, but you added that to the description above
16:48:24 <wwoods> "aw crap sorry, go ahead and apply that"
16:48:51 <wwoods> kparal: right - either they can have a local one and send patches/patchsets from that, they can publish their copy on their fedorapeople page
16:49:13 <wwoods> or if it's an ongoing process where they're constantly sending patches and merge requests it might make sense to keep their branch in the autoqa repo
16:49:23 <kparal> sure, ok
16:49:41 <wwoods> but yes, the fedorapeople suggestion is a good one
16:49:59 <wwoods> do you have a link to some instructions about the best way to publish a git repo on your fp page?
16:50:03 * jlaska once I clear out my local changeset ... I'll queue up a remote git branch
16:50:35 <jlaska> #link https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org#BETA_git_hosting_support
16:50:57 <kparal> aw, jlaska was faster
16:51:02 <kparal> as always
16:51:07 <jlaska> kparal: nah, thank my firefox
16:51:28 <wwoods> nice, thanks
16:51:30 <jlaska> kparal: want me to add that link to the patch process wiki page?
16:51:43 <kparal> I think it's needed when you want to have "git://" access. but any http server is good enough
16:51:59 <jlaska> #action jlaska - update [[AutoQA_PatchProcess]] to include fedorapeople.org git repo
16:52:03 <jlaska> kparal: okay
16:52:08 <wwoods> so yeah, that's the policy. it all seems sound, so probably it will get put in the autoqa trac wiki and/or fp.o wiki.. somewhere
16:52:29 <kparal> autoqa trac wiki sounds good
16:52:53 <jlaska> We've got patch submission and branching currently documented at https://fedoraproject.org/wiki/AutoQA_PatchProcess
16:53:00 <jlaska> but I can easily adjust or
16:53:06 <jlaska> move the content if needed
16:53:26 <kparal> I think it can coexist, it can just reference the policy
16:53:29 <jlaska> okay
16:53:35 <jlaska> alright, next topic?
16:53:39 <wwoods> sure
16:53:55 <jlaska> wwoods: I've got you for an encore show ...
16:54:03 <jlaska> what's the latest on the depcheck front?
16:54:18 <jlaska> #topic AutoQA updates - depcheck
16:54:23 <wwoods> no change - been working on other things
16:54:32 <jlaska> something called an Alpha I hear?
16:54:43 <wwoods> the current status is.. there's a working, yum-based depcheck script
16:55:04 <wwoods> it needs some basic testing but since it's using the yum code for its depsolving, and yum has its own set of unit tests for depsolving
16:55:14 <wwoods> we can assume that it's correctly depsolving the packages given
16:55:23 <wwoods> or at least doing it wrong in exactly the same way that yum does
16:55:25 <jsmith> wwoods: Link to said script?
16:55:33 <jlaska> #info there's a working, yum-based depcheck script in git
16:55:40 <kparal> :))
16:55:41 <wwoods> http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=tests/depcheck/depcheck
16:56:43 <wwoods> here's where things get complex: now that we have an algorithm to test, we need to figure out *what* to test
16:57:02 <wwoods> just testing every new build/update *by itself* will not work
16:57:36 <wwoods> we need some way of batching the new builds/updates and testing them as a group
16:57:56 <jlaska> wwoods: this is for updates from different src.rpm's that are dependent?
16:57:57 <wwoods> until the proposed group is proven to be closed with respect to the existing published repos
16:58:05 <wwoods> correct
16:58:30 <wwoods> handling this might require some changes to bodhi/koji
16:58:51 <wwoods> to have an intermediate tag to hold the pending/proposed new updates/builds
16:59:07 <wwoods> until such time as they pass depcheck and can actually be cleared for pushing
16:59:23 <wwoods> it requires some careful thought and testing and I haven't had time for it recently
16:59:34 <wwoods> hoping to get back to it.. this week, maybe
17:00:06 <jlaska> is this something you'd need to pull rel-eng into, or is this head down / loud music time?
17:00:49 <wwoods> the latter; it might prove to be easiest to keep the list of pending/held updates internal to autoqa
17:00:50 <kparal> wwoods: I think the "tag to hold" will go along with the prepared policy to do autoqa testing for each new package
17:01:35 <jlaska> kparal: indeed!
17:01:47 <wwoods> kparal: true - a good policy probably requires an intermediate tag between fresh, untested builds and stuff that passes autoqa
17:02:04 <jlaska> wwoods: okay, so just keep this is a regular check-in next week?
17:03:29 * wwoods a little confused
17:03:38 <wwoods> yeah, a checkin on this next week would be a good idea
17:03:40 <jlaska> #info testing multiple dependent packages still needs some careful thought
17:03:47 <jlaska> wwoods: sorry, yup that's what I meant
17:04:04 <jlaska> wwoods: thanks for the updates
17:04:14 <jlaska> #topic AutoQA updates - resultsdb
17:04:57 <jlaska> kparal, you want to give an update on this front?
17:05:00 * maxamillion is back
17:05:16 <kparal> ok, so, we had another discussion about the concepts of autoqa resultsdb
17:05:48 <kparal> I have started to write some use cases that could be helpful when designing the resultsdb
17:06:01 <kparal> nothing there yet, but it will be at https://fedoraproject.org/wiki/AutoQA_resultsdb_use_cases
17:06:33 <kparal> I have something drafted already, but I found out that it is very often about autoqa itself, not about resultdb per say :)
17:06:34 <jlaska> #info Another design discussion held last week - https://fedorahosted.org/pipermail/autoqa-devel/2010-February/000234.html
17:06:44 <kparal> *per se
17:07:04 <jlaska> I've got some nitrate feedback to provide this week
17:07:10 <kparal> great
17:07:23 <kparal> and jskladan started some drafting of db schema
17:07:36 <jskladan> and i made i draft of DB scheme from kamil's an mine thoughts - available here http://jskladan.fedorapeople.org/dbschema.png http://jskladan.fedorapeople.org/dbschema.dia
17:08:01 <kparal> it will be also available somewhere on wiki and announced on autoqa-devel
17:08:31 <jlaska> nice, so we're doing a mailing list checkin on Friday again?
17:08:46 <kparal> we still have to discuss it, I had not much time to go through it
17:08:50 <kparal> jlaska: yes we can
17:09:15 <jskladan> the division  to "resultdb" and "TCMS?" is made mainly for the sake of "dividing information" - i think, that the resultdb part is completely satisfactory for storing results
17:09:25 <jskladan> but one might like to have some metadata on tests
17:09:55 <jskladan> (that's the tcms part of the sheme)
17:10:23 <jlaska> jskladan: I see, thanks.  I'd be curious how that lines up to what israwhidebroken uses now
17:11:06 <jlaska> in the interest of time, shall we move to the next topic?
17:11:15 <jskladan> haven't seen it yet (or it sliped my mind), so i do not know - any link? :)
17:11:21 <jlaska> kparal: jskladan anything else to highlight before Friday?
17:11:33 <jskladan> we can move on IMO
17:11:36 <kparal> that would be all
17:11:38 <jlaska> jskladan: jskladan http://git.fedorahosted.org/git/?p=autoqa.git;a=tree;f=front-ends/israwhidebroken;h=382dbdc09ac06415b6211f60c196273ebbf18743;hb=HEAD
17:11:46 <jlaska> thanks for the updates gang
17:11:49 <jskladan> jlaska: thx
17:11:52 <jlaska> #topic AutoQA - beakerlib
17:12:14 <jlaska> jskladan: I left this on the agenda, but not sure if there were any updates/concern you wanted to share
17:12:32 <jskladan> OK, last week i somehow finished the initscript checking thingie
17:12:43 <jskladan> but since then nothing new
17:13:05 <jskladan> i only spoke with benl about licenses
17:13:16 <jskladan> of the tests we'd like to re-use
17:13:30 <jlaska> Anything you want to track for the next meeting?
17:13:43 <jskladan> and he pointed out, that legal might have to revise the licenses and stuff
17:13:50 <jskladan> before pushing stuff upstream
17:14:05 <maxamillion> I might have come into this too late, but could there be something like "chain-test" that is similar to "chain-build" in koji?
17:14:17 <maxamillion> nvm, that was an old topic
17:14:26 * maxamillion was still scrolled up like a noob
17:14:35 <jlaska> maxamillion: no worries
17:14:48 <jlaska> jskladan: okay, we'll keep that on the radar
17:15:16 <jlaska> #topic AutoQA - install automation
17:15:18 <jskladan> that's all from me on this
17:15:36 <jlaska> jskladan: thanks, I'm already keeping you guys late, so I'm moving fast now :)
17:15:56 <jlaska> Folks on autoqa-devel probably saw this, but Liam is making good progress with the dvd install automation script
17:16:00 <jlaska> #link https://fedorahosted.org/autoqa/ticket/107#comment:4
17:16:26 <jlaska> the big change is the use of dogtail to automate passing kernel boot arguments to the DVD install
17:16:42 <jlaska> in addition to more test case cleanups
17:17:15 <jlaska> I spoke with Liam this morning (evening) and he's going to look into having the script prepare the at-spi (and X) environment needed for testing ... instead of relying on an existing root desktop session
17:17:24 <jlaska> and last up ...
17:17:42 <jlaska> #topic AutoQA - packaging
17:17:51 <jlaska> #info no updates
17:17:59 <wwoods> man, automating media-based installs is pretty huge
17:18:04 <jlaska> wwoods: and painful! :)
17:18:32 <jlaska> nothing great to share on the packaging front ... I'm working some other approaches to try and get some focused packaging time to knock this out in batch
17:19:06 <jlaska> I'm waiting to hear back from Max, but I think this would make a good FAD session
17:19:30 <jlaska> so hopefully I'll have more to share on that next week
17:19:36 <jlaska> alright ... that's all for AutoQA
17:19:42 <jlaska> open topic time ...
17:19:50 <jlaska> #topic Open Discussion - <your topic here>
17:20:09 <jlaska> Anything to discuss that we've not already touched on?
17:20:16 <kparal> yes
17:20:30 <kparal> .bug 569352
17:20:31 <jlaska> kparal: take it away
17:20:33 <zodbot> kparal: Bug 569352 Broken dependencies for 1:openoffice.org-langpack-en-3.2.0-12.7.fc13.x86_64 - https://bugzilla.redhat.com/show_bug.cgi?id=569352
17:20:44 <kparal> it's really problem of yum-langpacks plugin
17:20:50 <jlaska> #topic Open Discussion - https://bugzilla.redhat.com/show_bug.cgi?id=569352
17:20:57 <kparal> do we consider that a blocker? and which blocker?
17:20:59 <jlaska> #link https://bugzilla.redhat.com/show_bug.cgi?id=569352
17:21:49 * jlaska looking through https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria
17:21:49 <kparal> I did a quick search over the release criteria and haven't found to which milestone should we assing bugs in accepted features
17:22:31 <jlaska> #info I did a quick search over the release criteria and haven't found to which milestone should we assing bugs in accepted features
17:22:56 <jlaska> iirc, the topic of bugs in features came up during our initial review of the criteria @ FUDCon
17:23:05 <jlaska> and it's completely slipping my mind right now
17:23:58 <kparal> ok, so what next? :)
17:24:15 <jlaska> kparal: Unless anyone else has ideas, I'll need to think on this one a bit
17:24:25 <jlaska> how'd you work around this problem?
17:24:34 <kparal> just disable the plugin
17:24:39 <jlaska> yum --disableplugin=langpack ?
17:24:49 <kparal> I have changed a config file
17:25:27 <kparal> I can try this too
17:25:42 <jlaska> well, I'll mark this as CommonBugs material so we can document the problem, and hopefully Jens can inspect the bz tonight and offer some thoughts on the plugin side of things
17:26:16 <kparal> --disableplugin works too
17:26:24 <jlaska> kparal: okay, thanks
17:27:13 <jlaska> kparal: let's line this up for documenting the issue ... I don't have a good enough handle on how many people this would affect right now
17:27:32 <kparal> it may appear at other packages too, I don't know the cause
17:27:53 <kparal> ok
17:27:54 <jlaska> yeah, I'll monitor this while you're out tomorrow and see what Jens can offer as for impact
17:28:30 <jlaska> #topic Open Discsussion - <your topic here>
17:28:34 <jlaska> kparal: thanks
17:28:48 <jlaska> anything else to run through during todays meeting?
17:30:02 <jlaska> alright .... end of meeting.  Thanks everyone.
17:30:17 <jlaska> #endmeeting