QA/Meetings/20130506

Attendees

• adamw (104)
• jreznik (22)
• Viking-Ice (21)
• brunowolff (16)
• dgilmore (14)
• tflink (12)
• zodbot (6)
• kparal (4)
• nirik (2)
• spoore (1)
• mkrizek (1)
• satellit (1)
• jskladan (1)
• pschindl (1)

Agenda

• Previous meeting follow-up
• Fedora 19 Beta status/planning
• Secondary arch freeze exceptions
• Test Days
• Open floor

Previous meeting follow-up

• martix or adamw to write a Graphics Test Week recap email - we did not get around to this yet
• tflink to do some promotion for the blocker bug proposal webapp - Tim wrote a blog post, he will write a list mail soon

Fedora 19 Beta status/planning

• #959911 is a strange livecd-creator bug, we will keep an eye on it if we start having weird problems composing lives
• TC3 is out and in testing, TC4 will come when appropriate

Secondary arch freeze exceptions

• We agreed that 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)

Test Days

• Test_Day:2013-04-30_MariaDB seemed to be poorly attended, adamw will see if we need to re-run it
• Test_Day:2013-05-02_Localization_(i18n) looks like it went off well and resulted in useful feedback
• Test_Day:2013-05-07_ABRT looks ready to go, we just need to do some announcing
• Test_Day:2013-05-09_SSSD_Improvements_and_AD_Integration needs a live image and some publicity

Open floor

N/A

Action items

• martix or adamw to write a Graphics Test Week recap email
• tflink to write a list post announcing the blocker bug proposal webapp
• brunowolff to update the FE guidelines to reflect the agreement (see above)
• adamw to look into Test_Day:2013-04-30_MariaDB lack of participation and see if we should re-run it
• kparal to ensure abrt and sssd test days have live images ready
• adamw to do some promotion for the test days

IRC Log

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

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!