17:00:38 <jreznik> #startmeeting F22 Beta Go/No-Go meeting
17:00:38 <zodbot> Meeting started Thu Apr  9 17:00:38 2015 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:39 <jreznik> #meetingname F22 Beta Go/No-Go meeting
17:00:39 <zodbot> The meeting name has been set to 'f22_beta_go/no-go_meeting'
17:00:53 <jreznik> #topic Roll Call
17:01:17 <jreznik> hey everyone, who's here today?
17:01:46 * satellit listening
17:01:59 * jzb raises hand
17:02:02 <roshi> .hello roshi
17:02:03 <zodbot> roshi: roshi 'Mike Ruckman' <mruckman@redhat.com>
17:02:06 <sgallagh> .hello sgallagh
17:02:09 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:02:14 <nirik> .hello kevin
17:02:16 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
17:02:43 <jreznik> #chair sgallagh roshi nirik adamw
17:02:43 <zodbot> Current chairs: adamw jreznik nirik roshi sgallagh
17:02:45 <adamw> .hello adamwill
17:02:47 <zodbot> adamw: adamwill 'Adam Williamson' <adamw+fedora@happyassassin.net>
17:03:30 <jreznik> let's move on!
17:03:33 <jreznik> #topic Purpose of this meeting
17:03:34 * randomuser wanders in
17:03:35 <jreznik> #info Purpose of this meeting is to see whether or not F22 Beta is ready for shipment, according to the release criteria.
17:03:36 <jreznik> #info This is determined in a few ways:
17:03:38 <jreznik> #info No remaining blocker bugs
17:03:39 <jreznik> #info Release candidate compose is available
17:03:41 <jreznik> #info Test matrices for Beta are fully completed
17:03:42 <jreznik> #link http://qa.fedoraproject.org/blockerbugs/milestone/22/beta/buglist
17:03:44 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC1_Installation
17:03:45 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC1_Base
17:03:47 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC1_Desktop
17:03:48 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC1_Server
17:04:07 <jreznik> #topic Current status
17:04:40 * pwhalen is here
17:04:41 <jreznik> as you can see from test matrices, we do have RC1 but still a few proposed blocker bugs on the list
17:05:14 <nirik> so yeah, blocker review?
17:05:16 <adamw> also coverage isn't complete, notably missing most server role tests
17:05:20 <adamw> but let's do blocker review...
17:05:45 * danofsatx is actually here....
17:05:54 <roshi> should I start then or is someone else going to?
17:05:57 <jreznik> #info RC1 is available, we have 5 blocker bugs proposed and QA coverage is not yet complete
17:06:09 <sgallagh> adamw: I keep forgetting to submit them, but I've run the server role tests and found no new bugs
17:06:13 <jreznik> roshi: would be great, if you can take care of it!
17:06:21 <roshi> sure thing
17:06:26 <jreznik> thx!
17:06:32 <adamw> sgallagh: oh good, i can stop killing myself then. all of the tests in the matrix?
17:06:43 <roshi> #topic Blocker Review
17:06:50 <sgallagh> Not all; I haven't done the kickstart-based ones
17:07:02 <roshi> I'll skip the boilerplate since we all know why we're here doing this :p
17:07:07 <adamw> k.
17:07:08 <sgallagh> And I meant to do the AD ones this morning, but the other one got in the way
17:07:08 <roshi> we have 5 proposed for Beta
17:07:09 <jreznik> sure
17:07:15 * adamw can't do AD but can do kickstart.
17:07:21 <roshi> #topic (1210259) missing libicui18n.so.52 after fedup to F22, firefox won't start
17:07:24 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1210259
17:07:27 <roshi> #info Proposed Blocker, firefox, NEW
17:07:42 <nirik> I don't think this needs to be a blocker really...
17:08:00 <nirik> it's going to be fixed before we release and it's not something that we would need to respin for
17:08:35 <adamw> it makes sense to me to accept it as a special blocker allowing us to push it stable before beta release.
17:08:41 <juliuxpigface> *juliuxpigface is here (sorry, I'm a bit late)
17:08:42 <nirik> sure, fine
17:08:47 <adamw> or, i suppose we can do it as a 0-day...
17:08:51 <adamw> we have a 0-day window for beta?
17:08:58 <kparal> blocker does not mean just compose issue
17:09:05 <danofsatx> we do now
17:09:29 <nirik> adamw: as soon as we say go we could do a stable push (well, the day after I guess as we need a tag for the exact thing that is beta)
17:09:31 <kparal> we should fix this before official announcement, but we don't need to block 'go' decision with this, if that makes sense
17:09:31 <adamw> well, whatever, i just figure we should push this stable before the beta release announce goes out.
17:10:23 <roshi> +1 to pushing the fix to stable before the announcement
17:10:25 <kparal> by granting this a freeze exception I think we can consider it 'solved'
17:10:35 <jreznik> that's another option
17:10:42 <roshi> since this only bothers upgrades, it can be fixed with an update
17:10:50 <adamw> eh, let's just go with nirik's approach
17:11:00 <adamw> -1 blocker in that case
17:11:14 <nirik> I am sure we will be pushing stable stuff before release. We usually do that saturday or so. ;) does it have karma?
17:11:21 <adamw> yeah, it has +4./
17:11:35 <sgallagh> nirik: It's firefox. It usually has stablekarma before hitting updates-testing /rant
17:11:36 <danofsatx> -1 blocker
17:11:41 <sgallagh> -1 blocker
17:11:43 <roshi> -1 blocker
17:11:47 <jreznik> kparal asked for karma for it
17:11:48 <juliuxpigface> -1 blocker
17:11:51 <jreznik> -1 blocker
17:12:22 <nirik> sgallagh: yeah, trye.
17:12:26 <roshi> proposed #agreed - 1210259 - RejectedBlocker Final - This can be solved with updates, there's no need to block Beta release for it.
17:12:29 <nirik> sure, -1 blocker
17:12:36 <sgallagh> roshi: Ack
17:12:50 <adamw> ack
17:12:53 <adamw> r
17:12:56 <adamw> rejectedblocker beta?
17:12:57 <nirik> ack
17:13:03 <roshi> hah, yeah
17:13:12 <adamw> .fire roshi
17:13:12 <zodbot> adamw fires roshi
17:13:12 * roshi is filing a final blocker now
17:13:21 <roshi> damnit, not again...
17:13:22 <roshi> :p
17:13:31 <roshi> proposed #agreed - 1210259 - RejectedBlocker Beta - This can be solved with updates, there's no need to block Beta release for it.
17:13:41 <adamw> ack
17:13:45 <jreznik> ack
17:13:52 <sgallagh> ack
17:13:53 <roshi> #agreed - 1210259 - RejectedBlocker Beta - This can be solved with updates, there's no need to block Beta release for it.
17:13:54 <juliuxpigface> ack
17:14:11 <roshi> though, you should really fire the guys who just acked without reading, not the guy with the typo :p
17:14:25 <roshi> #topic (1210042) F22 Beta RC1 progress bar does not update
17:14:25 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1210042
17:14:25 <roshi> #info Proposed Blocker, gtk3, NEW
17:14:27 <adamw> .fire everyone
17:14:27 <zodbot> adamw fires everyone
17:14:30 * nirik fires himself. Hurray! the rest of the day free!
17:14:38 <roshi> haha
17:14:53 <jreznik> not me! I did not ack it in time for the first time!
17:15:03 <nirik> so, this is anoying, but I don't think it's beta blockery.
17:15:04 <jzb> adamw: wait until after the release for the firings, pls.
17:15:29 <pwhalen> agreed, -1 blocker for this
17:15:35 * satellit I have seen this in workstation netinstall in boxes   progress stops @ 33% but then resumes in installing and completes
17:15:41 <danofsatx> -1 blocker
17:15:42 <roshi> -1 for this
17:15:56 * danofsatx has to go fix a user issue, back soon
17:16:01 <sgallagh> -1 blocker
17:16:02 <juliuxpigface> -1 blocker
17:16:10 <nirik> pwhalen: another good datapoint might be downgrading gtk3 and seeing which update brought in the bug? not sure how easy that would be tho...
17:16:11 <sgallagh> danofsatx: I recommend a 2x4 for that
17:16:38 <nirik> we do probibly have a few weeks still in koji of images.
17:16:45 <nirik> and all the tc's
17:16:48 <roshi> proposed #agreed - 1210042 - RejectedBlocker Beta - This bug is annoying, but doesn't actually *stop* the install from proceeding and is thus not considered a blocker for Beta.
17:16:54 <nirik> ack
17:17:01 <pwhalen> nirik, its been an issue for a while on dev boards. highbank works fine. we did discuss it before and it wasnt a blocker ..
17:17:03 <pwhalen> ack
17:17:04 <jreznik> ack
17:17:08 * roshi was tempted to test you all with another final thrown in there
17:17:13 <sgallagh> ack
17:17:16 <juliuxpigface> ack
17:17:18 <roshi> #agreed - 1210042 - RejectedBlocker Beta - This bug is annoying, but doesn't actually *stop* the install from proceeding and is thus not considered a blocker for Beta.
17:17:24 <nirik> pwhalen: ah, ok. Wasn't aware it was around for a while, I thought it just cropped up
17:17:25 <roshi> #topic (1209602) Creating a database server role instance doesn't set the password for the owner
17:17:27 <jreznik> roshi: for that reason I read it!
17:17:28 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1209602
17:17:31 <roshi> #info Proposed Blocker, rolekit, ON_QA
17:17:34 <sgallagh> Should we call the previous one a Final Blocker though
17:18:07 <roshi> I'll repropose with I secretarialize all these
17:18:07 <sgallagh> /me notes this was pulled into RC1 anyway.
17:18:16 <roshi> s/with/when
17:18:38 <adamw> yeah, i didn't call for votes in bug or anything as we had an accepted FE whcih the same update fixes
17:18:43 <adamw> +1 for me though
17:18:44 <nirik> so, sure... +1
17:18:48 <jreznik> +1
17:18:51 <sgallagh> +1
17:19:41 <roshi> proposed #agreed - 1209602 - AcceptedBlocker Beta - This bug is a clear violation of the following Final criterion: "The core functional requirements for all Featured Server Roles must be met, without any workarounds being necessary."
17:19:46 <adamw> ack
17:20:01 <sgallagh> ack
17:20:02 <juliuxpigface> ack
17:20:17 <roshi> #agreed - 1209602 - AcceptedBlocker Beta - This bug is a clear violation of the following Final criterion: "The core functional requirements for all Featured Server Roles must be met, without any workarounds being necessary."
17:20:19 <jreznik> ack
17:20:28 <roshi> #topic (1209695) yum/dnf changes break composoing ostree trees
17:20:28 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1209695
17:20:28 <roshi> #info Proposed Blocker, rpm-ostree, ON_QA
17:21:15 <nirik> since this isn't a release blocking image I guess -1
17:21:20 <roshi> -1/+1 FE
17:21:32 <nirik> but also that brings up the question... what is in those images we have? do we ship them with beta?
17:21:38 <sgallagh> -1 blocker, +1 FE (should we have to respin for something else)
17:21:39 <jreznik> -1 blocker/+1 FE
17:21:58 <roshi> jzb: can you answer nirik? I don't know
17:22:15 <jzb> which images, specifically?
17:22:25 <jzb> I've spun up earlier TCs and they seemed OK
17:22:45 <nirik> http://dl.fedoraproject.org/pub/alt/stage/22_Beta_RC1/Cloud-Images/x86_64/Images/
17:23:01 <nirik> due to this bug we don't know what releaseve or whatever it actually used I don't think.
17:23:07 <nirik> dgilmore: ^ you around ?
17:23:48 <nirik> dgilmore: which images are affected by the rpm-ostree breakage?
17:24:46 <nirik> walters might be able to see too? by downloading the images and looking at them?
17:24:49 <adamw> i think dgilmore figured the images that got built contained the stuff from the nightly tree.
17:24:54 <adamw> but i don't know for sure.
17:25:16 <jzb> sgallagh: what are the odds we'll need to respin?
17:25:17 <nirik> right. So if we reject this as a blocker, do we ship them? do we delete them? do we note they are not right?
17:25:31 <nirik> I guess we could circle back to this
17:25:38 <jreznik> dgilmore was around a few minutes ago, so he might appear later
17:25:41 <adamw> yeah, doesn't seem like something we have to decide at go/no-go
17:25:44 <adamw> maybe at readiness
17:25:58 <adamw> and of course we may +1 a later blocker and wind up fixing this as an fe later.
17:26:04 <adamw> -1/+1 is my vote too
17:26:09 <nirik> right. -1/+1 is my vote.
17:26:40 <sgallagh> jzb: The odds are low right now, but we haven't finished blocker review
17:26:53 <jzb> OK.
17:27:09 <dgilmore> ajax: lasim here
17:27:12 <dgilmore> gahh
17:27:14 <dgilmore> i am here
17:27:16 <roshi> proposed #agreed - 1209695 - RejectedBlocker AcceptedFreezeException Beta - This doesn't affect a release blocking edition, so is not considered a blocker. It would however be good to get a fix in if we have to respin for something else.
17:27:29 <nirik> ack
17:27:30 <juliuxpigface> ack
17:27:38 <dgilmore> all the Atomic images are effected
17:27:48 <dgilmore> afaik atomic is blocking
17:27:54 <dgilmore> I have been told it has to be there
17:27:59 <dgilmore> and has to be right
17:28:02 <dgilmore> which it is not
17:28:16 <dgilmore> i am -1 to the proposal
17:28:43 <jreznik> dgilmore: see https://bugzilla.redhat.com/show_bug.cgi?id=1209695#c7
17:28:57 <jreznik> Cloud WG agreed at a meeting today that the Atomic images are not considered 'release blocking'
17:29:16 <dgilmore> jreznik: that is not what I have been told by people
17:29:34 <adamw> well, it's what the fedora WG said.
17:29:35 <nirik> what people
17:29:42 <dgilmore> jreznik: so I guess the Cloud WG and those people need to talk
17:29:43 <nirik> can we get them to actually talk to the rest of the project
17:29:43 <jreznik> I'm not sure if there's log, I can try to take a look for it
17:29:47 * nirik is getting annoyed.
17:29:48 <sgallagh> dgilmore: FESCo and QA have never stated that this was release-blocking.
17:29:53 <dgilmore> nirik: sadly I can not mention it in public
17:30:10 <nirik> wow.
17:30:12 <jzb> dgilmore: can you loop me in?
17:30:26 <dgilmore> jzb: sure
17:30:29 <roshi> I looked for logs and couldn't find any decision saying it was release blocking...
17:30:30 <jzb> dgilmore: gracias
17:30:32 <nirik> this is not how things should be done.
17:30:38 <adamw> log is https://meetbot.fedoraproject.org/fedora-meeting-1/2015-04-08/cloud_wg.2015-04-08-18.59.log.html .
17:30:40 <sgallagh> dgilmore: Well, I'm sorry, but if no one could be bothered to go through proper channels and have FESCo sign off on it, I fail to see how that's our problem here today.
17:30:48 * nirik goes to get more coffee and to calm down a bit.
17:30:57 <jzb> nirik: I think there's probably some miscommunication
17:30:59 <adamw> yeah, no-one can declare Fedora images to be release blocking in a way that can'
17:31:05 <adamw> t be disclosed in public. that is Not On.
17:32:03 <roshi> which might be a large part of the confusion
17:32:16 <roshi> the discussion we had in the cloud WG is at the bottom, open floor
17:32:37 <jzb> can we table this for now? I'm pretty sure this is a miscommunication.
17:33:08 <roshi> sure, we can move on to the next one
17:33:19 <jreznik> jzb: this is go/no-go so we should get answer asap
17:33:39 <roshi> ]
17:33:39 <roshi> #topic (1209347) Unable to start Gnome X session on AMD based laptop
17:33:39 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1209347
17:33:39 <roshi> #info Proposed Blocker, xorg-x11-drv-ati, NEW
17:33:43 <adamw> jreznik: we can at least delay till we've reviewed the other blockers
17:33:44 <jreznik> jzb: but we can move on for now and if you can sort it out with the rest of folks/dgilmore, it would be great
17:33:57 <adamw> this is the big one we've been poking all morning...
17:34:05 <jreznik> yeah
17:34:11 <adamw> if anyone in the meeting has a hybrid graphics laptop they haven't tested rc1 on yet, please do
17:34:23 <jzb> jreznik: I'm on it.
17:34:28 <roshi> I'm on the fence with this one
17:34:45 <juliuxpigface> adamw: I've got amd+amd and I'm currently downloading the workstation rc1
17:35:37 <sgallagh> As noted, I've been able to repro on an Intel/nVidia hybrid
17:35:48 <adamw> so far we've confirmed, what, 3? laptops with hybrid graphics seem to hit this bug, no report that i know of from a laptop with modern hybrid graphics (i.e. after NVIDIA started branding it as 'optimus') that *doesn't* have the problem
17:35:57 <nirik> I'm -1/+1 I guess... it's nasty, but there's some workarounds and we can hopefully fix this in an update.
17:36:20 * adamw would really kinda like more data...
17:36:22 <roshi> basic graphics works, right?
17:36:34 <roshi> and sometimes enforcing=0/selinux=0 ?
17:36:35 <nirik> yeah.
17:36:49 <adamw> the one time selinux=0 worked seems to have been a freak
17:36:57 <nirik> of course basic graphics is poor, but it will get you a session
17:36:58 <adamw> didn't work for finalzone and sgallagh can't repeat it
17:37:06 <roshi> meh
17:37:16 <jreznik> dual gpus are...
17:37:17 <sgallagh> nirik: We can't really fix liveusb boot in an update (just to be clear)
17:37:22 <danofsatx> -1 blocker / +1 common bug
17:37:47 <sgallagh> But I still come down slightly on the side of a Common Bug rather than blocking
17:37:48 <nirik> sgallagh: right. true. we can fix it by final tho
17:37:49 <kparal> honestly, hybrid graphics mostly haven't worked in the past either
17:37:51 <roshi> but they could install with basic gfx and update, right?
17:37:55 <adamw> jreznik: ...common?
17:38:07 * adamw has the impression more new laptops *are* hybrid than aren't, these days
17:38:22 <sgallagh> adamw: That's really only true of workstation laptops
17:38:26 <jreznik> adamw: not working very well as sgallagh suggested above :(
17:38:30 <roshi> that's what it seems to me, once you get out of the "office productivity" level of laptop
17:38:32 <sgallagh> The vast majority of consumer models are Intel only
17:38:56 <adamw> that doesn't sound right.
17:38:58 <jreznik> gamers laptops + top models
17:38:59 * adamw checks bestbuy
17:39:10 <roshi> if I had a spare 2.5" drive I'd check on this lenovo
17:39:14 <kparal> a large portion of newer models are hybrid, to my knowledge
17:39:46 <jreznik> kparal: with intel having enough power for basic gaming it's less common but for amd it's true
17:39:52 <sgallagh> Ultimately, this is going to be a judgement call
17:39:59 <roshi> for sure
17:40:10 <danofsatx> Lenovo models over, say, $600 are hybrid, Asus ROG models may or may not be hybrid
17:40:21 <sgallagh> Do we feel that the workaround of installing in basic graphics mode is good enough for Beta, provided we block for this at Final?
17:40:25 <sgallagh> I say "yes"
17:40:31 <danofsatx> Dell Precision mobile workstations are hybrid
17:40:36 <kparal> I'd love this to be improved, but hybrid graphics support has been poor to non-working for a long time, we're not going to fix it in a week
17:40:58 <adamw> hum, guess you're right, most of the ones i see on bestbuy seem to be intel
17:40:59 <jreznik> kparal: likely we can fix this issue
17:41:05 * oddshocks pops in late, messed up the time
17:41:29 <jreznik> adamw: it's simple - hybrid is expensive = higher end models
17:42:43 <roshi> proposed #agreed - 1209347 - RejectedBlocker Beta AcceptedBlocker Final - This bug is a nasty one, but workarounds exist and the drivers can be fixed post 'basic graphics' installation with an update for Beta. This will block for final.
17:42:47 <jreznik> we can't make hybrid experience better by final, but this issue should be fixable thus -1/+1 FE
17:42:59 <nirik> ack
17:43:05 <jreznik> ack
17:43:09 <sgallagh> ack
17:43:14 <adamw> -1 beta blocker, +1 final blocker, +1 beta FE for a tested safe fix
17:43:31 <sgallagh> what adamw said
17:43:42 <danofsatx> thirded
17:43:46 <juliuxpigface> +1
17:44:11 <roshi> proposed #agreed - 1209347 - RejectedBlocker AcceptedFreezeException Beta AcceptedBlocker Final - This bug is a nasty one, but workarounds exist and the drivers can be fixed post 'basic graphics' installation with an update for Beta. If possible, a fix would be accepted for Beta. This will block for final.
17:44:18 <adamw> ack
17:44:21 <kparal> ack
17:44:26 <nirik> ack
17:44:30 <roshi> #agreed - 1209347 - RejectedBlocker AcceptedFreezeException Beta AcceptedBlocker Final - This bug is a nasty one, but workarounds exist and the drivers can be fixed post 'basic graphics' installation with an update for Beta. If possible, a fix would be accepted for Beta. This will block for final.
17:44:50 <roshi> #topic (1210428) Cloud images won't successfully reboot
17:44:50 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1210428
17:44:50 <roshi> #info Proposed Blocker, cloud-init, NEW
17:44:51 <sgallagh> Meaning only respun if another blocker caused it to happen, presumably?
17:44:59 <roshi> yeah
17:45:13 <roshi> we don't respin for FE's
17:45:28 <nirik> roshi: so, on this one, it's only openstack? other things all work?
17:45:30 <sgallagh> Just clarifying.
17:45:47 <nirik> and did you get someone else with another openstack to confirm?
17:45:50 <kparal> nirik: seem to work :)
17:46:07 <sgallagh> nirik: says EC2 as well
17:46:10 <roshi> openstack and EC2
17:46:15 <roshi> oddshocks saw it on EC2
17:46:25 <nirik> icky.
17:46:28 <roshi> dustymabe confirmed on the other openstack
17:46:36 <oddshocks> Yeah, can confirm, seems to be the case with both atomic and base images
17:47:05 <jzb> Hey all
17:47:24 <jzb> I can clarify the blocker thing when we're at a good point
17:47:33 <adamw> let's circle back after this.
17:47:38 <jzb> k
17:47:48 <roshi> sgtm
17:47:50 <adamw> how important is it for rebooting of cloud instances to work?
17:47:51 <roshi> votes?
17:47:57 <roshi> well
17:48:01 * roshi shrugs
17:48:02 * danofsatx sighs
17:48:04 <danofsatx> +1
17:48:13 <danofsatx> this is bad, very bad.
17:48:19 <roshi> it's hard to say because we don't have any means of gathering metrics of how people use them
17:48:25 <nirik> it's nice as sometimes people update and reboot them... but in the 'cloud' mentality you should just make a new instance
17:48:30 <roshi> this works for me locally, just not on the providers
17:49:00 <dgilmore> s in we can not ship it
17:49:02 <adamw> i would assume that for medium-life instances you'd want to be able to update them and stuff
17:49:02 <dgilmore> gahh
17:49:17 <roshi> *I* would want to be able to update them
17:49:17 <nirik> FWIW, I'm not sure cloud-init is at fault here...
17:49:30 <roshi> I was in a hurry, so I picked a component :p
17:49:41 <nirik> I know. I'm not sure what actually is. ;)
17:49:43 <jreznik> roshi: then you're not the right cloud guy :)
17:50:08 <roshi> ?
17:50:27 <roshi> I'm not sure which component this would be either
17:50:37 <adamw> we do have a direct criterion for this, btw, "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops."
17:50:55 <nirik> adamw: desktops?
17:50:57 <roshi> yeah, but it's not a desktop - so I went with the other
17:51:08 <jzb> fwiw
17:51:10 <adamw> i'm assuming the 'standard console commands' portion applies to cloud images.
17:51:11 <jreznik> restart is the must on desktop, true
17:51:25 <jzb> in a perfect world people would rarely reboot cloud images
17:51:35 <nirik> yeah.
17:51:37 <jzb> but assuming there's still a need to spin up an image and do updates
17:51:38 * adamw is more interested in the actual world.
17:51:46 <jzb> before sending them out, reboot is a necessity
17:51:49 <roshi> jreznik: fwiw, I consider myself a QA guy in a cloud hat - not a proper cloud person yet :p
17:51:51 <jzb> I'd consider this a blocker.
17:52:16 <nirik> well, It's definitely a final blocker in my mind... just not sure about beta.
17:52:36 <roshi> I'm on the fence about Beta vs Final
17:52:46 <roshi> but for sure +1 blocker on one of those
17:52:47 <jreznik> final sure but if jzb thinks, it's also beta... I'm really not cloud guy
17:52:59 <sgallagh> Same; I'm +1 Final, +0 Beta.
17:53:02 * adamw is with jreznik, willing to defer to the experts
17:53:10 <jzb> I hate to be contrarian, but I'd be +1 beta. Sorry.
17:53:17 <nirik> roshi: did you apply updates? or just changed services and rebooted?
17:53:28 <roshi> I'm no expert - but I'm +1 beta
17:53:36 <sgallagh> jzb: How likely do you feel it to be that it will be fixed within a week?
17:53:36 <roshi> I did it several times
17:53:42 <roshi> after updates
17:53:50 <roshi> right after first boot
17:53:55 <roshi> boot, login, reboot
17:54:07 <jzb> sgallagh: medium?
17:54:09 <roshi> did it with auto partitioning, manual partition
17:54:25 <adamw> sgallagh: sounds like we don't really know what's broken yet, so it might be hard to say.
17:54:39 * nirik sighs, so much for not slipping. Oh well.
17:54:39 <roshi> I have no idea how long/hard this is to fix
17:54:40 <jzb> sgallagh: if we declare it blocker I'll take it as an action to run down.
17:54:52 <sgallagh> I'm just wary of slipping indefinitely.
17:55:19 <jzb> sgallagh: understood.
17:55:25 <sgallagh> But if the Cloud WG wants to say "don't ship without fixing this", I won't resist.
17:55:35 <jreznik> sgallagh: we can always reconsider in case it shows as unresolveable issue
17:55:41 * adamw inclined to go with jzb and roshi
17:56:18 <adamw> (and danofsatx, sorry dan)
17:56:45 <jzb> I'd say if we don't have a bead on fixing the problem by Monday afternoon, then ship. If that's an option.
17:56:55 <sgallagh> jzb: It's not.
17:56:57 <jzb> ah
17:57:21 <sgallagh> jzb: In the past, we've managed to fudge things so we could move the decision out a single day.
17:57:24 <jreznik> sgallagh: it is an option to reconsider the decision based on other data coming
17:57:28 <sgallagh> But Monday is too late; no time for the mirrors to sync.
17:57:48 <jreznik> sgallagh: Monday is for week slip, that's how I understand it
17:58:24 <sgallagh> I thought he meant "if we can't figure it out by Monday, ship RC1"
17:58:28 <sgallagh> Which isn't doable
17:58:44 <nirik> right. it's a week slip
17:58:53 <jzb> sgallagh: that is what I meant
17:59:04 <roshi> proposed #agreed - 1210428 - AcceptedBlocker Beta - This is a clear violation of the cited criterion and the spirit of at least one more: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops."
17:59:13 <jreznik> no it isn't... I understood it - slip for a week and if we don't have solution on Monday, it's harder to fix and we will be ok with resetting blocker status
17:59:22 <jreznik> aha
18:00:08 <adamw> ack.
18:00:09 <jreznik> ack
18:00:13 <nirik> sigh. ack
18:00:14 <sgallagh> hold on
18:00:23 <oddshocks> ack
18:00:25 <roshi> ?
18:00:28 <jreznik> sgallagh: ?
18:00:29 <sgallagh> A blocker is either a blocker or it's not.
18:00:35 * roshi waits for sgallagh
18:00:41 <sgallagh> I don't really like this "It's a blocker if we can figure it out by Monday" statement.
18:00:53 <sgallagh> Either we're willing to slip until it's fixed, or we aren't
18:01:07 * pschindl is here. What's going on?
18:01:29 * nirik agrees.
18:01:42 <dgilmore> im with sgallagh here
18:01:43 <kparal> pschindl: cloud issue causing a slip
18:01:48 <adamw> sgallagh: the vote and the proposal don't say anything about that, we're simply accepting the bug as a blocker.
18:01:52 <nirik> if we are slipping a week, we will have another go/no-go.
18:02:13 <pschindl> kparal: so it's not you causing a slip? That's interesting :)
18:02:16 <roshi> I'm with sgallagh - which is why I didn't put it in the proposed #agreed :p
18:02:23 <adamw> i think it's reasonable to say we might re-evaluate if it turns out to be incredibly intractable, like it'd take months to fix. we've always said we're a hybrid approach so we can't really block the entire project for months on a bug like this. but for now we're simply accepting it as a blocker.
18:02:48 <roshi> makes sense to me
18:03:06 <roshi> this type of discussion was bound to happen when we started the different editions
18:03:14 <jreznik> it's still last blocker thing...
18:03:40 <adamw> roshi: yeah, it's a theme lately: the more bits we have, the less we want to block all of them for a breakage in one. but we really don't have many other choices atm.
18:03:46 <jzb> I think we have larger problems if it takes months to fix :-)
18:03:58 <sgallagh> So to be clear, barring outside forces, we're assuming that this is "slip until it's fixed". Yes?
18:03:58 <roshi> true
18:04:06 <roshi> but I also don't know where this regression started
18:04:07 <jzb> sgallagh: yes
18:04:08 * nirik also doesn't think a sub-week slip is practical, but we dont need to discuss that here.
18:04:11 <adamw> sgallagh: yes, it's a perfectly normal blocker bug, nothing unusual about it.
18:04:15 <roshi> something I'll have to dig into to find out
18:04:32 <sgallagh> (I want that statement to be very clear, because I want the Cloud guys seriously aiming for an immediate fix)
18:04:39 <jreznik> sgallagh: and we can always discuss it again if there's not progress in timely manner
18:04:41 <roshi> so, we have the acks
18:04:46 <sgallagh> /me nods
18:05:02 <roshi> proposed #agreed - 1210428 - AcceptedBlocker Beta - This is a clear violation of the cited criterion and the spirit of at least one more: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops."
18:05:08 <adamw> ackagain
18:05:09 <jreznik> but I agree we need immediate action on this from cloud wg
18:05:12 <roshi> just so we're clear what we're agking
18:05:16 <sgallagh> jzb: To be clear, the ideal situation is to have a fix ready on Monday or early Tuesday so we can do a compose and test it
18:05:18 <jreznik> ack
18:05:25 <sgallagh> The earlier the better
18:05:28 <jzb> sgallagh: yes
18:05:48 <dgilmore> a sub-week slip is not practical. I have said so since jreznik frist brought it up
18:06:15 <roshi> #agreed - 1210428 - AcceptedBlocker Beta - This is a clear violation of the cited criterion and the spirit of at least one more: "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops."
18:06:31 <jreznik> dgilmore: and I'm not talking about it here :)
18:06:35 <roshi> #action Cloud WG to focus down on this one bug and testing for the next week
18:06:38 <roshi> that work?
18:06:49 <jzb> roshi: yes
18:06:54 <adamw> sgallagh: the ideal situation is we have a fix in half an hour. :P
18:07:04 <roshi> ideal is solution yesterday :p
18:07:16 * jzb looks for keys to time machine.
18:07:16 <sgallagh> I chose my words poorly
18:07:26 <roshi> ok, everyone fine with circling back to the ostree bug now?
18:07:36 <adamw> the ideal situation is i own an extremely successful yak farm.
18:07:37 <adamw> sure
18:07:40 <jreznik> sure
18:07:51 <roshi> heh
18:07:51 <roshi> #topic (1209695) yum/dnf changes break composoing ostree trees
18:07:52 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1209695
18:07:52 <roshi> #info Proposed Blocker, rpm-ostree, ON_QA
18:08:08 <jzb> OK, lemme clarify this a bit
18:08:13 <jreznik> but I have meeting conflict with the another one I have to be... so I might not react...
18:08:36 <jzb> 1) it's not a blocker, though some of us (me) were a bit confused about that before.
18:09:10 <sgallagh> I'm +1 FE, so since we're respinning for the other bug, we may as well fix this.
18:09:15 <jzb> 2) there's no 'secret' blocker. What we had was a miscommunication about priority in terms of things that should be high priority for workload.
18:09:28 <adamw> there is no cabal?
18:09:32 <roshi> good to know
18:09:41 <jzb> adamw: I can neither confirm or deny a cabal.
18:09:45 <nirik> alright. Yeah, -1/+1
18:09:48 <sgallagh> adamw: Of course not. *puts away the MiB pen*
18:09:56 <roshi> -1/+1
18:10:13 <jzb> so if my vote counts, -1/+1
18:10:19 <jzb> thanks for y'all's patience.
18:10:50 <roshi> proposed #agreed - 1209695 - RejectedBlocker AcceptedFreezeException Beta - This bug does not afflict a release blocking edition for Fedora, but getting a fix in for Beta would be great.
18:10:57 <roshi> thanks for chasing that down jzb :)
18:11:11 <jzb> roshi: no problem
18:11:20 <jreznik> ack
18:11:29 <nirik> ack
18:11:32 <adamw> ack
18:11:41 <roshi> #agreed - 1209695 - RejectedBlocker AcceptedFreezeException Beta - This bug does not afflict a release blocking edition for Fedora, but getting a fix in for Beta would be great.
18:11:53 <roshi> and that's all we have for beta proposals
18:12:19 <roshi> back to you jreznik :)
18:12:25 <roshi> thanks folks
18:13:23 <jreznik> thanks roshi
18:13:27 <roshi> np
18:13:38 <sgallagh> Do we need to review the approved blockers?
18:13:44 <jreznik> do we want to check test matrices coverage as we are going to slip or not?
18:13:51 <sgallagh> Or are they generally accepted to be ready to go?
18:14:02 <jreznik> sgallagh: I think we're goog there except that one we just approved
18:14:06 <roshi> at this point, I don't think so (go over accepted)
18:14:13 <sgallagh> k
18:14:28 <dgilmore> we have accepted blockers?
18:14:37 <dgilmore> if so we can not be go
18:14:44 <jreznik> dgilmore: one and we're not go
18:15:00 <jreznik> accepted and unresolved
18:15:01 * nirik plays the one week slip sad trombone
18:15:13 <oddshocks> heh
18:15:18 <jreznik> #topic Go/No-Go decision
18:15:29 <dgilmore> releng is no go
18:15:48 <nirik> yeah, no point really in taking a long time with it... no go.
18:15:54 <oddshocks> +1
18:15:54 <sgallagh> no go :(
18:16:07 <jreznik> proposal #agreed Fedora 22 Beta status is No-Go by Release Engineering, QA and Development
18:16:19 <roshi> ack
18:16:33 <dgilmore> ack
18:16:35 <nirik> ack
18:16:38 <juliuxpigface> ack
18:16:45 <adamw> qa votes no-go in accordance with The Policy
18:16:52 <adamw> (outstanding unresolved blocker(s)).
18:17:00 <roshi> heh, "The Policy"
18:17:05 <adamw> roshi: there is in fact a policy
18:17:12 <jreznik> #agreed Fedora 22 Beta status is No-Go by Release Engineering, QA and Development
18:17:25 <roshi> oh yeah, just the caps made me chuckle
18:17:51 <adamw> =)
18:18:31 <jreznik> roshi: I had no-caps version but then I decided to rewrite it at the very last moment :D
18:18:52 <jreznik> so thank you everyone, it's sad we were so close but it's life
18:19:04 <jreznik> #action jreznik to announce slip
18:19:23 <jreznik> #topic open floor
18:19:44 <nirik> I guess this is telling us to test cloud images sooner? ;(
18:19:54 <roshi> I'm going to start looking into when this cloud regression started (after I grab a sandwich)
18:20:16 <roshi> but I might need help from releng or something to narrow things down/find a fix
18:20:22 <roshi> yeah, that was my fault I think
18:20:33 <roshi> usually things fail locally and work on a provider
18:20:39 <adamw> eh, it's also telling us we have sixty jjillion spinning plates.
18:20:45 <nirik> yeah.
18:20:48 <oddshocks> Yeah, i wouldn't sweat it
18:20:52 <roshi> I've been testing locally while working on testcloud, and things worked there
18:20:52 <nirik> ETOOMANYDELIVERABLES
18:21:02 <roshi> but I didn't make sure someone was running tests anywhere else
18:21:08 * adamw misses life when we cared about KDE and GNOME lives and 'the DVD'.
18:21:18 <roshi> I shoulda checked on it sooner
18:21:20 <adamw> (and is vaguely jealous of life when we didn't even have the lives.)
18:21:28 <roshi> just been otherly focused since alpha
18:21:56 <sgallagh> Well, part of the agreement was that the WGs would be doing some of their own testing (and I know I've been a little lax on formal Server testing during Beta)
18:22:12 <jreznik> sgallagh: yes, it's the must
18:22:13 <dgilmore> adamw: that life was much easier for me
18:22:16 <adamw> https://fedoraproject.org/wiki/QA/TestResults/Fedora9Install/Beta
18:22:23 <roshi> and danofsatx hasn't finished the time machine I asked him to make forever ago
18:22:43 <roshi> :p
18:22:51 <adamw> we really ought to look into automating some server/cloud testing...
18:23:02 <roshi> it's in the works
18:23:12 <roshi> kushal runs cloud tests pretty regular
18:23:16 <roshi> but he's at pycon now
18:23:50 <adamw> oh yeah, i poked him about submitting results to the matrix
18:23:57 <roshi> me too :p
18:23:58 <jreznik> ok, anything else today?
18:24:07 * jreznik saw his tweets from pycon
18:24:13 <roshi> not from me
18:24:39 <jreznik> so thanks again! setting fuse to 0...
18:25:06 <jreznik> and one more reminder - readiness meeting is in half hour, same channel
18:25:12 <jreznik> #endmeeting