15:00:24 #startmeeting Fedora QA Meeting 15:00:24 Meeting started Mon Jun 20 15:00:24 2011 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:24 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:33 #meetingname fedora-qa 15:00:33 The meeting name has been set to 'fedora-qa' 15:00:38 #topic Roll Call 15:00:42 j_dulaney: hi there. Well, got struck by two most unpleasant things at once - illness and end-semester exams 15:01:03 * j_dulaney waves 15:01:03 * jskladan steps out of the shadows 15:01:15 jskladan: Man, that sucks 15:01:29 Hey j_dulaney, jskladan 15:01:35 yo 15:01:59 hey adamw 15:02:05 tflink, adamw, jlaska 15:02:36 hey robatino 15:02:43 * jlaska sees tflink joined too 15:02:49 anyone else I'm forgetting? 15:03:10 Hi there 15:03:15 Vita! 15:03:51 okay, let's get things moving ... 15:03:53 * vhumpa1 stands out of his dark dungeon 15:03:57 Yo, bro 15:04:47 we didn't have a meeting last week ... so I have no previous items to cover 15:04:58 but if something surfaces, let's discuss in open-discussion 15:05:05 #topic Release Criteria Updates 15:05:37 adamw: I don't know if you had any remaining criteria updates ... or if you've made all the planned changes already 15:05:57 the other item on under this topic, was vhumpa1's investigation into the Shell duplicate application names 15:06:16 there may be something else, i'm still kinda swimming upstream here 15:06:32 i know vita's been working hard on that but i haven't caught up with that thread yet, vita can update i'm sure :) 15:06:55 adamw: what's the upstream work you're doing? re: shell? 15:07:23 I reached up to some upstream people and the response I got was that it was an non-issue 15:07:56 * j_dulaney sort of expected as much 15:08:00 vhumpa1: oh rats, so they're not interested in a solution that better distinguishes duplicate application names in the menu? 15:08:04 Basically, we are free to do what we want about this issue, but they want to have nothing to with it 15:08:33 jlaska: oh, no, metaphorically swimming upstream 15:08:39 jlaska: as in freeing myself from giant piles of email 15:08:47 #info Upstream GNOME not interested in resolving duplicate application names - Fedora free to resolve as it sees fit 15:08:54 adamw: oh oh roger :) 15:09:00 If we were to submit a patch or some such, would they actually apply it? 15:09:04 jlaska: I really just have the same input as I told you on Friday 15:09:18 vhumpa1: right on 15:09:29 * j_dulaney notes that he was literally going upstream yesterday, in a boat 15:09:59 Since, it an issue of when you have multiple environments mixed up, it is people's problem 15:10:22 Upstream is focusing only on their desktop experience, not when you mix applications from multiple DE's ? 15:10:23 And they don't want to have design decision driven by this 15:10:28 okay 15:10:33 jlaska: exactly 15:10:47 vhumpa1: is this important enough that we want to continue persuing options? 15:11:14 vhumpa1: how about the parallel discussion about stuff like the GenericName field and app descriptions in tooltips? 15:11:17 We are free to make a path or gnomeshell extension - but should not "expect them to condone it" :) 15:12:01 jlaska: A good question, I think it is, yet not with very high priority 15:12:01 #info We are free to make a path or gnomeshell extension - but should not "expect them to condone it" 15:12:43 adamw: I believe that is the same stuff 15:13:06 adamw: I mean that is what I was asking for the upstream opinion for 15:13:39 so, no movement there either? hum. 15:13:45 adamw: renaming the desktop files in Fedora packing process seems like a no-go now based on some input I got 15:14:23 What about just editing the menu names in the .desktop file? 15:14:48 Ah sorry for mistyping, that is what I ment in the previous post 15:15:02 from a fedora packaging perspective? 15:15:03 Ah 15:15:07 Yep 15:15:20 How so? 15:15:30 It doesn't seem like it would be difficult. 15:15:36 * adamw doesn't see anything specifically forbidding it in http://fedoraproject.org/wiki/PackagingGuidelines#Desktop_files 15:15:39 We take the desktop files from upstream... So they'd have to be modified with each new version etc... if I am not mistaken 15:15:40 maintenance? 15:15:48 jlaska: exactly 15:15:55 vhumpa1: i've modified .desktop files before, it's not terribly hard 15:16:10 Could not a script be created? 15:16:23 adamw: definitely not :) Depends on if maintainers would be willing to do so 15:16:43 Include it as an automated part of the build process so that it wouldn't be forgotten 15:16:49 you can usually run a sed command inside the spec 15:16:50 so ...do we want to take this to the packaging-list with suggestions for updating the Desktop_files guidance? 15:17:02 j_dulaney: I suppose so, that it could be automated from inside spec files somehow 15:17:16 jlaska +1 15:17:23 well, this is only feedback from one upstream 15:17:37 jlaska: might be worth it 15:17:42 have we looked at all the current name collisions and seen how many actually involve GNOME packages? (and how many involve *two* GNOME packages?) 15:17:50 good question 15:17:56 what's the scope of the problem space? 15:18:15 adamw: I can think of one such within Gnome 15:18:19 i'd say, it would not be more than 10-15 packages 15:18:25 The Update/Updates thing 15:18:36 even less if we target really only the most obvious one 15:18:41 vhumpa1: +1 15:18:42 ones 15:19:02 j_dulaney: i think one of those is a Fedora package, not a GNOME one 15:19:06 Still: how exactly to rename them and how is an question 15:19:32 oh, no, they're both from gnome-packagekit. i lose. 15:19:41 i think we could prevail upon hughsie to fix that one, though. 15:19:45 Might bring some unhappiness from some upstream people if we rename some apps in a way they dont like it 15:20:02 yeah, it's a slightly touchy subject 15:20:14 i think we should check on the other collisions and see what upstream projects they involve 15:20:15 vhumpa1: Of course, in some instances, we are the upstream... 15:20:29 anyone want to pull together a complete list of the collisions? 15:20:42 * j_dulaney can 15:20:42 s/want to/want to volunteer/ 15:20:48 thanks j_dulaney 15:21:01 #action j_dulaney - will gather a full list of the application name collissions 15:21:11 j_dulaney: you can find a sketch of such in the testlist discussion 15:21:24 anything we need to discuss before we have the complete list of collisions? 15:21:31 or will that list be used to figure out step#2? 15:21:47 vhumpa1: Roger 15:22:44 anything else to cover on this topic? 15:23:31 i think that's important to figuring out step #2 15:23:40 yeah, that makes sense 15:23:48 okay, getting ready to move on then 15:24:00 thanks all for the update ... we'll follow-up on the list with this topic 15:24:06 #topic AutoQA updates 15:24:19 brb, nature calls 15:24:19 kparal is out today ... tflink, can you guide us through the latest and greatest? 15:24:28 quick give adamw action items! 15:24:29 not a problem 15:24:55 proposed #action adamw finish AutoQA 0.5.0 15:25:07 ack! 15:25:09 :) 15:25:11 LOL 15:25:16 +1 15:25:29 actually ... adamw is really good at giving out action items to me ... so I'll be +0 on this :) 15:25:51 We've been working to test and finish up AutoQA 0.5.0 and at the moment we're hoping to finish up and release this week some time 15:26:08 #info We've been working to test and finish up AutoQA 0.5.0 and at the moment we're hoping to finish up and release this week some time 15:26:26 the major features are bodhi comment email reduction and better log data presentation (in HTML) 15:26:56 * jlaska loves the error highlighting in the HTML reports 15:27:01 we still have 2 issues to work out (that I'm aware of) - jskladan has submitted a patch for one and I'm still working on the other 15:27:59 that's about all I can think of to say from AutoQA land. Look for a new release announcement later this week! 15:28:30 tflink: given the testing you guys have already done ... does it seem feasible to resolve those 2 issues and release this week? 15:29:38 jlaska: I think so. jskladan's patch looks good and I'm still having issues reproducing the last bug 15:30:11 tflink: cool, are you getting what you need out of the test instance we setup? 15:30:12 if I still can't reproduce it in the next couple of days, I'm of the opinion that we can ship with it and fix it if it becomes a problem 15:30:20 okay 15:30:27 #info we still have 2 issues to work out (that I'm aware of) - jskladan has submitted a patch for one and I'm still working on the other 15:30:36 #info Look for a new release announcement later this week! 15:30:47 to reproduce that bug? No, that setup isn't set up for reproducing the issue 15:30:57 this is the email issue, right? 15:31:07 yep - the wonders of tight coupling! 15:31:08 would it help if you had autoqa-results-staging@ ? 15:31:18 * vhumpa1 goes back to studies 15:31:24 tflink: on fedorahosted i mean, instead of your private setup? 15:31:27 vhumpa1: good luck! 15:31:38 jlaska: thx! will need it 15:31:39 jlaska: it wouldn't matter. The SMTP traffic is being blocked 15:31:45 #action vhumpa1 finish autoqa 0.5.0 15:31:51 either fedorahosted or my list are outside the network and affected 15:31:55 adamw: strikes! 15:32:14 and the emails that go out to that list are different 15:32:22 I see 15:32:23 the issue has to do with the bodhi comment emails 15:32:28 ah! 15:32:40 which are disabled on the test system 15:33:00 tflink: thanks for the details 15:33:09 np 15:33:22 okay, if nothing else on the autoqa front, we'll move on 15:33:34 fingers crossed for a successful autoqa release this week 15:33:57 that makes at least two of us. I want to get this stuff into production 15:33:59 oh well, I might as well #info something ... 15:34:44 #info Fedora infrastructure team planning to move existing autoqa systems on July 12 ... jlaska working with smooge+nirik to prepare install/configure new servers (prod + stage) ahead of time 15:35:16 so thanks to those two for providing guidance, and what is shaping up to be a much more official setup 15:35:21 more news @ 11 15:35:22 Try to have 0.5.4 or .5 out by then? 15:35:51 who knows what %{version} we'll be at then :) 15:36:16 okay ... moving on ... 15:36:25 #topic R^3 - Retrospective recommendation review 15:36:30 #link https://fedoraproject.org/wiki/Fedora_15_QA_Retrospective#Recommendations 15:36:41 I finally pulled together the retrospective feedback into some recommendations 15:36:57 I've blogged and fired this off to the list to the thunderous sound of crickets 15:37:14 if you have a moment, please review what I've documented on the page so far 15:37:29 some of these things are already inprogress (b/c you guys naturally like to fix problems) 15:37:48 s/guys/people/ :) 15:38:14 there aren't a lot of earth shattering changes proposed imo ... but of course, it would be nice to have some input 15:38:26 some highlights ... 15:38:32 * j_dulaney likes 15:38:49 Since the Alpha's have always slipped, and each time it's due to live image-related problems (creation or install) 15:38:49 * adamw will have feedback soon 15:39:12 I thought we should ask to have live images included during TC1 (updated SOP), and also with the acceptance test runs leading up to the TC 15:39:41 I've got a few items on the list that we'll need to approach other teams on 15:39:53 for example ... there are 3 items that need to be reviewed with rbergeron 15:40:00 same for rel-eng (likely dgilmore) 15:40:21 yay more lives 15:40:45 * j_dulaney notices that he now can set blocker status. 15:41:14 Is that across the board for all Bugzilla account holders, or just those with a FAS? 15:41:26 j_dulaney: related to a feature awilliam requested maybe? 15:41:28 .bug 707252 15:41:30 jlaska: Bug 707252 Allow any registered user to change the Blocks: field - https://bugzilla.redhat.com/show_bug.cgi?id=707252 15:41:38 yeah, i've been waiting on that one for a bit 15:41:55 jlaska: Indeed 15:42:16 j_dulaney: so far it's been that you need editbugs privileges to set that field 15:42:22 which packagers and bugzappers and rh staff get 15:42:28 okay ... so please all take a minute to review, add feedback, tell me what sucks or is missing 15:42:35 (in as constructive a way as possible of course) :) 15:42:48 I'd like to start converting these tasks into tickets and begging for volunteers 15:43:03 if there is something you like on the list, and want to get started on ... by all means, go for it 15:43:14 adamw: So, it is across the board now, then? 15:43:26 #info I finally pulled together the retrospective feedback into some recommendations. I'd like to start converting these tasks into tickets and begging for volunteers. if there is something you like on the list, and want to get started on ... by all means, go for it 15:43:41 * j_dulaney wonders about how to prevent things like the GlibC almost-foulup 15:43:48 #info j_dulaney noted that bugzilla now allows any logged in user to set the Blocks field 15:44:00 any other comments/thoughts/concerns on this? 15:44:12 if folks are okay with this process/format ... I'll also add a ticket for me to SOP this 15:44:13 j_dulaney: i dunno, i hadn't heard of any change 15:46:04 okay, I'll stay tuned to the list for ideas 15:46:06 thanks all! 15:46:14 #topic Open Discussion - 15:46:26 I had one item I just remembered ... but someone else can go first 15:47:49 actually ... my topic was a bout whether we should include athmane's security test matrix in F16 release validation runs 15:47:59 but I think I'll actually just add that to the retrospective recommendations 15:48:25 * j_dulaney raises hand 15:48:43 #info jlaska asked whether we should include athmane's security test matrix in the list of F16 release validation matrices (refer to https://fedoraproject.org/wiki/User:Athmane/Fedora_15_Security_Lab_Testing) 15:48:44 i'd say definitely, and one thing i'm trying to do is come up with a third test matrix for releases which will include those and a few other tests that aren't really install or desktop 15:48:48 Btrfs test case creation 15:48:55 but i've been terminally short on round tuits :( 15:49:12 adamw: nice, I think I've got that suggestion from you on the retrospective 15:49:17 adamw: Know the feeling 15:49:50 j_dulaney: re: btrfs ... do you mean tests related to installing systems with btrfs partitions? 15:49:56 or more about post-install btrfs tasks? 15:49:58 (or both) 15:50:16 For instance: 15:50:16 Both 15:50:21 https://fedoraproject.org/wiki/User:Jdulaney/Draft_Testcase_Mount_btrfs 15:50:35 https://fedoraproject.org/wiki/User:Jdulaney/Draft_Testcase_btrfs_migration 15:50:51 j_dulaney: I've got it on the retrospective to talk with rhe about adding installer coverage for btrfs (actually, it was her idea) 15:51:07 perhaps your additional tests might line up with the additional stuff adamw is talking about 15:51:22 Indeed 15:51:31 definitely as package specific tests to start with 15:51:35 adamw: Let's talk on this later this week? 15:51:35 when I have time? 15:52:21 Okay .... last call for open-discussion topics ... 15:52:30 I'll #endmeeting in 2 minutes 15:52:33 * jlaska sets fuse 15:53:33 1 minute until #endmeeting ... 15:54:14 j_dulaney: sure 15:54:30 alright ... thanks everyone! 15:54:34 What about, say Wednesday? 15:54:40 I'll send minutes to the list later today 15:54:44 #endmeeting