15:02:01 #startmeeting Fedora QA meeting 15:02:01 Meeting started Mon Oct 14 15:02:01 2013 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:02:03 #meetingname fedora-qa 15:02:03 The meeting name has been set to 'fedora-qa' 15:02:09 #topic Roll call 15:02:35 * roshi is here 15:02:43 * mkrizek is here 15:03:16 * tflink is present 15:03:30 * brunowolff is lurking 15:03:35 #chair tflink brunowolff 15:03:35 Current chairs: adamw brunowolff tflink 15:03:47 * jskladan lurks 15:04:03 dgilmore: you about? we might need to check in on tc status 15:04:18 adamw: i am 15:04:25 thanks 15:05:49 alrighty, let's get going 15:05:53 #topic Previous meeting follow-up 15:06:44 #info "adamw to co-ordinate with anaconda team to get a new anaconda build done and roll TC2" - did that, TC2 got built with the stuff we wanted, and we're now onto TC3ish 15:07:04 " tflink and handsome_pirate to write up detailed proposals for projects to be worked on in a possible longer f21 schedule and post / link to them in the trac ticket " - i believe this got done, but do you want to provide more details, tflink? 15:07:40 * jreznik is here, bit late, phone call 15:08:43 a proposal was submitted to fesco on wednesday to delay f21 for work on tooling and infrastructure 15:09:16 the proposal they reviewed from QA is: https://fedoraproject.org/wiki/User:Tflink/f21_delay_taskbot_development_proposal 15:09:43 The current state is that f21 has been delayed 1 month with branch being no earlier than 2014-03-01 15:10:24 this will be re-visited in January once the WGs for fedora.next have met and produced some output on how they would like to proceed 15:10:44 coolbeans 15:10:58 so the current plan is to have autoqa replaced by 2013-03-01 15:11:15 tflink: I still don't see where you get that month and time for branching 15:11:28 see my comment in the ticket 15:11:42 jreznik: do you want to discuss here or in the ticket? 15:12:10 tflink: ticket, so it's not lost in the internet 15:12:34 k 15:13:08 for coherance, jreznik thinks that branch would be later and doesn't understand where I'm getting 2013-03-01 from 15:13:36 discussion on that point will continue in the fesco ticket https://fedorahosted.org/fesco/ticket/1178 15:14:21 * satellit joining late 15:14:28 #info "tflink and handsome_pirate to write up detailed proposals for projects to be worked on in a possible longer f21 schedule and post / link to them in the trac ticket" - this was done: https://fedoraproject.org/wiki/User:Tflink/f21_delay_taskbot_development_proposal was reviewed by FESCo among other submissions, and F21 will be delayed a minimum of one month. current plan is to have autoqa replacement in place by 2013-03-01 15:14:31 * jreznik can share full TaskJuggler schedule to the usual place 15:14:41 sorry, it's too long to detail the controversy :) 15:15:07 #topic Fedora 20 Beta status 15:15:21 so, let's see 15:15:31 TC2 got built and tested pretty well, coverage looks a lot better than TC1 15:15:53 i filed a TC3 request over the weekend and it seems like there were some complications with building, dgilmore, can you summarize? 15:16:24 Dropping gimp-help broke composes. This is been fixed in git. 15:18:13 brunowolff: fixed? do you have reference? 15:18:36 do you mean 'is being' or 'has been'? 15:18:39 I just saw the log of dgilmore's commits to spin-kickstarts. 15:19:09 brunowolff: it's not fix, it's workaround to make tc4 happen 15:19:26 The fixes were commited. Composes pull directly from git. I don't know whether or not new composes were started after the fix was commited (to rawhide and f20). 15:19:55 right, so it's not exactly that the bug's been fixed, but dgilmore has put gimp-help back in for the purpose of doing the compose 15:20:00 brunowolff: it fixed compose but it means we still have gimp-help-* 15:20:12 we still kinda need to gank it, to hit the size target 15:20:24 adamw: he's looking on the pungi issue 15:20:42 Well, the oversize issue is probably still there, but things should be composing again. 15:21:02 yes. 15:21:04 * satellit TC4 is up 15:21:13 so, let me summarize 15:21:28 #info TC3 compose was done, but the attempt to remove gimp-help from the DVD to save space caused major problems 15:21:50 #info TC4 was then composed with gimp-help-* restored to the DVD image to ensure a successful (but over-size) compose 15:22:07 Well, if one wanted to do that, presumably gimp would need to be changed not to require gimp-help. I don't know if that is happening as I don't following dimp packaging. I do notice stuff with spin-kickstarts ocassionally, as I follow that. 15:22:07 #info TC3 is a dead letter, TC4 has oversize DVD image but should be fully testable 15:22:27 brunowolff: we wanted to yank the localized gimp-help *subpackages*, not gimp-help *itself* 15:22:40 aiui, anyway 15:24:06 adamw: so the issues is that when we remove gimp-help* pungi pukes 15:24:41 adamw: TC3 i pulled in the wrong anaconda 15:24:56 so i redid the compose will all the correct builds 15:25:31 * handsome_pirate rolls in late 15:26:22 dgilmore: right, but it seems to be a pungi issue of some kind not just a straight forward dependency fail, right? 15:26:25 ahoy, pirate 15:26:51 maybe one question is why we have gimp-help-* now being pulled into compose, I don't see any change in packages compared to f19 15:27:00 adamw: unknown 15:27:19 jreznik: pungi changes from dmach 15:27:26 still, we can work on that outside of the meeting 15:27:30 just wanted to nail down the status 15:27:35 jreznik: he gave me some patches to pull in langpacks 15:27:44 and that is where pungi is puking 15:28:11 so we want to be testing tc4 now, and really making sure we get full coverage and catch as many blockers as possible 15:28:19 freeze is this wednesday 15:28:28 dgilmore: ok, I can ask him 15:28:41 (to take a quick look if it helps) 15:29:08 jreznik: not really but thanks 15:29:20 anyone have any notes on test coverage? anything we're worried about not being able to cover? 15:29:40 dgilmore: at least he will be aware of it... 15:29:46 one important note is that tc4 ought to work on the beaglebone black: some of us have those boards, so we should definitely check that 15:30:09 #info TC4 should be tested on the beaglebone black 15:32:20 * handsome_pirate will hit that 15:32:25 thanks pirate 15:32:35 * handsome_pirate gave a scratch build a go this weekend on BBB and it worked 15:32:36 i'm not in the same continent as my BBB so it'll have to wait for me to test it :/ 15:32:41 well, pbrobinson probably has one here. 15:32:45 handsome_pirate: nice 15:32:48 I'll test that too 15:32:52 thanks folks 15:33:03 It was basically TC2 with the new kernel 15:33:07 so the other note I have is to consider doing a freeze exception for GNOME 3.10.1 15:33:27 it seems like we always wind up with a sucky schedule conflict with GNOME's schedule - they'll be doing 3.10.1 right around the freeze date 15:33:32 Could we do a scratch build to test before that? 15:33:37 of course 15:33:39 i usually do one 15:33:44 easy enough to spin up a live image 15:33:49 Okay, so, we're all going to lunch 15:33:58 adamw: I do 15:34:00 adamw: I'd like to talk about OPW at some point, but we're off 15:34:00 it'll include fixes for lots of stuff including blockers in gnome-software 15:34:06 handsome_pirate: who's 'we'? 15:34:27 adamw: The folks I work with 15:34:34 okay 15:34:41 thanks for dropping by 15:35:10 so it's probably just sensible to pull 3.10.1 in wholesale, we have the whole of freeze period to stabilize it and it's a bugfix release anyway, so shouldn't be a problem 15:35:22 would anyone be particularly opposed to doing that? 15:35:29 yeah, I don't think it's been a huge problem in the past 15:35:52 obviously for the future we really ought to look at making sure we don't have this silly schedule overlap, but for f20 we're stuck with it 15:35:59 we did it several times, worked pretty well... so it s*word be ok 15:36:03 :) 15:36:22 :) 15:37:02 adamw: how? ;-) not sure we are able to schedule in week detail to make it happen... at least I'm trying for bigger picture overlap of schedules that it makes sense but even that is lottery :) 15:37:56 I think pulling in the whole thing makes more sense than pulling in just parts. That seems like it might introduce more problems. 15:38:20 jreznik: i dunno precisely, but it seems like something we should fix. the 'we' that isn't me. :P 15:38:43 brunowolff: right, we'd have to pull in at least gnome-software changes to fix blockers, and probably wind up with something else too. this seems simpler 15:38:58 * Viking-Ice joins in late and points out that the QA proposal did not included Anaconda or other QA way's to handle multiple products 15:39:28 #agreed in principle we'll support a freeze exception proposal for GNOME 3.10.1 to land just after beta freeze 15:39:47 Viking-Ice: well, we said right in the last meeting, if you have ideas for stuff to do during a longer F21 schedule, write them up for FESCo 15:39:54 iirc that was your idea...did you write it up for fesco? 15:40:24 adamw, to few responses from Anaconda team to write anything up really 15:40:42 tflink's proposal wasn't labelled Official QA Team Proposal List, it was just his own proposal for an idea to work on 15:41:06 Viking-Ice: yeah, i saw you didn't really get much traction :/ 15:41:12 it's not like we can "force" them to alter their development cycle nor were any alternatives proposed 15:41:14 "the proposal they reviewed from QA is" 15:41:46 yeah. if you had made a proposal, tim would've included it in that list. 15:41:49 you didn't, so he didn't... 15:41:53 if fedora changes, anaconda would have to follow it up... 15:42:11 adamw, no traction just means no go from QA on multiproduct proposal 15:42:12 he listed all the proposal that, in the end, QA folks sent to fesco and fesco looked at. 15:42:13 Viking-Ice: which is factually correct - they didn't review any other proposals from QA 15:43:11 I dont know if anaconda has discussed the move to their own development cycle internally 15:43:20 i don't know either 15:43:22 does anyone? 15:44:25 as I stated above - they will have to follow new model, if Fedora would have new model and we don't know anything about it yet, nothing was decided/agreed on yet 15:44:32 in anycase anything on our side ( dedicated tester/reporter/triager etc team from QA is on hold until ) 15:45:12 as in coming up with ( or try to ) dedictated QA anaconda team 15:45:34 jreznik: this is more about a specific proposal viking suggested to change the anaconda development schedule 15:45:52 jreznik: if you check anaconda-devel-list he proposed it there but didn't get much response from actual anaconda team 15:46:00 as he says, the proposal is a bit stuck if anaconda team doesn't buy in 15:46:14 I saw it, of course 15:46:44 one ( Chris ) or two ( if Jens is part of it ) 15:47:21 we are stuck until Anaconda team responds so we can try to provide resources or try find alternative methods to solve the dilemma 15:47:24 Viking-Ice: so, i don't think the 21 schedule question is settled yet, as per above 15:47:38 just that so far they've already definitely decided on _at least_ a one month push bacl 15:47:52 so you still have time to try and get buy-in on the idea and send it up to fesco if that happens 15:49:03 I dont run after people and get buy ( I had my fill with that with the systemd migration in F16 ) in the developers can simply respond to that topic if it's in or out 15:49:11 Viking-Ice: fair enough 15:49:34 jreznik: can we ask anaconda folks to give some feedback on the idea so we know whether it's viable or not? 15:49:45 if they dont respond to that after this week it's off the table and I proposed that QA votes against multiproduct proposal 15:50:14 because there is no way we can handle anaconda + multi products 15:50:27 on the same release cycle 15:50:37 welp, we can burn that bridge when we get to it 15:50:59 adamw: yep but again - if we change to multiple products, they have to follow it because otherwise not only qa guys would get mad from testing... 15:51:25 well, aiui this is a specific idea of viking's as to what they could change to make things easier with the multi-product proposal 15:51:40 if multi-product is actually going to go ahead obviously anaconda's going to have to respect it in SOME way 15:52:01 like viking, i don't know if they've actually looked at that whole thing yet at all 15:52:48 afaik anaconda needs to be on own release cycle or anaconda + base coreOS on it's own release cycle or every product on it's own release cycle 15:52:54 ok, in this words, it makes sense 15:53:02 that hasn't ever worked before. 15:53:31 it sounds like there's quite a lot of uncertainty going around and we've got 7 minutes left 15:53:35 I try to use some of my own ways (no conspiracy) how to get to the answer 15:53:52 jreznik, use what every means you can 15:54:01 ship them whiskey if you have too ;) 15:54:13 so maybe for now we can just at least check if anaconda team is aware of this multi-product proposal thing and whether they already have some plan to work with it or are planning to object to it or whatever...and then we might be on slightly more clear ground 15:54:14 ( surely they must be tired of wwoods monshine by now ) 15:54:17 heh 15:54:35 adamw: yep 15:54:58 regardless of whatever comes out of wg we in QA need to find a way to handle multiple products as effective as possible 15:55:00 viking's mail did mention the multi-product stuff, but sort of in a way that assumes the reader already knows what's going on there - it's easy to miss it if you aren't actually aware of that 15:55:08 Viking-Ice: if it's going to happen, we certainly do 15:55:24 Viking-Ice: proposals welcome for sure... 15:55:32 for next week's agenda or the list or anything 15:55:52 as a Public Service Announcement: remember you can stick topics into the meeting agenda in the wiki ahead of the meeting if you want to 15:56:01 or send 'em to the list in reply to a meeting thread 15:56:11 yeah 15:56:16 let's move to Josef 15:56:22 and new test day 15:56:23 stuff 15:56:26 yup 15:56:31 #topic Test Day result tracking 15:56:42 I actually put this one in, just as it seemed sensible to discuss it after the list thread 15:56:56 for the first is it ready ( enough ) 15:57:18 Viking-Ice: define ready 15:57:21 of so let's move all activity to it, if not let's stick with the wiki until it's ready 15:57:27 so it was suggested on the list - https://lists.fedoraproject.org/pipermail/test/2013-October/118284.html - that we 'stop using the wiki' for tracking test day results 15:57:41 tflink, on par with wiki usage or better 15:58:01 atodorov had used the little tool jskladan wrote to track results for a test day, and liked it much more than the wiki, so he suggested we push it more heavily as the default for test days in future 15:58:02 Viking-Ice: I meant ready for what - do all result tracking or just test days 15:58:06 as of right now it kinda exists and has been used 15:58:11 tflink: for now i was figuring just test days 15:58:17 tracking validation test results is a bit different 15:58:23 it seems to be a nice fit for test days, though 15:58:32 IIRC, the original idea was to ease transition into something different 15:58:43 * adamw doesn't remember for sure 15:58:46 so the test day app could record results in a better way and dump everything to wiki format 15:58:48 jskladan: still there? 15:58:56 well I dont think we should disrupt that release workflow in the midst of the cycle 15:59:13 still, if it's better than the wiki right now, we can certainly consider it, and using it might encourage work on something even better 15:59:15 that way we could have a better way to record results while maintaining the same method for historical results 15:59:17 use of that app for the GNOME test day was smooth 15:59:30 Viking-Ice: it's not a new tool, it's been around for a while just not discussed all that much 15:59:59 IIRC, it came out of some issues in the F18 power management test day during devconf that year 16:00:05 well, there's various ways we could do it 16:00:14 we could simply update the test day SOP to encourage using the app for tracking results 16:00:38 adamw: sorry, I got distracted by dinner (bad me) 16:00:39 and then whoever's looking after test days for F21 could make sure the person running each test day is aware of it 16:00:45 you're not allowed to eat! 16:00:45 I'm not a huge fan of supporting it in any official capacity in it's current state, though; it's a TG2 app 16:00:59 s/any/much of any/ 16:01:12 what's the implication of that, for us monkeys? :) 16:01:17 TG2 = TurboGears 2, right? 16:01:27 it's a web framework that we don't have much experience with 16:01:38 let´ s swap it out for test days, see how it turns out and shapes then consider it swapping it out tracking validation test results next cycle 16:02:15 tflink: adamw: Viking-Ice: it's in no shape to track validation - it was not designed to do that, and validation IMHO needs a bit different approach 16:02:32 right, for now i was only thinking about test days 16:02:44 jskladan: yeah, sorry if it sounds like I was implying anything outside that 16:02:46 it seems to be written specifically to the test day workflow, right? it seems like a nice fit for that 16:02:48 I've put together some short wiki page: https://fedoraproject.org/wiki/User:Jskladan/Sandbox:TestdayApp 16:02:58 anyone against swapping this out for testday raise your hand ? 16:02:58 it's an easy enough thing to add to the test day SOP - and it works 16:02:58 on how things work 16:03:07 adamw: yup 16:03:10 +1 for test day usage 16:03:12 #info jskladan wrote a webapp for tracking test day results that is documented at https://fedoraproject.org/wiki/User:Jskladan/Sandbox:TestdayApp 16:03:32 * adamw is +1 in principle, but at least it should probably live on a Real System in a recognized fedora domain rather than an IP address, if that's not too difficult 16:03:37 and only for test days 16:03:55 it should be available at testdays.cloud.fedoraproject.org 16:03:57 adamw: it lives on http://testdays.qa.fedoraproject.org/testdays/all_events 16:04:13 OK cool - when i looked the test day page was using an IP address link, iirc 16:04:16 awesome, that seems fine 16:04:18 +1 test day usage ( and placed somewhere under qa.fedoraproject.org/ the ip is a residue from the old times 16:04:25 roger 16:04:35 but I do have some concerns about it being in the cloud, not being backed up and being managed by hand 16:04:48 tflink: well, in the end the idea is that the results are copied back into the test day page, right? 16:04:53 that's why it spits them out in wiki format 16:05:00 if the lifetime of the data is only a couple of days, I'm much less concerned 16:05:02 if we do that, then the risk of breakage doesn't seem too terrible 16:05:19 it doesn't matter if it breaks outside of a test day being 'active' and we don't lose the data from previous test days if it does 16:05:29 let's keep it under qa.fedoraproject.org as opposed to it's own domain we want the same landing page for all qa community members ( I would think ) 16:05:40 Viking-Ice: sure, that domain is fine, i was just worried about it being an ip address 16:05:40 Viking-Ice: that's not possible for the short term 16:06:01 oh, i thought by 'under' viking meant a subdomain, i.e. the way it is 16:06:01 tflink, ? 16:06:04 I can go through infra policy and details for why that can't happen if you'd like but I think that's out of scope for this meeting 16:06:21 testdays.qa.fp.o is 'under' qa.fp.o as I see it 16:06:35 adamw: it's testdays.cloud.fedoraproject.org 16:06:47 adamw: it lives on http://testdays.qa.fedoraproject.org/testdays/all_events 16:06:51 nvm, I forgot that josef got around the normal policy :) 16:07:02 seems to work 16:07:03 :P 16:07:05 tflink, we should be able to fake the actual address ( proxypass rewrite rules what not ) 16:07:19 I think we're ok there, sorry for the confusion :) 16:07:23 Viking-Ice: you mean to use something like qa.fedoraproject.org/testdays/... ? 16:07:30 tflink, yes 16:07:40 *sigh* 16:07:53 anywho that's technical 16:07:55 Viking-Ice: that can't happen for other reasons, but we're off topic for an over time meeting 16:08:15 i think we're just crossing wires and everyone is actually fine with http://testdays.qa.fedoraproject.org/ 16:08:18 but let me know if i'm wrong 16:08:34 i may have sounded like i was proposing moving it, but I wasn't; tflink thought it wasn't available there, but it is. that's my current understanding. 16:08:38 that's another topic 16:08:40 OK 16:08:42 for now: 16:08:51 let's agree with switching to start using it 16:09:01 for test days 16:09:07 +1 16:09:07 it's not IP adress, lives in qa space, so pretty good for me 16:09:11 +1 16:09:16 proposed #agreed we will update the Test Day SOP to encourage use of the webapp at http://testdays.qa.fedoraproject.org/ for tracking test day results, with the results to be copied back into the test day wiki page within a few days of the end of the test day 16:09:16 +1 16:09:25 ack 16:09:26 ack and +1 16:09:29 ack 16:09:32 * jskladan is all in 16:09:39 awesome 16:09:43 #agreed we will update the Test Day SOP to encourage use of the webapp at http://testdays.qa.fedoraproject.org/ for tracking test day results, with the results to be copied back into the test day wiki page within a few days of the end of the test day 16:09:49 big vote of thanks to jskladan for the app 16:10:04 does anyone want to take an action to update the SOP? roshi? 16:10:51 I got it :) 16:11:07 #action roshi will update the Test Day SOP as agreed (encourage use of webapp for tracking test day results) 16:11:21 okay, quickly...:) 16:11:24 #topic Open floor 16:11:30 anything vitally important that we missed? 16:11:35 1015731 is still listed as proposed FE (sugar) I thought it was voted on last time to be accepted at the end of the meeting .https://qa.fedoraproject.org/blockerbugs/milestone/20/beta/buglist 16:11:43 but looks removed now 16:11:56 .bug 1015731 16:11:59 tflink: Bug 1015731 netinstall f20 Beta TC-1 x86_64 of sugar-desktop boots to console login - https://bugzilla.redhat.com/show_bug.cgi?id=1015731 16:12:19 satellit: it was closed 16:12:46 this is not livesoas but install from netinatall of sugar-desktop diferent 16:12:54 I just deployed a fix to the blocker tracking app to remove closed bugs from the lists 16:13:03 ? 16:13:12 satellit: the bug is CLOSED NEXTRELEASE 16:13:31 so it should be fixed 16:13:55 ok so sugar-desktop works in TC4? have not tested yet 16:14:05 depends on the exact status of the fix i guess 16:14:12 * adamw looks 16:14:41 satellit: I'm not sure it's fixed, I was just explaining why it hadn't moved and why it disappeared 16:14:50 ok ok 16:15:17 confusion of SoaS live bug and sugar-desktop here? 16:15:26 "I was sure I closed this bug. I've added lightdm as a default DM in comps for F-20+ which will fix the problem. It was pushed on Oct 8th so should already be fixed in the latest compose." 16:15:28 sounds clear enough 16:15:35 so yeah, TC4 should be good, pbrobinson thinks 16:15:48 thanks 16:16:04 tflink: thanks for blocker tracking app fix! 16:16:52 np, I still don't understand why it stopped working like that but it's fixed now :) 16:18:27 adamw: satellit: I added lightdm into the sugar-desktop group as a DM, I dropped gdm from the list a while a go due to issues but the idea was to give people a choice of DM but I missed the "install from anaconda" options without thinking that people wouldn't think to choose a DM so I defaulted to lightdm 16:18:49 thanks.... 16:19:41 satellit: check out TC4 and get back to us :) 16:19:46 OK, sounds like that's all 16:19:52 * adamw sets the quantum fuse 16:22:37 ok 16:23:56 oh, there's no place to put checksum results for Images/i386 and Images/x86_64 16:24:23 the install test matrix template needs to be updated 16:26:26 * Martix is here 16:26:30 :-P 16:27:05 pwhalen pointed it out to me 16:32:48 #endmeeting