16:00:40 <jlaska> #startmeeting Fedora QA meeting
16:00:41 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:44 <jlaska> #meetingname fedora-qa
16:00:45 <zodbot> The meeting name has been set to 'fedora-qa'
16:00:52 <jlaska> #topic Gathering ...
16:01:06 * adamw gathers
16:01:14 * kparal is here and on eletricity power again
16:01:15 <daumas> there can be only one
16:01:34 <jlaska> kparal: hey, alright
16:02:54 <jlaska> wwoods: is out today
16:03:02 <jlaska> and I'm not expecting lili or rhe to be awake right now
16:03:33 <jlaska> kparal: is jskladan out for the day?
16:04:12 <kparal> jlaska: jskladan was hoping to be online, but it seems he's not here
16:04:20 <jlaska> okay
16:05:13 <jlaska> maxamillion had a conflict too iirc
16:05:20 <jlaska> #topic Previous meeting follow-up
16:05:29 <jlaska> #info maxamillion seeking input from the Mentors group for guidance on mentor responsibilities
16:05:42 <jlaska> not sure of anything new here, anyone else?
16:05:55 <adamw> not heere
16:05:56 <jlaska> I can catch up with maxamillion after
16:06:17 <jlaska> some of these tasks are a bit old ... next up ...
16:06:22 <jlaska> #info continued testing of bug#567346 to further isolate the failure conditions
16:06:28 <jlaska> .bug 567346
16:06:31 <zodbot> 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 <adamw> that's the update fail bug, right?
16:06:47 <jlaska> yeah, I believe this is the one you updated after Fridays blocker mtg?
16:06:50 <adamw> yeah.
16:07:09 <jlaska> Any objections to dropping this from the list, I think we've got it on the proper radar elsewhere
16:07:55 <adamw> sure
16:08:11 <jlaska> alrighty, next ..
16:08:20 <jlaska> #info jlaska to update AutoQA_PatchProcess to include fedorapeople.org git repo
16:08:52 <jlaska> 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 <jlaska> https://fedoraproject.org/wiki/AutoQA_PatchProcess#Private_Branch
16:09:09 <jlaska> that's all I have from previous meetings
16:09:18 <jlaska> before we move on, anything else not covered?
16:10:29 <jlaska> alright ... diving into the agenda ...
16:10:37 <jlaska> #topic Fedora 13 test status
16:10:48 <jlaska> this first topic is intended as a check-in on f13 test activities
16:10:57 <jlaska> we've got quite a bit going on at the moment, and the beta is on the horizon
16:11:15 <jlaska> I'm just going to rattle off a few milestones that I'm tracking ...
16:11:32 <jlaska> #info Pre-beta acceptance test - awaiting new anaconda build before sending through AutoQA - https://fedorahosted.org/rel-eng/ticket/3495
16:12:05 <jlaska> next up, we have ...
16:12:19 <jlaska> #info 2010-03-18 - Beta test compose
16:12:39 <jlaska> 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 <jlaska> we also have ...
16:13:17 <jlaska> #info 2010-03-18 - Palimpsest & udisks improvements test day
16:13:36 <jlaska> so quite a bit going on this week, on top of the proposal storm
16:14:07 * Viking-Ice sneaks inn
16:14:11 <jlaska> I don't have a ticket for the palimpsest test day ... who is coordinating that event?
16:14:16 <jlaska> Viking-Ice: welcome :)
16:14:17 <adamw> i was about to ask the same
16:14:18 <adamw> ot
16:14:26 <adamw> it's on the schedule but i'm not sure who's in charge of that
16:14:55 <adamw> 18:02, 16 February 2010 Davidz  (Talk | contribs) (3,046 bytes) (Add udisks test day)
16:15:14 <adamw> oh look, it's me!
16:15:34 <adamw> yeah, i have some emails from david about this, from back in february. i'll look after it.
16:15:44 <jlaska> adamw: want to divide and conquer on this one?
16:15:51 <adamw> nah, it's fine, i've got it.
16:15:51 <jlaska> since you had all of webcam last week?
16:16:37 <jlaska> 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 <adamw> there's stuff on the feature page too.
16:17:02 <jlaska> ah, nm ... I was thinking about DeviceKit (https://fedoraproject.org/wiki/Category:DeviceKit_Test_Cases)
16:17:39 <jlaska> I'll check-in with Hurry to see if she needs anything for the test compose milestone this week
16:17:54 <adamw> DeviceKit would be right
16:18:02 <adamw> DeviceKit-disks turned into udisks
16:18:19 <jlaska> I thought we had a focus on this already, but then the *Kit name threw me
16:18:34 <adamw> we had HAL, then DeviceKit, then DeviceKit-disks, then udisks
16:18:36 <adamw> easy! =)
16:18:50 <jlaska> kparal: I think we could make a fun flow chart for that progression :)
16:19:02 <jlaska> oh, and last thing on my radar for F13 testing this week
16:19:17 <jlaska> #info 2010-03-19 - F13 Beta Blocker bug review #2
16:19:37 <jlaska> Cranes Maska has quite a few bugs to knock out before that meeting
16:19:50 <jlaska> anything else on the F13 front folks want to share?
16:19:52 <adamw> i wouldn't expect much from that guy
16:19:59 <jlaska> adamw: I set the bar low
16:20:25 <jlaska> alrighty ... moving on ...
16:20:37 <jlaska> #topic proventesters
16:21:12 <jlaska> 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 <jlaska> 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 <jlaska> is there general agreement on the FAS group name, 'proventesters'?
16:22:19 <adamw> sure
16:22:22 <adamw> brb call of nature
16:22:36 <kparal> just call back :)
16:22:48 <jlaska> heh
16:23:10 <jlaska> 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 <daumas> jlaska: what will a "proventester" acl give to a person who receives it?
16:24:46 <jlaska> daumas: great question, I'm not sure this process has been fully fleshed out yet
16:25:12 <jlaska> 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 <jlaska> perhaps people can lend their thoughts .... /me grabs links ...
16:25:33 <jlaska> http://lists.fedoraproject.org/pipermail/test/2010-March/088980.html
16:25:40 <adamw> basically we're working on maxa's proposal i thought?
16:25:44 <Viking-Ice> what happen with using the already existing QA group?
16:26:23 <adamw> Viking-Ice: http://lists.fedoraproject.org/pipermail/test/2010-March/089065.html
16:27:11 <Viking-Ice> Ah ok good point mentioned there..
16:27:33 <jlaska> 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 <jlaska> if nothing else, I'll checking with maxamillion after the meeting and see what he needs to move forward
16:27:59 <adamw> be nice to hear where oxf13 is on it
16:28:38 <jlaska> #Help additional feedback needed, see http://lists.fedoraproject.org/pipermail/test/2010-March/088980.html
16:28:41 <jlaska> #help additional feedback needed, see http://lists.fedoraproject.org/pipermail/test/2010-March/088980.html
16:29:01 <jlaska> adamw: what aspect is Oxf13 working on?
16:30:07 <adamw> i'm not exactly sure, but he was definitely talking about the whole area
16:30:20 <jlaska> alright ... sounds like some data gathering is needed
16:30:29 <jlaska> I'll bug those two later on
16:30:48 <jlaska> okay ... next topic ... back by popular demand
16:30:51 <jlaska> #topic Privilege Escalation test
16:31:42 <jlaska> 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 <adamw> right
16:32:05 <adamw> 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 <adamw> i believe the next step was to come up with the script to identify privesc-relevant packages
16:32:29 <kparal> should this be automated test for autoqa or manual test, similar to current desktop validation test plan?
16:32:40 <jlaska> kparal: I wonder if these eventually might make good _instrospection_ tests?
16:32:46 <adamw> 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 <adamw> i think there's going to be automated and manual elements to it
16:33:19 <adamw> we can use autoqa to identify packages which have added critpath-relevant stuff, or packages where it changes
16:33:24 <jlaska> wouldn't hurt to start with manual definition
16:33:29 <adamw> and there may be common errors we can catch with autoqa (or may not)
16:33:40 <adamw> but there will also be manual tests we'll want to run on the identified packages
16:34:09 <jlaska> adamw: the best candidate I knew of was for any packages who change/add/remove their polkit definitions?
16:34:28 <adamw> that's part of it, but there are other things to check for too
16:34:51 <adamw> setuid binaries, certain d-bus config files I believe, and consolehelper files are the obvious
16:35:20 <adamw> 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 <jlaska> kparal: these seem like good candidates for rpmguard tickets once we have test defined ... since there is a comparison factor here?
16:35:55 <kparal> that's possible
16:36:14 <jlaska> 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 <jlaska> adamw: is this something you'd like to see in place for Final, or sooner?
16:36:51 <adamw> well the rpmguard stuff will be pretty 'obvious' once we have the tool to generate an overall list in place
16:37:12 <adamw> 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 <jlaska> who can provide that?
16:38:39 <jlaska> adamw: that seems like a reasonable goal ... given the 200 other things everyone has on their plates
16:39:15 <adamw> 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 <jlaska> #info interested in a list of packages to apply priv esc tests against for final
16:39:33 <adamw> maybe take an action item for me to talk to him about it? anyone else want to be involved?
16:39:59 <jlaska> #info wwoods previously mentioned producing a tool to provide the list of packages
16:40:22 <jlaska> #action adamw to check-in with wwoods on tooling needs for priv esc. test
16:41:20 <jlaska> 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 <adamw> sure, if something comes up we have a document to point to to say what it should do.
16:42:14 <adamw> 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 <jlaska> indeed
16:42:50 <jlaska> alright, anything else on that front ... or just the first step, follow-up w/ wwoods
16:43:02 <adamw> first step is fine for now
16:43:17 <jlaska> eggsellent, thanks adamw
16:43:29 <jlaska> okay, open discussion time ...
16:43:31 <jlaska> #topic Open discussion - <Your topic here>
16:43:42 <jlaska> anything not covered that folks would like to discuss?
16:44:24 * Viking-Ice nothing from me...
16:44:37 <kparal> well maybe I have a question about the proposals. but we can also discuss it afterwards
16:45:30 <kparal> about the update policy proposals, to be more exact
16:45:50 <jlaska> #topic Update Policy proposals
16:45:52 <jlaska> kparal: take it away
16:46:25 <kparal> 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 <kparal> the first one when accepting packages to updates-testing, the second one when accepting packages to stable updates
16:46:48 <kparal> is that correct?
16:47:29 <jlaska> kparal: that's my understanding
16:47:31 <kparal> because for example I think we want to check dependencies sanity before pushing to updates-testing, not to break our repo
16:47:49 <kparal> OTOH the upgrade path should be checked just when before push to stable updates
16:47:58 <jlaska> right, and then the same to ensure that things are pushed int he right order to 'updates'
16:48:01 <kparal> otherwise the situation may change in between
16:48:48 <jlaska> 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 <kparal> 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 <kparal> but the policies are meant to be complex, right? :)
16:49:33 <daumas> kparal: dep checking to stable pushes is loooong overdue
16:49:51 <kparal> daumas: what do you mean?
16:50:17 <jlaska> 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 <jlaska> 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 <daumas> 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 <kparal> 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 <kparal> but as I understand it, we can't assume that something that was ok 2 days ago is still ok now
16:51:54 <kparal> e.g. the dependencies
16:52:38 <kparal> so AutoQA will slow it down a little at both sides
16:52:50 <kparal> if I see it wrong please correct me
16:53:01 <jlaska> kparal: one aspect with both policies is that they require autoqa be inproduction
16:53:11 <daumas> kparal: slowing down a few minutes will save days of recoup time.
16:53:21 <jlaska> so the very small test environment we are piloting now won't be representative of the resources available once deployed
16:53:54 <kparal> ok, that's a good answer for me
16:54:14 <jlaska> but honestly, I'd love to have the problem of autoqa being too slow
16:54:31 <jlaska> that would mean all these java packages are behind us :)
16:54:52 <jlaska> #topic Open Discussion - <your topic here>
16:54:59 <jlaska> alright ... anything else for today?
16:55:12 <jlaska> otherwise, I'll call #endmeeting in a few minutes
16:56:02 <adamw> where are you with the autoqa packaging stuff?
16:56:05 <adamw> drowning? need a rope?
16:56:19 <jlaska> adamw: several ropes are being shot out as we speak
16:56:25 <adamw> ah great
16:56:38 <jlaska> adamw: I'll have an email out to java-devel@ and probably devel@ later this week looking for FAD participants
16:57:21 <jlaska> #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 <jlaska> alright gang ... thanks for your time
16:57:49 <jlaska> as usual, I'll send minutes to the list
16:57:52 <jlaska> #endmeeting