16:00:06 <jkurik> #startmeeting F23 Beta Go/No-Go meeting 16:00:06 <zodbot> Meeting started Thu Sep 17 16:00:06 2015 UTC. The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:35 <sgallagh> Salutations! 16:00:43 <jkurik> #meetingname F23_beta_Go_No-Go_meeting 16:00:43 <zodbot> The meeting name has been set to 'f23_beta_go_no-go_meeting' 16:00:59 <jkurik> #topic Roll Call 16:01:04 <nirik> .hello kevin 16:01:05 <jkurik> sgallagh: welcome 16:01:05 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com> 16:01:09 <sgallagh> .hello sgallagh 16:01:11 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com> 16:01:34 <jkurik> lets wait for one or two minutes to let people to join 16:01:40 * satellit listening 16:01:57 <sgallagh> jkurik: Well, we have to wait until we have all groups represented, else we cannot proceed 16:02:27 <jkurik> yes, I hope they will join in a while 16:02:58 <adamw> ahoy. 16:03:09 * adamw never remembers what time this meeting is. 16:03:24 <nirik> I think we have moved it +/- a few hours at times. 16:03:34 <sgallagh> adamw: That is absolutely not because we try to keep you from joining. 16:04:06 <adamw> well, there did seem to be an unusually large number of bear traps outside. 16:04:38 <sgallagh> adamw: Bear traps? I ordered pit traps. Somebody screwed up 16:05:12 <roshi> that's what you get when ordering from ACME 16:05:25 <sgallagh> Meep meep 16:05:40 <sgallagh> I think we still need mattdm and dgilmore or pbrobinson, yes? 16:05:49 <jkurik> #chair sgallagh adamw nirik roshi 16:05:49 <zodbot> Current chairs: adamw jkurik nirik roshi sgallagh 16:06:02 * mattdm is here 16:06:03 <jkurik> dgilmore: are you around ? 16:06:12 * kparal is here 16:06:15 <mattdm> was just getting grabbing a plateful of food 16:06:20 <adamw> nirik can be releng, i think, but dgilmore is best 16:06:28 * nirik nods. 16:06:58 * pbrobinson is here but I believe dgilmore to be best too 16:07:10 <jkurik> #chair sgallagh adamw nirik roshi mattdm pbrobinson 16:07:10 <zodbot> Current chairs: adamw jkurik mattdm nirik pbrobinson roshi sgallagh 16:07:23 <jkurik> ok, so let's start, hopefully dgilmore will join 16:07:32 <jkurik> #topic Purpose of this meeting 16:07:39 <sgallagh> Well, a nirik *and* a pbrobinson is probably close enough :) 16:08:05 <jkurik> #info Purpose of this meeting is to see whether or not F23 Beta is ready for shipment, according to the release criteria. 16:08:07 * pbrobinson runs away and hides ;-) 16:08:07 <jkurik> #info This is determined in a few ways: 16:08:08 <jkurik> #info No remaining blocker bugs 16:08:10 <jkurik> #info Release candidate compose is available 16:08:11 <jkurik> #info Test matrices for Beta are fully completed 16:08:13 <jkurik> #link https://qa.fedoraproject.org/blockerbugs/milestone/23/beta/buglist 16:08:14 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Beta_RC1_Installation 16:08:16 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Beta_RC1_Base 16:08:17 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Beta_RC1_Desktop 16:08:19 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Beta_RC1_Server 16:08:23 <jkurik> pbrobinson: please stay here, we need you 16:08:33 <jkurik> #topic Current status 16:08:37 <adamw> pbrobinson: look out, the bear traps are over that way. 16:08:40 <pbrobinson> jkurik: I was _joking_ 16:08:43 <jkurik> #info We have two accepted blockers for the Beta, when one of these is already in verification. 16:08:43 <kparal> cloud link missing 16:09:05 <jkurik> kparal: ah, you are right 16:09:15 <adamw> two? I only see 1260394 16:09:26 <sgallagh> One of those is reopened for F22 16:09:32 <sgallagh> It's fixed in F23 16:09:36 * nirik sees 6 proposed and 1 accepted 16:09:50 <jkurik> ah, the second one just disapeared 16:10:07 <jkurik> it was there 30mins agou 16:10:14 <adamw> pfah, things move fast in the blocker world ;) 16:10:21 <dgilmore> hi all 16:10:24 <jkurik> #info We also have 6 proposed blockers for the Beta, when one of these is already in verification 16:10:35 <adamw> so, it's not noted in the bug, but i believe we can treat #1260394 as a special blocker 16:10:41 <jkurik> #info We have one accepted blockers for the Beta, which is already in verification. 16:10:52 <nirik> blocker review/ 16:10:52 <nirik> ? 16:10:56 <adamw> the update was not included in beta rc1, but as it's an upgrade-related issue it doesn't need to be, it really just needs to be in stable by the time beta goes out 16:11:06 <jkurik> Let's start with Mini-blocker review 16:11:08 <adamw> sure 16:11:20 <jkurik> adamw: may we use your services, please ? 16:11:31 <adamw> roshi does it more than me these days 16:12:01 <roshi> can do, unless you want to swap and I secretarialize 16:12:25 * roshi gets started then 16:12:29 <jkurik> #topic Mini blocker review 16:12:34 <roshi> #topic (1263235) audit in F23 is older than in F22, breaks upgrade 16:12:35 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1263235 16:12:35 <roshi> #info Proposed Blocker, audit, ON_QA 16:13:18 <nirik> hum. 16:13:21 <adamw> this again is upgrade related so really just needs to go stable 16:13:26 <nirik> does this actually apply to the dnf plugin? 16:13:46 <adamw> nirik: the bug report explicitly shows it being used, so i'm going with 'yes' 16:13:48 <nirik> ie, I thought it did distro-sync 16:13:54 <nirik> well, no, it's just using dnf 16:13:59 <nirik> oh, so it is. 16:14:03 <nirik> odd. 16:14:06 <sgallagh> nirik: No, it *can*, but the default is not to use distro-sync 16:14:18 <nirik> thats unfortunate 16:14:19 <kparal> as least not yet, I'm trying to push for it 16:14:20 <sgallagh> wwoods was waiting on a ruling from FESCo on what is the preferred choice there 16:14:20 <roshi> +1 for the special blocker 16:14:32 <sgallagh> We kind of forgot about it because there isn't a ticket 16:14:34 <kparal> +1 16:14:38 <adamw> fwiw i have tweaked the wiki page to suggest using --best and --distro-sync 16:14:50 <nirik> so sure, +1 to make sure this is stable before tuesday 16:15:00 <kparal> sgallagh: there is now, see proposed final blockers 16:15:02 <jkurik> it seems to be already fixed however we will need a new RC, right ? 16:15:07 <sgallagh> +1 special blocker 16:15:14 <sgallagh> jkurik: No we don't 16:15:19 <adamw> so i'd like us to be clear on exactly what we're +1ing here for the record, since the 'special blocker' processes are not written down yet (i should really fix that) 16:15:21 <nirik> jkurik: no, it just needs to be in the stable/base repo before release 16:15:25 <sgallagh> It only happens on upgrade, which means it just needs to be in the stable repo 16:15:40 <roshi> proposed #agreed - 1263235 - AcceptedBlocker Beta - This bug is a conditional violation of the Beta criteria. Please fix so we can roll another RC for testing. 16:15:50 <sgallagh> patch 16:15:53 <adamw> in this case the requirement is that this be pushed stable as part of the 0-day set, right? 16:16:03 <nirik> adamw: well, really we could just say not blocker, and note to upkarma it. We always do a stable push before release. 16:16:13 <jkurik> then +1 as a blocker 16:16:18 <nirik> at least for the last N years. 16:16:22 <adamw> nirik: yeah, like i said in the bug, the blocker process is a bit of an awkward way to handle this, but we don't have anything else 16:16:26 <roshi> sgallagh: go ahead and send your patch 16:16:27 <sgallagh> proposed #agreed - 1263235 - AcceptedBlocker Beta - This bug is a conditional violation of the Beta criteria. The fixed package needs to be in the stable repo by release day. 16:16:36 <roshi> ack 16:16:45 <kparal> ack 16:16:46 <adamw> ack (with caveat that we should have some better way to handle this) 16:16:52 <nirik> what adamw said. ;) 16:16:57 <dgilmore> this could be fixed without a recompose 16:16:59 * adamw adds it to his todo list, where it will rot away gently 16:17:06 <adamw> dgilmore: yeah, we're not requiring a new RC. 16:18:06 <sgallagh> #agreed - 1263235 - AcceptedBlocker Beta - This bug is a conditional violation of the Beta criteria. The fixed package needs to be in the stable repo by release day. 16:18:22 <roshi> #topic (1263498) 32-bit Cloud image missing for 23 Beta RC1 16:18:23 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1263498 16:18:23 <roshi> #info Proposed Blocker, distribution, NEW 16:18:30 <roshi> thanks sgallagh 16:18:31 <nirik> we have one now. 16:18:38 <roshi> yeah 16:18:44 <roshi> and from my testing it's good to go 16:18:48 <dgilmore> nak it was decided for Alpha that 32 bit cloud is not a blocker 16:18:55 <dgilmore> but we now have it and will ship it 16:18:57 <roshi> still have to run the EC2 and Openstack testing though 16:19:10 <roshi> dgilmore: it changed again to blocker 16:19:20 <adamw> confusion reigns! 16:19:26 <roshi> it's the magical shapeshifting blocker image 16:19:28 <dgilmore> roshi: how, FESCo signed off on it not being a blocker 16:19:35 <dgilmore> did they sign off on it being a blocker again 16:19:50 <roshi> that, I can't say 16:19:53 <dgilmore> roshi: serriously we can not flip flop like that 16:19:58 <dgilmore> so its not a blocker 16:20:00 <roshi> been dizzy from the spinning round and round 16:20:19 <dgilmore> we are going to ship it as we have it 16:20:19 <roshi> *i* think it shouldn't be - and until this week thought it wasn't 16:20:24 <dgilmore> but it is not a blocker 16:20:39 <roshi> ok, I'll update the wiki as well 16:20:56 <roshi> +1 close this ticket citing the fesco vote 16:20:58 <sgallagh> roshi: looks like you updated https://fedoraproject.org/w/index.php?title=Fedora_Program_Management%2FReleaseBlocking%2FFedora23&diff=422212&oldid=421353 16:21:09 * danofsatx is here 16:21:09 <sgallagh> Without checking in with FESCo? 16:21:21 <adamw> does someone have a record of said fesco vote? 16:21:35 <roshi> yeah, I did - acting on what I thought was the correct info at the time 16:21:54 <nirik> basically fesco said: yeah, that list. 16:21:55 <sgallagh> https://fedorahosted.org/fesco/ticket/1427 16:22:01 <nirik> but it was not clear on the wiki page 16:23:19 <roshi> I don't know, tbh - I'm fine not shipping 32 cloud 16:23:27 <sgallagh> Can we take this discussion elsewhere, since the fact is irrelevant at this point? 16:23:36 <dgilmore> roshi: it will ship as we have it now 16:23:38 <roshi> yeah, sure 16:23:39 <sgallagh> Non-blocking means "ship it if we have it" 16:23:46 <dgilmore> we are getting off topic for here 16:23:46 <roshi> right 16:23:51 * nirik nods 16:23:51 <adamw> sgallagh: er, that ticket doesn't include any vote on 32-bit cloud that I can see. 16:24:06 <adamw> we're not really off topic, since the topic is whether this bug is a blocker or not. 16:24:39 <roshi> in that ticket, the update says to get the WG sign offs on their lists and fesco would review - as I read it, at least 16:24:53 <roshi> so when cloud decided they still wanted 32, i updated the wiki with that 16:25:00 <roshi> thinking it was still up for review 16:25:29 <mattdm> here's the cloud ticket https://fedorahosted.org/cloud/ticket/118 16:25:32 <mattdm> https://fedorahosted.org/cloud/ticket/118 16:25:35 * adamw would like to know for sure the status in case this comes up again for final. 16:25:56 <mattdm> it also doesn't mention 32 bit, but there are +1s for roshi's changes, which clearly do 16:26:17 <roshi> https://fedorahosted.org/cloud/ticket/106 16:26:26 <roshi> is the 32bit discussion 16:26:27 <sgallagh> So the FESCo decision happened on 2015-09-02 16:26:27 <nirik> when fesco voted on the 2nd to accept the page... 16:26:32 <mattdm> ah there we go 16:26:42 <nirik> it was there. 16:26:48 <nirik> i386 (Fedora-Cloud-netinst-i386-23.iso) in 23_RCx/Server/i386/ 16:26:55 <nirik> but thats netinstall 16:27:00 <sgallagh> https://lists.fedoraproject.org/pipermail/devel/2015-September/214054.html 16:27:00 <mattdm> " Yes, let's please add those back and get a comms plan going to sunset the image in the F24 timeframe. Any objections?" 16:27:01 <nirik> Signed off by Cloud WG on: TBD 16:27:23 <jkurik> On the cloud meeting has been decided for 32bits that "Retiring this arch for cloud in F24 timeframe." 16:27:27 <roshi> on the wiki I put the date we had the meeting to sign of on the list 16:27:43 <jkurik> so I believe we need to have it for F23 16:28:09 <adamw> this all seems extremely indirect. 16:28:22 <roshi> it was, and has been adamw 16:28:30 * nirik really hopes we do this better for f24. 16:28:32 <roshi> the wiki page and tracking all of this is directly because of that 16:28:50 <roshi> especially after I had such a hard time keeping track of who thought what was blocking for F22 16:28:51 <dgilmore> this is all a mess 16:29:13 <roshi> we got it settled for F22, and *this* is a result of that 16:29:33 <nirik> roshi: this was an attempt to make it better, but it just made it worse. ;) 16:30:01 <sgallagh> I propose that we treat it as non-blocking for Beta since we are confused and have a discussion (with FESCo) about the status for Final 16:30:12 <nirik> sgallagh: +1 16:30:17 <roshi> works for me 16:30:24 <roshi> +1 16:30:25 <dgilmore> not being a blocker does not mean it wont ship. just that we will not hold up the release for it 16:30:33 <dgilmore> sure 16:30:35 <nirik> correct 16:30:40 * mattdm nods 16:30:41 <jkurik> I guess we need to talk to Cloud WG as FESCo delegated this to WGs 16:31:12 <mattdm> jkurik: maybe bring this back to one of those tickets so this isn't lost? 16:31:17 <dgilmore> this is why I wanted a full list of deliverables for the release before Alpha, and knowing what was and was not a blocker 16:31:28 <dgilmore> but we failed to do that 16:31:43 <roshi> proposed #agreed - 1263498 - RejectedBlocker Beta - There is some confusion as to whether this is blocking, and we're waiting on deliberation from Fesco for it's status for Final. 16:31:44 * adamw is +1 to anything that looks like a definite decision 16:31:45 <dgilmore> it should have been signed off months ago 16:31:47 <adamw> ack 16:31:55 <roshi> dgilmore: yeah, the timing of the list didn't work out 16:32:01 <sgallagh> roshi: ack 16:32:08 <adamw> however, we're going to pull in the images since they have been built, right? 16:32:08 <dgilmore> +1 16:32:14 <dgilmore> ack 16:32:17 <sgallagh> adamw: Yes 16:32:18 <dgilmore> whatever :) 16:32:20 <roshi> #agreed - 1263498 - RejectedBlocker Beta - There is some confusion as to whether this is blocking, and we're waiting on deliberation from Fesco for it's status for Final. 16:32:25 <dgilmore> adamw: we are 16:32:33 <dgilmore> so its going to ship 16:32:37 <adamw> kk. 16:32:38 <roshi> onto the next one 16:32:39 <roshi> #topic (1244394) Upgrade stuck on script 16:32:39 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1244394 16:32:39 <roshi> #info Proposed Blocker, initial-setup, POST 16:32:41 <jkurik> #action jkurik to re-open https://fedorahosted.org/cloud/ticket/106 and clarify 32bits deliverables whether these are blocking or not for F23 16:33:53 <sgallagh> adamw: BTW, if you're curious, I'm that person you're referring to in Comment #16 ;-) 16:34:14 <adamw> sgallagh: i thought it was you but couldn't remember for sure, sorry 16:34:19 <sgallagh> No worries. 16:34:19 * nirik reads 16:35:16 <nirik> does this happen on dnf-plugin-system-upgrades ? 16:36:59 <sgallagh> nirik: I think we established it only happens on "live" upgrades. 16:37:20 * satellit I did not see it yesterday in a f22 > f23 upgrade (f22 wks had run g-i-s) f22 live install 16:37:33 <adamw> the case we're concerned about at this point, i believe, is regular updates to installed f23 systems 16:37:38 <nirik> ok. Then IMHO it's a nasty bug, but not a blocker 16:38:22 <roshi> the case we're concerned about doesn't qualify as a blocker to me 16:38:41 <roshi> -1 from me 16:38:49 <nirik> we should try and fix it as soon as we can and hopefully before release, but -1 blocker. 16:38:50 <roshi> +1 FE though 16:39:11 <jkurik> +1 as FE 16:39:19 <sgallagh> It's mostly painful for people doing an unsupported live upgrade or people who installed Alpha and stumble into this situation 16:39:44 <danofsatx> yes. it's only applicable to pre-beta F23 installs on updates 16:40:09 <adamw> danofsatx: well, it's not been fixed yet, so as things stand, *any* F23 install is potentially susceptible to it on update. 16:40:15 <adamw> including Beta installs. 16:40:19 <sgallagh> Right 16:40:25 <roshi> proposed #agreed - 1244394 - RejectedBlocker AcceptedFreezeException Beta - This is a serious bug for those affected, but it's not wide spread enough to be considered blocking. If we have to cut another RC, we'd be inclined to include a fix for this if it's available. 16:40:31 <adamw> nack 16:40:36 <adamw> can we please discuss this a bit further? 16:40:40 <sgallagh> But any solution we come up with should address the F22 case as well. 16:40:42 <roshi> sure 16:40:46 <adamw> i'd like to propose sometihng but i'm just crossing some t's 16:41:00 <sgallagh> I'm still in favor of the %pre solution and aiming to have this in the 0day update set 16:41:11 <adamw> right, that's more or less what i wanted to say 16:41:14 <roshi> works for me - didn;t know you had more adamw 16:41:28 <adamw> i would say it doesn't necessarily have to be in the 0-day set (though it'd be nice if it is) 16:41:50 <sgallagh> Right, the %pre solution should work whenever it lands. 16:41:51 <adamw> *but* i'd say that if we ship beta as-is, we should require that the next i-s update have a %pre fix or equivalent 16:42:08 <adamw> as things stand we have a pending i-s update submitted for stable: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15307 16:42:51 <adamw> so we should un-queue that and ask mkolman in-bug to implement a %pre solution or equivalent before resubmitting 16:42:57 <nirik> sure. 16:43:13 <sgallagh> adamw: Makes perfect sense to me 16:43:13 <roshi> that makes sense 16:43:15 <adamw> i'm ok with rejectedblocker/acceptedfe but wanted to make sure that sounds OK to everyone 16:43:32 <adamw> nirik: can you or dgilmore zap the update? 16:43:35 <roshi> want me to put the bit about %pre in the proposed agreed? 16:43:52 <adamw> roshi: if you can fit a quick summary in, sure 16:44:19 <nirik> sure... hum. do we know which update causes the issue? or it's all older updates? 16:44:44 <roshi> proposed #agreed - 1244394 - RejectedBlocker AcceptedFreezeException Beta - This is a serious bug for those affected, but it's not wide spread enough to be considered blocking. However, if a fix can be added in %pre by release day, we'd grant an FE to fix this issue. 16:45:04 <sgallagh> nirik: Let's take that to #fedora-qa or #fedora-devel 16:45:08 <nirik> sure 16:45:17 <dgilmore> adamw: ca try 16:45:23 <dgilmore> can even 16:45:27 <nirik> roshi: it doesn't need to be a FE for that does it? 16:45:51 <dgilmore> nirik: not once we open up 16:45:55 <nirik> right 16:46:08 <nirik> so I would say we just drop the FE stuff from it... 16:46:17 <roshi> if we want it ready to go for 0day release though... wouldn't it need one? 16:46:21 <adamw> no 16:46:24 <dgilmore> no 16:46:25 <sgallagh> no 16:46:27 <danofsatx> I would think that after initial boot, the i-s service should be masked or disabled, making this a moot point to begin with. It shouldn't even be running. 16:46:28 <adamw> but i'm ok with FE 16:46:38 <adamw> just in case we somehow wind up slipping, it'd be good to fix this then. 16:46:46 <sgallagh> But we can leave FE in, because if we end up respinning for some other reason, might as well carry it 16:46:47 <dgilmore> once we have a Beta and make sure that all blockers and FE have gone stable we open the flood gates 16:47:05 <dgilmore> FE will not hurt so sure :) 16:47:13 <adamw> danofsatx: it *should* be, yes. that's the unknown part of this bug: in some cases it seems like i-s somehow runs in a regular session. exactly when/how that happens is the part no-one's figured out yet, but as we have multiple reports of the bug, it clearly does happen. 16:47:50 <roshi> acks, then? 16:48:07 <dgilmore> ack 16:48:11 <jkurik> ack 16:48:11 <danofsatx> ack 16:48:11 <sgallagh> ack 16:48:13 <roshi> #agreed - 1244394 - RejectedBlocker AcceptedFreezeException Beta - This is a serious bug for those affected, but it's not wide spread enough to be considered blocking. However, if a fix can be added in %pre by release day, we'd grant an FE to fix this issue. 16:48:25 <roshi> #topic (1263762) Kernel panic when booting 32b images from usb on AMD processors 16:48:26 * nirik shrugs ok. 16:48:28 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1263762 16:48:31 <roshi> #info Proposed Blocker, kernel, NEW 16:49:49 <nirik> there's workarounds and not too many people have this setup, so -1 blocker from me. 16:49:51 <sgallagh> I think we've beaten this particular horse rather soundly in the BZ and elsewhere 16:49:54 <sgallagh> -1 Blocker 16:50:17 <danofsatx> -1. 16:50:30 <danofsatx> mail list thread doesn't show it to be a bug 16:50:34 <kparal> 32bit amd machines seem to boot 32bit images fine, it's just 64bit amd + 32bit images 16:50:38 <danofsatx> erm, common bug, that is 16:51:08 <danofsatx> belay my last, I don't know WTF I'm talking about.... 16:51:09 <sgallagh> kparal: And not even all 64-bit CPUs 16:51:14 <nirik> right. so they could: switch to 64bit images, boot with maxcpus=1, or wait for the fix to land. 16:51:36 <sgallagh> Yeah, I think this needs to be on the Common Bugs page, but not a blocker 16:51:43 <sgallagh> The workarounds are legion 16:52:05 <mattdm> yeah. next! :) 16:52:25 <adamw> yep, -1. 16:52:53 <roshi> proposed #agreed - 1263762 - RejectedBlocker Beta - This bug isn't considered widespread enough to warrant blocker status and there are plenty of means to work around this. 16:53:04 <jkurik> ack 16:53:07 <adamw> sure, ack 16:53:15 <kparal> ack 16:53:18 <roshi> #agreed - 1263762 - RejectedBlocker Beta - This bug isn't considered widespread enough to warrant blocker status and there are plenty of means to work around this. 16:53:26 <roshi> #topic (1263988) livecd-iso-to-disk doesn't create bootable usb drive 16:53:26 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1263988 16:53:26 <roshi> #info Proposed Blocker, livecd-tools, NEW 16:54:19 <roshi> if it works from F21 and F22, I'm -1 for this 16:54:22 <sgallagh> Since this works from F22, I'm -1 blocker 16:54:38 * nirik reads 16:54:40 <sgallagh> I could see an argument for Final, but not for Beta 16:54:48 * danofsatx is confused 16:54:50 <roshi> yeah 16:55:08 <sgallagh> danofsatx: What about? 16:55:10 <nirik> sure, -1 blocker at this point... 16:55:11 <danofsatx> is the current tool livecd-tools 16:55:12 <kparal> I'm fine with moving this to Final 16:55:16 <dgilmore> -1 blocker 16:55:29 <danofsatx> I know we're moving from one tool to another, but I forget which is which 16:55:37 <danofsatx> oh, and -1, btr 16:55:38 <danofsatx> btw 16:55:43 <dgilmore> we should perhaps document in CommonBugs 16:55:52 <adamw> danofsatx: livecd-iso-to-disk , dd , and liveusb-creator are the 'supported' methods. 16:55:57 <adamw> yeah, commonbugs can't hurt 16:55:58 <adamw> -1 16:56:20 <jkurik> are we going to make this FE ? 16:56:45 <roshi> proposed #agreed - 1263988 - RejectedBlocker Beta - This but only affects attempting to write from F23, but this method works on our stable releases and therefore is not considered a blocker. Please repropose for Final if this doesn't get fixed in the meantime. 16:56:47 <sgallagh> jkurik: I don't see any value in that 16:56:51 <dgilmore> ack 16:56:57 <sgallagh> ack 16:57:06 <roshi> jkurik: we could reevaluate this for FE if we expect to have to roll another RC 16:57:14 <jkurik> ok 16:57:16 <jkurik> ack 16:57:19 <roshi> #agreed - 1263988 - RejectedBlocker Beta - This but only affects attempting to write from F23, but this method works on our stable releases and therefore is not considered a blocker. Please repropose for Final if this doesn't get fixed in the meantime. 16:57:29 <sgallagh> But as this is the last proposed blocker, I don't see another RC being likely... 16:57:34 <roshi> #topic (1264012) liveusb-creator doesn't create bootable Live i686 image in default cp mode 16:57:37 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1264012 16:57:39 <roshi> #info Proposed Blocker, liveusb-creator, NEW 16:57:41 <roshi> ^^ is the last blocker proposal 16:58:02 <sgallagh> Last comment sounds like it was user error, not something that would happen in proper usage 16:58:03 <sgallagh> -1 blocker 16:58:22 <danofsatx> -1 16:58:36 * satellit gnome-disks restore works fine as a workarround 16:58:37 <adamw> roshi: FE for usb writing tools doesn't make sense in general, they don't need to be in the frozen set. 16:58:42 <roshi> -1 same reasoning as the last now 16:58:45 <jkurik> -1 16:58:47 <roshi> last one, I mean 16:58:49 <roshi> ah 16:58:50 <nirik> -1 blocker 16:58:52 <adamw> in general issues with the *tools* are rarely blockers - we mainly have the criterion for issues with the *media* 16:59:03 <dgilmore> I think syslinux is still busted 16:59:09 <adamw> in the past we've had cases where the media were somehow badly set up such that they couldn't be successfully written to USB 16:59:11 <dgilmore> but -1 16:59:24 <adamw> dgilmore: that would make sense as to why it doesn't happen on 22 i guess 16:59:30 <adamw> -1, same as before 16:59:32 <roshi> proposed #agreed - 1264012 - RejectedBlocker Beta - This but only affects attempting to write from F23, but this method works on our stable releases and therefore is not considered a blocker. Please repropose for Final if this doesn't get fixed in the meantime. 16:59:55 <dgilmore> adamw: it was busted for Alpha, its why the cloud images switched to grub 16:59:59 <danofsatx> ack 17:00:05 <adamw> dgilmore: yeah, i know what you're talking about 17:00:11 <adamw> dgilmore: i just forgot that luc uses it 17:00:21 <kparal> ack 17:00:24 <adamw> ack 17:00:26 <jkurik> ack 17:00:27 <sgallagh> ack 17:00:30 <dgilmore> ack 17:00:36 <roshi> #agreed - 1264012 - RejectedBlocker Beta - This but only affects attempting to write from F23, but this method works on our stable releases and therefore is not considered a blocker. Please repropose for Final if this doesn't get fixed in the meantime. 17:00:44 <jkurik> what about https://bugzilla.redhat.com/show_bug.cgi?id=1260394 - it just appears on the Accepted Blockers list 17:01:07 <roshi> there's one proposed FE, if we want to go over it 17:01:37 <roshi> jkurik: we'll look at that next 17:01:37 <roshi> #topic (1260394) plasma-desktop and plasma-workspace packages break KDE session loading 17:01:46 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1260394 17:01:46 <roshi> #info Accepted Blocker, plasma-desktop, ON_QA 17:02:23 <hhorak> Nobody approached me but rather checking, anybody with some topic for E&S meeting? 17:02:38 <sgallagh> hhorak: This is the Go/No-Go meeting 17:02:51 <adamw> do we need a #fedora-meeting-3? :) 17:03:02 <dgilmore> adamw: there is about 5 of them 17:03:06 <sgallagh> adamw: I think the Ministry of Silly Walks is meeting in there right now 17:03:20 <adamw> i've updated 1260394 to note that it's a 'special blocker' along the lines of the other 'must be in 0-day set' ones 17:03:25 <sgallagh> /me nosd 17:03:31 <sgallagh> *nods* 17:03:37 <roshi> yeah, nothing more to do with this one 17:03:46 <roshi> do the one FE, or move on? 17:03:59 <sgallagh> roshi: It's unlikely to matter 17:04:02 <dgilmore> roshi: do the FE 17:04:07 <jkurik> I would vote for FE 17:04:12 <roshi> #topic (1263230) python2-solv does not obsolete python-solv 17:04:12 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1263230 17:04:13 <roshi> #info Proposed Freeze Exceptions, libsolv, NEW 17:04:56 <roshi> yeah, 0day should be fine for this 17:05:11 <sgallagh> I'm -1 FE on this. There's no value at all to the frozen package set. 17:05:13 <dgilmore> +1 FE it can just go stable for Tuesday 17:05:28 <sgallagh> dgilmore: An FE isn't needed for that. 17:05:34 <dgilmore> sgallagh: I strongly believe you are wrong 17:05:50 <dgilmore> sgallagh: its not but I believe you are wrong 17:06:04 <sgallagh> dgilmore: Sorry, I'm not following 17:06:17 <dgilmore> sgallagh: it provides a way to make sure we push it and it does not accidently fall through the cracks 17:06:27 <dgilmore> its in not needed 100% but there is value 17:06:34 <roshi> votes? 17:06:55 <nirik> well, there's actually no fixed package to push yet. 17:06:56 <sgallagh> dgilmore: That would be true of a "special" blocker, sure 17:07:01 <roshi> -1 just based on it not being in the frozen set - which is what FE's are for 17:07:04 <danofsatx> +1 17:07:12 <sgallagh> But an FE is always a best effort no matter what. 17:07:19 <roshi> +2/-2 right now 17:07:27 <dgilmore> sgallagh: being able to use dnf to update seems pretty valuable to me 17:07:45 <jkurik> +1 for FE 17:08:04 <roshi> +3/-2 now, writing proposed agreed 17:08:29 <nirik> I'm confused... this prevents upgrades? but N people have done them? 17:09:06 <roshi> proposed #agreed - 1263230 - AcceptedFreezeException Beta - It would be good to update this package so users with the old package can complete updates. Accepted FE. 17:09:19 <roshi> it prevents updates to users who have python-solv installed 17:09:39 * adamw is still confused 17:10:02 <adamw> why does this need to be in the frozen package set? are we saying that you can't upgrade *from* some particular version of it? 17:10:06 <kparal> it does not prevent, but holds back libsolv to F22 version. which is an important package and we'd like to see it upgraded 17:10:22 <adamw> but a freeze exception is to get a package in the frozen Beta tree / on the media. 17:10:24 <roshi> a 0day update can handle this fine 17:10:34 <roshi> that's why we have split votes adamw 17:10:42 <roshi> +3/-2 currently 17:11:02 <dgilmore> adamw:just to give us a checklist item to make sure we push it stable before release ships 17:11:05 <adamw> if the bug is 'upgrading to this version of the package doesn't work', an FE is not really relevant. 17:11:07 <nirik> -1 17:11:11 <adamw> dgilmore: that's not what FEs are for, so -1 17:11:14 <kparal> yes, 0 day update will solve this. this vote doesn't really matter now, it would matter if this was fixed earlier 17:11:19 <nirik> 0 packages depend on that one 17:11:24 <nirik> workaround: remove it. 17:11:28 <adamw> we're using the blocker process at a pinch to track cases we block on, but i don't want to start using the FE process *too*, let's not compound the mess 17:11:48 <roshi> proposed #agreed - 1263230 - RejectedFreezeException Beta - This package isn't a part of the frozen set, so there's no need for an FE. 17:12:07 <adamw> dgilmore: for right now i'll set up an ad hoc tracker bug for all the 0-day push cases we ran into today just to make sure we don't miss any. 17:12:17 <kparal> ack 17:12:27 <roshi> thanks adamw 17:12:29 <adamw> ack, w/e 17:12:35 <dgilmore> adamw: okay thats fine 17:12:43 <nirik> adamw: this could be a commonbugs too... 17:13:41 <roshi> acks? 17:13:50 <nirik> ack 17:13:52 <roshi> #agreed - 1263230 - RejectedFreezeException Beta - This package isn't a part of the frozen set, so there's no need for an FE. 17:14:01 <roshi> jkurik: back to you - that's all of them 17:14:16 <kparal> haven't we skipped 1264012? 17:14:17 <jkurik> ok, thanks for the review 17:14:28 <jkurik> #topic Test Matrices coverage 17:14:31 <kparal> roshi: ^^ 17:14:31 <roshi> kparal: nope 17:14:40 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Beta_RC1_Summary 17:14:42 <roshi> it was rejected just like 1263988 17:14:56 <kparal> roshi: I somehow missed that, thanks 17:15:42 <roshi> np 17:16:19 <jkurik> so it looks like we have some issues with Spins 17:17:13 <adamw> jkurik: sorry, what do you mean? 17:17:22 <adamw> if you mean the size check results, none of them is in blocking images. 17:17:45 <roshi> still some cloud testing to do (EC2 and openstack), but I expect no issues 17:18:02 <jkurik> adamw: ok 17:18:09 <kparal> SAS and hwraid is missing, as usual 17:18:15 <adamw> i did hwraid for TC5 17:18:28 <adamw> was gonna do RC1 this morning, didn't get around to it, but no reason to believe anything changed 17:18:32 <adamw> i can just stuff in a 'previous TC5 result' 17:18:36 <kparal> ok, great 17:18:56 <adamw> i think we should keep SAS in as some sort of tradition. :P 17:18:57 * satellit same for missig non blocking spins 17:19:15 <adamw> are we missing some spins? 17:19:35 <kparal> all the failure marks seem to be related to rejected blockers, so it should be fine 17:19:38 <satellit> a few have not been install tested 17:19:56 * nirik did xfce. 17:20:03 <nirik> not sure I updated the wiki tho. ;) 17:20:13 <adamw> satellit: oh, 'missing' in that sense - yeah, it's not required. 17:20:20 <satellit> k 17:21:19 * adamw realizes he's spent far less time running validation tests this cycle thanks to the validation testing bot...but probably spent all the same time maintaining the validation testing bot 17:21:19 <jkurik> so then... 17:21:20 <adamw> so...hmmm. 17:21:29 <jkurik> proposed #info No blocking issues comming from Test Matrices 17:21:45 <adamw> s/comming/coming/ 17:21:50 <adamw> and also note that the coverage looks great 17:22:02 <roshi> yeah, it does 17:22:02 <jkurik> proposed #info No blocking issues coming from Test Matrices 17:22:57 <jkurik> #info No blocking issues comming from Test Matrices 17:23:11 <jkurik> #topic Go/No-Go decision 17:23:21 <adamw> so i did have one other issue to bring up 17:23:28 <adamw> https://fedorahosted.org/rel-eng/ticket/6253 17:23:37 <adamw> a lot of the ISOs in the RC1 tree seem to be present in multiple locations 17:23:47 <adamw> oh, now i see pbrobinsons says he cleaned it up 17:23:49 <adamw> let me see... 17:24:09 <nirik> yeah, that was cleaned up 17:24:22 * adamw re-creates the download table to check 17:24:56 <nirik> the new i686 cloud image still needs to be put in place... 17:25:05 <adamw> yep, that looks to be the only thing outstanding now 17:25:17 * satellit there were 2 entries in it today 17:25:36 <jkurik> adamw: should not be blocking, right ? 17:26:13 <adamw> jkurik: sure, that's what we agreed 17:26:17 <adamw> per QA's rules - https://fedoraproject.org/wiki/Go_No_Go_Meeting - QA votes Go 17:26:43 <jkurik> PgM votes Go 17:26:50 <dgilmore> releng votes Go 17:27:24 * nirik votes go with whatever votes he has. :) 17:27:36 <dgilmore> nirik: FESCo :) 17:27:41 <dgilmore> or infra? 17:27:44 <dgilmore> or both 17:27:49 <nirik> both! :) 17:28:05 * mattdm votes go with symbolic FPL figurehead vote 17:28:25 <jkurik> ok, so we have Infra,FESCo,Releng,PgM, QA, FPL - anyone else ? 17:29:29 <jkurik> proposed #info Beta release of Fedora 23 is considered as GOLD 17:29:33 * danofsatx checks his memberships 17:29:36 <sgallagh> FESCo votes go 17:29:42 <dgilmore> ack 17:29:45 <sgallagh> (Sorry, got interrupted by a phone call) 17:29:47 <dgilmore> sgallagh: too late 17:29:47 <roshi> ack 17:29:55 <dgilmore> nick voted for FESCo 17:30:00 <dgilmore> nirik: 17:30:00 * mattdm runs off to meeting 17:30:03 <sgallagh> ack 17:30:18 <sgallagh> dgilmore: Come on, I want to contribute too ;-) 17:30:39 <jkurik> #info Beta release of Fedora 23 is considered as GOLD 17:30:48 <jkurik> #topic Open floor 17:31:08 <jkurik> anything else someone wants to discuss ? 17:31:19 * roshi has nothing 17:31:32 <adamw> awesome job everyone 17:31:37 <adamw> we're definitely getting better at this stuff 17:31:44 <roshi> for sure 17:31:46 <adamw> one RC, no hero testing and no slips == woo 17:31:48 <danofsatx> yeah, only 1.5 hours today 17:31:57 <roshi> that's a win for sure 17:31:59 <adamw> and we didn't even have to fudge anything too badly this time ;) 17:32:01 <roshi> let's keep it up for final 17:32:13 <adamw> oh, i created a tracker bug for 0-day updates: https://bugzilla.redhat.com/show_bug.cgi?id=1264167 17:32:19 <adamw> kinda following the general blocker bug tracker style 17:32:25 <dgilmore> adamw: muchas gracias 17:32:27 <adamw> i'll try and propose some kinda policy for it later 17:32:44 <sgallagh> Hooray for no last-minute shenanigans this time! 17:32:53 <jkurik> #info adamw has created a tracker bug for 0-day updates: https://bugzilla.redhat.com/show_bug.cgi?id=1264167 17:33:11 <roshi> I still have to test EC2 and Openstack, so cross your fingers everything goes well 17:33:40 <sgallagh> Someone stick roshi in the isolation chamber :) 17:33:59 <adamw> but...we only built it big enough for kparal 17:34:12 <danofsatx> even better 17:34:18 <sgallagh> adamw: the human body is more compressible than you might expect 17:34:32 <jkurik> seems like no serious topic, so let's end the meeting :-) 17:34:37 <roshi> can't lock us in together, we'll plot out blockers to find for final while we're in there 17:35:11 <sgallagh> roshi: Not if we isolate you *from the air* 17:35:27 <sgallagh> Ok, time to end the meeting :) 17:35:32 <jkurik> let see most of you on the Readiness meeting in 25 minutes on the same channel :-) 17:35:32 <roshi> kparal and I will overcome :p 17:35:42 <roshi> sounds good - thanks jkurik ! :) 17:35:42 <jkurik> #endmeeting