16:00:04 #startmeeting F23-blocker-review 16:00:04 Meeting started Mon Sep 14 16:00:04 2015 UTC. The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:04 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:04 #meetingname F23-blocker-review 16:00:04 The meeting name has been set to 'f23-blocker-review' 16:00:05 #topic Roll Call 16:00:25 * kparal is here 16:00:25 who's around for some blocker review goodness? 16:00:50 we've got 3/3 proposed for beta/final 16:00:55 goodness, that's exactly how I'd describe it 16:01:10 * garretraziel is here 16:01:16 #chair kparal garretraziel adamw 16:01:16 Current chairs: adamw garretraziel kparal roshi 16:01:28 * satellit listening 16:01:40 #topic Introduction 16:01:40 Why are we here? 16:01:40 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 16:01:44 #info We'll be following the process outlined at: 16:01:46 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:01:49 #info The bugs up for review today are available at: 16:01:51 #link http://qa.fedoraproject.org/blockerbugs/current 16:01:54 #info The criteria for release blocking bugs can be found at: 16:01:56 * pschindl is here 16:01:56 #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria 16:01:59 #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria 16:02:02 #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria 16:02:06 #chair pschindl satellit 16:02:06 Current chairs: adamw garretraziel kparal pschindl roshi satellit 16:02:15 we'll give adamw a minute to get back 16:02:23 so much attendance today, damn! :) 16:02:41 sshh, you'll frighten them away 16:03:22 * nirik is lurking around in the back 16:03:29 #topic (1258569) SElinux kickstart directive and cli directive not honoured 16:03:32 #link https://bugzilla.redhat.com/show_bug.cgi?id=1258569 16:03:34 #info Proposed Blocker, anaconda, NEW 16:04:16 * danofsatx is here 16:04:40 if that parameter works, it's just a doc/user error... 16:04:42 -1 blocker. 16:04:48 -1 blocker 16:04:48 yeah 16:05:00 assuming the parameter works still 16:05:11 the only part of this that's arguably a bug is that anaconda doesn't handle 'selinux=0' as expected, but the criterion really doesn't require it to, for me. 16:05:20 me either 16:05:20 and 'noselinux' is an obvious alternative. 16:05:28 -1 blocker 16:05:33 I always read that as "nose-linux" 16:05:34 -1 16:05:45 -1 16:05:49 roshi: :) 16:06:38 So when “selinux=0” is used, SELinux will be disabled both in the installation environment and in the installed system, but when “inst.selinux=0” is used SELinux will only be disabled in the installed system. 16:06:42 https://rhinstaller.github.io/anaconda/boot-options.html#inst-selinux 16:06:52 * kparal just linking current docs 16:07:14 if the docs are incorrect, it should still be a blocker until they fix the docs or the code? 16:07:20 proposed #agreed - 1258569 - RejectedBlocker Beta - This bug doesn't violate the criteria. If the "noselinux" flag doesn't work, please repropose. 16:07:50 ack 16:07:53 ack 16:08:13 /me arrives late 16:08:24 * kparal understands people don't want to block on docs, he just has a perfectionist syndrome 16:08:29 ack 16:08:35 #agreed - 1258569 - RejectedBlocker Beta - This bug doesn't violate the criteria. If the "noselinux" flag doesn't work, please repropose. 16:08:40 kparal: i don't think it really merits a blocker even for that. 16:08:51 who wants to secretarialize? 16:08:53 kparal: the criterion was not actually intended to mean 'disabling it via anaconda must work' 16:08:55 * adamw will do it 16:09:01 alright 16:09:02 thanks adamw 16:09:03 adamw: Re-proposing doesn't mean it'll be accepted 16:09:11 #topic (1258236) mouse scroll wheel no longer works after upgrade f22->f23 16:09:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=1258236 16:09:16 #info Proposed Blocker, gtk3, MODIFIED 16:09:29 kparal: though i recognize it's a bit ambiguous. the only thing that the criterion was really meant to require was 'selinux must be enabled by default' 16:09:38 Sorry, I think I confused two concurrent lines of conversation there 16:09:43 sgallagh: never mind :) 16:10:28 -1 16:10:36 "I consider having regular mouse wheel working (under Xorg) as a minimum to release a new milestone" 16:10:40 -1 for me 16:10:45 there are so many other ways 16:10:48 and there's a patch 16:10:49 nice try, cole, but i'm pretty sure the release criteria don't include a "whatever cole thinks" entry. :P 16:10:52 I'd be happy to take an FE for this, but not a blocker 16:10:53 I'd be +1 FE though 16:10:57 -1. bug? sure. annoying? sure. blocker? no. 16:10:58 this is beta, after all 16:11:00 -1 Blocker, +1 FE 16:11:03 i'd be OK with fe if the fix isn't too icky 16:11:24 adamw: https://bug753431.bugzilla-attachments.gnome.org/attachment.cgi?id=310997 16:11:29 according to bz, it's already patched and working, so +1 fe 16:11:44 -1 blocker, +1 fe (for final) 16:11:58 Someone reused 'i' for an iterator when they shouldn't have... 16:12:13 proposed #agreed - 1258236 - RejectedBlocker AcceptedFreezeException Beta - This bug doesn't violate any criteria so isn't considered a blocker. However, if there's a patch to test, we'd consider letting the fix in during freeze. 16:12:26 ack 16:12:32 ack 16:12:39 ack 16:12:48 #agreed - 1258236 - RejectedBlocker AcceptedFreezeException Beta - This bug doesn't violate any criteria so isn't considered a blocker. However, if there's a patch to test, we'd consider letting the fix in during freeze. 16:12:55 #topic (1244394) Upgrade stuck on script 16:12:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=1244394 16:12:56 #info Proposed Blocker, initial-setup, NEW 16:12:57 ACk 16:13:16 this one seems a bit uncertain 16:13:24 I'm not sure if this one viloates any specific criteria. 16:13:34 normally i'd want to punt for more data, but we're pretty close to the deadline... 16:13:45 dnf will hang due to a bug in the postun of initial-setup .35 16:13:56 I'm pretty sure we have an "upgrade must complete and result in a functional system" criterion 16:14:06 (Though, I forget which milestone that is) 16:14:09 the updates happen, but the cleanup phase gets stuck. 16:15:04 sgallagh: beta. 16:15:13 danofsatx: that can result in a substantially messed-up system 16:15:17 http://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria#Updates 16:15:25 The installed system must be able to download and install updates with the default console package manager. 16:15:31 so, +1 blocker then. 16:15:33 that's updates, not upgrades. 16:15:54 I hit it on an update of an already installed F23 16:15:59 but: the upgrade criterion says "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed. ... The upgraded system must meet all release criteria." 16:16:06 c9 says it happened during an update as well 16:16:08 danofsatx: oh, this same thing with i-s? fun 16:16:20 so i'm inclined to give this at least a provisional +1 16:16:20 yes, exact same thing. 16:16:24 we can always de-blocker it later if appropriate 16:16:50 but, what is weird - I have two Dell D630 laptops with the exact same configuration. One hit this, the other didn't. 16:16:58 I wonder if somebody reproduced this with dnf system-upgrade, and just dnf update --releasever=23 16:17:24 kparal: You mean with both? 16:17:32 *and not just 16:17:54 danofsatx: Were you using 'dnf system-upgrade'? 16:18:06 it seems the reporters were live upgrading their systems 16:18:13 which is not exactly supported 16:18:32 but c9 says it happened during regular package update, not system upgrade, which is covered by our criteria 16:19:12 * danofsatx is spinning up an F22 VM to test 16:19:18 we can revisit in a bit 16:19:20 kparal: Yeah, I strongly suspect that this only happens when an upgrade occurs without being in the clean update env. 16:19:31 Which we still need to fix, but I don't think is deserving of a blocker 16:19:39 Since it's not an officially-supported upgrade mechanism, 16:19:43 punt, test and vote in bug? 16:19:57 or come back to after we do the final proposals? 16:19:58 roshi: Just a moment. 16:20:12 I want to finish describing my thought process here. 16:20:31 * satellit_e using the latest spins updated or with fully updated make a diffence? 16:20:41 * satellit_e lives 16:20:45 my question is, why is i-s even getting an update on an installed system 16:20:55 1) danofsatx's case: presumably you updated to F23 early in the cycle, before the latest initial-setup packages that cause this. 16:21:04 danofsatx: why wouldn't it? 16:21:08 danofsatx: Because the package exists. 16:21:17 it seems to me like the appropriate thing here is to drop the systemd restart macros 16:21:29 since we never actually expect i-s to be acting as some kind of daemon 16:21:30 danofsatx: And in your case, you installed a pre-release, which means you'll pick up any changes to i-s before it's released. 16:21:53 (i-s being updated post-release is a different question, but let's skip it for now) 16:22:07 these two systems were installed from F23 Alpha - Cinnamon 16:22:22 adamw: I strongly suspect that this cannot be hit if we boot into the systemd offline updates mode 16:22:29 (Based on the discussion in the BZ) 16:22:59 We should strongly urge that it be fixed before Final to aid those who don't use the supported upgrade mech, but I don't think it is a beta blocker 16:23:30 EOF 16:23:44 sgallagh: sure, but what about on a regular update? 16:23:55 danofsatx is saying that he hit it just updating his installed F23. 16:24:01 adamw: within a pre-release is a special case (IMHO) 16:24:14 meh, /me not convinced. 16:24:15 You're accepting a certain degree of risk 16:24:39 Particularly since we leave updates-testing on 16:24:47 still, since the issue is with post-install updates, we don't really need to fix this in the frozen package set, i guess. 16:24:51 If we were stable-only, I'd be more inclined to hesitate 16:25:40 I am with adamw here, I think it's one of the worst things that can happen if an update doesn't complete 16:25:49 it's terribly hard to recover from a messed up rpmdb 16:26:04 kalev: I don't disagree that it needs to be fixed. I disagree with the assertion that we couldn't ship Beta without fixing it first 16:26:04 on the other hand, i'm not sure the blocker process gets us anywhere with something that affects updates 16:26:15 sgallagh: it means it's impossible to update beta 16:26:23 or not impossible, but requires manual workarounds 16:26:52 I lean towards blockers on things that break any update mechanism 16:26:59 it's not just updates, it's the packages that's in the frozen set that's not uninstalling correctly 16:27:00 but I'm not sure on this one, tbh 16:27:03 I'm not sure that's true, kalev 16:27:24 * kalev double checks the error message in the ticket. 16:27:34 kalev: f23 installs pull from u-t by default 16:27:41 er, updates 16:27:47 so as soon as a fix for this hits u-t, it is effectively fixed 16:27:51 it doesn't need to go to stable 16:27:53 loooking at the ticket, it says "Sep 13 18:03:40 ERROR Non-fatal POSTUN scriptlet failure in rpm package initial-setup" 16:28:08 does it mean that if one installs beta and has the bad package, any updates _from_ that package are broken? 16:28:12 correct, a non-fatal error that hangs dnf. 16:28:14 because its postun script is bad? 16:28:22 that's the way I see it 16:28:23 kalev: yeah, true 16:28:25 well 16:28:29 i think saying 'any' is going too far 16:28:37 kalev: The problem appears to be due to a systemd service getting restarted during postin 16:28:42 Which shouldn't be 16:28:53 So it's still fixable in an update 16:28:54 as there's a factor we haven't worked out here: the bug only happens when i-s is actually running, and we haven't figured out the circumstances in which that happens yet 16:29:01 sgallagh: no, it's postun 16:29:05 postin is ok in the sense that this is fixable with an update; postun is not because that requires that the fix is in the frozen package set 16:29:05 not post 16:29:14 I think the bad script is only in initial-setup-0.3.35-1.fc23.x86_64 so once that one is out of the tree we should be good 16:29:18 I misread, then 16:29:23 * adamw checks 16:30:05 current git master and f23 both have postun_with_restart. 16:30:26 so, i guess i'll say i'd be at least in favour of an FE here, since it seems like we have a decent rationale for one 16:30:37 I'm fine with that. 16:30:50 If the problem is really with the F22 postun, there's nothing we can block on that would fix it in any case. 16:30:58 for me the question of whether it's a blocker kinda depends on the question of what's the circumstance, exactly, in which you have a stray initial-setup running when you run an update. 16:31:16 sgallagh: we're not thinking about f22 here 16:31:17 * danofsatx is updating F22 vm, upgrade to 23 will start shortly 16:31:26 adamw: To me, the obvious solution would be just kill any running i-s in %pre 16:31:45 sgallagh: we're thinking about a case where you install f23 beta (with an initial-setup package that has the bug) and then run a normal update 16:31:50 * kalev nods. 16:32:29 yes, that's the case that needs the fix in the frozen package set. F22->F23 updates are fixable with an update and don't require a fix in the frozen set 16:32:30 sgallagh: i guess that might help, but it smells like a hack. is there anything wrong with my idea of just not using the restart-y postun? 16:32:38 I wouldn't think bugs from a broken TC in the same milestone would block, though 16:32:51 adamw: Because that would have to have been on the old package, wouldn't it? 16:32:57 so this is updates from a previously installed F23 Beta, right? 16:33:02 roshi: so far as we know the bug is still in i-s *right now*. i.e. if we built Beta today, its i-s package would have the restart-y postun. 16:33:08 ah 16:33:10 hrm 16:33:12 sgallagh: sure, but if we give it an FE...:) 16:33:26 adamw: Still doesn't address the F22 side... 16:33:34 sgallagh: ship an F22 update. 16:33:44 or, i mean, just upgrade the proper way. 16:34:06 this only affects 'live' upgrade from F22, so far as we know, i.e. not using dnf system-upgrade. 16:34:21 right, but since a lot of people are set in their ways, that's still going to bite them 16:34:43 well, look, we can debate the right way to fix it outside this meeting 16:35:06 but i'm gonna say we should at least give this a +1 FE as it's *conceivable* that we want to change the postun for Beta to fix this 16:35:13 Absolutely +1 FE 16:35:14 we don't have to *use* the FE if we wind up doing something else 16:35:17 I remain -1 Blocker 16:36:05 votes? 16:36:22 I'd be +1 to a blocker here, not because of the F22->F23 updates, but because it must be possible to update F23 beta installs afterwards 16:36:33 the F22 initial setup is 0.3.31-1 - I'll let you know if it is broken in a bit. 16:36:54 i'm kinda +/-0 on blocker right now, +1 FE. 16:37:00 I mean, it's kinda fine if the beta doesn't install at all -- then the testers just keep away from it. but if it installs fine but explodes after first upgrade, it's extremely frustrating 16:37:28 * danofsatx wanted to put SSDs in the laptops anyway.... 16:37:38 also note that I am mostly only arguing for the sake of Server and KDE -- afaik we don't even install initial-setup in Workstation 16:37:55 Server doesn't include initial-setup either 16:38:07 and since I hit it in Cinnamon, a non-blocking desktop.... 16:38:08 ahh, that weakens the blocker case 16:38:24 i guess i'd tend slightly -1 blocker, as we probably *can* do something abou this without needing to fix the frozen package (i.e. %pre hack or whatever) 16:38:25 proposed #agreed - 1244394 - AcceptedFreezeException Beta - This bug still needs some testing to determine blocker status. However, we'd like to see a fix for this during freeze. 16:38:42 ack 16:38:44 ack 16:38:45 ack 16:38:48 ack 16:38:49 ack 16:38:51 ack 16:38:54 ack 16:39:12 #agreed - 1244394 - AcceptedFreezeException Beta - This bug still needs some testing to determine blocker status. However, we'd like to see a fix for this during freeze. 16:39:42 ok, we're onto Final proposals 16:39:44 #topic (1262599) Fedora 23 artwork (background/wallpaper) not applied by default 16:39:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=1262599 16:39:50 #info Proposed Blocker, f23-kde-theme, NEW 16:40:15 +1 16:40:20 +1 16:41:31 +1 16:41:40 +1 16:41:45 +1 saw it in testing 16:41:47 proposed #agreed - 1262599 - AcceptedBlocker Final - This bug is a clear violation of the following criterion: "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme." 16:41:58 ack 16:42:18 ack 16:42:19 ack 16:42:21 ack 16:42:21 #agreed - 1262599 - AcceptedBlocker Final - This bug is a clear violation of the following criterion: "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme." 16:42:22 ack 16:42:23 ack 16:42:29 #topic (1262600) Plasma live session notifies for available updates 16:42:32 #link https://bugzilla.redhat.com/show_bug.cgi?id=1262600 16:42:35 #info Proposed Blocker, plasma-pk-updates, NEW 16:42:54 +1, it shouldn't do that. 16:43:22 +1 16:43:30 +1 16:43:31 +1 16:43:32 +1, seems straightforward 16:43:33 +1 16:43:34 +1 16:43:39 And Rex looks like he's on it 16:44:09 proposed #agreed - 1262600 - AcceptedBlocker Final - This bug is a clear violation of the following criterion: "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image." 16:44:34 ack 16:44:39 ack 16:44:47 ack 16:44:55 ack 16:44:56 ack 16:45:01 #agreed - 1262600 - AcceptedBlocker Final - This bug is a clear violation of the following criterion: "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image." 16:45:05 #topic (1261721) preexisting btrfs snapshot cannot be assigned as mountpoint for new installation 16:45:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=1261721 16:45:11 #info Proposed Blocker, python-blivet, NEW 16:46:01 Didn't we already say no to this? 16:46:02 is btrfs a blocking setup? 16:46:20 no, we said we needed more info, which cmurf appears to have provided 16:48:47 just to be clear, at the time of blocker review last week, this was proposed as being something to do with encryption (not btrfs), and all we knew was that it was likely some kind of cmurf special setup 16:48:54 since then we've got quite a lot more info on what's going on 16:49:24 i believe dlehman is fairly clear that this is effectively a feature request - it's not something in anaconda that's broken, it's just something anaconda doesn't currently support 16:49:27 i'm -1 16:51:25 I'm -1 as well 16:51:48 -1 16:52:32 proposed #agreed - 1261721 - RejectedBlocker Final - This bug doesn't violate any criteria and is not considered a blocker. 16:53:26 ack 16:53:37 ack 16:53:40 ack 16:53:42 ack 16:53:43 #agreed - 1261721 - RejectedBlocker Final - This bug doesn't violate any criteria and is not considered a blocker. 16:54:01 ok, we've got one beta FE proposal 16:54:07 #topic (1262484) Fedora 21 doesn't contain F23 gpg keys: upgrade with dnf fails 16:54:11 #link https://bugzilla.redhat.com/show_bug.cgi?id=1262484 16:54:13 #info Proposed Freeze Exceptions, fedora-release, ON_QA 16:54:41 This isn't really an FE, since it just has to be pushed to the previous release 16:54:43 I don't think this needs a freeze exception, just needs to have the F21 package go stable 16:54:45 And is already in teseting there 16:54:46 yeah 16:55:13 Though it affects upgrades, so maybe this qualifies as a "special blocker"? 16:55:29 (Which begs the question if N->N+2 direct upgrades are supported) 16:55:40 -1, it'll get into f21 and not be an issue 16:55:43 In any case, no special handling should be needed by us 16:55:46 'supported' isn't the word 16:55:48 So -1 16:55:58 adamw: "Expected to work", then 16:55:59 the question of whether they're supported is a tricky one, but they clearly don't *block*, which is what we care about here 16:56:01 -1 16:56:06 -1 16:56:09 -1 16:56:10 we had the same issue last cycle 16:56:15 the criterion specifically states "the previous stable Fedora release", i.e., not the one before that 16:56:17 don't remember the vote outcome, though 16:56:24 /me nods 16:56:29 so if this was a blocker it'd be a special blocker, but it's not a blocker so it's nothing. :P 16:56:29 -1 16:56:42 (Thanks for not phrasing that as *a* previous stable Fedora release :) ) 16:56:51 proposed #agreed - 1262484 - RejectedFreezeException Beta - There's no need for an FE to get this fixed, as it's an F21 issue. 16:57:12 ack 16:57:12 ack 16:57:35 ack 16:57:37 ack 16:57:42 ack 16:58:10 #agreed - 1262484 - RejectedFreezeException Beta - There's no need for an FE to get this fixed, as it's an F21 issue. 16:58:26 ok, go through the accepted blockers for beta, or close out and get with the testing 16:58:29 ? 16:58:46 there's 7 accepted blockers if we go that route 16:59:14 I think we have to go through them 16:59:14 Maybe the only NEW one? 16:59:41 I think NEW and MODIFIED at least 16:59:44 ok 16:59:45 i more or less know where we're at, so it won't take long. 16:59:47 +1 close 16:59:58 Oh, and I tested 1260875 just a little while ago 17:00:07 Anyone have an issue with my marking it VERIFIED? 17:00:09 * danofsatx is in too much physical pain to go through the rest 17:00:34 ok, sounds good to go through the NEW and MODIFIED 17:00:49 #topic Accepted Blocker Review 17:00:50 #topic (1260318) TypeError: uid should be integer, not str 17:00:50 #link https://bugzilla.redhat.com/show_bug.cgi?id=1260318 17:00:50 #info Accepted Blocker, anaconda, MODIFIED 17:01:59 looks like we were right about it being common enough 17:02:20 Which version of anaconda was in TC5? 17:02:32 this one is not fixed in TC5 17:02:45 Oh wait. Yeah, I see the TC5 reports. 17:02:47 there will be new anaconda/blivet builds today that will address all the issues that are MODIFIED 17:02:48 ok 17:02:54 ones that are ON_QA/VERIFIED were in TC5 (or earlier) 17:03:11 ok, cool 17:03:23 so the only other one is 1260394 17:03:30 #topic (1260394) plasma-desktop and plasma-workspace packages break KDE session loading 17:03:33 #link https://bugzilla.redhat.com/show_bug.cgi?id=1260394 17:03:36 #info Accepted Blocker, plasma-desktop, NEW 17:04:48 so the KDE folks are clearly on this, but i don't know the exact current status 17:04:51 So this is still broken and shows no signs of resolution? :( 17:04:54 it was on my list to talk to them about it today 17:05:02 i think 'shows no signs of resolution' is unnecessarily pessimistic. 17:05:49 TC-5 has 5.4.0 here in virt-manager 17:05:58 Sorry, I meant to say that none of the comments indicate a solution is impending 17:08:19 well, not sure i agree with that either. 17:08:32 seems to me the downside of just doing "Requires: sddm-breeze" is pretty tiny. 17:08:48 and if we need to we can just do that and tell 'enterprise users' who are incapable of deploying a config file to go hang. 17:08:54 (controversial? moi?) 17:09:14 anything for us to do for this bug here in meeting? 17:10:11 don't think so, sgallagh and i are on it like donkey kong. 17:10:18 am i a chair? 17:10:22 yeah 17:10:34 adamw: Depends, do you have a pillow on your lap? 17:10:48 #info adamw and sgallagh are following up with KDE and DNF teams, at least a workaround for this should be viable easily enough 17:11:07 that's it then, we can move on 17:11:12 #topic Open Floor 17:11:15 sgallagh: message for you from NBC's commissioning department: don't call us, we'll call you 17:11:18 anyone have anything for this? 17:11:26 Plans for RC1? 17:11:46 basically it's waiting on the KDE bug at this point 17:11:56 Right, which sounds like a short rebuild away. 17:11:59 anaconda should be done soon 17:12:10 So barring disaster, plan for RC1 to build tonight? 17:12:18 * roshi hopes for it 17:12:20 sounds like a plan 17:12:47 Three days for release validation. Will wonders never cease? 17:13:12 that sounds so much better than 6 hours 17:13:25 or how much was it last time? :) 17:14:05 kalev: I think we had a full 9 17:14:32 * adamw hopes somebody is standing by in brno with the large roll of kparal duct tape 17:15:04 * kparal intends to work from home for the full next month. doors locked 17:15:19 /me changes the isolation chamber delivery address 17:15:23 well, I guess let's call this meeting, do some testing and hope for an RC1 tonight 17:15:52 just give him my normal ration of bourbon over an hour or something, should hold him up for a while 17:16:04 make sure adamw is pouring 17:16:27 fine canadian whisky is on standby 17:16:37 * roshi sets the fuse 17:16:44 thanks for coming folks! great turnout today 17:16:46 3... 17:17:14 2... 17:17:24 hi there, one quick question 17:17:36 go for it :) 17:17:46 who from QE is goint to be on Readiness meeting ? 17:17:50 this Thursday 17:17:56 I'll be there 17:18:01 ok, thanks 17:18:10 I'm sure others will be as well 17:18:14 * adamw may or may not depending on how much overnight blocker heroism is needed 17:18:18 but yeah, we'll be there one way or another 17:18:22 then please continue countdown ... 17:18:38 1... 17:18:44 thanks folks! 17:18:47 #endmeeting