16:01:12 #startmeeting F21-blocker-review 16:01:12 Meeting started Wed Sep 3 16:01:12 2014 UTC. The chair is kparal. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:12 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:12 #meetingname F21-blocker-review 16:01:12 The meeting name has been set to 'f21-blocker-review' 16:01:12 #topic Roll Call 16:01:13 bug tabs pre-loaded, even ;) 16:01:18 danofsatx: and you shall have it! 16:01:36 Hello folks 16:01:39 who's here for our usual 3 hours of pure fun? 16:01:39 * pschindl is here 16:01:45 #chair pschindl roshi 16:01:45 Current chairs: kparal pschindl roshi 16:01:47 * roshi is here 16:01:50 * pwhalen is here 16:01:55 good day, everyone! 16:02:03 * satellit listening 16:02:06 hi kparal 16:02:11 * danofsatx has a hard stop in 1.5 hours 16:03:08 * tflink can be around if needed 16:03:19 adamw might attend intermittently, as he said 16:03:29 and provided I spelled it correctly, even 16:03:31 * sgallagh has to run the FESCo meeting in an hour, but I'll be reading both 16:03:47 let's go 16:03:49 #topic Introduction 16:03:49 Why are we here? 16:03:49 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 16:03:49 #info We'll be following the process outlined at: 16:03:49 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:03:51 #info The bugs up for review today are available at: 16:03:53 #link http://qa.fedoraproject.org/blockerbugs/current 16:03:55 #info The criteria for release blocking bugs can be found at: 16:03:57 #link https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria 16:03:59 #link https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria 16:04:01 #link https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria 16:04:04 #info 6 Proposed Blockers 16:04:05 #info 5 Accepted Blockers 16:04:09 #info 2 Proposed Freeze Exceptions 16:04:11 #info 1 Accepted Freeze Exceptions 16:04:14 ============================================================ 16:04:15 Proposed Blockers 16:04:17 ============================================================ 16:04:20 #topic (1128474) Adjust anaconda for new format of .buildstamp with Product name included 16:04:21 #link https://bugzilla.redhat.com/show_bug.cgi?id=1128474 16:04:23 #info Proposed Blocker, anaconda, POST 16:04:45 oh, secretary volunteer... roshi? 16:04:57 yup 16:05:01 thanks 16:05:19 np 16:06:02 cookie to the first one to come up with proper criterion 16:06:38 When using the dedicated installer images, the installer must be able to use either HTTP or FTP repositories (or both) as package sources. The network install image must default to a valid publicly-accessible package source. 16:06:56 ^^ 16:06:58 that works 16:06:59 whoops, wrong one 16:07:13 I think the second sentence covers it 16:07:19 that one fits fine, IMO 16:07:19 danofsatx: do you have a better one? 16:07:23 oh, didn't see that.... 16:07:29 * danofsatx was befuddled. 16:07:30 WORKSFORME 16:07:38 works for me 16:07:39 where's me cookie? 16:07:47 .moar danofsatx cookie 16:07:47 here cookie, have some more danofsatx 16:07:50 hehe 16:07:55 .moar cookie danofsatx 16:07:56 here danofsatx, have some more cookie 16:07:59 you probably lost it already - when you were befuddled 16:09:08 ahoyhoy 16:09:24 o/ 16:09:53 So this seems like an obvious blocker, yes? 16:09:58 adamw ho! 16:10:11 yeah, seems that way 16:10:12 +1 blocker for me 16:10:24 +1 blocker 16:10:31 +1 blocker 16:10:34 +1 16:10:37 propose #agreed 1128474 - AcceptedBlocker - violates "The network install image must default to a valid publicly-accessible package source." criterion 16:10:37 ack/nack/patch? 16:10:44 ack 16:10:46 hey 16:10:47 ACK 16:10:50 have I lost everybody? 16:10:51 I might have been too fast, but technically, you should say 'ack' now :) 16:11:01 yes, it seems as obvious blocker to me as well 16:11:04 ack 16:11:13 ack 16:11:14 #agreed 1128474 - AcceptedBlocker - violates "The network install image must default to a valid publicly-accessible package source." criterion 16:11:30 #topic (1135746) Fedora 21 Server TC5 software selection spoke is blank 16:11:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=1135746 16:11:30 #info Proposed Blocker, comps, NEW 16:11:31 though, if I was going to be a kermudgeon I would say that it was defaulting to the right place, just not setting it up correctly locally... 16:11:48 * danofsatx doesn't follow 16:12:08 is anyone secretarying? 16:12:12 roshi is 16:12:15 yup, me 16:12:29 roshi: the term 'valid' is intended to convey 'working' :P 16:12:33 that way I can get more emails on the bugs as they get updated :p 16:12:44 roshi: it's so much fun, isn't it 16:13:06 this also seems as an obvious blocker 16:13:09 something like that :) 16:13:23 +1 16:13:29 and there are votes in the bug already 16:13:31 +1 blocker 16:13:31 * satellit repo is bad also if try to ues sources for http:// 1128474 16:13:34 * danofsatx is reporter 16:13:55 +1 16:14:00 +1 blocker 16:14:02 propose #agreed 1135746 - AcceptedBlocker - violates "When using a dedicated installer image that contains packages, the installer must be able to use the install medium as a package source." 16:14:08 Ack 16:14:13 ack 16:14:30 ack 16:14:41 #agreed 1135746 - AcceptedBlocker - violates "When using a dedicated installer image that contains packages, the installer must be able to use the install medium as a package source." 16:14:55 #topic (1134524) F21 Workstation Alpha TC4 netinstall does not offer correct environment 16:14:56 #link https://bugzilla.redhat.com/show_bug.cgi?id=1134524 16:14:56 #info Proposed Blocker, distribution, MODIFIED 16:15:30 Didn't we accept this last week? 16:15:31 this BZ leaves me confused. 16:15:40 sgallagh: I thought so 16:15:43 no, we punted awaiting imput from workstation WG 16:15:48 ah 16:15:58 Right, we weren't sure if netinstall was supported 16:16:00 from what I've read on the desktop list, workstation team concluded they care about netinst 16:16:22 which would make it a blocker 16:16:33 https://bugzilla.redhat.com/show_bug.cgi?id=1134524#c8 16:17:55 I'm a bit confused. so does it work or not? 16:18:07 so, based on c8, should this criteria be moved to beta? 16:18:13 not till release? 16:19:06 * kparal reads the whole report properly 16:19:21 perhaps the bigger issue is we should have repos for TCs if this is going to be an issue going forward 16:20:00 if desktop team concludes they care about netinst, we need to look at the criteria for that... 16:20:19 true 16:20:43 so, IIUIC, this doesn't work out of the box, but works if you feed it a custom repo link 16:21:11 yes 16:21:11 the general pre-.next requirement at alpha was that it should work without manual repo config 16:21:19 so if we care about workstation netinst we should probably block on this 16:21:41 +1 to that 16:21:50 * roshi has a hard time thinking netinst wouldn't be cared about 16:21:58 why doesn't it simply use development/21/ repo? 16:22:40 kparal: Because that provides it with ALL of the environments. We want it to be equivalent to the set of stuff you'd get from the live install 16:22:56 there was a discussion that .ks in live was different than repo (minor) 16:23:08 what's wrong on offering all the environment? 16:23:18 so i'd say we should agree in principle to modify the criteria wording to require workstation netinst to work in the same way we previously required non-productized netinst to work, and block on that basis 16:23:19 we could have just a single netinst this way 16:23:22 kparal: Selecting the right one by default, I think 16:23:30 kparal: it's just not what they want 16:23:34 kparal: It's not that easy. 16:23:41 it never is :) 16:23:48 "2) What you get going through either path should be identical; 16:23:48 installing from the network shouldn't put you into a 16:23:48 choose-your-own-adventure path of selecting desktops and optional 16:23:48 server components. 16:23:48 " 16:23:57 yeah, kparal it would involve changing spokes and whatnot and a global netinst wasn't something people wanted 16:24:03 (not sure why though, tbh) 16:24:05 but that's not really our problem, our problem is just deciding if this is a blocker 16:24:13 adamw: ok, I understand that argument 16:24:25 +1 blocker 16:24:28 we're doing blocker review not product design :) 16:24:33 * danofsatx settles it 16:24:46 psh, being all specific and on point about it adamw :p 16:24:46 so we have to agree that the criterion should be changed 16:24:51 as adamw said 16:25:04 hm, does it? 16:25:14 +1 with the blocker if we change the criteria to support it 16:25:21 but can we change F21 criterion if we're already evaluating against it? F22 criterion is the new edit target, not F21 16:25:25 now i remember, the current criterion actually covers that bug, and at first we thought that'd be a problem but now it doesn't seem to be 16:25:30 the current criterion say: "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set." 16:25:43 danofsatx: we've pretty commonly done it in the past, yeah. 16:25:57 doesn't sound right, but ok 16:26:01 we could *clarify* the criterion for .next, but it's good enough right now to use to make this a blocker, so let's do that and move on 16:26:10 +1 blocker 16:26:10 ok 16:26:34 repo for wks has only server and libreoffice if change sources 16:26:35 danofsatx: the thing we try for is doing the things that make sense and not just following a rule regardless of if it fits the purpose we had the criterion for initially 16:26:44 especially with the .next stuff, AIUI 16:26:56 understood. 16:27:01 propose #agreed 1134524 - AcceptedBlocker - violates "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set." 16:27:07 ack 16:27:10 our targets move a bit more than is optimal sometimes :) 16:27:11 Ack 16:27:17 ack 16:27:20 ack 16:27:35 at least it's a target rich environment. hard to miss ;) 16:27:38 danofsatx: practically speaking, we suck too much at updating the criteria in time to commit to not changing them ;) 16:27:42 haha 16:27:46 #agreed 1134524 - AcceptedBlocker - violates "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set." 16:27:50 danofsatx: we still haven't done the rewrites for .next for beta/final yet 16:28:05 #topic (1102241) [RFE] libguestfs should detect OSTree (project-atomic) qcow2 disk image 16:28:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=1102241 16:28:05 #info Proposed Blocker, libguestfs, NEW 16:28:23 i'll add a note to revisit that criterion 16:28:47 I have a feeling we already discussed this one last week? 16:29:39 of course we did 16:29:50 who was the secretary? let's blame somebody 16:30:15 adamw it seems! 16:30:29 anyway: 16:30:30 16:26:08 #agreed - 1102241 - RejectedBlocker - This doesn't directly violate any specific criteria and a workaround is already in place as a default for generating the images 16:30:40 WORKSFORME 16:30:43 so let's just skip this one and go on 16:30:46 any objections? 16:31:08 none from me 16:31:11 roshi: please update the bug report and then fire adamw 16:31:11 +1 skip 16:31:26 Nothing to see here. Move along. 16:31:28 #topic (1136519) Review Request: f21-kde-theme - Fedora Twenty One KDE Theme 16:31:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=1136519 16:31:28 #info Proposed Blocker, Package Review, MODIFIED 16:31:31 .fire adamw 16:31:31 adamw fires adamw 16:31:32 bah, I won't fire adamw - he can just owe us one :p 16:31:39 :) 16:32:28 -1 blocker, +1 FE 16:32:31 so, does this change the default background or not? 16:32:36 "I guess doesn't qualify as "default", but does affect kde spin theming." 16:32:39 It changes the default background FOR KDE 16:32:43 on KDE it does 16:32:57 and without it, it would be the same as in F20? 16:33:03 correct 16:33:03 in that case it would be a blocker 16:33:09 KDE is blocking 16:33:20 same f21 clouds with login screens on left 16:33:23 still in Fedora.Next world, at least I think 16:33:29 although, there was talk in the channel this morning regarding sddm...let me see if I can find it 16:34:09 * roshi catches up on the reading the report 16:35:06 Ah right. KDE is blocking. 16:35:09 ok, this fixes KDM, which is no longer the default display manager for KDE. it is now sddm, and it is currently unclear whether sddm is updated. 16:35:31 danofsatx: does it change also the desktop background? 16:35:38 not just login manager screen? 16:35:46 according to rdieter, yes 16:36:03 "This is Fedora Twenty One KDE Theme Artwork containing KDM theme, 16:36:03 KSplash theme and Plasma Workspaces theme." 16:36:09 I unfortunately haven't verified any of them yet :( 16:36:13 I guess "Plasma Workspaces" is nowadays what they call KDE 16:36:30 satellit: any input? 16:37:09 I saw the screenshot on #fedora-kde yesterday looked like clouds with left login bars 16:37:13 * kparal pinging rdieter on #fedora-devel 16:37:26 sorry, I'm here 16:37:56 jreznik_: now something about this bug? does it really change the default desktop background, or just the login manager screen? 16:37:57 kparal: right Plasma Workspaces means KDE and it changes default background 16:38:03 coolie 16:38:05 coolio 16:38:23 propose #agreed 1136519 - AcceptedBlocker - violates "The default desktop background must be different from that of the two previous stable releases." 16:38:24 that's why I pushed on rdieter to have it asap and did review yesterday night 16:38:29 ack 16:38:38 jreznik_: thanks 16:38:44 Ack 16:38:47 ack 16:39:02 ack 16:39:04 (Out of curiosity, does this requirement mean that we could just come up with three backgrounds and cycle through them repeatedly?) 16:39:19 it wouldn't violate the criteria as it's written 16:39:48 #agreed 1136519 - AcceptedBlocker - violates "The default desktop background must be different from that of the two previous stable releases." 16:39:50 * rdieter waves, hi 16:39:57 red green and blue solid color backgrounds ? :) 16:39:57 hey, we just accepted it :) 16:40:21 mkolman: We used to have solid-red as a background when you logged in as root. 16:40:23 kparal: ok, need anything else from me? 16:40:24 * sgallagh waves his cane 16:40:36 sgallagh: it's a pet project for design team, I actually told gnokii if we could just have one wp forever and he wasn't happy to hear it :) 16:40:37 rdieter: no, thanks. jreznik_ already answered everything 16:41:05 #topic (1135670) RuntimeError: maximum recursion depth exceeded 16:41:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=1135670 16:41:05 #info Proposed Blocker, python-blivet, POST 16:42:26 so I guess this occurs when you click the storage spoke? 16:42:30 or custom partitioning spoke 16:42:47 samantha doesn't get a cookie for not providing a criterion 16:43:00 i think we're looking at an existing mdraid array here 16:43:03 looking at the patch 16:43:11 mkolman: do you know? 16:43:23 kparal: it's evaluating existing storage, i think, so it's not UI interaction dependent 16:43:23 because custom part doesn't have to work in Alpha 16:43:25 IIRC 16:43:30 anaconda evaluates existing storage as soon as you start it 16:44:03 that would be really long list without recursion depth limits :) 16:44:14 Right, I think this causes a crash no matter the path as long as the existing configuration triggers the bug 16:44:15 alright, in that case let's find a good criterion 16:44:17 so this becomes basically a conditional case 16:44:37 * kparal offers a second cookie 16:44:45 Right, the question is whether Alpha is required to handle all existing cases or whether it assumes an unpartitioned drive 16:44:48 if it affects all existing mdraids, i'd say that's enough possible cases to merit blocker status 16:44:55 lemme check the criteria again 16:44:56 we may be really tight at aplha 16:45:00 kparal: I think a fix is already WiP 16:45:18 "The installer must be able to complete an installation to a single disk using automatic partitioning. " 16:45:22 The installer must be able to complete an installation using any supported locally connected storage interface. 16:45:26 " 16:45:26 ...well, so long as the disk is big enough, of course. It must work whether the disk is formatted or not and whether or not it contains any existing data - but since this is an Alpha, it's OK if it can only install to a disk with existing data by overwriting it. 16:45:26 " 16:45:27 "The installer must be able to complete an installation using any supported locally connected storage interface." 16:45:34 no, that's not the one 16:45:36 ;) 16:45:54 adamw: the second quote is from where? 16:46:00 that's devices/interfaces, not filesystems/storage vlo,ues 16:46:08 kparal: the 'Details!' paragraph 16:46:13 riiiight 16:46:25 always forget to look in there 16:46:26 wait, we're supposed to read those? :p 16:46:29 * roshi ducks 16:46:41 in that case +1 blocker 16:47:28 other opinions? 16:47:36 if it affects all existing mdraid, +1 16:47:42 +1blk 16:47:43 +1 16:47:47 certainly +1 fe, and we have a fix already, so we don't need to worry too hard about it 16:48:30 propose #agreed 1135670 - AcceptedBlocker - adamw says we shouldn't worry too hard about it 16:48:42 er, that's not the right one 16:48:45 propose #agreed 1135670 - AcceptedBlocker - violates "The installer must be able to complete an installation to a single disk using automatic partitioning." 16:48:46 haha 16:48:49 :) 16:49:26 patch: #agreed 1135670 - AcceptedBlocker - violates "The installer must be able to complete an installation to a single disk using automatic partitioning... whether the disk is formatted or not and whether it contains any existing data" 16:49:45 =) 16:49:45 ack 16:49:49 oh. hmm. 16:49:50 wait. 16:49:51 ack 16:49:56 that says "single disk", doesn't it? 16:50:01 it does 16:50:03 single disk raid is pretty unusual. 16:50:07 we all fail reading comprehension! 16:50:12 in that case i change my vote to -1 blocker +1 FE 16:50:13 nack 16:50:31 oh damn, more complications 16:50:56 adamw: I'm sticking with blocker 16:51:04 Because we still can't install to a single disk 16:51:11 Because reading the set of disks crashes 16:51:22 that's actually a good point 16:51:23 hrm, that is a bit ambiguous 16:51:34 i think i was thinking of a single disk attached to the system when i wrote the criterion, but... 16:51:35 Regardless of how many disks are in the RAID set, we can't break it apart and install on just one of them 16:51:55 it might be a bit too much to ask for Alpha 16:51:58 but is it worth blocking Alpha? it's pretty corner case 16:52:11 i wouldn't say corner case, but not necessarily serious enough to block alpha 16:52:27 I guess I'm also more -1/+1 here 16:52:30 is it really still a corner case with the hybrid drives all the rage these days? 16:52:36 adamw: I meant corner case in your meaning of not enought to block alpha 16:52:50 danofsatx: we're talking about Alpha now 16:52:51 * roshi hasn't voted yet, but it seems to be a configuration issue and a fix is wip 16:52:56 -1/+1 fe 16:53:00 -1/+1 fe 16:53:24 +1/+1 (I think it should go in, but I'm okay if we decided it's not a blocker) 16:54:12 propose #agreed 1135670 - RejectedBlocker AcceptedFreezeException - doesn't strictly violate Alpha disk criteria (not a single disk setup), but we would include the fix if this is fixed in time 16:54:17 ack 16:54:25 Ack 16:54:49 ack 16:55:00 ack 16:55:10 ack 16:55:13 #agreed 1135670 - RejectedBlocker AcceptedFreezeException - doesn't strictly violate Alpha disk criteria (not a single disk setup), but we would include the fix if this is fixed in time 16:55:30 and we have one extra contestant here 16:56:17 #topic (1136953) Make eog the default image viewer 16:56:18 #link https://bugzilla.redhat.com/show_bug.cgi?id=1136953 16:57:26 I'm not sure this release criterion was made with this purpose 16:57:52 and I think this is too trivial to block Alpha 16:58:06 but +1 FE of course 16:58:56 Yeah, I'll admit it was a bit of a reach, but it didn't *exactly* match the FE criteria as written either 16:59:08 but it's a good question, whether we should block later milestone with this type of requests 17:00:02 kparal: I'd say it should have the same weight as FESCo requests 17:00:20 jreznik: meaning block Alpha? 17:00:53 kparal: if we block Alpha on FESCo requests, then yes (even it's trivial change) 17:01:04 I mean it makes sense. they want to change it, we should wait. but it's not a "QA blocker". it's some other kind of blocker :) 17:01:05 as WGs are I'd say in par with FESCo 17:01:19 kparal: it's the same kind as FESCo blocker 17:01:20 jreznik: FESCo has the privilege to declare any BZ a blocker, regardless of the criteria 17:01:33 sgallagh: are you sure workstation group wants to block alpha with this? 17:01:43 I'm not sure that WGs should have that exact power though, as blocker means it holds up all the Products 17:01:58 kparal: I'm certain that they'd be fine with FE 17:01:58 sgallagh: good point 17:02:09 Since they have a fix ready anyhow 17:02:13 +1 sgallagh 17:02:20 let's de-nominate to FE then? 17:02:26 I'd say so 17:02:28 Fine with me 17:02:40 we might hit the same topic some time in the future, but let's do this now 17:02:46 I'm +1 17:02:49 fe 17:03:01 +1 fe. sry 17:03:10 +1 FE 17:03:14 kparal: yeah, I think we will hit this in the future, so maybe let's do FE now but raise it on list what to do in the future 17:03:24 good call 17:03:26 +1 FE 17:03:53 propose #agreed 1136953 - AcceptedFreezeException - if this is fixed in time, we will accept it in the release 17:04:28 roshi: and please adjust the blocks: field 17:04:36 yeah 17:05:01 ack/nack/patch? 17:05:10 ack 17:06:00 ack 17:06:06 ack 17:06:09 Ack 17:06:15 #agreed 1136953 - AcceptedFreezeException - if this is fixed in time, we will accept it in the release 17:06:20 * sgallagh goes semi-responsive for FESCo meeting 17:06:27 ping me directly if my input is needed 17:06:29 sgallagh: thanks for attending 17:06:42 ============================================================ 17:06:43 Proposed Freeze Exceptions 17:06:43 ============================================================ 17:06:52 #topic (1136813) Release Notes in f21 alpha TC5 workstation does not start when clicked in Sundry 17:06:52 #link https://bugzilla.redhat.com/show_bug.cgi?id=1136813 17:06:52 #info Proposed Freeze Exceptions, fedora-release-notes, MODIFIED 17:07:39 ah, it has been dropped 17:07:52 an hour ago 17:07:54 let's go on 17:07:55 I dropped this and filed two new ones instead :) 17:08:21 you make my life so difficult 17:08:22 https://bugzilla.redhat.com/show_bug.cgi?id=1136959 and https://bugzilla.redhat.com/show_bug.cgi?id=1135890 are the FE requests 17:08:23 ok 17:08:26 I am very sorry! 17:08:30 #topic (1136959) gnome-screenshot launcher doesn't work 17:08:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=1136959 17:08:30 #info Proposed Freeze Exceptions, gnome-screenshot, NEW 17:09:09 +1 FE 17:10:19 +1 FE is fine with me 17:10:26 it's likely to have minimal impact and it fixes a crasher 17:10:34 +1 FE 17:10:36 +1FE 17:10:42 +1 FE 17:11:00 propose #agreed 1136959 - AcceptedFreezeException - if this is fixed in time, we will accept it in the release 17:11:09 may I throw one more bug in? 17:11:16 drago01: sure 17:11:23 ack 17:11:28 kparal: https://bugzilla.redhat.com/show_bug.cgi?id=1133142 17:11:29 ack 17:11:32 ack 17:11:49 #agreed 1136959 - AcceptedFreezeException - if this is fixed in time, we will accept it in the release 17:12:00 ack 17:12:03 #topic (1135890) can't set password 17:12:03 #link https://bugzilla.redhat.com/show_bug.cgi?id=1135890 17:12:03 #info Proposed Freeze Exceptions, gnome-initial-setup, NEW 17:12:29 +1 17:12:45 drago01: do you propose that one as FreezeException or an AlphaBlocker? 17:13:01 https://bugzilla.redhat.com/show_bug.cgi?id=1135141 ? 17:13:03 kparal: freeze exception (I do have a fix already anyway) 17:13:17 password is too short? 17:13:45 * satellit no pop up 17:14:08 +1 FE 17:14:31 +1 FE (I love voting on my own requests) 17:14:39 satellit: I guess your bug is a duplicate of the one being discussed? 17:14:49 looks like it 17:14:58 I'll mark them as duplicate 17:15:09 satellit, yours looks awfully similar. the problem appears to be grey text on grey background - it's there, but you can't see it. 17:15:31 propose #agreed 1135890 - AcceptedFreezeException - if this is fixed in time, we will accept it in the release 17:15:44 was told that checker in G-I-S was tricky 17:16:40 * kparal pokes roshi pschindl 17:17:02 ack/nack/patch? 17:17:31 ack 17:17:35 danofsatx: mine button did not work if password too short or simple 17:18:01 ack 17:18:11 ack 17:18:33 ack 17:18:39 * roshi was reading 17:18:54 #agreed 1135890 - AcceptedFreezeException - if this is fixed in time, we will accept it in the release 17:18:56 g-i-s password standards are high (which is a good thing) 17:19:16 now let's do the one drago01 proposed right now 17:19:19 #topic (1133142) Wrong shadows on CSD windows when SNA is enabled 17:19:19 #link https://bugzilla.redhat.com/show_bug.cgi?id=1133142 17:19:20 #info Proposed Freeze Exceptions, xorg-x11-drv-intel, MODIFIED 17:19:38 roshi: actually the password check is meant to be advisory, not enforced 17:19:42 that's getting changed upstream 17:20:12 it's annoying during testing, but I like the "We won't let you use 'password' as your password" 17:20:25 -1 FE. corner case. 17:20:37 roshi: (there are studies that suggest that enforced high password standards just force people to write passwords down somewhere so its not always a "good thing") 17:20:48 +1 FE, makes Alpha looks much more polished 17:20:49 drago01: do you have any reasoning for this bug? updating intel driver is quite risky 17:20:56 not shown now if too short a password... 17:21:01 is SNA the default method? 17:21:24 kparal: looks bad; sna is enabled by default; intel has high user base; fix isn't that invasive 17:21:26 drago01: True, but if you train people to lock those passwords in a desk, it's significantly mitigated 17:21:48 drago01: are we very very sure that it shouldn't break anything else? 17:21:50 +1 FE if SNA is defualt 17:21:51 true drago01 - I suggest using a battery staple on such people :P 17:22:08 criteria? 17:22:17 danofsatx: no criteria for FEs 17:22:17 we don't have criteria for FEs, really. 17:22:21 just 'guidelines'. 17:22:22 oh. 17:22:25 kparal: pretty sure yes 17:22:31 ok 17:22:34 +1 FE then 17:22:49 propose #agreed 1133142 - AcceptedFreezeException - if this is fixed in time, we will accept it in the release 17:23:01 ack 17:23:28 ack 17:24:04 ack 17:24:09 .moar acks kparal 17:24:10 here kparal, have some more acks 17:24:15 zodbot: thanks 17:24:21 #agreed 1133142 - AcceptedFreezeException - if this is fixed in time, we will accept it in the release 17:24:40 #topic (1122081) BTRFVolumeDevice does not fill mountpoint property 17:24:40 #link https://bugzilla.redhat.com/show_bug.cgi?id=1122081 17:24:40 #info Proposed Freeze Exceptions, python-blivet, POST 17:26:40 +1 FE 17:26:49 this early i'm ok with it, +1 FE 17:26:53 later on i'd probably -1 17:27:03 +1 adamw 17:27:05 +1 17:27:05 +1 FE 17:27:17 +1 17:27:29 propose #agreed 1122081 - AcceptedFreezeException - if this is fixed in time, we will accept it in the release 17:27:37 ack 17:27:41 ack 17:27:59 #agreed 1122081 - AcceptedFreezeException - if this is fixed in time, we will accept it in the release 17:28:20 and now your most favorite part 17:28:22 ============================================================ 17:28:22 Accepted Blockers 17:28:22 ============================================================ 17:28:31 #topic (1134507) Installing Fedora Server F21 Alpha TC4 from network tree crashes 17:28:32 #link https://bugzilla.redhat.com/show_bug.cgi?id=1134507 17:28:32 #info Accepted Blocker, anaconda, MODIFIED 17:29:34 this might be already fixed, needs to be tested, maybe even with TC5 17:30:59 yeah, the anaconda version is already stable 17:31:06 not sure if it is in TC5 17:31:11 #info this might be already fixed, needs to be tested, maybe even with TC5 17:31:41 roshi: please add needinfo to sgallagh and ask to re-test 17:31:48 maybe switch to ON_QA? 17:31:51 Hmm? 17:32:03 TC5 doesn't work at all for Server 17:32:06 See the earlier blocker :) 17:32:11 will do 17:32:20 ah 17:32:28 so we will need to wait 17:32:34 I'll be working on fixing that this afternoon. 17:32:42 Hopefully we'll be able to roll a working TC6 tomorrow 17:32:56 #undo 17:32:56 Removing item from minutes: INFO by kparal at 17:31:11 : this might be already fixed, needs to be tested, maybe even with TC5 17:33:04 #info this might be already fixed, needs to be tested with TC6 17:33:18 sgallagh: thanks for info 17:33:32 let's move on 17:33:36 #topic (1088933) update grubby to support device tree options for arm 17:33:36 #link https://bugzilla.redhat.com/show_bug.cgi?id=1088933 17:33:37 #info Accepted Blocker, grubby, POST 17:34:14 hey, progress! 17:34:24 if you say so 17:34:31 so don't ask for the needinfo on the previous bug kparal ? 17:34:41 roshi: no :) 17:34:54 whew, I almost pressed the button too 17:34:58 i dont think the status has changed, but we'll discuss it at our meeting today 17:34:59 that was a close call :P 17:35:01 roshi: Go ahead and set needinfo 17:35:06 It'll keep me honest :) 17:35:10 hehe 17:35:21 pwhalen_: can you please update the bug report afterwards? 17:35:22 done 17:35:28 now you must be honest :) 17:35:56 kparal, ok 17:36:00 thank you 17:36:26 #info pwhalen will discuss this today at arm meeting and will update the bug report 17:36:54 let's go on... 17:36:58 #topic (1127450) Black screen after userless installation of KDE live 17:36:59 #link https://bugzilla.redhat.com/show_bug.cgi?id=1127450 17:36:59 #info Accepted Blocker, initial-setup, ON_QA 17:37:20 I tested this and it looked fixed 17:37:44 satellit: great 17:38:01 https://bugzilla.redhat.com/show_bug.cgi?id=1127450#c25 17:38:16 #info satellit tested this and it seems to be fixed, let's set to VERIFIED and close it once it is pushed 17:38:35 who will do that once it's pushed? 17:38:46 someone 17:38:48 :) 17:39:00 I dunno - that guy has plenty on his plate :p 17:39:01 bodhi, ideally 17:39:32 * kparal is skipping a few more accepted blockers already in verified state 17:39:43 and that's all! 17:39:51 is there any purpose to go over accepted FEs? 17:40:06 not at this point I don't think 17:40:22 but then again, Go/No-Go is tomorrow 17:40:49 if it was fixed back on 08-20 probably nothing needs 'pushing' 17:40:55 i'll double check and close it 17:41:04 I have one more thing to discuss, if you guys have a few more minutes 17:41:11 #topic Open Discussion 17:41:16 kalev: bring it on 17:41:30 the topic is GNOME 3.13.91 17:41:50 I've got builds underway and it's fixing 3 proposed FE-s, at least 17:42:07 I'm planning to submit it to Bodhi / testing later today or early tomorrow 17:42:24 and depending on the feedback there, considering asking for a freeze exception for the whole of 3.13.91 update 17:42:31 would that make sense? 17:42:48 does it introduce any significant behaviour changes? 17:42:50 it would be nice to get extensive alpha testing for the new release 17:42:52 api/abi changes, etc etc 17:43:08 GNOME is in feature and UI and API / ABI freeze since .90 17:43:12 so it should be mostly bug fixes 17:43:25 i see the 's' word 17:43:52 I'd rather have it in Alpha than not. but if there were no blockers and this update arrived, I'd rather not take it in 17:44:19 so if we look like having at least a week to Alpha release, why not 17:44:37 yes, I guess it depends on the schedule, I wouldn't want to pull this in very late either 17:44:42 if we can get it in the next day or two, while we're still whacking showstoppers in netinst, it's probably ok 17:44:45 (at that point when it is proposed as FE) 17:44:45 need at least a few days to fix up issues that come up 17:44:46 i wouldn't want to go beyond that 17:44:55 in theory we're supposed to be releasing this week, btw, but...yeah, that's not happening. 17:44:57 adamw: the 's' word is mostly used as self protection "you me there are NO BUGS" .. "I said should ..." "ok" ;) 17:45:06 but we do have quite a few people working on GNOME so we should be able to fix any new issues in a timely manner 17:45:44 yeah, I'd agree with adamw - if we can get this week, it still ok I'd say 17:46:55 #info GNOME 3.13.91 is about to land in updates-testing soon, FreezeException might be discussed if there's still reasonably long time before Alpha release 17:47:05 OK cool, I'll try to get this in testing quickly and will file a freeze exception request once things are in place 17:47:32 and we might need to vote on it in the bug report itself, since the next meeting is in a week 17:47:39 thanks kalev 17:47:43 true kparal 17:48:13 o_O 17:48:26 A Freeze Exception for a complete GNOME Megaupdate? 17:48:42 sgallagh: we did it several times 17:48:47 nothing can go wrong, right? 17:48:50 ... 17:49:25 things have been so smooth so far :) 17:49:33 we don't have a lot of criteria covering Alpha desktop, so we're pretty flexible in how well it works 17:49:43 and it's better to spot the problems earlier than later 17:49:44 * jreznik tried gnome a few days ago but 10 minutes was enough to force him to make his default desktop working again :) 17:50:18 * satellit_e this is wks TC5 install seems ok 17:50:34 ok, anything else anyone? 17:50:41 * roshi has nothing 17:50:50 secretarializing is done as well 17:52:08 roshi: thanks a lot 17:52:23 it's actually easier to lead the meeting than to update the bugzilla :) 17:52:32 np - trying to get my bz email quota up :) 17:52:42 I know - why do you think I run the meetings now :p 17:53:00 maybe they should introduce badges for that - e.g. CCed to 10 000 bug reports! 17:53:08 haha 17:53:10 for sure 17:53:18 bug stalker I,II,III ... 17:53:29 +1 tflink 17:54:11 thanks everyone for coming. these meetings get longer and longer as we get closer to the release... :) 17:54:27 #endmeeting