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