15:00:10 #startmeeting Fedora QA Meeting 15:00:10 Meeting started Mon May 10 15:00:10 2010 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:14 #meetingname fedora-qa 15:00:14 The meeting name has been set to 'fedora-qa' 15:00:22 #topic Gathering critmass 15:01:57 this will make for a quick meeting :) 15:02:06 * kparal arrives 15:02:06 ah, kparal welcome 15:02:24 adamw: wwoods: jskladan: robatino: maxamillion 15:02:57 jskladan seems to be still somewhere out 15:02:57 yo 15:03:08 kparal: okay 15:03:21 lemme check if wwoods is around 15:04:10 not in yet 15:04:30 okay, let's get this party started, wwoods and jskladan can join mid-meeting 15:04:35 jlaska: quick meeting? that sounds promising :) 15:04:42 etank: hey, welcome! : 15:04:55 so yes ... short list of topics for today ... http://lists.fedoraproject.org/pipermail/test/2010-May/090788.html 15:05:45 so let's do quick review from last week 15:06:17 #topic Preview meeting follow-up 15:06:28 #info jlaska to migrate approved FAS 'qa' members into 'proventesters' 15:06:51 this task is complete 15:07:03 so now all approved members of 'qa' are now also approved 'proventesters' 15:07:11 the next item was ... 15:07:19 #info jlaska to request bodhi change to require 'proventesters' feedback for critpath 15:07:48 I have requested an update to bodhi (see https://fedorahosted.org/bodhi/ticket/424) 15:07:54 'for f12 and earlier' i suppose 15:08:05 lmacken quickly responded and has a fix in bodhi for this ... the fix has not yet been deployed 15:08:59 adamw: does bodhi currently rely on QA feedback on critpath packages for F12 too? 15:09:27 oh wait never mind, was misparsing 15:09:49 okay, that's all I've got from last week 15:10:05 I'll need to catch up w/ lmacken once F-13 testing calms down to get a sense for when the deployment will go live 15:10:24 we'll also kick the tires on further defining the proventesters workflow then 15:10:44 * jlaska got a txt from wwoods, he's delayed this morning 15:10:49 okay, now for the big show ... 15:10:55 #topic Fedora 13 RC#2 test status 15:11:09 * kparal adds fireworks 15:11:18 #info upcoming milestone - 2010-05-11 - Fedora 13 Final Go/No-Go Meeting (20:00 EST) 15:11:28 #info upcoming milestone - 2010-05-12 - Fedora 13 Final Release Readiness Meeting 15:11:48 kparal: lots of starburts please! :) 15:12:02 adamw: I misread the schedule, seems #4 blocker meeting was last Wed, not last Friday 15:12:16 robatino: pointed this out last week, but I initially misread the schedule 15:12:33 ah, well, never mind 15:12:58 want to hold a mini-blocker review of the current F13Blocker bugs now? 15:13:11 otherwise, we can chase these down individually outside of the meeting 15:13:34 #topic https://bugzilla.redhat.com/show_bug.cgi?id=590466 15:14:04 did we lose bugbot? 15:14:22 is it not only in #fedora-qa? 15:14:24 sure, let's do a mini-review 15:14:48 there's some confusion about exact cause for this, but anyway, as I posted, i don't consider that a blocker. it can be fixed in an update. 15:14:49 adamw and mgarrett have been talking through /topic issue 15:15:17 nice to see someone testing on a macbook air : 15:15:28 but yes, I'm +1 with that assessment 15:16:21 I don't think Oxf13 is around yet for an additional vote 15:16:49 adamw: how to you intend to proceed ... leave on the list pending feedback from RelEng, or remove from blocker now? 15:17:08 #info confusion as to the exact cause for this bug 15:17:08 i figured we could leave all the nominees on to air at the go/no-go meeting, but i don't mind if we want to demote them now 15:17:59 anything for a faster go/no-go meeting :) 15:18:14 okay, knock it off then 15:18:27 okay, I'll update the bz after the meeting 15:18:44 i've just done it 15:18:47 #agreed QA agreed that 590466 does not impact the release criteria and can be resolved in a future update 15:18:53 adamw: fast fingers strikes again! 15:18:58 #topic https://bugzilla.redhat.com/show_bug.cgi?id=590640 15:19:20 kparal: this is one you encountered earlier today ... what's your estimated impact on this issue? 15:20:00 jlaska: well, I have seen it only when installing from NFS, and only from our local Brno mirror 15:20:08 installing from my own mirror worked well 15:20:40 the impact may be very low 15:21:08 clumens looked into this issue, and was perplexed at what might cause the issue 15:21:19 seems a bit of an unknown quantity 15:21:27 and it's not super-easy to set up different NFS configs to test with :/ 15:21:31 kparal: I remember you uncovered some odd NFS access issues with the brno mirror while testing NFS repos in F12 15:21:36 can we get any more brainpower on it? 15:21:58 clumens looked into it, I can ask him to summarize ... or see if dlehman might have other ideas 15:22:02 I'll work with clumens on resolving it now, hopefully it's just some local mirror problem 15:22:50 #info fails when testing with RHT Brno Fedora NFS mirror, but works when installing from local nfs exported DVD mount 15:23:04 #info unclear user impact, kparal will discuss further w/ clumens for insight 15:23:28 if we can't pinpoint this one further, and no one else is able to hit the same conditions ... should we remove this from the list? 15:23:40 i think we should leave it for now 15:23:46 at least see if we can get better data before tomorrow 15:23:51 it worries me a little bit 15:24:32 #agree 590640 - unclear on impact to release criteria, leave on the list pending additional information 15:24:41 #agreed 590640 - unclear on impact to release criteria, leave on the list pending additional information 15:24:44 #topic https://bugzilla.redhat.com/show_bug.cgi?id=590661 15:25:17 adamw: this is your addition to the list? 15:25:28 sorry no, mether added this 15:25:42 i suspect but am not sure this behaved the same in F12 15:26:13 I'm here now, but for another meeting. 15:26:13 mether thinks otherwise 15:26:17 i can probably try and test it 15:26:18 Oxf13: welcome 15:26:29 though i'm not sure i actually have a windows CD handy here 15:26:43 I can reinstall F-12 on a system that still has a windows partition 15:26:49 so this one you can work around by holding shift 15:26:53 right 15:27:03 which is pretty similar to having to hold something to get the windows boot loader menu 15:27:04 to clarify, this doesn't block the release criteria 15:27:05 ? 15:27:11 it's arguable 15:27:17 and depending on the bug, we might be able to fix this with post-release updates 15:27:21 but we might not. 15:27:31 "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working " 15:27:33 adamw: is this a scenario where the intended behavior is unclear? 15:27:34 if this was the only thing left on the list, I'd be hard pressed to slip for it 15:27:52 Oxf13: that's kind of my feeling. it sucks a lot and i'd love to fix it, but it's hard to do a week slip for it 15:27:58 adamw: hmm, I'm not sure it impacts that criteria 15:28:07 IIRC we were supposed to notice a chain-load and thus have a timeout 15:28:09 is the method for accessing the bootloader screen documented? 15:28:11 yeah, like i said, arguable. _technically_, the criterion is satisfied 15:28:16 adamw, is there a simple workaround or do the user have to edit grub.conf? 15:28:19 and I'm not sure if that's a grub feature, or an anaconda feature 15:28:32 grub.conf can be edited graphically with system-config-boot 15:28:32 mether: the simple work around is to hold shift while booting 15:28:34 * jlaska has another meeting in 1.5 minutes 15:28:35 but my intent when i wrote the criterion was more or less 'it should behave sanely when installing alongside windows', and this is fairly obvious dumb behaviour 15:28:37 #chair kparal adamw 15:28:37 Current chairs: adamw jlaska kparal 15:28:53 Oxf13: unfortunatelly Shift does not work on some PCs correctly, bios reports stuck key and halts 15:29:03 kparal: sure, if you hold it from boot on 15:29:12 kparal: you may have to tap it, or hold it from a later boot point 15:29:14 adamw, I would argue that the listed criteria makes the bug a blocker 15:29:17 just like trying to access the windows boot loader 15:29:18 Oxf13: right, which gets finicky. 15:29:22 or the apple boot loader 15:29:22 does someone have a link to documentation for how to access grub menu? 15:29:32 jlaska: sec 15:29:46 there should be plenty given we went to a 0 timeout a couple releases ago 15:30:45 #info debatable whether this impacts the release criteria 15:30:56 system-config-boot is installed by default in a graphical install, it can be used to change the timeout 15:31:02 #info current dual-boot criteria states -- "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working " 15:31:15 Oxf13: i'm not convinced this behaved the same in f12, i'd really like to check that. remember, we found out the telnet similar bug was a regression from f12. 15:31:21 let's get testing on that 15:31:31 #help Confirm multi-OS bootloader configuration when installing F12 15:31:41 i can't find any documentation of this in f12 or f13 release notes or f12 user guide or any common bugs page 15:31:48 adamw: I don't believe it behaved the same in F12 15:31:58 adamw: at least in dualboot scenario 15:32:03 oh, i see, just general documentation for getting into bootloader 15:32:07 outside of dual boot we indeed had a 0 second timeout for grub 15:32:08 i'm not sure we ever actually wrote anything down 15:32:15 probably a question for the docs team, though. 15:32:28 well, outside of dual boot and serial 15:32:28 i'm sure i never put it in commonbugs, though. 15:32:40 because 0 second timeout isn't a bug 15:32:41 okay, so what's left on this 15:32:42 it's a feature 15:32:49 i think we should discuss this at go/no-go tomorrow 15:32:51 more testing ... and possible documentation of this behavior change? 15:32:54 since it's clearly a tricky one to make a call on 15:33:00 present findings @ go/no_go meeting tomorrow? 15:33:05 and yes, check if this is a regression from f12, and definitely document it if we don't slip for it 15:33:11 okay ... 15:33:27 #action help testing dual-boot behavior in F12 15:33:39 #action identify if any bootloader config documentation exists 15:33:54 * adamw feels dumb, as he noticed this when he installed f13 on this system two weeks ago but never really thought about yelling about it 15:33:55 sigh 15:33:56 #agreed 590661 - remains on the list, pending additional information to be presented @ go/no_go 15:34:18 #topic https://bugzilla.redhat.com/show_bug.cgi?id=590666 15:34:49 this is the last bug on the list 15:34:54 I have more. 15:34:57 Oxf13: okay 15:35:08 adamw: kparal: you have #chair ... /me dual-meeting 15:35:20 adamw: please take this if you can 15:35:36 "take this" ? 15:35:43 the chair 15:35:46 ah 15:36:21 uh 15:36:27 let's see 15:36:59 bastien nominated this and the lid issue, apparently under the impression we could 'fix it in gold', after I chatted to him 15:37:13 i explained there's no possibility of that, either we ship rc2 or slip, and he was okay with dropping this one as a blocker too 15:37:19 but of course we can decide we want to slip for it. 15:37:39 i believe the impact is basically that you can't do tethering with a Bluetooth phone via DUN (which is an F13 feature), until NetworkManager gets fixed 15:37:55 obviously this is quite easy to fix with an update, but it _is_ an F13 feature we're going to ship completely broken. 15:38:01 so, that's the scenario...thoughts? 15:38:08 is it all phones, or just specific ones? 15:38:19 or all bluetooth phone connectivity or just a few? 15:38:35 it's specific to tethering (using the phone as a modem) via Bluetooth DUN 15:38:49 it shouldn't affect other things you can do with a phone via bluetooth (transferring files and whatnot) 15:39:19 and I believe it doesn't affect Bluetooth PAN tethering (that's another way of tethering via Bluetooth, there's two mechanisms, most phones just support one or the other), though i don't think we've directly tested that 15:39:31 i *think* it affects all phones, but not 100% sure; dcbw should know, of course 15:40:30 dan's not around at present it seems, i can ask for a more precise impact assessment in the bug 15:41:10 was it already mentioned what the release criteria impacted was? 15:41:51 I don't think it impacts release criteria 15:41:58 it's just that DUN was a feature 15:42:10 which means that there isn't a regression from 12 15:42:28 i mean, we could theoretically argue it breaks the critpath if your only internet connection is a cellphone and your only way to tether with it is bluetooth, but that's rather farfetched 15:42:53 so it's mostly just the feature thing. 15:43:25 yeah 15:43:31 i'm probably okay with just document+fix in an update for this, really. 15:43:32 and I'm ok with fixing this in updates 15:44:53 +1 15:45:29 okay, let's demote it then 15:45:33 i'll take care of that 15:45:48 #agreed 590666 isn't blockery enough, we can document + fix with an update 15:45:56 #topic YOUR_BUG_HERE 15:45:59 so, oxf13? 15:47:55 you said you had something to add 15:49:07 * kparal pinging Oxf13\ 15:49:17 * adamw pings oxf13 with the giant hammer o' pain 15:49:27 sorry, in a second meeting 15:49:44 I got a report that our live images, at least the desktop one, doesn't have kernel-firmware on it, and as such many devices don't work 15:49:49 no bug yet, somebody shoudl file one 15:49:57 but this I do believe is just a config change, but may have space concerns 15:50:04 ouch, that is something i'd want to respin for 15:50:15 although I don't have kernel-firmware installed here., just a tic 15:50:17 Size : 8165344 15:50:20 that's 8MB right? 15:50:25 yep 15:50:43 hrm, I have "linux-firmware" 15:50:46 that'd give kde spin a few probs, but kde team did identify some packages we can lose from that without having trouble 15:50:47 and a bunch of individual firmware files. 15:50:58 this is just one report though, not confirmed 15:51:18 this person was complaining about intel wireless not working, which I think is managed in a different -firmware package 15:51:31 okay, so we need more info on this 15:51:37 what firmware packages do we have, which of them are on the live images 15:51:56 anyone can boot the desktop live quick and take a look? 15:52:06 and it looks like a ton of firmware goes into the live images. 15:52:39 actually I'd rather have the reporter do some investigation, because from the look of the package set, it should be fine 15:52:43 okay 15:52:43 * kparal booting live image 15:52:48 where's the report here? 15:52:48 so the reporter may ahve jumped to the wrong conclusion 15:52:57 there isn't, it was sent to me as a facebook email. *sigh* 15:53:00 heh 15:53:11 next up, the Twitter bug report 15:53:14 'it duznt work LOL' 15:53:50 so, do you want to know something from live image? 15:53:59 kparal: a quick rpm -qa | grep firmware maybe 15:54:08 linux-firmware is on the live image too 15:54:17 adamw: I already got that 15:54:19 ah 15:54:21 I have the logs from the compose. 15:54:26 intel firmwares should be iwl-*-firmware i think 15:54:28 there is plenty of firmware, this reporter is on crack 15:54:31 iwl*-firmware 15:54:41 and ipw*-firmware 15:55:12 adamw: http://fpaste.org/yWgt/ 15:55:25 I think I'm calling this a non-issue 15:55:29 fc12 package, interesting 15:55:31 until I get more feedback from reporter 15:55:37 * Viking-Ice sneaks in late.. 15:55:39 kparal: firmware doesn't change that often. 15:55:54 that sure looks like all the intel firmware's there. 15:56:08 * kparal could have sorted it 15:56:16 and all the other things i recognize as major wireless firmware, at a glance 15:56:26 kparal: yeah, never mind though =) 15:56:40 Oxf13: is it the same on KDE spin? 15:57:02 yes 15:57:07 * jlaska back from meeting 15:57:12 the firmware stuff likely comes in from the fedora-live-base 15:57:16 then i agree, non-issue 15:57:24 tell your reporter to lay off the crack pipe =) 15:57:33 so #agreed on this? 15:57:38 I'm still curious as to why his intel wifi didn't come up, but it's certainly not because of a missing firmware package 15:57:45 Oxf13: yeah. 15:57:56 #agreed the report oxf13 received about missing firmware on live images appears to be crack 15:58:11 anyone else have a potential blocker issue to bring up? 15:58:24 there are a number of spin-kickstart changes that went in over the weekend 15:58:37 one of which touches on fedora-live-base, which would mean every livecd I've made would have to be re-spun 15:58:53 I need to review the change and discuss it with the developer to see what's going on here. 15:59:04 I'm quite a bit disturbed at all the late changes to spin-kickstarts 15:59:29 Oxf13: could that git repo benefit from release specific branches? 15:59:41 that does seem silly. perhaps we should have a freeze on spin-kickstarts close to RC time. 15:59:43 and to make moblin work, they need an updated package or two, which should only exist on the moblin spin (and the everything repo) so tagging those isn't a big deal. 15:59:53 adamw: we do, the problem is lack of testing until RC time 16:00:00 ah :) 16:00:01 to be fair, I announced "get your spins working" rather late 16:00:51 Anyone have any non-bug discuss topics today? 16:01:37 jlaska: summer of code 16:01:38 #topic open floor 16:01:48 #topic open floor: summer of code 16:01:50 go for it, kparal 16:02:19 ok 16:02:33 as you may be know, there's Fedora's Summer Coding 2010: http://fedoraproject.org/wiki/Summer_Coding_2010 16:02:51 there are already quite some ideas proposed: http://fedoraproject.org/wiki/Summer_Coding_2010_ideas 16:03:19 our QA team created a few proposals themselves: https://fedoraproject.org/wiki/QA:Summer_of_Code_Ideas 16:03:39 * jlaska has to flesh out a few more ideas 16:03:59 we would act as a mentors for students implementing those ideas 16:04:02 the problem is we don't know how many resources this effort would need 16:04:26 so, it really needs someone devoted and enthusiastic for this matter :) 16:04:38 a lot of our proposals don't have any mentor 16:04:50 * Viking-Ice got one after kparal finishes 16:05:08 so we'd like mentors and possibly students for the QA ideas? 16:05:09 so if there is someone, who would like to mentor some of them (or propose some other idea from QA world), that would be fantastic 16:05:33 yes, we need to find mentors amongst ourselves 16:05:39 and then find students :) 16:05:54 or the students should rather find us 16:06:04 we would blog about the opportunities etc 16:06:18 the deadline for ideas is May 13th 16:06:34 and then another week for student applications 16:06:41 that's three days, for the temporally vague =) 16:06:55 so, anyone got really really interested? :) 16:07:28 it would mean creating a detailed description for a chosen idea or creating your own 16:07:36 * adamw just wants to finish f13 release then crawl into a corner and die quietly 16:07:37 and then mentoring a student over holidays 16:07:51 (July, August) 16:08:11 anyone have experience mentoring (or as a student) on a summer of code project? 16:08:21 good question, thanks jlaska 16:09:20 nope 16:09:21 #help if you have experience (as a student or mentor) with Summer of code, please contact the QA team 16:10:37 well, seems like no response to me... 16:10:55 I have no time to spend on it this summer 16:11:08 * jlaska just unsure what is required ... would love to hear back from someone who participated in such an event in the past 16:11:13 sorry, i'm sort of interested but also frazzled from f13 cycle and behind on other things, so it's hard to get motivated to go and look at this now 16:12:22 alright. if we don't find a voluteer for mentoring, then I think it will have to wait for some other time 16:12:31 you can put a call out on the list 16:12:54 on a positive note, we now have a place to start collecting project ideas for anyone interested in getting involved in Fedora QA 16:13:13 #link https://fedoraproject.org/wiki/QA:Summer_of_Code_Ideas 16:14:32 Shall we move on to Viking-Ice's discussion topic? 16:14:41 Ok.. I think we need to know which packages we ship contain dead or little to no active upstream and perhaps warn users on install time and let reporters and bugzappers know about those. I do believe we are wasting of everybody's time dealing with theses packages.. 16:15:12 #topic open floor: reporting on upstream activity 16:15:27 Viking-Ice: how do you measure upstream activity? 16:15:34 sounds more like a development topic to me... 16:16:01 i'd quite like something like this too, but it's quite icky to automate, as there's almost as many organization systems for upstream projects as there are upstream projects 16:16:35 jlaska: commits $ time . 16:17:11 adamw: packagers burden to keep track on.. 16:17:54 packagers know ( or atleast should know ) if upstream is dead or not 16:18:00 it's a clever idea, seems worth a proposal that outlines the scope of the problem, severel methods for reporting on upstream health ... and circulating around devel@ ? 16:18:44 it would seem hard to device an accurate heuristic that would work ... but it's an interesting idea 16:19:06 Well we actually need also to get some bugzilla activity stats got go with it.. 16:19:25 maybe just bugzilla could allow to mark some components as "with dead upstream" and particular maintainer could trigger that setting? 16:19:28 How much resource are we spending in dealing with dead upstream 16:19:32 and then it would be shown to bug reporters 16:20:03 Viking-Ice: yeah, not a bad project idea ... just needs someone to define the problem space and pull together some recommended solutions for review? 16:20:25 Viking-Ice: were you volunteering, or just looking for feedback on the idea? 16:20:53 kparal: I think this needs to be flag at install time so if a end user hits a bug he can be assured there's no point in reporting it 16:21:25 Vikings-Ice: just in feed back stage at the moment.. 16:21:44 Viking-Ice: okay 16:21:55 if there's nothing else for today ... let's close out the meeting 16:21:59 (1 minute from #endmeeting) 16:22:18 If this is a generally considered a good idea for #future to work on.. 16:22:32 it'd certainly be good to have it, yep. 16:22:58 yeah, is this a common request from maintainers of dead upstream projects? 16:23:08 good discussion to take to the list 16:23:10 list(s) 16:23:29 endmeeting extended ... closing in 30 seconds 16:23:44 this is a packagers burden so let's wait for other things to cool down first ;) 16:23:58 on "the" list first 16:24:14 sounds like a plan 16:24:20 okay folks ... thanks for your time 16:24:26 kparal: adamw: thanks for the #chair assistance 16:24:29 #endmeeting