15:00:03 <adamw> #startmeeting Fedora QA meeting
15:00:03 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:09 <adamw> #meetingname fedora-qa
15:00:09 <zodbot> The meeting name has been set to 'fedora-qa'
15:00:15 <adamw> #topic roll call
15:00:21 * jreznik is here
15:00:26 * satellit listening
15:01:58 * brunowolff is here
15:02:01 <adamw> 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 <adamw> alrighty
15:03:08 <adamw> morning folks
15:03:10 * jskladan is here
15:03:12 <adamw> #topic previous meeting follow-up
15:03:30 <adamw> "martix or adamw to write a Graphics Test Week recap email"
15:03:44 <adamw> i didn't get around to that; i don't think martix did either
15:04:11 <adamw> EPIC FIAL
15:05:09 <adamw> #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 <adamw> #action martix or adamw to write a Graphics Test Week recap email
15:05:22 <adamw> #chair tflink brunowolff
15:05:22 <zodbot> Current chairs: adamw brunowolff tflink
15:05:23 * Viking-Ice joins
15:05:27 <adamw> morning viking
15:05:37 <adamw> "tflink to do some promotion for the blocker bug proposal webapp"
15:05:42 <adamw> I think you wrote a blog post, right tflink?
15:07:19 <tflink> 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 <adamw> #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 <adamw> #action tflink to write a list post announcing the blocker bug proposal webapp
15:08:47 <tflink> nirik: yeah, it just fell off the list of stuff todo
15:08:50 <adamw> #topic Fedora 19 Beta status/planning
15:09:05 <adamw> ...and go! freeform discussion while adamw answers the call of nature
15:10:05 <brunowolff> 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 <adamw> we use livecd-creator for the 'production' lives, so potentially
15:12:12 <adamw> what was the bug?
15:13:01 <brunowolff> With the -c option the path to the ks file doesn't seem to be used.
15:13:56 <adamw> huh. I use that often enough.
15:14:28 <brunowolff> .bug 959911
15:14:28 <adamw> what's the bug #?
15:14:31 <adamw> ah :)
15:14:32 <zodbot> brunowolff: Bug 959911 fedora-lxde-packages.ks and others missing - https://bugzilla.redhat.com/show_bug.cgi?id=959911
15:14:49 <adamw> #info 959911 is a strange livecd-creator bug, keep an eye on it if we start having weird problems composing lives
15:14:59 <adamw> alright, anything else on f19 status?
15:15:04 <adamw> tc3 seems to be broadly testable
15:15:13 <adamw> we're doing blocker review right after this meeting
15:16:17 <adamw> i don't think QA needs to do anything about the Great Password Hoohaa
15:17:14 * adamw watches crickets
15:17:57 <Viking-Ice> great password hoohaa is anaconda unless it hits the security criteria stuff
15:18:19 <Viking-Ice> which certain person was so eager to add...
15:18:53 <adamw> heh
15:20:52 <adamw> #info TC3 is out and in testing, TC4 will come when appropriate
15:21:15 <brunowolff> 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 <adamw> yeah, i agree. it's a devel issue.
15:23:16 <adamw> alrighty then
15:23:27 <adamw> #topic Secondary arch freeze exceptions
15:24:07 <adamw> 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 <adamw> 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 <adamw> i believe jreznik wanted to discuss what we ought to do in such cases
15:24:38 <jreznik> adamw: yep, that was me :)
15:24:44 <brunowolff> 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 <Viking-Ice> yeah dealing with it on case by case bases seems to be the right thing to do
15:25:16 <brunowolff> It was a bit handwavey, but I think the process worked OK.
15:25:19 <jreznik> brunowolff: it's more if we want to handle it as non-blocking releases or not
15:25:40 <jreznik> brunowolff: as sec arch guys/releng would like to see same handling
15:25:57 <adamw> it worries me that we might end up on a bit of a slippery slope...
15:26:04 <jreznik> do we have a definition of non-blocking ones?
15:26:22 <adamw> i'm sorry, a definition of non-blocking whats?
15:26:45 <jreznik> 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 <Viking-Ice> secondary arch issues generally are non blocking
15:27:16 <adamw> right, the 'rule' is simple enough - we only block releases on primary arches
15:27:17 <jreznik> adamw: sorry, non-release-blocking
15:27:29 <adamw> the question was about the noun, not the adverb :)
15:27:46 <brunowolff> 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 <jreznik> adamw, Viking-Ice: but then for non-release-blocking ones we accept FEs for issues blocking blocking ones :)
15:27:51 <Viking-Ice> 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 <jreznik> brunowolff: yep
15:28:16 <adamw> jreznik: that's the policy for desktops, yes
15:28:27 <jreznik> adamw: yep
15:28:32 <adamw> 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 <jreznik> and that's the question if it fits sec archs or not
15:28:57 <brunowolff> I am in favor of handling arch specific issues for secondary arches, like non-blocking desktops.
15:29:05 <adamw> 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 <adamw> but then, sometimes we do, so it's not _entirely_ different
15:29:37 <adamw> it seems like people are in favour of just saying 'propose them as FE and then evaluate them one by one'?
15:30:02 <tflink> +1
15:30:16 <Viking-Ice> +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 <jreznik> that's what we do now, dgilmore had a different opinion and he said we historically accepted it automatically but...
15:31:22 <adamw> that wasn't my recollection.
15:31:23 <jreznik> Viking-Ice: then why to care about other desktops?
15:31:24 <brunowolff> 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 <jreznik> 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 <adamw> we can add it to the FE guidelines, for sure
15:33:11 <adamw> brunowolff: that sounded like you were volunteering to me :)
15:33:12 <brunowolff> 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 <brunowolff> Sure, I'll add something similar to the non-blocking release wording.
15:33:58 <dgilmore> 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 <adamw> #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 <adamw> dgilmore: welp, if it was discussed i missed it :)
15:35:11 <Viking-Ice> 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 <dgilmore> i strongloy object to the propossed wording
15:35:48 <adamw> 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 <Viking-Ice> o_O
15:36:09 <adamw> you =  releng
15:36:28 <Viking-Ice> dgilmore, patch to the wording?
15:36:40 <adamw> 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 <dgilmore> adamw: i generally pull in accepted NTH, but i have very rarely refused to do so
15:37:42 <dgilmore> 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 <adamw> 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 <adamw> 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 <dgilmore> 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 <dgilmore> we really want primary and secondary arch releases to be the same
15:40:05 <brunowolff> 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 <brunowolff> I don't see this happening enough to cause a real problem with FE ticket bloat.
15:40:59 <adamw> well, sigh. i thought what we decided was reasonable, but i don't want to cause a rift with releng.
15:41:04 <dgilmore> 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 <adamw> sometimes 'risky' has more to do with the package affected and the timing than the actual nature of the fix.
15:41:30 <Viking-Ice> dgilmore,  as do we for all various other things but unfortunately bits and archers aren't being treated equal
15:41:33 <adamw> murphy's law, and all that
15:41:33 <dgilmore> at which point it will get less qa and could cause breakages
15:42:37 <adamw> dgilmore: what do you think would be the problem with evaluating secondary arch blockers through the FE process?
15:42:42 <jreznik> 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 <dgilmore> 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 <adamw> do secondary arches actually do blocker review at present?
15:45:26 <dgilmore> adamw: they are supposed to
15:45:34 <adamw> mmf.
15:45:37 <jreznik> sharkcz: that's a good question for you ^^^
15:45:44 <Viking-Ice> adamw, aren't we supposed to be doing that blocker review ?
15:45:44 <tflink> 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 <Viking-Ice> tflink, agreed
15:45:59 <adamw> 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 <adamw> Viking-Ice: reviewing secondary arch blockers? we never have...
15:46:28 <adamw> Viking-Ice: in general all work relating to secondary arches is supposed to be done by those teams
15:46:36 <dgilmore> adamw: having QA look at it and say we really dont think this is right is okay
15:46:51 <adamw> that's basically what the FE process *is*, though.
15:47:02 <adamw> it's a process by which we can do that and have it all recorded and written down properly.
15:47:09 <Viking-Ice> 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 <adamw> 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 <tflink> 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 <tflink> I don't think any of us doubt the secondary arch folks when they say something is a blocker, either
15:48:45 <adamw> we could add a presumption in favour of FE status to the guidelines, i guess?
15:48:54 <adamw> rather than the more neutral-sounding 'evaluate on a case-by-case basis'
15:49:12 <adamw> something like 'these bugs will generally be accepted as FE issues, and only rejected in extraordinary circumstances', or whatever
15:49:16 <jreznik> 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 <dgilmore> adamw: that id be okay with. I would really only want it rejected if we think it would break primary
15:49:33 <jreznik> adamw: that's definitely better
15:49:56 <brunowolff> I have noted the wording change.
15:49:58 <adamw> 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 <dgilmore> adamw: i am good with that
15:50:36 <brunowolff> I agree
15:50:39 <Viking-Ice> I rather not we blindly accept stuff
15:50:57 <jreznik> Viking-Ice: it's not about blidly accepting stuff
15:51:04 <adamw> 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 <tflink> 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 <tflink> usually in the mode of, rather
15:51:52 <adamw> 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 <tflink> true
15:52:20 <tflink> I don't have any objections to favoring secondary blockers for accepted FE, though
15:52:24 <Viking-Ice> I guess we can try this and revert when we get bitten O_O
15:52:29 <adamw> :P
15:52:30 <adamw> okay then
15:52:46 <jreznik> Viking-Ice: sure
15:53:42 <adamw> #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 <adamw> #action brunowolff to update the FE guidelines to reflect the agreement
15:54:06 <adamw> #topic open floor
15:54:12 <adamw> whoops
15:54:13 <adamw> #unfo
15:54:14 <adamw> #undo
15:54:14 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xa429850>
15:54:18 <adamw> #topic Test Days
15:54:30 <adamw> so, let's get through this fast
15:54:55 <adamw> it looks like we didn't get much participation in the mariadb event
15:55:07 <adamw> #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 <Viking-Ice> why bother re-runningit
15:55:35 <adamw> #info https://fedoraproject.org/wiki/Test_Day:2013-05-02_Internationalization went off fine
15:55:48 <adamw> 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 <Viking-Ice> those responsable for the mariadb migrations should just bloddy test it themselves
15:56:19 <Viking-Ice> switching databases on upgrades is WRONG
15:56:34 <Viking-Ice> while we still ship the same database
15:56:43 <adamw> #info https://fedoraproject.org/wiki/Test_Day:2013-05-07_ABRT preparation looks all ready, let's do some announcements
15:56:52 <Viking-Ice> 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 <adamw> #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 <adamw> is someone working with the sssd organizers on that one?
15:57:45 <kparal> I'm building that one too
15:57:48 <adamw> okay
15:57:53 <kparal> they already have it
15:58:00 <adamw> #action kparal to ensure abrt and sssd test days have live images ready
15:58:09 <adamw> #action adamw to do some promotion for the test days
15:58:13 <adamw> #topic open floor
15:58:18 <adamw> alrighty, we have 1 minute :)
15:59:18 <adamw> anything else we need to discuss?
15:59:56 * adamw sets boring old deterministic fuse for 1 minute
16:00:34 <adamw> everyone over to #fedora-blocker-review after this!
16:00:41 <adamw> we have quite a few proposed blockers to knock off.
16:02:53 <adamw> thanks for coming folks, blocker review starting up now
16:02:55 <adamw> #endmeeting