17:00:29 <jkurik> #startmeeting F24 Alpha Go/No-Go meeting
17:00:29 <zodbot> Meeting started Thu Mar 17 17:00:29 2016 UTC.  The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:29 <zodbot> The meeting name has been set to 'f24_alpha_go/no-go_meeting'
17:00:35 <jkurik> stickster: right :-)
17:00:42 <stickster> .hello pfrields
17:00:43 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
17:00:48 <jkurik> #meetingname F24-Alpha-Go_No_Go-meeting
17:00:48 <zodbot> The meeting name has been set to 'f24-alpha-go_no_go-meeting'
17:00:55 <jkurik> #topic Roll Call
17:01:01 <jkurik> .hello jkurik
17:01:02 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
17:01:03 <adamw> .hello adamwill
17:01:06 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:01:06 <stickster> oops, jumped the gun :-)   o/ all
17:01:07 <nirik> .hellomynameis kevin
17:01:09 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
17:01:37 * kparal lurks
17:01:49 <jkurik> so, we need at least someone from QE, FESCo and RelEng
17:01:53 * lbrabec lurks too
17:01:57 <sgallagh> I'm here
17:02:08 <sgallagh> .hello sgallagh
17:02:09 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:02:28 <linuxmodder> .hello corey84
17:02:29 <zodbot> linuxmodder: corey84 'Corey Sheldon' <sheldon.corey@gmail.com>
17:02:41 <jkurik> dgilmore: hi Dennis, are you with us ?
17:02:41 <linuxmodder> will be  mostly lurking tho
17:03:04 <dgilmore> jkurik: kinda
17:03:12 <dgilmore> got a meeting I am in
17:03:26 <linuxmodder> so like 4  lurkers toady :)
17:03:32 <jkurik> #chair dgilmore nirik sgallagh stickster adamw
17:03:32 <zodbot> Current chairs: adamw dgilmore jkurik nirik sgallagh stickster
17:03:43 <adamw> sgallagh: can you update https://fedoraproject.org/wiki/Test_Results:Fedora_24_Alpha_1.5_Server , if you've run the tests?
17:03:43 <jkurik> Hi everybody
17:04:00 <linuxmodder> afternoon alll
17:04:11 <jkurik> #topic Purpose of this meeting
17:04:12 <jkurik> #info Purpose of this meeting is to check whether or not F24 Alpha is ready for shipment, according to the release criteria.
17:04:14 <jkurik> #info This is determined in a few ways:
17:04:15 <jkurik> #info No remaining blocker bugs
17:04:17 <jkurik> #info Release candidate compose is available (check https://fedorahosted.org/rel-eng/ticket/6371 )
17:04:18 <jkurik> #info Test matrices for Alpha are fully completed
17:04:31 <sgallagh> adamw: Short answer is that I've not managed to get many of them done. I hit a blocker early on and spent quite a while unblocking it
17:04:40 <mattdm> (I am also here -- sorry for being late!)
17:04:41 <sgallagh> I was hoping someone else would run some of the tests, but no one did
17:04:45 <adamw> sgallagh: ah, ok :/ sorry, i did not have time either
17:04:50 <adamw> too busy herding robots
17:04:58 <jkurik> we have RC for the Alpha (thanks dgilmore & adamw)
17:05:03 <adamw> we can decide what to do about it after we do the mini blocker review, i guess
17:05:11 <jkurik> #link https://qa.fedoraproject.org/blockerbugs/milestone/24/alpha/buglist
17:05:12 <sgallagh> /me nods
17:05:13 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_24_Alpha_1.5_Installation
17:05:14 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_24_Alpha_1.5_Base
17:05:16 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_24_Alpha_1.5_Desktop
17:05:17 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_24_Alpha_1.5_Server
17:05:19 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_24_Alpha_1.5_Cloud
17:05:20 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_24_Alpha_1.5_Summary
17:05:27 <jkurik> #topic Current status
17:05:38 <jkurik> #info We have several accepted blockers and also several proposed blockers for the Alpha_1.5.
17:05:39 <adamw> process note there: technically we've decided we kinda don't have 'TCs' and 'RCs' any more. but we can consider any 'candidate' / 'production' compose built after freeze as a potential 'RC'.
17:05:58 <jkurik> adamw: thanks for the correction
17:06:35 <jkurik> #info we do not have RC anymore, however from the formal point of view the Alpha_1.5 compose plays the role of RC for this purpose
17:07:05 <jkurik> Let's start with Mini-blocker review
17:07:19 <jkurik> adamw: may I ask you please to chair the mini-blocker review ?
17:07:54 <adamw> sure, can do
17:07:57 <jkurik> #topic Mini-Blocker Review
17:08:21 <adamw> ok, just going through alpha proposed blockers:
17:08:31 <adamw> #topic (1315494) C.UTF-8 doesn't actually work as a default locale
17:08:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1315494
17:08:31 <adamw> #info Proposed Blocker, anaconda, NEW
17:08:46 <adamw> this one is the one that's been intentionally left in 'proposed' state because it'll bite us if a new anaconda build is needed
17:08:58 <sgallagh> So this is still "special". It only applies if we have to take other anaconda fixes, so let's push this to the bottom of the pile.
17:09:01 <adamw> but it's not a blocker so far as Alpha-1.5 is concerned, because the bug isn't in that build of anaconda
17:09:02 <adamw> right
17:09:04 <sgallagh> And come back if needed.
17:09:27 * nirik nods
17:09:28 <adamw> #info this bug does not affect Alpha-1.5; it will only affect us if we need a new anaconda build for any other reason. It is on the proposed list for tracking this
17:09:38 <adamw> #topic (1318615) gnome-initial-setup crashes after choosing a language
17:09:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1318615
17:09:38 <adamw> #info Proposed Blocker, gnome-initial-setup, NEW
17:09:43 <adamw> oh hey, i didn't even notice this one...
17:10:09 <stickster> I mentioned this to mclasen___ a short time ago, but it's newly filed so I'm not sure the maintainer's even had a chance to look
17:10:18 <adamw> so this is kind of a conditional blocker, i guess
17:10:35 <adamw> the conditions are: don't create a user in anaconda, and then need/want to change language in gnome-initial-setup
17:11:24 <sgallagh> I think the phrasing we chose for this criterion was basically that at least one of those two user-creation mechanisms must work
17:12:00 <nirik> yeah.
17:12:03 <adamw> well...yeah, but this is kind of a different case
17:12:04 <nirik> "using a user account created during installation or a 'first boot' utility."
17:12:19 <sgallagh> So if it works by actually using Anaconda user-creation, I'm in favor of noting this as "Hey, it's an Alpha", personally
17:12:38 <adamw> i think i'm -1 for alpha on the grounds that it's not going to be common enough, though
17:12:47 <jkurik> sgallagh: +1, I am sharing the same POV
17:13:03 <nirik> yeah, -1 if the other path works
17:13:32 <sgallagh> adamw: Do we know if the other path works properly?
17:13:40 * stickster is not voting but agrees with both adamw + sgallagh
17:14:03 <sgallagh> stickster: Why aren't you voting? Blocker bug review is open to all
17:14:24 <adamw> sgallagh: the bug says it does.
17:14:58 <adamw> right, blocker bug votes are accepted from all then weighted according to a highly complex, pseudo-intelligent system known as 'me'
17:15:12 <adamw> sounds like that's several -1s
17:15:21 <sgallagh> adamw: The bug says it works if the user doesn't change the language.
17:15:37 <sgallagh> It doesn't explicitly state whether it boots if the user changes langs and uses Anaconda to create the user.
17:15:39 <stickster> sgallagh: In that case, -1 for Alpha. I wasn't sure I played more than advisory/informed role here.
17:15:52 <sgallagh> Anyway, -1
17:15:52 <adamw> sgallagh: step 1 quite strongly implies that, though. anyhow, we've no information it doesn't work.
17:16:53 <adamw> proposed #agreed 1318615 - RejectedBlocker (Alpha) - this bug only occurs in a quite specific situation (user not created in anaconda, language changed in g-i-s) and we agreed this is not a broad enough impact to constitute an Alpha blocker
17:16:59 <nirik> ack
17:17:02 <sgallagh> ack
17:17:05 <jkurik> ack
17:17:11 <adamw> #agreed 1318615 - RejectedBlocker (Alpha) - this bug only occurs in a quite specific situation (user not created in anaconda, language changed in g-i-s) and we agreed this is not a broad enough impact to constitute an Alpha blocker
17:17:40 <adamw> #topic (1318541) Cannot unlock KDE desktop
17:17:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1318541
17:17:40 <adamw> #info Proposed Blocker, plasma-desktop, NEW
17:17:57 <adamw> hmm, so i'm actually in the middle of re-testing this now
17:18:07 <adamw> i just tried it again, creating user in anaconda this time, and i still get the bug
17:18:34 <stickster> hmm
17:18:51 <nirik> weird.
17:19:02 <sgallagh> adamw: Wait, are you still discussing the previous one?
17:19:07 <adamw> no, i'm discussing this one.
17:19:21 <dgilmore> sorry meeting is over
17:19:22 <adamw> we thought it might only happen if the user account was created in initial-setup, since rdieter tried to reproduce and couldn't
17:19:39 <nirik> there is a work around (all be it gross)
17:19:58 <adamw> http://paste.fedoraproject.org/341728/82351411
17:20:03 <adamw> yeah, the workaround is pretty awful.
17:20:16 <adamw> that's my journalctl, it looks like kscreenlocker_greet crashes
17:21:28 <adamw> hi rdieter
17:21:30 <stickster> adamw: Speaking of your criterion citation in the bug... How many minutes would need to elapse to be considered "working"?
17:21:30 <rdieter> yo
17:21:33 <nirik> sddm-greeter also seems to crash?
17:21:45 <sgallagh> adamw: It *does* display the error and workaround to the user, yes?
17:21:51 <adamw> stickster: i dunno, but five or ten or whatever the screen lock timeout seems to be seems rather short.
17:21:59 <adamw> sgallagh: only after you try to unlock several times
17:22:19 <adamw> and you'd have to do the workaround every time the screen locked, i guess
17:22:25 <sgallagh> adamw: Right, but my point is that the user is at least informed of a way to get around it. Ugly though it is
17:22:29 * stickster isn't disputing this could arguably pass criteria to block, to be fair
17:22:42 <adamw> so long as they keep trying to unlock rather than just giving up and saying "screw this", yes.
17:22:49 <sgallagh> (which is a nice change of pace from most bugs)
17:23:27 <adamw> rdieter: so i reinstalled with user creation in anaconda, and still hit the bug
17:23:35 <rdieter> ok, boo
17:23:41 <adamw> rdieter: http://paste.fedoraproject.org/341728/82351411 is my journal, it shows kscreenlocker_greet crashing
17:24:00 <nirik> could it be related to spice/vm somehow? did you not see it on bare metal rdieter ?
17:24:03 <adamw> rdieter: did you make the user an admin or not? did you wait for the screen to lock automatically due to inactivity, or did you lock it manually?
17:24:04 <rdieter> possible to get any backtraces?
17:24:17 <rdieter> adamw: I was admin, locked manually
17:24:22 <adamw> rdieter: abrt-cli is saying they're not valid problem directories, i guess drkonqi or whatever is interfering, but i can see if i have any manually
17:24:28 <adamw> rdieter: maybe one of those affects it...
17:24:38 <rdieter> adamw: ok, I can try other cases
17:24:46 * adamw can try on bare metal and twiddle a bit if we want to move on and come back later...
17:24:57 <rdieter> I suspect this will be difficult to diagnose/debug crashes without backtraces
17:25:23 <adamw> there's a coredump in the abrt dir so i can probably get one manually, but it'll take a bit of time
17:26:20 <adamw> so what do we think? anyone wanna vote either way definitely, or would you rather we poke it a bit more?
17:26:43 <jkurik> I am +1 for a blocker here
17:26:46 <adamw> if you figure this is OK for alpha even assuming it always happens, you can vote -1 now i guess, extra info won't change your mind
17:26:50 <nirik> I'm a very weak -1 since there's a workaround
17:27:12 * adamw kinda hates the 'there's a workaround' trend. i mean, there's almost always a goddamn workaround.
17:27:13 <nirik> bare metal vs vm wouldn't help much, I think many people use vm's for alphas...
17:27:26 <adamw> rdieter: did you test on vm or metal, btw?
17:27:26 <nirik> didn't mean to be trendy. :)
17:27:29 <adamw> =)
17:27:31 <rdieter> metal for me
17:27:35 <nirik> also, can hopefully be fixed soon in updates?
17:27:42 <adamw> it just seems like we've been waving the 'there's a workaround' card at a lot of blockers for the last few releases
17:27:49 <rdieter> nirik: given debuging/backtraces, ideally yes, it should be fixable
17:28:04 <nirik> adamw: true.
17:28:19 <adamw> nirik: well, that's kind of a problem because mostly people do KDE installs from live, i think, so even if we fix it with an update, you'd have to do your updates right after install to avoid hitting the bug
17:28:21 <rdieter> adamw: workaround too *for alpha*, disable screenlocker
17:28:31 <stickster> adamw: True, but I think that also needs to be weighed against the population of Alpha testing users
17:29:00 <rdieter> I'm ok with considering it a blocker for now (assuming the worst), until it's better understood
17:29:01 * adamw watches debuginfo packages install
17:29:03 <nirik> well, we don't really know that tho
17:29:25 <sgallagh> rdieter: Well, this is Go/No-Go, so if we rule it a blocker, it also definitely means a slip.
17:29:27 <adamw> rdieter: just to get you up to speed - if we accept this as a blocker we're basically slipping, which is why there's a 'discussion'
17:29:32 <adamw> snap
17:29:35 <nirik> I do think alpha using people would be more likely to look at common bugs, etc than later. but meh
17:29:35 <sgallagh> That being said, I'm inclined to say +1 blocker here
17:29:36 <stickster> heh
17:29:38 <rdieter> ah, k
17:29:44 <stickster> nirik: Yeah, that was my point
17:29:59 <adamw> rdieter: "At least 2923MB more space needed on the / filesystem'. whee. guess i get to reinstall with a bigger disk
17:29:59 <stickster> or rather, the point I was trying to make :-)
17:30:18 <nirik> adamw: can you try and submit with abrt-cli ?
17:30:19 <adamw> ok, how bout this, let's leave this for now and me and rdieter can poke it a bit and everyone can think about it, let's move onto the other hot topic
17:30:24 <sgallagh> adamw: Jeepers, that's a lot of debuginfo
17:30:25 <rdieter> ok, consider me officially ok with not blocking *just* for this
17:30:27 <rdieter> adamw: +1
17:30:30 <adamw> nirik: see above, abrt-cli considers it not a valid problem directory for some reason.
17:31:04 <sgallagh> rdieter: That's the definition of a non-blocker.
17:31:08 <adamw> #agreed 1318541 - short-term punt - we will circle back to this later in the meeting, it's still under investigation, let's discuss the other hot topic bug while that's happening
17:31:34 <nirik> ack sure
17:31:41 <stickster> *nod
17:31:45 <adamw> for the record: we have two accepted blockers, one of them is easy, it's already VERIFIED and appears fixed in Alpha-1.1 and Alpha-1.5, nothing to discuss there
17:31:49 <adamw> the other accepted blocker is more interesting
17:31:54 <adamw> #topic (1317721) cockpit.socket not enabled automatically on Fedora Server installs
17:31:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1317721
17:31:54 <adamw> #info Accepted Blocker, fedora-release, POST
17:32:24 <adamw> so the initial bug sgallagh found was indeed fixed in Alpha-1.5, but turns out that wasn't enough to fix things entirely
17:32:38 <adamw> so in Alpha-1.5, cockpit is still not working out of the box, which is a clear violation of the criteria
17:32:57 <stickster> yeah, this one kind of seals the fate, it seems
17:32:59 <adamw> the 'workaround' for this is easy (start cockpit.service manually), *so long as you're in a position to do that*
17:33:06 <sgallagh> (also, I'll add that the same bug prevented rolekit from working out of the box as well)
17:33:22 <sgallagh> adamw: You can just turn it on from the Cockpit UI... oh wait
17:33:29 <stickster> *snort
17:33:42 <adamw> i'm gonna be a stickler and say +1. the criterion says this has to work, no workarounds. we wrote that in there, we should stick to it.
17:33:42 <nirik> well, there's a workaround... <runs from adamw>
17:33:44 <sgallagh> Yeah, I think this remains a clear blocker
17:33:48 <nirik> +1 blocker yeah
17:33:50 * adamw chases nirik with a big stick
17:33:53 <sgallagh> +1 blocker
17:33:55 <stickster> +1 blocker, regretfully
17:34:07 <sgallagh> /me notes that a patch that fixes it is already out in a PR, but it will require a respin
17:34:44 <jkurik> +1 for blocker
17:34:45 <adamw> proposed #agreed 1317721 - remains AcceptedBlocker (Alpha) - this was not entirely fixed in Alpha-1.5 and we still consider it to be a clear release blocker
17:34:51 <jkurik> ack
17:34:53 <nirik> ack
17:35:02 <dgilmore> ack
17:35:04 <sgallagh> adamw asked me earlier if I wanted to push for heroics on this. I am against it. We should slip and do proper testing
17:35:06 <sgallagh> ack
17:35:21 <nirik> yeah, getting too old for the heroics. ;)
17:35:24 <adamw> #agreed 1317721 - remains AcceptedBlocker (Alpha) - this was not entirely fixed in Alpha-1.5 and we still consider it to be a clear release blocker
17:35:41 <adamw> ok, circling back to the KDE one:
17:35:46 <adamw> #topic (1318541) Cannot unlock KDE desktop
17:35:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1318541
17:35:47 <adamw> #info Proposed Blocker, plasma-desktop, NEW
17:36:05 <adamw> so with the cockpit decision i think making an immediate decision on this becomes less important
17:36:08 <sgallagh> I'm a solid +1 FE on this one and a weak +1 blocker
17:36:23 <nirik> yeah. +1 FE -0.5 blocker
17:36:29 <jkurik> I am still +1 to block on this
17:36:45 <dgilmore> +1 blocker
17:36:48 <adamw> so assuming we're not going to attempt any kind of heroics, we can punt this to monday's blocker review meeting and collect a bit more data?
17:36:49 <stickster> Not immediate but I'm +1 FE, -1 blocker.
17:37:02 <adamw> since we're kinda split on it that seems like the best idea
17:37:22 <nirik> sounds reasonable
17:37:27 <sgallagh> Works for me
17:37:28 <stickster> *nod
17:37:29 <nirik> there's a lot not known yet.
17:38:09 <sgallagh> adamw: I think we can hand over an FE right now though
17:38:16 <sgallagh> In case a fix happens quickly, then at least it can land
17:38:17 <adamw> point
17:38:20 * adamw edits his proposal...
17:38:36 <nirik> sure, would definitely be good to fix.
17:38:37 * stickster is not pitching any heroics. If someone wanted to provide them, I wouldn't want the plasma issue to block. If not, the extra week will probably obviate this bug anyway.
17:38:42 <adamw> proposed #agreed 1318541 - AcceptedFreezeException (Alpha), punt (delay decision) on Blocker status till next regular blocker meeting - there's still a lot of data to gather here, we should have a clearer picture of the bug by Monday and we do not need to make a decision immediately
17:38:57 <nirik> ack
17:39:00 <jkurik> ack
17:39:00 <stickster> ack
17:39:05 <adamw> #agreed 1318541 - AcceptedFreezeException (Alpha), punt (delay decision) on Blocker status till next regular blocker meeting - there's still a lot of data to gather here, we should have a clearer picture of the bug by Monday and we do not need to make a decision immediately
17:39:06 <sgallagh> ack
17:39:15 <dgilmore> ack
17:39:16 <adamw> ok, I believe that's it for mini blocker review, or did I miss anything?
17:39:28 <adamw> i will do the secretarialization later
17:39:34 <jkurik> adamw: thanks a lot
17:40:06 <jkurik> so, as it seems like we need to slip, does it make sense to go through Test Matrices coverage ?
17:40:19 <nirik> not really.
17:40:21 <adamw> well, quickly for the record - we have pretty solid coverage for everything except Server
17:40:29 <sgallagh> *sad trombone*
17:40:33 <jkurik> ok
17:40:36 <adamw> sgallagh was too busy fighting the bugs we already discovered to complete the testing, and I was too busy wrestling robots
17:40:47 <jkurik> #topic Test Matrices coverage
17:40:47 <adamw> we'll definitely get through the rest of the tests asap to find any other lurking blockers
17:40:55 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_24_Alpha_1.5_Summary
17:41:13 <adamw> #link https://www.happyassassin.net/testcase_stats/24/
17:41:36 <sgallagh> Yeah, I can run the rest of the tests this afternoon with a few manual tweaks to get the services starting properly.
17:42:59 <adamw> #info coverage is good except for Server, we will fill that out ASAP
17:43:33 * satellit_e Concernrd tha soas is missing in 1.5 but worked fine in 1.1
17:44:43 <jkurik> I quickly scaned the Test Matrice and as far as I can see, it seems to be more/less OK
17:45:15 <jkurik> anything we need to express here ? (except the missing Server)
17:46:11 <nirik> satellit_e: it looks like it hit a anaconda/blivet/livemedia-creator bug... I've seen it in the past, and it's sporadic... not sure if there is a bug, but we should file one if not.
17:46:25 <satellit_e> k
17:46:42 <adamw> jkurik: nope, other than that all alpha tests are covered i think, except SAS install which at this point i leave on there as an in-joke :P
17:47:07 <adamw> nirik: live image creation has been quite churn-y the last few days, if you look at the compose check emails, lots of images appearing and disappearing
17:47:21 <adamw> not sure if it's the new lorax which fails the image compose when it hits the bug that renders the image uninstallable
17:48:36 <nirik> Not sure. This is https://paste.fedoraproject.org/341746/36837145/ at the end of livemedia-creator...
17:49:22 <nirik> anyhow, infra meeting in about 10min... shall we wrap this up? ;)
17:49:37 <jkurik> ok, so lets move on to the funny part
17:49:55 <jkurik> #topic Go/No-Go decision
17:50:44 <jkurik> as dicussed during the mini-blocker review, we agreed to slip, right ?
17:51:09 <adamw> yup, QA votes no-go as there are outstanding unaddressed blockers (and Server test coverage is not complete, though if there were no blockers we could likely fudge that)
17:51:10 <nirik> yep. we have unfixed known blockers.
17:51:15 <jkurik> however the next week there are Easterns (at least in Europe) and many people might be on leave
17:51:51 <jkurik> even so, I would propose to slip for one week only and hope we are fine
17:51:52 <stickster> correct, USA for instance is out Fri 2016-03-25
17:52:26 <sgallagh> Question: I'm running the remaining Server tests. If there are indeed no additional blockers found, would we want to retest just the presets fix and Go tomorrow?
17:52:59 <nirik> we need another compose at least right?
17:53:00 <jkurik> hmm... it means we will not have time to push bits to mirrors etc...
17:53:05 <sgallagh> (an answer of "hell no" is perfectly valid)
17:53:20 <sgallagh> /me is not asking anyone else to run heroics.
17:53:37 <jkurik> sgallagh: considering the Easterns the next week, I will incline to do so
17:53:42 <nirik> well, then we also have the kde lockscreen thing...
17:53:56 <adamw> well, but then the KDE bug becomes significant again
17:53:56 <adamw> right.
17:54:44 * nirik is personally fine with 1 week slip as normal. If peopel want to do heroics ok... but I thought we didn't want to.
17:55:31 <jkurik> dgilmore: if we slip for one week only, will releng be able to push bits live during the Easterns ?
17:55:33 <adamw> i don't have any particular appetite for heroics, especially since we're still fairly new on the pungi4 compose process.
17:55:35 * stickster is OK with that as well, I refuse to request heroics
17:56:12 <sgallagh> I'm mostly asking because as best I can tell, the only one doing heroics would be me.
17:56:42 <adamw> sgallagh: releng would also have to babysit the compose to make sure it went OK
17:56:46 <sgallagh> True
17:56:48 <nirik> well, releng would need to do another compose... and we would need to sort the kde lockscreen thing.
17:56:57 <adamw> and QA at least likes to do default-boot-and-install sanity checks on every new compose, regardless whether 'nothing changed';
17:57:14 <sgallagh> OK, so it sounds like it's really not worth it this time around.
17:58:26 * nirik nods.
17:58:43 <jkurik> dgilmore seems to be idle now, however I am not sure it is wise to push bits out during Esterns
17:59:21 <jkurik> on the other hand slipping for two weeks ... I do not like this idea
17:59:22 <sgallagh> /me rescinds the offer, so we can stop discussing it :)
17:59:32 <nirik> well, I think once we stage things, syncs are mostly automagic from there...
17:59:46 <nirik> we could try moving the go/no-go up a day? to wed?
17:59:54 <nirik> and stage bits thursday
18:00:01 <nirik> (provided we are go)
18:00:27 <adamw> fine by me
18:00:36 <nirik> INFO: anyone looking for the infrastructure meeting, we are almost done with this meeting I hope, if not we can go to #fedora-meeting-1
18:01:26 <nirik> proposal: slip 1 week, but next go/no-go meeting on 2016-03-23 at this same time.
18:01:27 <sgallagh> Fine with me as well
18:01:33 <sgallagh> +1
18:01:34 <adamw> +1
18:01:35 <nirik> jkurik: work for you?
18:01:48 <jkurik> yes, I am fine with it
18:02:00 <nirik> cool.
18:02:19 <stickster> +1 slip and meeting.
18:02:41 <jkurik> proposed #agreed Fedora 24 Alpha release slips. The next Go/NoGo meeting is going to be planned on March 23rd.
18:02:50 <nirik> ack
18:03:35 <sgallagh> ack
18:04:19 <stickster> ack
18:04:19 <jkurik> adamw, dgilmore ?
18:04:22 <nirik> ok, we done? ;)
18:04:24 <adamw> ack
18:04:30 <jkurik> #agreed Fedora 24 Alpha release slips. The next Go/NoGo meeting is going to be planned on March 23rd.
18:04:43 <jkurik> #action jkurik to publish the Go/No-Go result
18:05:08 <jkurik> thanks every one for comming
18:05:16 <jkurik> #endmeeting