15:00:03 #startmeeting Fedora QA meeting 15:00:03 Meeting started Mon May 6 15:00:03 2013 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:09 #meetingname fedora-qa 15:00:09 The meeting name has been set to 'fedora-qa' 15:00:15 #topic roll call 15:00:21 * jreznik is here 15:00:26 * satellit listening 15:01:58 * brunowolff is here 15:02:01 anyone else? 15:02:03 * mkrizek is here 15:02:09 * pschindl is here 15:02:13 * kparal here 15:02:14 * tflink is mostly here 15:02:30 * spoore is listening 15:02:44 * nirik is lurking 15:03:06 alrighty 15:03:08 morning folks 15:03:10 * jskladan is here 15:03:12 #topic previous meeting follow-up 15:03:30 "martix or adamw to write a Graphics Test Week recap email" 15:03:44 i didn't get around to that; i don't think martix did either 15:04:11 EPIC FIAL 15:05:09 #info "martix or adamw to write a Graphics Test Week recap email" - neither of us got around to it this week; let's try again 15:05:16 #action martix or adamw to write a Graphics Test Week recap email 15:05:22 #chair tflink brunowolff 15:05:22 Current chairs: adamw brunowolff tflink 15:05:23 * Viking-Ice joins 15:05:27 morning viking 15:05:37 "tflink to do some promotion for the blocker bug proposal webapp" 15:05:42 I think you wrote a blog post, right tflink? 15:07:19 adamw: yeah, don't remember if I send the list msg off, though 15:07:25 * tflink suspects that he did not do that 15:07:49 #info "tflink to do some promotion for the blocker bug proposal webapp" - tflink wrote a blog post: http://tirfa.com/proposing-blocker-bugs.html 15:07:57 * nirik thinks it could use an announce on devel-announce / test-announce? 15:08:25 #action tflink to write a list post announcing the blocker bug proposal webapp 15:08:47 nirik: yeah, it just fell off the list of stuff todo 15:08:50 #topic Fedora 19 Beta status/planning 15:09:05 ...and go! freeform discussion while adamw answers the call of nature 15:10:05 There was an odd bug reported for livecd-creator that I saw today. That doesn't affect live builds for the release, right? 15:12:10 we use livecd-creator for the 'production' lives, so potentially 15:12:12 what was the bug? 15:13:01 With the -c option the path to the ks file doesn't seem to be used. 15:13:56 huh. I use that often enough. 15:14:28 .bug 959911 15:14:28 what's the bug #? 15:14:31 ah :) 15:14:32 brunowolff: Bug 959911 fedora-lxde-packages.ks and others missing - https://bugzilla.redhat.com/show_bug.cgi?id=959911 15:14:49 #info 959911 is a strange livecd-creator bug, keep an eye on it if we start having weird problems composing lives 15:14:59 alright, anything else on f19 status? 15:15:04 tc3 seems to be broadly testable 15:15:13 we're doing blocker review right after this meeting 15:16:17 i don't think QA needs to do anything about the Great Password Hoohaa 15:17:14 * adamw watches crickets 15:17:57 great password hoohaa is anaconda unless it hits the security criteria stuff 15:18:19 which certain person was so eager to add... 15:18:53 heh 15:20:52 #info TC3 is out and in testing, TC4 will come when appropriate 15:21:15 There has been a lot of hyperbole in the password masking discussion. I do not believe this would fall under the category of a release blocking issue for security reasons (even if they decide to change the behavior). 15:22:15 yeah, i agree. it's a devel issue. 15:23:16 alrighty then 15:23:27 #topic Secondary arch freeze exceptions 15:24:07 so we had that situation during Alpha where a secondary arch team wanted us to pull a fix to a critpath package which fixed a release-critical issue, but only in a secondary arch 15:24:14 that seems like a tricky situation 15:24:17 * jreznik sent an email to test-list, we should have a policy for that not to repeat alpha.... 15:24:26 i believe jreznik wanted to discuss what we ought to do in such cases 15:24:38 adamw: yep, that was me :) 15:24:44 I thought the alpha exception was handled fine. There was some back and forth evaluating the importance of the fix versus the risk of breaking something. 15:25:07 yeah dealing with it on case by case bases seems to be the right thing to do 15:25:16 It was a bit handwavey, but I think the process worked OK. 15:25:19 brunowolff: it's more if we want to handle it as non-blocking releases or not 15:25:40 brunowolff: as sec arch guys/releng would like to see same handling 15:25:57 it worries me that we might end up on a bit of a slippery slope... 15:26:04 do we have a definition of non-blocking ones? 15:26:22 i'm sorry, a definition of non-blocking whats? 15:26:45 adamw: one thing is - you can grant FE, you don't have to pull it into compose (but if you pull it too late, it could lead to slip - I get your point) 15:26:46 secondary arch issues generally are non blocking 15:27:16 right, the 'rule' is simple enough - we only block releases on primary arches 15:27:17 adamw: sorry, non-release-blocking 15:27:29 the question was about the noun, not the adverb :) 15:27:46 Is the issue we don't state anywhere that what would be blocking issues for a primary arch are a freeze exception case for secondary arches? 15:27:51 adamw, Viking-Ice: but then for non-release-blocking ones we accept FEs for issues blocking blocking ones :) 15:27:51 thus making exceptions to that rule on case by case bases for critical secondary arch bugs is the way forward from my pov 15:28:11 brunowolff: yep 15:28:16 jreznik: that's the policy for desktops, yes 15:28:27 adamw: yep 15:28:32 brunowolff: well, we don't do that. whether it's an 'issue' is the question - whether that is what we should do 15:28:37 and that's the question if it fits sec archs or not 15:28:57 I am in favor of handling arch specific issues for secondary arches, like non-blocking desktops. 15:29:05 the difference between the desktop and arch case is that, usually, we don't have to poke sensitive packages to fix non-blocking desktops. 15:29:13 but then, sometimes we do, so it's not _entirely_ different 15:29:37 it seems like people are in favour of just saying 'propose them as FE and then evaluate them one by one'? 15:30:02 +1 15:30:16 +1 if secondary arch want the same elite treatment we give primary arch they simply have to work they way torwards becoming primary arch ;) 15:30:59 that's what we do now, dgilmore had a different opinion and he said we historically accepted it automatically but... 15:31:22 that wasn't my recollection. 15:31:23 Viking-Ice: then why to care about other desktops? 15:31:24 I think it might be useful to state a policy covering this, so there is less confusion. This lets people know we don't block on secondary arches, but also if it is something that would be a blocker in a primary arch, they should file an FE bug. 15:32:18 brunowolff: that would be at least a first step and I'd be ok with propose FE, we deal with it case by case... 15:32:41 we can add it to the FE guidelines, for sure 15:33:11 brunowolff: that sounded like you were volunteering to me :) 15:33:12 We are always supposed to deal with pulling FEs case by case. I think the difference with secondary arch FEs, is that they are more likely to be risky on average. 15:33:44 Sure, I'll add something similar to the non-blocking release wording. 15:33:58 ill see if i can dig up where it was discussed in the past, but ive been operating on the assumption for years that primary blockers are automatically accepted as NTH, i can choose to pull them in or not 15:34:29 #action brunowolff to update freeze exception guidelines to say that secondary arch 'blockers' should be proposed as FE issues and will be evaluated on a case-by-case basis 15:34:45 dgilmore: welp, if it was discussed i missed it :) 15:35:11 jreznik, strictly speaking we dont care about other desktops but sometimes we in QA have to deal with well board decisions and their limitations... 15:35:13 i strongloy object to the propossed wording 15:35:48 dgilmore: well, there's clearly a problem with just you deciding what to pull and what not to pull at compose time 15:36:09 o_O 15:36:09 you = releng 15:36:28 dgilmore, patch to the wording? 15:36:40 the point of the FE process is to have more than one of us make that decision, in a public, organized and logged forum.. 15:36:50 adamw: i generally pull in accepted NTH, but i have very rarely refused to do so 15:37:42 Viking-Ice: I want them automatically accepted as NTH, which doesnt mean that i will pull them. qa is free to suggest it not be pulled when requesting a compose 15:37:44 dgilmore: there has to be a bit of leeway for us to decide not to pull them in certain circumstances, yes, but that's kinda different from 'releng just assumes any secondary arch blocker is fair game for pulling and decides whether or not to on its own' 15:38:25 that seems like a process with way more holes and room for confusion in it than if we just evaluate such issues through the appropriate process (FE review). 15:39:10 adamw: I see it this way. the secondary arch has during their own qa process determined that its a blocker for them. we make it a NTH, doesnt mean it has to be pulled in on primary. 15:39:26 we really want primary and secondary arch releases to be the same 15:40:05 The difference is that the ticket would stay on the FE list even if QA thought we would be very unlikely to want to pull in any update. 15:40:52 I don't see this happening enough to cause a real problem with FE ticket bloat. 15:40:59 well, sigh. i thought what we decided was reasonable, but i don't want to cause a rift with releng. 15:41:04 adamw: if a secondary arch blocker fix is deemed to risky for release. it probably should be re-evaluated if the fix is right at all. it will be pushed as an update 15:41:28 sometimes 'risky' has more to do with the package affected and the timing than the actual nature of the fix. 15:41:30 dgilmore, as do we for all various other things but unfortunately bits and archers aren't being treated equal 15:41:33 murphy's law, and all that 15:41:33 at which point it will get less qa and could cause breakages 15:42:37 dgilmore: what do you think would be the problem with evaluating secondary arch blockers through the FE process? 15:42:42 generally I'm on dgilmore's side, it's even a good marketing when we're able to release some sec archs on the same day, I understand adamw's point on slippery thing and if we say we automatically accept them, it gives some weight but 15:44:21 adamw: that its duplicating the evaluation, I fear that on the primary side we are more likely to reject it just because of lack of knowledge on how it effectes the secondary arch 15:44:38 do secondary arches actually do blocker review at present? 15:45:26 adamw: they are supposed to 15:45:34 mmf. 15:45:37 sharkcz: that's a good question for you ^^^ 15:45:44 adamw, aren't we supposed to be doing that blocker review ? 15:45:44 I'm not against trying to keep primary and secondary in sync for release but I'm not sure automatically accepting FEs and pulling them into a compose is wise 15:45:56 tflink, agreed 15:45:59 well i guess i can resign myself to the 'automatic FE' plan right up until a secondary arch FE issue causes a slip... 15:46:16 Viking-Ice: reviewing secondary arch blockers? we never have... 15:46:28 Viking-Ice: in general all work relating to secondary arches is supposed to be done by those teams 15:46:36 adamw: having QA look at it and say we really dont think this is right is okay 15:46:51 that's basically what the FE process *is*, though. 15:47:02 it's a process by which we can do that and have it all recorded and written down properly. 15:47:09 adamw, yes but they kinda cant if there are going to be pull-ins from bits that might affect primary arches thus we ought to be doing that stuff 15:47:20 you're essentially saying 'it's fine if you do that, but i want you to do it in a completely ad-hoc, disorganized and untracked manner'. 15:47:27 dgilmore: personally, I trust the secondary arch people when they say it's a blocker. I'm just not a fan of doing stuff like touching glibc for _any_ non-release-blocking reason right before go/no-go 15:47:49 * dgilmore gives up. 15:47:51 I don't think any of us doubt the secondary arch folks when they say something is a blocker, either 15:48:45 we could add a presumption in favour of FE status to the guidelines, i guess? 15:48:54 rather than the more neutral-sounding 'evaluate on a case-by-case basis' 15:49:12 something like 'these bugs will generally be accepted as FE issues, and only rejected in extraordinary circumstances', or whatever 15:49:16 tflink: but day before go/no-go you would treat all FEs the same way - even automatically accepted other desktops ones (and now with cinnamon, mate there's bigger chance it will break gnome...) 15:49:30 adamw: that id be okay with. I would really only want it rejected if we think it would break primary 15:49:33 adamw: that's definitely better 15:49:56 I have noted the wording change. 15:49:58 can we all agree on that one? we run these issues through FE process, but the assumption is that they'll be accepted? 15:50:19 adamw: i am good with that 15:50:36 I agree 15:50:39 I rather not we blindly accept stuff 15:50:57 Viking-Ice: it's not about blidly accepting stuff 15:51:04 Viking-Ice: well, we wouldn't be 'blindly' accepting it, that's the point of the compromise - at least they'd all have to go through a meeting, and they *can* be rejected with sufficiently good reason 15:51:08 * jreznik agrees 15:51:29 dgilmore: the consequences of breaking increase as we get closer to go/no-go. if we're 3 days before go/no-go, I'm usually in reject anything that _could_ break primary in release blocking ways, not just would 15:51:41 usually in the mode of, rather 15:51:52 tflink: that's kind of a weakness in the FE process in general, rather than this specific case, though. which we'd better not get into as we're close to time 15:52:00 true 15:52:20 I don't have any objections to favoring secondary blockers for accepted FE, though 15:52:24 I guess we can try this and revert when we get bitten O_O 15:52:29 :P 15:52:30 okay then 15:52:46 Viking-Ice: sure 15:53:42 #agreed secondary arch 'blocker' issues should be proposed as freeze exception issues and will be reviewed under the usual FE review process, but there will be a presumption in their favour (i.e. we will usually expect to accept them, and would need a good argument to reject them) 15:53:53 #action brunowolff to update the FE guidelines to reflect the agreement 15:54:06 #topic open floor 15:54:12 whoops 15:54:13 #unfo 15:54:14 #undo 15:54:14 Removing item from minutes: 15:54:18 #topic Test Days 15:54:30 so, let's get through this fast 15:54:55 it looks like we didn't get much participation in the mariadb event 15:55:07 #action adamw to look into Test_Day:2013-04-30_MariaDB lack of participation and see if we should re-run it 15:55:26 why bother re-runningit 15:55:35 #info https://fedoraproject.org/wiki/Test_Day:2013-05-02_Internationalization went off fine 15:55:48 Viking-Ice: well it seems like kind of an important test day, to make sure all the mariadb/mysql mess is working in practical terms 15:55:54 those responsable for the mariadb migrations should just bloddy test it themselves 15:56:19 switching databases on upgrades is WRONG 15:56:34 while we still ship the same database 15:56:43 #info https://fedoraproject.org/wiki/Test_Day:2013-05-07_ABRT preparation looks all ready, let's do some announcements 15:56:52 so those pushing mariadb get to eat their own dog food 15:57:07 * kparal is building yet another (third) Live image for ABRT test day 15:57:34 #info https://fedoraproject.org/wiki/Test_Day:2013-05-09_SSSD_Improvements_and_AD_Integration still needs a live image, the test cases look to be ready 15:57:43 is someone working with the sssd organizers on that one? 15:57:45 I'm building that one too 15:57:48 okay 15:57:53 they already have it 15:58:00 #action kparal to ensure abrt and sssd test days have live images ready 15:58:09 #action adamw to do some promotion for the test days 15:58:13 #topic open floor 15:58:18 alrighty, we have 1 minute :) 15:59:18 anything else we need to discuss? 15:59:56 * adamw sets boring old deterministic fuse for 1 minute 16:00:34 everyone over to #fedora-blocker-review after this! 16:00:41 we have quite a few proposed blockers to knock off. 16:02:53 thanks for coming folks, blocker review starting up now 16:02:55 #endmeeting