From Fedora Project Wiki

< QA‎ | Meetings
Revision as of 00:45, 7 May 2013 by Adamwill (talk | contribs) (update page with the results of the meeting)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

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!

Retrieved from "https://fedoraproject.org/w/index.php?title=QA/Meetings/20130506&oldid=335786"