15:00:19 #startmeeting Fedora QA Meeting 15:00:19 Meeting started Mon Jul 12 15:00:19 2010 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:24 #meetingname fedora-qa 15:00:24 The meeting name has been set to 'fedora-qa' 15:00:30 #topic Gathering ... 15:00:40 * jlaska waits a few minutes for folks to arrive 15:00:56 mor-diddly-orning 15:01:14 * jskladan tips the hat 15:01:17 * kparal joins up 15:01:24 * dafrito waves 15:01:36 * tertl3 arrives 15:01:36 * j_dulaney killes a Kligon 15:01:45 kills 15:02:06 * j_dulaney decides to sleep as soon as this is done 15:02:18 what an attendence :) 15:02:26 nice 15:02:31 better than last week 15:02:35 * wwoods here 15:02:43 howdy all 15:02:45 * vaschenb newbie is nervous :-) 15:02:55 * Southern_Gentlem 15:03:07 vaschenb: why? 15:03:25 he don't know what tortures to expect :) 15:03:28 j_dulaney: it's my first time :-D 15:03:29 Read and learn 15:03:34 he's still waiting for the hazing to start :) 15:03:35 Ah 15:03:45 alright, time to start thinning the herd! 15:03:46 oh boy a new guy! do we have the dump truck full of manure ready or what 15:03:48 * adamw revs up the chainsaw 15:03:52 wwoods: haha 15:03:53 I mean er uh. WELCOME 15:04:06 oh, that's right, wwoods - manure before chainsaw. where ARE my manners 15:04:12 :-D 15:04:17 lol 15:04:21 tertl3 is also new 15:04:31 * jskladan lolz 15:04:34 yes 15:04:38 I am a noob 15:04:48 alrighty, I think we have critical mass ... let's get started 15:04:59 tertl3: welcome into virgin group :-) 15:05:14 #topic Previous meeting follow-up 15:05:20 #info jlaska to cleanup (or remove) the Critical Path Packages#Background section so that it provides _some_ value 15:05:40 nothing sexy, but I added some wording to http://fedoraproject.org/wiki/Critical_Path_Packages#Background 15:06:06 that looks a lot better. 15:06:14 Unless there is rioting in the streets, let's get this off my list :) 15:06:44 no riots here ;) 15:06:44 dafrito and adamw are the wiki-experts ... suggestions always encouraged 15:06:52 alrighty ... thanks 15:07:09 this next one really has several threads tracking it ... 15:07:11 #info j_dulaney to draft a combined proventesters / joinproventesters wiki page for list review 15:07:28 we have a few drafts ... shall we save the updates on this for the proventester update 15:07:36 sure, that'd make sense to me 15:07:41 Indee 15:07:41 alrighty ... 15:07:43 indeed 15:08:00 last one ... 15:08:08 #info wwoods to evaluate nss-softokn dependency problem for proper 'depcheck' coverage 15:08:16 and from what I can tell, this was done already 15:08:17 #link http://lists.fedoraproject.org/pipermail/devel/2010-July/138478.html 15:08:33 right - we still want to write up a test case for this, when we start writing depcheck test cases 15:09:01 roger, I think you've got that captured already in trac too 15:09:04 but I think that description of the problem will be sufficient to allow that, and theoreticallly depcheck should catch that, if it runs mash 15:09:08 (which it will) 15:09:14 cool 15:09:41 alrighty ... that's all I had on my list from last week 15:09:43 anything I missed? 15:10:25 okay ... diving into the agenda 15:10:29 2 brief updates ... 15:10:34 #topic Pre-Alpha Rawhide Acceptance Test Plan #1 15:10:54 < insert thunder and lightning > 15:11:10 * j_dulaney ducks and covers 15:11:19 it has started ... we hit our first of 3 Fedora 14 pre-alpha acceptance test milestones last Thursday 15:11:55 these are still very much experimental test runs ... intended primarily to run through the rawhide acceptance test plan 15:12:28 updated anaconda+pykickstart were built last week, and install images were built by rel-eng over the weekend 15:12:50 Testing is underway ... and I'll send a test summary to the list in the next day or so 15:12:59 available in the nightly builds? 15:13:17 no ... nightly installable rawhide images are not provided 15:13:35 this milestone is intended to help scrub custom-built rawhide install images before F-14 Alpha ... to help shake out early bugs 15:14:03 #info jlaska to send test summary to test@l.fp.org once complete 15:14:05 #link https://fedoraproject.org/wiki/Test_Results:Fedora_14_Pre-Alpha_Rawhide_Acceptance_Test_1 15:14:08 the nightly composes are running, though. and i think they're rawhide. 15:14:44 yes indeed, those are just package repos. So as always, you can update to rawhide using the documented procedures 15:14:57 https://fedoraproject.org/wiki/Releases/Rawhide#Installing_Rawhide 15:15:06 Okay, next up ... 15:15:12 #topic Fedora 14 Install Matrix Review 15:15:32 er, what? i mean the nightly live images. 15:15:32 Hurry (rhe) has been putting the finishing touches on the much improved install test matrix 15:15:39 oh well. 15:15:41 adamw: ah I see, yes you are right :) 15:15:54 adamw: too much nightly content to keep track of 15:16:11 fwiw, i don't particular recommend rawhide right now, for GNOME anyway. it's so broken i'm in XFCE. 15:16:21 just as a note =) 15:16:24 #info Hurry has an updated F14 install test plan out for review at - https://fedoraproject.org/wiki/QA:Fedora_14_Install_Test_Plan 15:16:29 adamw: good to note, thanks 15:16:42 * j_dulaney couldn't get it to boot last time he tested it 15:16:45 #info Hurry has an updated F14 install test matrix out for review as well - https://fedoraproject.org/wiki/QA:Fedora_14_Install_Results_Template 15:16:46 i've been following the trac tickets, looks like nice stuff 15:17:03 yeah, should be some nice improvements 15:17:20 easier to see which tests/results impact the different use cases (cd, dvd, boot.iso etc...) 15:18:01 Hurry welcomes feedback on those 2 wiki documents. Unless anything drastic, we'll be using those to track install testing for F-14 15:18:40 okay ... next topic ... 15:18:50 #topic Proventester Update 15:19:01 quite a bit of wiki love over the last week 15:19:14 who wants to take this one? 15:20:07 there ended up being three drafts, and I think we settled on adamw's 15:20:21 drafts: 15:20:39 https://fedoraproject.org/wiki/User:Adamwill/Draft_proventesters <--- adamw 15:20:58 https://fedoraproject.org/wiki/User:Dafrito/Proven_tester <--- dafrito 15:21:15 https://fedoraproject.org/wiki/User:Jdulaney/Proven_Tester <--- j_dulaney 15:21:53 I believe adamw's to be the best 15:22:10 dulaney's came first, then dafrito's, then mine. so far, dafrito and I say we prefer mine, mike c says he likes it too, no-one else has said much. =) 15:22:33 I also like how none of us can agree on the page name =) 15:22:43 LOL 15:22:46 does this replace [[QA/JoinProvenTesters]] and [[Proven_tester]]? 15:22:47 hehe 15:22:54 jlaska: indeed 15:23:14 adamw's seems to be the clearest of the lot to me. 15:23:35 My version is a kluge combining what was really two drafts. 15:23:39 yeah, I like adding back the sections for specific types of feedback ... but like I said in email, that might be specific to the odd way my brain works :) 15:24:16 so, should we consider this topic _voted_ on then? 15:24:25 jlaska: I concur 15:24:33 however you spell it 15:24:37 if so i'll go ahead and move mine into the live namespace, and edit one of the pages to be a redirect to it 15:24:40 j_dulaney: got it in one 15:25:00 yeah, my version was off-topic, I'd go with adam's 15:25:08 +1 15:25:31 I'll go ahead and axe mine 15:25:42 btw ... good work all around folks, nice to see this process flow with proposed drafts 15:26:19 Did we want to rename the page to proventesters as well? 15:26:36 nah, i'll keep the Proven_tester name 15:26:37 let's see how many different page names we can come up with :) 15:26:41 it's best to avoid page renames whenever possible 15:26:53 mediawiki gets lost after one level of redirects 15:27:09 really? doh 15:27:21 i'll put this draft into the Proven_tester name and edit JoinProvenTesters to be a redirect to it 15:27:32 kparal: yeah. try creating a page, then rename it twice, then go to the URL of the first name 15:27:36 adamw: I'd say go ahead 15:27:58 the websites team has a script they run periodically to remove all those double/triple redirects 15:28:07 but still, it can get confusing 15:29:22 #info team agreed to make [[User:Adamwill/Draft_proventesters]] the official [[Proven_tester]] page 15:29:39 Alright, I'm not aware of anything else we need to be tracking for Proventesters 15:29:56 perhaps the proventester mentor requests? 15:30:27 I was going to ask, how do y'all thik it's going since activation? 15:30:37 well, it's hard to tell 15:30:40 that's one thing i wanted to mention 15:30:46 that brings up a good follow-up topic 15:30:48 it'd be nice to be able to track proven tester feedback 15:30:57 after all, we all know how easy metrics are! (sorry, injoke for the bugzappers crowd) 15:31:24 lmacken: has some scripts he used to generate metrics ... we could investigate using those scripts for a weekly test summary? 15:31:40 http://lists.fedoraproject.org/pipermail/devel/2010-June/137413.html 15:31:49 i think there's already a report on bodhi feedback sent to -devel periodically; i've been meaning to email the author to ask if it can be adjusted to report only on feedback from proventesters, and only for critpath packages 15:32:22 There seems to be a lot of 0 karma 15:33:19 I'm seeing 11 untested F13 critpath updates - https://admin.fedoraproject.org/updates/critpath?release=F13&untested=True 15:33:28 In several cases, it seems that the 0 karma was given for packages that are core to Fedora, but people are unfamiliar with them 15:34:12 Shall we keep this on the list for a future meeting? 15:34:22 It seems that folks aren't looking at what a package does 15:34:35 * j_dulaney is guilty of that 15:34:54 adamw: do you have a link to one of those sample reports? Perhaps someone is interested in following-up on that topic? 15:35:21 i can see a couple of packages in that report which are somewhat trickyt 15:35:26 might be good to ask the package maintainers for some info about how to do basic package verification/acceptance 15:35:35 *somebody*'s gotta have a clue 15:35:39 for koji and mash, clearly we need someone in releng to be active as a proventester 15:35:40 e.g. mash, koji 15:35:51 iscsi-utils is very hardware-specific 15:36:01 Indeed 15:36:03 as is wacom 15:36:09 adamw: not really - you can have both iscsi endpoints be all-software, as I understand it 15:36:13 wacom, yes 15:36:19 wwoods: okay, knowing-what-the-hell-you're-doing specific =) 15:36:29 what is wacom? 15:36:36 one could argue that all package testing has that specific requirement. 15:36:36 j_dulaney: tablets 15:36:40 Ah 15:36:42 j_dulaney: (the ones artists use) 15:36:45 so do we have 2 topics here ... 15:36:45 wacom tablets are far less rare 15:36:46 I'm a moron then 15:36:48 I have one 15:36:49 you can get one for like $40 15:36:53 1) generating proventester metrics 15:37:00 wwoods: sure, you know what I mean - knowing-what-the-hell-you're-doing-with-something-somewhat-obscure 15:37:02 I didn't think about using it for testing 15:37:10 2) providing some package-specific wiki test guidelines 15:37:11 ? 15:37:24 j_dulaney: okay, then problem solved - plug it in, check you can scribble on it at every boot, and +1 the wacom updates 15:37:40 adamw: roger 15:38:29 jlaska: i can't find the karma reports i'm thinking of, any more :/ 15:38:36 jlaska: i'm fairly sure it wasn't just an opium dream though... 15:38:39 adamw: did you see the lmackenreport I linked to above? 15:38:50 yeah, that's not what i was thinking of, though close 15:38:52 okay 15:38:58 i guess it's not too important, obviously luke's the guy to ask 15:39:15 * adamw strictly follows his rule to never touch a drop of opium till after 2pm 15:39:33 okay ... anyone want to take this up with Luke, see how perhaps we can generate proventester reports on a recurring basis? 15:39:39 i will 15:39:57 everyone take 1 step back ... except adamw! 15:40:00 hehe 15:40:13 thanks adamw 15:40:28 one other from the list; openldap is there because it can be involved in login, i think? 15:40:32 #action adamw to talk with lmacken about generating recurring email reports on proventester 15:40:39 so we kinda need someone with an LDAP auth system to +1 those updates 15:41:04 I wish there was a list somewhere of what the critpath updats do 15:41:06 I think sudo requires it 15:41:19 jlaska: oh, hmm...didn't know that 15:41:34 j_dulaney: how do you mean, exactly? what the update changed? 15:41:37 okay, so anything else we want to track on this topic for next week? 15:42:01 hum 15:42:06 i think the mentoring process is going fine so far 15:42:08 adamw: What the library does, so we know if we can test it or not 15:42:32 j_dulaney: ah, so just what jlaska mentioned above 15:42:59 j_dulaney: a couple of things you can do - look at the RPM description (rpm -q packagename) and also what requires the package (use repoquery for that) 15:43:08 that often gives you a good idea of what it's for 15:43:13 # repoquery -q --whatrequires $foo 15:43:32 ITYM rpm -qi packagename 15:44:20 @ping 15:44:20 @ping 15:44:21 pong 15:44:21 @ping 15:44:22 pong 15:44:23 pong 15:44:33 that was odd 15:45:05 Ugh 15:45:08 @ping 15:45:08 j_dulaney: You've given me 3 commands within the last minute; I'm now ignoring you for 5 minutes. 15:45:22 alright, I'd like to leave at least 15 minutes for the last topic 15:45:22 j_dulaney: please don't do that in the channel, esp. in the middle of a meeting 15:45:37 j_dulaney: consider privmsgs for talking to the bot 15:45:40 anything else to track for next week? 15:45:45 I apoligize, my connection went wacky 15:46:29 alrighty ... we'll follow-up on the metrics topic next week then 15:46:30 thanks folks 15:46:34 next up ... 15:46:35 wwoods: rpm -qi gives you the package description. repoquery --whatrequires tells you what requires it (well, you also have to do it for everything it provides). 15:47:18 (adamw: right you said "look at the RPM description (rpm -q packagename)" - rpm -q isn't gonna give you the description.) 15:47:22 #topic AutoQA Package Update Acceptance Test Plan 15:47:50 wwoods: apologies, I was hoping to leave you more time to discuss today 15:48:01 wwoods: oh yes, thanks :) 15:48:23 jlaska: s'ok 15:48:50 so right - we've got this excellent acceptance plan for package updates 15:48:54 https://fedoraproject.org/wiki/QA:Package_Update_Acceptance_Test_Plan 15:49:05 and we've been working on automating as much of it as possible 15:49:23 (preferably everything) 15:49:28 kparal: indeed! 15:49:49 one of the key things adhering to this plan *should* accomplish 15:49:57 is preventing us ever having broken deps in the repos (yay) 15:50:09 big yay! 15:50:29 among other various important things that will be helpful for packager/tester sanity. 15:50:54 so. we've had this plan kicking around a long time, I've been messing with the depcheck test for months, etc. 15:51:04 and now we've finally got autotest/autoqa running in the Fedora infrstructure 15:51:21 AND the Fedora 14 release cycle is starting up soon 15:51:42 so I feel like now's a good time to try to get as much done on the PUATP as possible. 15:51:51 I broke things up into a few milestones: 15:51:58 https://fedorahosted.org/autoqa/milestone/Package%20Update%20Acceptance%20Test%20Plan 15:52:05 https://fedorahosted.org/autoqa/milestone/Package%20Update%20Acceptance%20Test%20Plan%20-%20package%20sanity%20tests 15:52:11 https://fedorahosted.org/autoqa/milestone/Package%20Update%20Acceptance%20Test%20Plan%20-%20depcheck 15:52:14 blerg, long URLS 15:52:28 but you can just check out the roadmap - https://fedorahosted.org/autoqa/roadmap 15:52:37 * kparal has installed %20->space converter into his eyes 15:53:19 * adamw needs some o' those 15:53:39 * j_dulaney notes he could get involved here. 15:53:52 kparal: you pointed out that we had a goal-setting meeting a while back and decided that resultdb was basically the Top Of The List for stuff we wanted to get done 15:54:07 which is still true for the larger roadmap, I think 15:54:26 yea, I remember it somewhat like that :) 15:54:47 right - that's definitely an incredibly important part of the AutoQA roadmap 15:55:00 but I think that can go on in parallel with automating PUATP 15:55:18 and there are a lot of people interested in seeing PUATP automated as soon as possible 15:55:25 I think the important part is not having everyone work on 5 different tasks. but we can shift priorities if needed, that's no problem 15:55:34 kparal: agreed 15:55:37 +1 15:55:47 indeed 15:55:53 so I'm suggesting that - as much as is possible - we should shift work to PUATP-related tasks for a while 15:56:05 alright, so depcheck testing is the #1 now? 15:56:10 j_dulaney: for a start, subscribe to autoqa-devel list 15:56:21 j_dulaney: https://fedorahosted.org/mailman/listinfo/autoqa-devel 15:56:23 adamw: roger 15:56:34 I keep getting approached by board members / desktop team members / etc asking about depcheck and friends 15:56:37 I know FESCo is interested 15:56:48 and we've put a good deal of work into PUATP already 15:57:15 and I'd love to have it functional - it'll make us look real good if it works the way we want it to 15:57:17 wwoods: ok, so I believe there's enough work even for me, right? :) 15:57:18 heh 15:57:29 kparal: yeah I think there's plenty to go around! 15:57:30 heh 15:57:34 should we all work on it? 15:58:06 In as far as you can find tasks/tickets to take, definitely 15:58:14 alright then 15:58:36 I'd like to get it moved far enough forward that we have at least a couple of the mandatory PUATP tests running for new updates 15:59:14 I'm not suggesting NO WORKING ON ANYTHING UNTIL THIS IS COMPLETE 15:59:38 that's obviously sill 15:59:39 err, silly 15:59:50 * kparal is fine with taking it as the main point of focus 15:59:54 * j_dulaney will slave to get it done 15:59:55 but let's seriously all try to take bits and pieces and get this thinger done 16:00:00 wwoods: you mentioned a sprint idea in your autoqa-devel mail, are the type of remaining tasks things that might lend well to a day of hacking on this stuff? 16:00:28 that would be cool 16:00:28 ok, from my point of view - i'd like to see the "common base class for tests" in master (at least smth like that) at least before we start with the "multiple hook tests" 16:00:34 * kparal will need some help with getting started on depcheck, maybe sprint could help 16:00:46 jlaska: yeah I think so! the package sanity tests, for instance - those tickets could use a day's worth of work 16:01:07 jskladan: absolutely agreed - I'm going to review that patch right after the meeting 16:01:07 other than that, i don't see any obstacle on the road (yet :) ) 16:01:12 and the same for kparal's label patch 16:01:23 because we need that for ticket #156 in the package sanity tests 16:01:28 and for proper virt stuff 16:02:21 I think its agreed, we will start working on depcheck and its requirements 16:02:27 now we're kind of over time for the meeting, but we can divide up a few obvious tickets right now 16:02:35 well, sadly i need to go home after the meeting, but feel free to potentialy bug me via email and i'll respond during my night time, or we can check the code via telephone tomorrow or smth like that, if you should find it too confusing/not ok/whatever 16:03:08 or - yeah, I don't want to keep the Brno guys (it's beer-o-clock there!) 16:03:19 * j_dulaney wants something to start on 16:03:25 so if we're agreed that depcheck / PUATP is the thing to do 16:03:25 * jskladan wwoods reads minds! :) 16:03:49 either feel free to take tickets in trac 16:04:01 or let's discuss who should/can take tickets on autoqa-devel 16:04:10 j_dulaney: definitely recommend subscribing to that list 16:04:21 wwoods: already have 16:04:22 https://fedorahosted.org/mailman/listinfo/autoqa-devel 16:04:23 wwoods: I'll try to explore it a little (probably ask you some stuff) and then start working on some of its tickets 16:04:25 excellent 16:04:36 yeah I'm happy to answer questions or provide assistance on any of it 16:05:01 if anyone wants to take the HelloWorld test, that's probably a pretty easy ticket for anyone with a bit of python skill 16:05:29 maybe a good start for vaschenb ;) 16:05:42 kparal: I was thinking that too, actually 16:05:54 that's: https://fedorahosted.org/autoqa/ticket/195 16:06:43 huh :-) 16:06:47 also: if there's tickets that seem invalid / unneeded for finishing PUATP, either move them around or bring it up on the list or in #fedora-qa 16:06:58 wwoods: what's the finish line for us ... closing out all three of the milestones you linked above? 16:07:21 yeah - I'd like to see all three of those milestones complete before, let's say, F14 Beta 16:08:00 That's October 15, according to http://poelstra.fedorapeople.org/schedules/f-14/f-14-quality-tasks.html 16:08:23 Actually, I think we could probably shoot for F14 Alpha 16:08:34 (September 7) 16:08:49 kparal: ok, tomorrow I'll do what you want, now I've to go destroy my body... 16:08:56 perhaps even just the depcheck milestone by F14-Alpha 16:09:09 once we hit Alpha we're going to want to put more work into release testing / installer automation 16:09:13 and the remainder by F14-Beta (bonus points of course for wrapping this up early too) 16:09:24 but ideally this should all be up and running when F-14 is released 16:09:40 so F14 can be one of the smoothest releases we've ever had 16:09:47 and then we all get well-earned QA Victory Beers 16:09:59 heh, I like those 16:10:00 jlaska: that sounds like a reasonable schedule 16:10:17 anyone object / further discussion on timelines? 16:10:21 * vaschenb is out, idling here for complete log of meeting... 16:10:47 vaschenb: cya 16:11:03 vaschenb: log will be available on wiki pages and in ML 16:11:26 * wwoods takes that as "no objections", updates milestone due dates 16:11:42 wwoods: thanks! 16:11:52 I better go steal all the easy tickets first! (just kidding) 16:12:06 * j_dulaney wants the easy stuff 16:12:20 The idea being I start off easy 16:12:26 kparal: I might bug you for rpmfluff info and/or help writing depcheck test cases (ticket #202) 16:12:44 wwoods: yes, sure 16:12:52 the pst tickets need review - some of them are finished/obsolete, like #139: "pst: Find a way how to test packages coming to updates-testing" 16:12:57 that's the post-bodhi-update hook, yay 16:13:15 wwoods: we were actually thinking to ask vaschenb to use rpmfluff to create a few broken packages for us. but we will see 16:13:19 can we schedule a pst ticket sprint day sometime this week? wednesday maybe? 16:13:26 kparal: ooh, also a good idea 16:13:44 or maybe j_dulaney? rpmfluff is a fun little tool 16:13:48 is rpmfluff C or python? I forget 16:13:54 wwoods: I would wait with the pst stuff 16:13:58 wwoods: rpmfluff is python 16:13:58 I'd like to look into it 16:14:40 kparal: fair 'nuff 16:14:48 wwoods: pst stuff can wait until we have depcheck working. pst stuff wasn't really worked on recently, because psplicha had some other work. but we will surely come back to it 16:15:08 okay, let's revisit pst status in next week's meeting 16:15:34 first priorities are: multi-hook testing, label / base test class patches 16:15:52 and the depcheck test 16:16:03 * Viking-Ice joins in Better late then never ;) 16:16:24 someone should review output of rpmlint / rpmguard on the -results list 16:16:48 err. I mean. do we have a policy about which rpmlint/rpmguard test results we actually want to consider errors/failures 16:17:02 or should someone review the current output we've been getting and write such a policy? 16:17:09 writing one would be good 16:17:14 we probably need to run that past the packaging folks 16:17:14 i don't believe there is such a policy 16:17:27 I would do one thing after another :) 16:17:30 adamw: ah - well the PUATP will require one 16:17:39 will, i do not want to be mean or something, but looks like we're heading back to the "all at once" again :)) 16:17:51 jskladan: heh, maybe you're right 16:18:07 if the output from those tests is more than just informational, yeah, we'd need to work that path. But perhaps that's a future task? 16:18:22 wwoods: there's https://fedoraproject.org/wiki/Packaging/Guidelines#rpmlint 16:18:35 wwoods: that's about the most 'official' thing that currently exists, afaik 16:18:39 so yeah, depcheck only this week, we can do a status checkin on pst and rpm{lint,guard} policy next week sometime 16:18:59 wwoods: the priority you outlined earlier seems pretty focused to me: multi-hook testing, label/base test class patches and depcheck 16:19:17 jlaska: +1 16:19:25 jlaska: right, just want to be sure we're accounting for all the PUATP pieces in the medium-term 16:19:30 that's 2 milestones ... and then working those 2 patches into master, right? 16:19:35 yup! 16:19:37 wwoods: ah, true true 16:20:11 okay, I'll include a link to each of those milestones in the minutes 16:20:21 and the other PUATP pieces.. we just reviewed them and kparal and jskladan have gently reminded me that they can wait 'til later 16:20:24 heh 16:20:33 * j_dulaney apologizes for bad connection 16:20:56 anything others can do to help with those 2 patchsets out for review? 16:21:14 wwoods: I don't know if you got my request to email me info on rpmfluff? 16:21:30 jlaska: not sure. documenting changes / new capabilities perhaps? 16:21:42 we'll probably need to update the wiki pages on writing new tests, for instance 16:21:49 wwoods: and that I'd like in on that? 16:21:51 wwoods: okay ... I'll jump on kparal's label thread tomorrow 16:22:15 j_dulaney: google is your friend ... https://fedorahosted.org/rpmfluff/ 16:22:50 j_dulaney: didn't see that, but I'll definitely try to keep you in the loop 16:23:10 thanks jlaska, wwoods 16:23:17 any other thoughts/concerns before open floor? 16:23:32 not from kparal 16:24:33 Chan 'eil idir as j_dulaney. 16:25:13 okay, thanks gang. wwoods I'll try to capture this in the minutes, but kick me if I miss anything 16:25:18 jlaska: with gusto 16:25:25 not too much gusto :) 16:25:37 * wwoods brought the extra-heavy boots 16:25:37 #topic Open discussion - 16:25:54 wwoods: hah ... not the steal tipped kodiac work boot 16:26:00 * j_dulaney has nothing 16:26:10 okay gang, we've run over today ... that's my fault for not leaving enough time 16:26:12 I asked for one thing to add to the list 16:27:03 upstream bugzillas vs our bugzilla should reporters be directed to upstream bugzilla tracks system and what not 16:27:22 Where does QA stand on this issue 16:27:29 i don't think we have time to discuss that properly now. 16:27:30 hi 16:27:39 this is a long meeting 16:27:39 adamw: why not 16:27:48 tertl3: they're not usually this long, heh 16:27:50 tertl3: not usually this long, thanks for sticking around :) 16:28:08 not problem, I was playing TF2 16:28:14 we need to settle this once and for all 16:28:14 i play it in a windpw though 16:28:15 Viking-Ice: we're already 30 minutes over time =) 16:28:20 * j_dulaney is about to pass out 16:28:33 j_dulaney, dont drink the Nyquil! 16:28:42 Viking-Ice: I'd say that's more a bugzappers question but my gut feeling is that plain ol' bug-reporting users should be reporting stuff to RHBZ 16:28:42 LOL 16:28:54 j_dulaney, i'm just kidding 16:29:12 wwoods: this affects all QA mostly reporters thou and perhaps triagers 16:29:16 i like the tylenol cold and cough 16:29:23 * jskladan needs to go, bb gang! 16:29:23 but that our talented and well-trained bugzapper ninja squadrons should feel free to copy/move bugs upstream as they see fit 16:29:27 jskladan: take care 16:29:39 peace 16:29:53 wwoods: practically speaking that ain't going to solve the problem, as bugzappers coverage hovers solidly around the 2% of components mark... 16:29:55 wwoods: is it not the maintainers responsibility do play that role not the triagers one 16:30:03 I havent booted into fedora in a few days 16:30:14 Viking-Ice: I'm not sure I understand what the "issue" is 16:30:31 there are clear instructions on when to file upstream, vs when to file in Fedora? 16:30:44 jlaska;: reporters being directed to upstream bugzillas 16:30:53 jlaska: I've not seen such 16:30:55 they are or aren't being reported to upstream? 16:31:09 I personally report to upstream whenever possible, whenever I'm sure it's not Fedora specific 16:31:25 maintainers close bug file this stuff upstreasm 16:31:27 upstream 16:31:41 is that good, bad? 16:31:45 what's your stance/recommendation? 16:31:46 when in fact they should act as the bridge between components the maintain and upstreasm 16:31:52 upstreasm 16:31:52 ah 16:31:57 frack 16:32:00 upstream! 16:32:18 my stance is simple all bugs should be reported to our bugzilla 16:32:30 wait is this about that thread on the devel list? are maintainers closing bugs in rhbz and saying "file this upstream instead" or something? 16:32:41 and maintainers should act as the bridge between upstream bugzilla and our bugzilla for their component 16:33:10 Viking-Ice: yeah historically that's the policy, and anything that needs upstream attention either a) the upstream is alert and pays attention to our bugzilla, or b) the maintainer or some diligent tester pushes things upstream when needed 16:33:15 wwoods: reoccurring thread happens every release sometimes often in the release cycle 16:33:36 general policy is still "fedora reports go to rhbz" 16:33:49 don't think we've changed anything about that 16:34:05 Ugh, can't type fast enough in current state. 16:34:37 wwood: Well some maintainers ignore or simple close bugs wontfix file upstream 16:35:16 File problem with maintainers? 16:35:18 waste of everybody's time reporters triagers and maintainers mean if this is going to be the procedure then simply remove the components from our bugzilla 16:35:19 so this is about that mail thread. 16:35:37 that thread gets a big tl;dr frmo me 16:35:49 Viking-Ice: I think that's a bit extremist 16:35:51 wwoods: yup it's "why the WONTFIX?" this time 16:36:04 jlaska: not really 16:36:06 alright, so we're not going to reach any conclusions on this topic in the meeting 16:36:21 indeed 16:36:25 worth thinking about, maybe revisit in other meetings 16:36:35 unless others want to weigh in, let's take this up at a future meeting, or on list 16:37:15 listsounds good, too drawn out for meeting 16:38:07 Viking-Ice: alright, if we have something that needs review of finalizing for next week ... I'll add it to the list 16:38:23 otherwise ... we can continue the debate/discussion on the list 16:38:26 we need to settle this or atleast provide QA stance on the topic 16:38:40 put it on next meetings agenda 16:38:50 gather feedback from the list this week 16:39:07 I'm missing the exigency, but am open to learning 16:39:29 okay folks ... thanks for your time today 16:39:38 as always, I'll send minutes to the list/wiki 16:39:42 #endmeeting