16:00:40 #startmeeting Fedora QA meeting 16:00:41 Meeting started Mon Mar 15 16:00:40 2010 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:43 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:44 #meetingname fedora-qa 16:00:45 The meeting name has been set to 'fedora-qa' 16:00:52 #topic Gathering ... 16:01:06 * adamw gathers 16:01:14 * kparal is here and on eletricity power again 16:01:15 there can be only one 16:01:34 kparal: hey, alright 16:02:54 wwoods: is out today 16:03:02 and I'm not expecting lili or rhe to be awake right now 16:03:33 kparal: is jskladan out for the day? 16:04:12 jlaska: jskladan was hoping to be online, but it seems he's not here 16:04:20 okay 16:05:13 maxamillion had a conflict too iirc 16:05:20 #topic Previous meeting follow-up 16:05:29 #info maxamillion seeking input from the Mentors group for guidance on mentor responsibilities 16:05:42 not sure of anything new here, anyone else? 16:05:55 not heere 16:05:56 I can catch up with maxamillion after 16:06:17 some of these tasks are a bit old ... next up ... 16:06:22 #info continued testing of bug#567346 to further isolate the failure conditions 16:06:28 .bug 567346 16:06:31 jlaska: Bug 567346 gpk-update-viewer does not install updates if there is any dependency issue, and does not correctly report this - https://bugzilla.redhat.com/show_bug.cgi?id=567346 16:06:37 that's the update fail bug, right? 16:06:47 yeah, I believe this is the one you updated after Fridays blocker mtg? 16:06:50 yeah. 16:07:09 Any objections to dropping this from the list, I think we've got it on the proper radar elsewhere 16:07:55 sure 16:08:11 alrighty, next .. 16:08:20 #info jlaska to update AutoQA_PatchProcess to include fedorapeople.org git repo 16:08:52 nothing crazy here, I made a minor update to the [[AutoQA_PatchProcess]] wiki page pointing to the instructions for setting up a git repo on fedorapeople.org 16:09:01 https://fedoraproject.org/wiki/AutoQA_PatchProcess#Private_Branch 16:09:09 that's all I have from previous meetings 16:09:18 before we move on, anything else not covered? 16:10:29 alright ... diving into the agenda ... 16:10:37 #topic Fedora 13 test status 16:10:48 this first topic is intended as a check-in on f13 test activities 16:10:57 we've got quite a bit going on at the moment, and the beta is on the horizon 16:11:15 I'm just going to rattle off a few milestones that I'm tracking ... 16:11:32 #info Pre-beta acceptance test - awaiting new anaconda build before sending through AutoQA - https://fedorahosted.org/rel-eng/ticket/3495 16:12:05 next up, we have ... 16:12:19 #info 2010-03-18 - Beta test compose 16:12:39 I'm not seeing tickets yet for the beta composes, I'll catch up with Oxf13 after to make sure I don't fill dups 16:13:03 we also have ... 16:13:17 #info 2010-03-18 - Palimpsest & udisks improvements test day 16:13:36 so quite a bit going on this week, on top of the proposal storm 16:14:07 * Viking-Ice sneaks inn 16:14:11 I don't have a ticket for the palimpsest test day ... who is coordinating that event? 16:14:16 Viking-Ice: welcome :) 16:14:17 i was about to ask the same 16:14:18 ot 16:14:26 it's on the schedule but i'm not sure who's in charge of that 16:14:55 18:02, 16 February 2010 Davidz (Talk | contribs) (3,046 bytes) (Add udisks test day) 16:15:14 oh look, it's me! 16:15:34 yeah, i have some emails from david about this, from back in february. i'll look after it. 16:15:44 adamw: want to divide and conquer on this one? 16:15:51 nah, it's fine, i've got it. 16:15:51 since you had all of webcam last week? 16:16:37 we had a previous palimpsest test day, but I can't find it at the moment ... hopefully that has some useful tests 16:16:50 there's stuff on the feature page too. 16:17:02 ah, nm ... I was thinking about DeviceKit (https://fedoraproject.org/wiki/Category:DeviceKit_Test_Cases) 16:17:39 I'll check-in with Hurry to see if she needs anything for the test compose milestone this week 16:17:54 DeviceKit would be right 16:18:02 DeviceKit-disks turned into udisks 16:18:19 I thought we had a focus on this already, but then the *Kit name threw me 16:18:34 we had HAL, then DeviceKit, then DeviceKit-disks, then udisks 16:18:36 easy! =) 16:18:50 kparal: I think we could make a fun flow chart for that progression :) 16:19:02 oh, and last thing on my radar for F13 testing this week 16:19:17 #info 2010-03-19 - F13 Beta Blocker bug review #2 16:19:37 Cranes Maska has quite a few bugs to knock out before that meeting 16:19:50 anything else on the F13 front folks want to share? 16:19:52 i wouldn't expect much from that guy 16:19:59 adamw: I set the bar low 16:20:25 alrighty ... moving on ... 16:20:37 #topic proventesters 16:21:12 There has been some discussion on the list in previous weeks regarding the creation of a proventesters group, responsible for providing critpath bodhi feedback for QA 16:21:49 I've seen a few email from Oxf13, adamw and maxamillion, but wanted to give someone a chance to talk about where we are, what's next etc... 16:22:09 is there general agreement on the FAS group name, 'proventesters'? 16:22:19 sure 16:22:22 brb call of nature 16:22:36 just call back :) 16:22:48 heh 16:23:10 so I don't see the group created yet, https://admin.fedoraproject.org/accounts/group/view/proventester ... so that seems like a reasonable starting point 16:24:22 jlaska: what will a "proventester" acl give to a person who receives it? 16:24:46 daumas: great question, I'm not sure this process has been fully fleshed out yet 16:25:12 for today, I just wanted to check-in and see where things stood. I know maxamillion has a few threads out to help move things along on this front 16:25:20 perhaps people can lend their thoughts .... /me grabs links ... 16:25:33 http://lists.fedoraproject.org/pipermail/test/2010-March/088980.html 16:25:40 basically we're working on maxa's proposal i thought? 16:25:44 what happen with using the already existing QA group? 16:26:23 Viking-Ice: http://lists.fedoraproject.org/pipermail/test/2010-March/089065.html 16:27:11 Ah ok good point mentioned there.. 16:27:33 adamw: I thought so as well, but I know it's getting a lot of focus and I haven't seen a lot of feedback to maxa's RFC 16:27:56 if nothing else, I'll checking with maxamillion after the meeting and see what he needs to move forward 16:27:59 be nice to hear where oxf13 is on it 16:28:38 #Help additional feedback needed, see http://lists.fedoraproject.org/pipermail/test/2010-March/088980.html 16:28:41 #help additional feedback needed, see http://lists.fedoraproject.org/pipermail/test/2010-March/088980.html 16:29:01 adamw: what aspect is Oxf13 working on? 16:30:07 i'm not exactly sure, but he was definitely talking about the whole area 16:30:20 alright ... sounds like some data gathering is needed 16:30:29 I'll bug those two later on 16:30:48 okay ... next topic ... back by popular demand 16:30:51 #topic Privilege Escalation test 16:31:42 adamw: I know you've asked about drafting test cases to support the recent priv escalation policy, I wanted to give you some time to talk through it 16:31:50 right 16:32:05 basically just a reminder that we didn't write the policy for the fun of writing policies =) it was to support privesc testing 16:32:21 i believe the next step was to come up with the script to identify privesc-relevant packages 16:32:29 should this be automated test for autoqa or manual test, similar to current desktop validation test plan? 16:32:40 kparal: I wonder if these eventually might make good _instrospection_ tests? 16:32:46 i'm trying to remember who it was said they would volunteer to do that back at the start, could be wwoods 16:32:54 i think there's going to be automated and manual elements to it 16:33:19 we can use autoqa to identify packages which have added critpath-relevant stuff, or packages where it changes 16:33:24 wouldn't hurt to start with manual definition 16:33:29 and there may be common errors we can catch with autoqa (or may not) 16:33:40 but there will also be manual tests we'll want to run on the identified packages 16:34:09 adamw: the best candidate I knew of was for any packages who change/add/remove their polkit definitions? 16:34:28 that's part of it, but there are other things to check for too 16:34:51 setuid binaries, certain d-bus config files I believe, and consolehelper files are the obvious 16:35:20 there's also some lovely outliers out there, like the app I came across the other day which inexplicably chose to use some random thing called 'beesu' which wraps consolehelper 16:35:25 kparal: these seem like good candidates for rpmguard tickets once we have test defined ... since there is a comparison factor here? 16:35:55 that's possible 16:36:14 kparal: as you mentioned earlier, I don't want to get too far ahead with tasking out autoqa stuff until we have the current mandatory list (and a place to store/view the results) complete 16:36:49 adamw: is this something you'd like to see in place for Final, or sooner? 16:36:51 well the rpmguard stuff will be pretty 'obvious' once we have the tool to generate an overall list in place 16:37:12 well it'd be nice to at least have a list of packages for us to eyeball, if nothing else, before final 16:37:41 who can provide that? 16:38:39 adamw: that seems like a reasonable goal ... given the 200 other things everyone has on their plates 16:39:15 as I said, i think wwoods said when we started discussing this that he'd be able to come up with a tool 16:39:33 #info interested in a list of packages to apply priv esc tests against for final 16:39:33 maybe take an action item for me to talk to him about it? anyone else want to be involved? 16:39:59 #info wwoods previously mentioned producing a tool to provide the list of packages 16:40:22 #action adamw to check-in with wwoods on tooling needs for priv esc. test 16:41:20 adamw: we have the policy in place now to help guide and severity questions around incoming bugs, so that does put us in better shape for F-13 testing than we were in for F-12 16:41:56 sure, if something comes up we have a document to point to to say what it should do. 16:42:14 but it would definitely be better to have an active testing plan in place rather than just hope for things to float to the surface =) 16:42:26 indeed 16:42:50 alright, anything else on that front ... or just the first step, follow-up w/ wwoods 16:43:02 first step is fine for now 16:43:17 eggsellent, thanks adamw 16:43:29 okay, open discussion time ... 16:43:31 #topic Open discussion - 16:43:42 anything not covered that folks would like to discuss? 16:44:24 * Viking-Ice nothing from me... 16:44:37 well maybe I have a question about the proposals. but we can also discuss it afterwards 16:45:30 about the update policy proposals, to be more exact 16:45:50 #topic Update Policy proposals 16:45:52 kparal: take it away 16:46:25 alright, just something to be clear on. from the current discussions and proposals, it seems probably that we will have two autoqa checking rounds 16:46:45 the first one when accepting packages to updates-testing, the second one when accepting packages to stable updates 16:46:48 is that correct? 16:47:29 kparal: that's my understanding 16:47:31 because for example I think we want to check dependencies sanity before pushing to updates-testing, not to break our repo 16:47:49 OTOH the upgrade path should be checked just when before push to stable updates 16:47:58 right, and then the same to ensure that things are pushed int he right order to 'updates' 16:48:01 otherwise the situation may change in between 16:48:48 exactly, for the tests that look for closure in deps and conflicts, it seems like those would need to run during any transition to 'updates-testing' or 'updates' 16:48:51 ok, I'm just modifying my proposal again, so I will include these two rounds of autoqa checks. I'm just afraid it will sound even more complicated than the first proposal 16:49:29 but the policies are meant to be complex, right? :) 16:49:33 kparal: dep checking to stable pushes is loooong overdue 16:49:51 daumas: what do you mean? 16:50:17 kparal: given the limited scope of the tests for package acceptance, I don't think we'll get a lot of push back from ensuring that both 'updates' and 'updates-testing' repos are dep solvable 16:50:59 kparal: I'm obviously not an english major, but I'll be happy to look at the wording and propose changes if there is something more concise that can convey the same meaning 16:50:59 kparal: pushes get made, users encounter "unable to resolve deps" and complain to the lists. it's been commonplace for a while. it's more rare these days, but most recently happened with nss and nspr 16:51:31 alright. I was thinking if we could make the AutoQA process run during the time the package spends in updates-testing. so AutoQA would not be a bottleneck (it may take a few hours) 16:51:50 but as I understand it, we can't assume that something that was ok 2 days ago is still ok now 16:51:54 e.g. the dependencies 16:52:38 so AutoQA will slow it down a little at both sides 16:52:50 if I see it wrong please correct me 16:53:01 kparal: one aspect with both policies is that they require autoqa be inproduction 16:53:11 kparal: slowing down a few minutes will save days of recoup time. 16:53:21 so the very small test environment we are piloting now won't be representative of the resources available once deployed 16:53:54 ok, that's a good answer for me 16:54:14 but honestly, I'd love to have the problem of autoqa being too slow 16:54:31 that would mean all these java packages are behind us :) 16:54:52 #topic Open Discussion - 16:54:59 alright ... anything else for today? 16:55:12 otherwise, I'll call #endmeeting in a few minutes 16:56:02 where are you with the autoqa packaging stuff? 16:56:05 drowning? need a rope? 16:56:19 adamw: several ropes are being shot out as we speak 16:56:25 ah great 16:56:38 adamw: I'll have an email out to java-devel@ and probably devel@ later this week looking for FAD participants 16:57:21 #info adam asked how autoqa packaging was going, jlaska noted that a FAD is in the works, expect more later this week 16:57:29 alright gang ... thanks for your time 16:57:49 as usual, I'll send minutes to the list 16:57:52 #endmeeting