17:00:17 <jkurik> #startmeeting F27 Final and Server Beta Go/No-Go meeting
17:00:17 <zodbot> Meeting started Thu Nov  2 17:00:17 2017 UTC.  The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:17 <zodbot> The meeting name has been set to 'f27_final_and_server_beta_go/no-go_meeting'
17:00:23 <jkurik> #meetingname F27-final-and-Server-Beta-Go-No-Go-meeting
17:00:23 <zodbot> The meeting name has been set to 'f27-final-and-server-beta-go-no-go-meeting'
17:00:29 <jkurik> #topic Roll Call
17:00:34 <jkurik> .hello jkurik
17:00:34 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
17:00:40 <jkurik> #chair nirik adamw sgallagh mboddu
17:00:40 <zodbot> Current chairs: adamw jkurik mboddu nirik sgallagh
17:00:52 <langdon> .hello2
17:00:53 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
17:00:58 <contyk> .hello psabata
17:00:59 <sgallagh> Here we go again...
17:00:59 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
17:01:03 <sgallagh> .hello sgallagh
17:01:04 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:01:11 <nirik> morning
17:01:18 <contyk> evening
17:01:30 <langdon> lunch!
17:01:46 <jkurik> Hi everybody
17:02:06 * kparal is lurking
17:02:22 <mboddu> .hello mohanboddu
17:02:23 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:02:31 <jkurik> ok, lets start
17:02:34 <rashmi> .hello rashmin
17:02:35 <zodbot> rashmi: rashmin 'Rashmi Nargundkar' <rnargund@redhat.com>
17:02:40 <jkurik> #topic Purpose of this meeting
17:02:47 <jkurik> #info Purpose of this meeting is to check whether or not F27 Final and F27 Server Beta are ready for shipment, according to the release criteria.
17:02:54 <jkurik> #info This is determined in a few ways:
17:02:59 <jkurik> #info * Release candidate compose is available
17:03:05 <jkurik> #info * No remaining blocker bugs
17:03:09 <jkurik> #info * Test matrices are fully completed
17:03:15 <jkurik> #topic Current status
17:03:20 <jkurik> We have an RC compose for F27 Final available at https://kojipkgs.fedoraproject.org/compose/27/Fedora-27-20171101.0/
17:03:24 <jkurik> We also have test matrices for F27 Final available at https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Base
17:03:30 <jkurik> There are some proposed blockers: https://qa.fedoraproject.org/blockerbugs/milestone/27/final/buglist
17:03:36 <jkurik> As far as I am aware, the RC for F27 Server Beta is not yet ready.
17:03:41 <jkurik> As such, we do not have test matrices for F27 Server Beta RCs.
17:03:51 <jkurik> Anyone wants to add/correct something ?
17:04:21 <sgallagh> Correct, we don't have an RC for f27 Beta yet. We're close, but not there yet.
17:04:30 <Kohane> Hello
17:04:39 <Kohane> .fas lailah
17:04:40 <zodbot> Kohane: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
17:04:49 <jkurik> sgallagh: thanks for the confirmation
17:04:52 <jkurik> Kohane: hi
17:05:04 <jkurik> #link https://kojipkgs.fedoraproject.org/compose/27/Fedora-27-20171101.0/ RC for the F27 Final
17:05:09 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Base Test matrices for the F27 Final
17:05:15 <jkurik> #info RC for the F27 Server Beta is not yet ready.
17:05:20 <jkurik> #info As we have no RC for F27 Server Beta there are subsequently no Test Matrices for the F27 Server Beta.
17:05:37 <jkurik> do we have adamw ?
17:06:59 * jkurik is pinging adamw on other channel
17:07:45 <jkurik> kparal: would you like to run Mini-Blocker review or do we wait for adamw ?
17:08:45 <Kohane> jkurik: hi
17:08:54 * mattdm is here
17:08:56 * kparal looking for the instructions
17:08:57 <mattdm> (sorry)
17:09:39 <jkurik> mattdm: hi
17:09:41 <kparal> jkurik: I think you have to chair me
17:09:47 <nirik> adamw was just around, I am sure he will show up in a few. ;)
17:09:56 <jkurik> #chair kparal
17:09:56 <zodbot> Current chairs: adamw jkurik kparal mboddu nirik sgallagh
17:10:25 <kparal> #topic F27-blocker-review
17:10:41 <jkurik> kparal: thanks
17:10:42 <kparal> #topic Introduction
17:10:42 <kparal> Why are we here?
17:10:42 <kparal> #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.
17:10:42 <kparal> #info We'll be following the process outlined at:
17:10:42 <kparal> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:10:44 <kparal> #info The bugs up for review today are available at:
17:10:46 <kparal> #link http://qa.fedoraproject.org/blockerbugs/current
17:10:48 <kparal> #info The criteria for release blocking bugs can be found at:
17:10:50 <kparal> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
17:10:52 <kparal> #link https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria
17:10:54 <kparal> #link https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria
17:11:11 <kparal> regular release first, right? server then
17:11:18 <jkurik> kparal: yes please
17:11:23 <kparal> #info 7 Proposed Blockers
17:11:23 <kparal> #info 5 Accepted Blockers
17:11:23 <kparal> #info 0 Accepted 0-day Blockers
17:11:23 <kparal> #info 0 Accepted Previous Release Blockers
17:11:23 <kparal> #info 2 Proposed Freeze Exceptions
17:11:23 <kparal> #info 6 Accepted Freeze Exceptions
17:11:33 <kparal> #topic (1508706) No longer works with USB webcam 19ff:0103 , error "Tried to capture in BGR3, but device returned format YUYV"
17:11:33 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1508706
17:11:33 <kparal> #info Proposed Blocker, cheese, NEW
17:11:48 * langdon steps away for a min
17:12:22 <mattdm> Is this a bug in Cheese or is it indicative of a regression of support of that camera _at all_?
17:12:24 <nirik> this seems hardware/driver specific
17:12:30 <jkurik> I am -1 to block on this as it seems to me like some HW issue affecting only minority of users
17:12:39 <kparal> with the limited responses it seems that integrated cameras work, while usb ones don't
17:12:55 <kparal> actually, I should have one around
17:13:08 <adamw> .hello adamwill
17:13:09 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:13:10 <adamw> sorry, was chatting
17:13:22 <kparal> adamw: can you take over then? :)
17:13:29 <adamw> kparal: i doubt it's usb vs. integrated
17:13:30 <adamw> sure
17:13:35 <adamw> it's much more likely to be about colorspaces
17:13:46 <adamw> i rather suspect it's "cameras which support some particular colorspace work, ones which don't don't"
17:13:56 <adamw> but anyway, so far we have I think two that don't work, five or six that do
17:14:21 * nirik s here works on 2 laptops.
17:14:36 <adamw> so i think with that ratio, this probably doesn't need to block
17:14:38 <kparal> my laptop one works and my external usb one works as well
17:14:45 <kparal> on f27 with updates-testing enabled
17:14:51 <sgallagh> Yeah, I'm -1 blocker, +1 FE if we end up slipping
17:15:09 <langdon> my x270 also works
17:15:38 <kparal> adamw: I'll secretarialize
17:16:03 <adamw> thanks kparal
17:16:04 <nirik> also something that is hopefully fixable in updates...
17:16:14 <adamw> nirik: yeah, except if anyone wants to use it on the live image.
17:16:28 <nirik> true, unless it's just a cheese update then you could update that.
17:16:34 <nirik> if it's kernel tho yeah
17:16:37 <adamw> i guess
17:16:39 <adamw> anyway
17:17:02 <jkurik> so it looks like we agreed on -1 to block
17:17:17 <mboddu> -1 Blocker and +1 FE
17:17:31 <mboddu> It can be addressed through an update
17:17:31 <adamw> proposed #agreed 1508706 - RejectedBlocker AcceptedFreezeException (Final) - this seems to be hardware dependent, so far about 20% of tested cameras were affected. We think this is a low enough failure rate to not consider this a release-blocking issue, but important enough to be worth an FE if the release slips.
17:17:50 <jkurik> ack
17:17:55 <mboddu> ack
17:18:06 <nirik> ack
17:18:39 <kparal> ack
17:18:42 <adamw> #agreed 1508706 - RejectedBlocker AcceptedFreezeException (Final) - this seems to be hardware dependent, so far about 20% of tested cameras were affected. We think this is a low enough failure rate to not consider this a release-blocking issue, but important enough to be worth an FE if the release slips.
17:19:07 <adamw> #topic (1508808) dbxtool service fails to start - EFI Signature List is malformed
17:19:07 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1508808
17:19:07 <adamw> #info Proposed Blocker, dbxtool, NEW
17:19:51 <adamw> so this also seems to be system-specific. basically it seems to boil down to, either there's really something wrong in the efi variables for the affected folks, or the efivars are fine and there's a bug in the check, but it doesn't always show up.
17:20:27 <nirik> yeah, it's working on my rawhide laptop FWIW.
17:20:27 <adamw> the *practical* consequence of this, i guess, is that the secure boot signature blacklist wouldn't get updated. but we can fix it with an update, very likely.
17:21:17 <Kohane> Yeah, but if there's a problem with EFI, is it possible to boot and install anyway?
17:21:31 <nirik> should be.
17:21:39 <Kohane> Oh. Okay.
17:21:47 <kparal> petr installed it
17:21:49 <adamw> yeah, it doesn't break boot.
17:21:53 <kparal> it just showed as a failed service
17:22:16 <adamw> so, given that the impact of this is quite restricted, again i'm -1 blocker. not sure about FE.
17:22:36 <sgallagh> I'm -1 blocker, -1 FE
17:22:53 <sgallagh> Any change to the boot process that isn't a blocker makes me very nervous.
17:22:59 <nirik> -1/+1 (If it turns out to be a simple fix)
17:23:09 <jkurik> I am -1 to block, -1 FE as well
17:23:22 <Kohane> Yeah, agree
17:23:30 <Kohane> -1 blocker -1 FE
17:24:15 <jkurik> I am with sgallagh to avoid to touch the boot process unless really necessary
17:24:56 <adamw> proposed #agreed 1508808 - RejectedBlocker RejectedFreezeException (Final) - this seems to only affect a minority of UEFI installs, based on current information. the practical consequences of the failure are not too terrible and can be fixed with a post-release update, so given the limited breadth of impact we don't believe this qualifies as a release blocking issue.
17:25:13 <sgallagh> ack
17:25:14 <jkurik> ack
17:25:14 <mboddu> ack
17:25:19 <Kohane> ack
17:25:36 <adamw> #agreed 1508808 - RejectedBlocker RejectedFreezeException (Final) - this seems to only affect a minority of UEFI installs, based on current information. the practical consequences of the failure are not too terrible and can be fixed with a post-release update, so given the limited breadth of impact we don't believe this qualifies as a release blocking issue.
17:25:51 <adamw> #topic (1508794) systemd/dracut doesn't wait for mediacheck to finish
17:25:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1508794
17:25:52 <adamw> #info Proposed Blocker, dracut, POST
17:26:04 <adamw> so, this one is gonna be fun :/
17:26:10 <mboddu> :)
17:26:11 <sgallagh> This would bother me less if it wasn't the damned default boot target
17:26:18 <adamw> basically, if you do the media check on boot, it gets 90 seconds to complete
17:26:30 <adamw> if it doesn't complete in 90 seconds, boot will fail, due to a timeout
17:26:42 <kparal> clear +1 blocker for me
17:26:47 <sgallagh> Right, so you'd best be installing from fast media :)
17:26:50 <adamw> 'check media and boot' is the default option for BIOS boots of both live and non-live media, i believe. not sure about UEFI boots.
17:26:54 <kparal> with usb 2.0 ports you're very likely to hit this
17:26:55 <Kohane> Yeah, it's a blocker.
17:27:03 <Kohane> +1 Blocker.
17:27:25 <adamw> kparal calculated that you need 18MB/sec transfer speed *not* to hit this with the KDE live image, which is the largest image we care about for f27 final.
17:27:29 <sgallagh> I'm guessing that VMs were fast enough at checking that we didn't see this sooner?
17:27:32 <adamw> er, sorry, workstation live
17:27:40 <Kellin> +1 Blocker
17:27:45 <nirik> thats the default option right?
17:27:47 <mattdm> sad, sad, sad +1
17:27:51 <adamw> sgallagh: and USB sticks. i did actually boot with the media check with a USB stick last night, but apparently mine's fast enough.
17:27:57 <adamw> reproduced with a CD this morning, though.
17:27:59 <kparal> sgallagh: yes. even our usb 3.0 sticks plugged into usb 3.0 drives are fast enough. that's why we only saw this with dvd
17:28:04 <mattdm> if it were just CDs, I might feel wiggly
17:28:14 <kparal> s/drives/ports
17:28:18 <mboddu> If its default boot target, then definitely +1 Blocker
17:28:27 <sgallagh> It failed with USB2.0?
17:28:29 <adamw> kparal: see, *this* is why i keep insisting on real media checks :P
17:28:50 <nirik> and the fix is one \ ? sheesh... I love computers. ;)
17:29:04 <sgallagh> I'd kind of like to propose that we hold this decision for the end.
17:29:04 <kparal> I used a slow 8GB stick with usb 2.0 port to make it go slower
17:29:13 <kparal> you know, the stuff people have at home
17:29:21 <sgallagh> I kind of feel like we could relnote this if it's literally the only thing holding us back
17:29:27 <adamw> usb 2.0's theoretical max transfer rate is 30MB/sec
17:29:33 <kparal> 18MB/s is very close to maximum real usb 2.0 throughput
17:29:34 <adamw> sgallagh: there's some others coming up that are at least awkward
17:29:40 <adamw> all non-live installs on Macs fail
17:29:45 <kparal> adamw: I get 20-25MB/s at most thought usb 2.0
17:29:49 <adamw> yeah
17:30:01 <adamw> i kinda feel like this is going to show up too much in the real world for us to get away with
17:30:02 <Kohane> adamw: Really? Why they fail?
17:30:05 <nirik> those "fedora branded" 2G ones are slow...
17:30:10 <sgallagh> adamw: That may be true, but I'm really on the fence here
17:30:15 <adamw> sure you can work around it
17:30:20 <adamw> but it's just a really bad look
17:30:29 <sgallagh> Yeah :-/
17:30:33 * nirik is reluctantly +1 blocker.
17:30:42 <adamw> yeah, given the USB 2.0 cases i'm +1 blocker
17:30:53 <sgallagh> I guess I'm 0.
17:31:01 * mboddu uses USB 2.0 on his old laptop
17:31:22 <jkurik> +1 to block :-(
17:31:29 * Kohane is surrounded by USB 2.0
17:31:50 <Kohane> +1 Blocker.
17:31:56 * jkurik is surrounded by DVDs drives
17:32:24 <kparal> it's less about usb2.0 and more about slow 4-8GB sticks
17:32:25 <adamw> proposed #agreed 1508794 - AcceptedBlocker (Final) - this is a conditional violation of the requirement that images boot by default. we believe it will be encountered sufficiently often in the real world, and leave a bad enough impression when it does happen, to accept it as a blocker.
17:32:34 <kparal> but it goes hand in hand
17:32:35 * mboddu trying to find his floppy disk :D
17:32:47 <Kohane> jkurik:  and then they say DVD drives are dead....
17:32:47 <mboddu> ack
17:32:50 <kparal> ack
17:32:54 <Kohane> ack
17:33:02 <adamw> #agreed 1508794 - AcceptedBlocker (Final) - this is a conditional violation of the requirement that images boot by default. we believe it will be encountered sufficiently often in the real world, and leave a bad enough impression when it does happen, to accept it as a blocker.
17:33:06 <adamw> sorry we didn't catch it earlier, folks :/
17:33:43 <jkurik> adamw: capital "W" in "we believe" - otherwise ack
17:33:47 <kparal> the reason is that we're too lazy to burn dvds in advance
17:34:38 <kparal> also, it takes an awful lot of time, of course
17:34:56 <adamw> #topic (1469813) [abrt] gnome-shell: _g_log_abort(): gnome-shell killed by signal 5
17:34:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1469813
17:34:57 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:35:07 <adamw> so this one is rather messy
17:35:16 <adamw> since we have a blocker already it's probably not worth spending a lot of time on
17:35:26 <adamw> there seem to be at least a few different cases going on here, all getting marked as dupes of this bug
17:36:07 <adamw> it's really difficult to make an assessment of how common it is / is likely to be, but it does worry me
17:36:14 <Kohane> adamw: Give me a moment to read, please, I don't use Gnome.
17:36:18 <mattdm> I think that I should talk to the RH desktop team about putting "split gnome shell and login manager" on the roadmap
17:36:27 <adamw> Kohane: it boils down to 'gnome-shell crashes sometimes for some people'
17:36:50 <adamw> mattdm: well, it's more the problem that effectively the shell is the display server, with wayland
17:36:53 <mattdm> All of these gnome shell crashers become "data loss" bugs when previously they were just weird blips as shell restarted quietly in the background
17:36:54 <adamw> so when it crashes the whole session dies
17:36:56 <Kohane> Oh, but that's Gnome's normal behaviour adamw
17:36:57 <adamw> right
17:37:01 <adamw> Kohane: haha
17:37:18 <adamw> mattdm: i agree it'd be super nice to somehow get that back how it was with X
17:37:44 <adamw> so i'm gonna propose we just leave this to the monday meeting, when hopefully we'll have more info
17:38:00 <mattdm> There's vague ideas of splitting up the process, but no one really signed up to go forward with it
17:38:05 * mboddu wonders that this Proposed blocker is also a proposed FE
17:38:20 <adamw> proposed #agreed 1469813 - punt (delay decision) - this is a rather complex report with probably multiple different problems bundled up together, we don't yet really have the information to make a determination
17:38:22 <langdon> i was so impressed when they moved it to the split process... also really wish it would come back..
17:38:24 <nirik> I'm leaning toward -1 blocker, but yeah, more info on it would be good.
17:38:27 <Kohane> Gnome crashes randomly on any laptop I had, have and will have.  And rarely could understand why it was crashing at all.
17:38:37 <adamw> mboddu: that's fine and allowed, though not usually really *necessary* (we tend to consider all proposed blockers for FE status too)
17:38:47 <nirik> adamw: so, I guess then no heroics if we do that. ;)
17:38:57 <adamw> nirik: i was not planning any heroics, no.
17:38:58 <mboddu> adamw: Okay
17:39:15 <adamw> did someone wanna talk about heroics? if so, please wait a second while i go and get my talking stick
17:39:19 <adamw> it's the one with the rusty nails in it
17:39:27 <jkurik> adamw: ack to the proposal
17:39:27 <nirik> ok. If it was just the dracut and mactel ones we could respin and try tomorrow, but I'm ok not doing that too
17:39:39 <sgallagh> adamw: I'm surprised the nails are rusty, considering how much use it gets
17:39:47 <adamw> sgallagh: oh, i rust 'em up specially.
17:39:47 <Kohane> adamw: LMAO
17:40:00 <Kellin> adamw: but only since we added rust packaging right?
17:40:03 <adamw> srsly, though, i guess nirik has a point...
17:40:26 <adamw> i *am* worried enough about this one that i'm not sure about rushing out a hero release with this still open
17:40:30 <sgallagh> Do we have fixes for those two?
17:40:36 <adamw> sgallagh: yeah. at least, we think we do.
17:40:45 <sgallagh> ok
17:41:00 <adamw> though we'd need martink to merge an anaconda patch and build a new anaconda
17:41:12 <adamw> well
17:41:20 <adamw> let's work through the other proposed blockers first, anyway
17:41:28 <jkurik> adamw: we have a blocker anyway, so why you would respin tomorrow ?
17:41:33 <adamw> jkurik: we also have a fix for it.
17:41:43 <jkurik> ah, ok
17:41:47 <nirik> so, I guess punt this one still and we can come back if we want?
17:41:49 <adamw> there's a one-liner patch posted for the mediacheck bug already
17:41:50 <adamw> nirik: yeah
17:41:58 <adamw> so, proposed #agreed ok for now? ack/nack/patch?
17:42:02 <Kohane> I didn't understand...  Is there a fix for the Gnome crashes bug?
17:42:04 <nirik> ack
17:42:07 <adamw> Kohane: no.
17:42:17 <nirik> Kohane: nope... we don't know enough about whats causing it.
17:42:17 <Kohane> Oh, okay.
17:42:29 <Kohane> As usual with Gnome.
17:42:42 <nirik> gnome is pretty stable for me...
17:42:45 <nirik> YMMV
17:43:02 <adamw> #agreed 1469813 - punt (delay decision) - this is a rather complex report with probably multiple different problems bundled up together, we don't yet really have the information to make a determination
17:43:13 <adamw> #topic (1486002) grub2-mkconfig does not work if xen.gz is installed.
17:43:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1486002
17:43:14 <adamw> #info Proposed Blocker, grub2, NEW
17:43:32 <adamw> so technically we fixed the initially reported issue here, but UEFI Xen domU installs still don't work.
17:43:44 <mattdm> Peter Jones says "Honestly I think this is an RFE and we should handle it in F28."
17:43:45 <adamw> however, pjones seems fairly sure this isn't actually anything new and they have *never* worked
17:44:02 <adamw> we have asked konrad whether he ever actually tested with UEFI before, but he hasn't replied yet.
17:44:10 <mattdm> yeah. so, -1 blocker and uh, I guess +1 FE if peter would want to do it, but he doesn't, so that's kind of moot
17:44:36 <adamw> not sure if i prefer to -1 it here or punt until we hear from konrad, but one of those two, anyway. not +1
17:44:52 <Kohane> As I don't know what xen.gz is, I'm 0 on this.
17:45:06 <jkurik> -1 blocker, +1 FE
17:45:32 <nirik> -1 blocker
17:46:30 <sgallagh> Kohane: Xen is the *other* virtualization system for Linux
17:46:36 <sgallagh> I'm -1/-1
17:46:47 <Kohane> sgallagh: Thanks
17:46:49 <sgallagh> Same reasons as before; too much risk with destabilizing stuff that works right now
17:47:18 <nirik> if this never worked, we should not try and make it work in the last days before release. ;)
17:47:24 <langdon> also the one amazon uses for their cloud :)
17:47:29 <Kohane> Then I'm -1 Blocker -1 FE
17:47:30 * mattdm away again for a bit... sorry
17:48:09 <adamw> we don't know for *sure* yet
17:48:15 <adamw> but we can vote on that basis and adjust if we get more data.
17:49:07 <adamw> proposed #agreed 1486002 - RejectedBlocker RejectedFreezeException (Final) - best information at present is that Xen UEFI installs have never worked. given this, we don't think it makes sense to treat this as a last-minute release blocking bug, or grant a freeze exception. If this turns out to be incorrect, we will re-evaluate.
17:49:25 <sgallagh> ack
17:49:27 <jkurik> ack
17:49:30 <Kohane> ack
17:51:03 <adamw> #agreed 1486002 - RejectedBlocker RejectedFreezeException (Final) - best information at present is that Xen UEFI installs have never worked. given this, we don't think it makes sense to treat this as a last-minute release blocking bug, or grant a freeze exception. If this turns out to be incorrect, we will re-evaluate.
17:51:11 <adamw> #topic (1507931) Missing cursor with latest kernel in QXL+SPICE VM
17:51:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1507931
17:51:12 <adamw> #info Proposed Blocker, kernel, NEW
17:51:31 <adamw> so this seems pretty solidly reproducible: with all the latest bits, on a qxl VM, the cursor is invisible in gdm
17:51:34 <adamw> works fine once you get into GNOME
17:52:31 <Kohane> So basically you don't see the cursor when you're in front of GDM but you see it after logging in?
17:52:35 <adamw> yes.
17:52:36 <jkurik> it is inconvenience, from my POV, not a really blocker
17:52:48 <Kohane> Yeah, I wouldn't call it blocker.
17:52:50 <nirik> yeah, I lean toward -1 blocker
17:53:21 <kparal> since it works with virtio, I guess I'm fine with -1
17:53:30 <mboddu> -1 blocker
17:53:40 <Kohane> adamw:  Out of curiosity: Does the mouse works, can you click on something and get a response? Or it doesn't work at all?
17:53:50 <Kohane> -1 blocker
17:53:55 <adamw> kpar has seen it more than me...i think it works but you just can't see it
17:53:58 <adamw> but i just used keys
17:54:06 <kparal> you can click. it's just invisible
17:54:20 <Kohane> Oh, okay. Thanks both.
17:54:23 <jkurik> invisible clicks :)
17:54:57 <adamw> i'm definitely +1 FE
17:55:01 <adamw> other votes?
17:55:10 <mboddu> -1 blocker, +1 FE
17:55:30 <nirik> yeah, +1 FE
17:56:11 <jkurik> I do not know how big the patch is, so I am +0FE
17:56:22 <kparal> -1/+1
17:56:35 <adamw> we can reject too complex of a fix.
17:57:35 <adamw> proposed #agreed 1507931 - RejectedBlocker AcceptedFreezeException (Final) - we agreed that this doesn't really break things enough to constitute a violation of the criteria, navigating gdm with a keyboard is easy and there are workarounds like using a different video adapter. However, it's visible enough to be worth fixing if the fix is not too complex
17:57:51 <jkurik> ack
17:57:58 <nirik> ack
17:58:03 <Kohane> ack
17:58:18 <adamw> #agreed 1507931 - RejectedBlocker AcceptedFreezeException (Final) - we agreed that this doesn't really break things enough to constitute a violation of the criteria, navigating gdm with a keyboard is easy and there are workarounds like using a different video adapter. However, it's visible enough to be worth fixing if the fix is not too complex
17:58:23 <adamw> #topic (1508899) Non-live Fedora 27 installs fail on Macs
17:58:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1508899
17:58:24 <adamw> #info Proposed Blocker, mactel-boot, NEW
17:58:46 <adamw> so this is a bit unfortunate :/ we caught this late as we only tested live installs earlier
17:59:09 <adamw> we tried to fix this earlier this week but the fix wasn't complete
17:59:22 <adamw> so as the summary says, all non-live installs on Mac will fail.
17:59:34 <mboddu> adamw: How many people do non-live installs?
17:59:37 <adamw> non-live blocking images are, iirc, Everything netinst and Workstation netinst.
17:59:43 <adamw> mboddu: we really do not have great data on that.
17:59:56 <adamw> especially when the question is 'how many people with macs do non-live installs'.
18:00:03 <adamw> the only answer i can really give you is 'at least one'. :P
18:00:25 <mboddu> adamw: yes, thats the question and thanks for the answer :)
18:00:34 <Kohane> mboddu:  That's a good question. Last time I tried to install Fedora it took me to a live session anyway, even when I selected it to install straight away.
18:00:46 <sgallagh> I'm happy to give this a +1 FE
18:00:47 <adamw> Kohane: live media always boot to a live session. they have to.
18:00:57 <adamw> Kohane: but this affects non-live images; netinst and DVD images.
18:01:02 <Kohane> Oh.
18:01:02 <sgallagh> Kohane: There is separate media for install-only
18:01:07 <Kohane> I see.
18:01:15 <sgallagh> The Live media can just be told to boot to Live and immediately launch anaconda
18:01:20 <Kellin> adamw: at least two, because I didn't report it and that's how I install too ;)
18:01:21 <Kohane> Well, I think this is blocker.
18:01:25 <mboddu> adamw: so, I am not sure if its considered as a blocker or not
18:01:28 <nirik> I could easily see larger places doing netinstalls on a lab or something
18:01:41 <Kellin> to a point, that's how the Princeton U lab installs Fedora to their Macs
18:01:50 * Kellin has worked with them in the past on installer issues on Macs.
18:01:56 <mboddu> Kohane: yeah, what adamw said, all live media always boot into live session
18:02:07 <kparal> +1 blocker per criteria
18:02:17 <Kohane> +1 Blocker
18:03:07 * nirik is a weak +1. we can't know how many people install this way, but it could be enough to be a blocker.
18:03:09 <jkurik> I am +1 to block
18:03:19 <sgallagh> I'm 0 on blocking
18:03:23 <adamw> so let's talk about the criteria a bit
18:03:30 <mboddu> +1 blocker per criteria
18:03:35 <mboddu> adamw: hehe
18:04:03 <adamw> the criterion says "All release-blocking images must boot in their supported configurations. "
18:04:05 <adamw> grr
18:04:07 <adamw> yes, that
18:06:21 * mkolman is fine with doing a hotfix Anaconda build for this
18:07:17 <mkolman> but it would really be good to avoid boot-related last minute fixes in the future
18:07:30 <adamw> sorry, got distracted by the doorbell
18:07:37 <kparal> mkolman: that would be really good, agreed :)
18:07:45 <nirik> yeah, I think we all want that.
18:08:05 <adamw> i think i'm inclined to +1
18:08:16 <adamw> so we're at +4
18:09:43 <adamw> proposed #agreed 1508899 - AcceptedBlocker (Final) - accepted as a blocker as a violation of Basic criterion "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces", for installs to Mac (which is a supported platform) using the Workstation and Everything netinst images (which are release-blocking)
18:10:00 <nirik> ack
18:10:04 <jkurik> ack
18:10:10 <mboddu> ack
18:10:13 <Kohane> ack
18:10:16 <kparal> ack
18:10:28 <adamw> #agreed 1508899 - AcceptedBlocker (Final) - accepted as a blocker as a violation of Basic criterion "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces", for installs to Mac (which is a supported platform) using the Workstation and Everything netinst images (which are release-blocking)
18:10:46 <adamw> so, that's all the proposed blockers
18:11:31 <Kohane> Okay.
18:11:44 <adamw> oh, are we doing server beta go/no-go here as well? or is this only final?
18:12:00 <jkurik> adamw: we are doing server beta go/no-go here as well
18:12:16 <adamw> okay then
18:12:20 <adamw> #info that's all the proposed Final blockers
18:12:26 <adamw> #info there is one proposed Server Beta blocker
18:12:30 <adamw> #topic (1508576) freeipa module installation fails
18:12:30 <jkurik> adamw: however as we do not have RC, we might skip the blocker review
18:12:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1508576
18:12:30 <adamw> #info Proposed Blocker, fedora-modular-release, ASSIGNED
18:12:35 <adamw> eh, it's one bug
18:12:37 <adamw> we may as well stamp it
18:12:39 <adamw> +1, obviously
18:12:40 <jkurik> ok
18:12:45 <Kohane> I think I know this one...
18:12:57 <Kohane> +1 Blocker
18:13:17 <jkurik> +1 to block
18:13:25 <nirik> +1 blocker
18:13:33 <adamw> proposed #agreed 1508576 - AcceptedBlocker (Server Beta) - clear violation of Basic criterion "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried"
18:13:45 <jkurik> ack
18:13:48 <mboddu> ack
18:14:02 <Kellin> ack
18:14:07 <sgallagh> +1 blocker
18:14:11 <adamw> #agreed 1508576 - AcceptedBlocker (Server Beta) - clear violation of Basic criterion "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried"
18:14:15 <sgallagh> I've got all the pieces lined up to fix in tonight's compose
18:14:25 <sgallagh> Just having some hiccups with the build infra this afternoon
18:14:31 <sgallagh> (which is why I'm only paying half attention)
18:14:43 <mboddu> sgallagh: awesome
18:15:05 <sgallagh> mboddu: Well, once that's fixed, I need to figure out why the actual install process is still failing
18:15:11 <sgallagh> I'm trying to debug that with the FreeIPA team
18:15:39 <mboddu> sgallagh: okay
18:15:40 <adamw> #info that's all proposed blockers
18:15:55 <jkurik> adamw: thanks
18:16:20 <jkurik> #topic Test Matrices coverage
18:16:28 <jkurik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Base Test matrices for the F27 Final
18:16:50 * Kohane away for a minute, be right back
18:17:41 <adamw> i'm working on the last boot/install tests now
18:17:59 <adamw> note that all Server-specific tests are not needed for Final
18:18:06 <adamw> so the whole Server matrix, and the Server boot/install tests
18:18:29 * adamw has KDE live UEFI install running from DVD ATM, Workstation netinst written to a CD for testing after that
18:19:28 <adamw> otherwise coverage is looking fairly good, just a couple of holes we could cover quite fast i guess
18:19:38 <jkurik> we are missing QA:Testcase_desktop_update_notification and QA:Testcase_desktop_keyring for Xfce on ARM
18:19:49 <adamw> yeah
18:19:58 <adamw> could probably test those on x64 if pwhalen isn't around...
18:20:10 <adamw> and good old install-to-SAS, of course.
18:20:11 * pwhalen is trying to fill 'em all
18:20:15 <adamw> thanks pwhalen!
18:20:19 * nirik suspects that one test is out of date.
18:20:24 <adamw> which one's that?
18:20:28 <jkurik> :)
18:20:34 <nirik> the update notifications on Xfce...
18:20:41 <nirik> it's done via dnfdragora now...
18:21:14 <adamw> the test case is phrased intentionally generically
18:21:24 <adamw> it just says, basically, 'something should notify about available updates'
18:21:48 <nirik> ok
18:23:03 <jkurik> so, I am OK to consider the overal coverage as sufficient for now (when pwhalen finish the two Xfce on ARM)
18:23:21 <jkurik> anyone has a different pov ?
18:23:38 <adamw> nope, i think we can say it's more or less done and we can complete it easily for next compose
18:23:58 <jkurik> ok
18:24:33 <jkurik> #info The coverage of matrices is considered as sufficient
18:24:48 <jkurik> #info As there is no RC For F27 Server Beta Test matrices are not ready as well and we are skipping the Test Matrices coverage check for the F27 Server Beta Release.
18:25:00 <jkurik> #topic Go/No-Go decision
18:25:14 <jkurik> so, how do you people see it ?
18:25:41 <jkurik> we need QA, releng, FESCo
18:25:49 <nirik> well, we are no go currently. We could just punt a week as normal, or we could try and address the 2 blockers asap and revisit tomorrow...
18:25:58 <sgallagh> I was just about to say the same
18:26:18 <sgallagh> But that would require us to revisit the GNOME issue we punted and decide +/- 1, to be fair
18:26:27 <nirik> yeah
18:26:57 <jkurik> I would be no-go and slip a week
18:27:16 <Kohane> I think is better a no-go
18:27:18 <mattdm> I would really, really, really like to not slip further. But I don't have any power to magically address those bugs.
18:27:45 <sgallagh> mattdm: Well, the two we marked as blocker have fixes ready.
18:27:55 <nirik> I'm happy to help test the mac one today/tonight, but I can't/wouldn't want to speak for anyone else.
18:27:58 <sgallagh> So the remaining question is whether the GNOME issue is worth blocking on
18:28:01 <pwhalen> would testing results for 1.2 be rolled over to 1.3?
18:28:25 <sgallagh> because the GNOME one *won't* be solved today, I'm pretty sure
18:28:25 <adamw> if we hero it, they'd have to be.
18:29:15 <Kohane> I don't like much heroing TBH...
18:29:31 <sgallagh> I'm personally a weak -1 on the GNOME Shell bug, as it's presumably fixable with updates.
18:29:31 <jkurik> I do not have a good feeling about the heroing either
18:30:04 <sgallagh> But I'm going to leave it to adamw and kparal whether they're willing to push themselves tonight
18:30:27 <mattdm> I also don't like to ask people to do hero work; I'd like to get F27 out the door, but it's not over yet with modular server still waiting.
18:31:08 <Kellin> I'm a no go; given how hard we've been pushing to date, forcing heroism will likely induce mistakes from exhaustion and delay us more in the long term.
18:31:54 <kparal> what exactly would get pushed and thus needed retesting?
18:32:06 <sgallagh> I'll back whichever play adamw and kparal want to make.
18:32:16 <kalev> if we end up slipping, I have a FE that might be nice to get in, given that we then have an additional week for testing :)
18:32:25 <kparal> pschindl is on PTO tomorrow
18:32:36 <sgallagh> kalev: We are NOT including a GNOME megaupdate if we can help it :)
18:32:54 <adamw> kparal: we'd want to re-run all the basic boot / install tests, and mac install.
18:32:55 <Kellin> -1 to adding more, we should fix what we know now and get it out the door
18:33:48 <kparal> sigh. it should be doable, yes
18:33:56 <adamw> fixes for the accepted blockers touch dracut and anaconda, i believe.
18:34:03 <adamw> well
18:34:05 <adamw> so
18:34:14 <adamw> we're still not totally sure about the mac fix, nirik is testing it atm.
18:34:34 <adamw> i think doing a hero respin for tomorrow is...possible, and a valid choice. i *am* worried about the GNOME crashes, though.
18:34:52 <kparal> 1469813?
18:35:46 <jkurik> kparal: yes
18:37:48 <jkurik> so, can we vote ? the choices are 1) heroing and have go/no-go tomorrow or 2) slip for a week
18:37:50 * kparal shrugs. if we can do another RC in 12 hours, we should probably try to test it. if anyone is able to reproduce the gnome crash, please have a look at it
18:38:15 <kparal> but I saw it just once I think
18:38:34 <jkurik> I am personally for #2: slip for a week
18:39:01 <Kohane> Me too.
18:39:20 <Kohane> #2 Slip for a week.
18:39:22 * adamw just looking at the gnome bug again
18:39:25 <mattdm> I am for trying to ship, but I'll defer to adam, kparal, etc.
18:39:30 <adamw> want to count affected people
18:39:31 * mattdm is also looking at the gnome bug
18:39:39 <mattdm> I dont see it in https://retrace.fedoraproject.org/faf/problems/?opsysreleases=125&component_names=&associate=__None&daterange=2017-10-03%3A2017-11-02&bug_filter=None&function_names=&binary_names=&source_file_names=&since_version=&since_release=&to_version=&to_release=
18:40:27 <nirik> adamw: should grub2-efi-x86 be installed?
18:40:51 <mattdm> oh no wait maybe https://retrace.fedoraproject.org/faf/problems/bthash/?bth=ace0521ace265a08414437a1fed40df38a39319c&bth=d165b159be67a0008491c16e600b051bdb35a66c
18:41:05 <Kellin> nirik: on a Mac?  yes, it's an x86 processor using a UEFI implementation
18:41:06 <mattdm> but note f26 and f25 :-/
18:42:01 <nirik> yes, I know, but I am asking about the specific package.
18:42:11 <adamw> nirik: grub2-efi-x64
18:42:39 <nirik> ok, it's not
18:42:41 <adamw> mattdm: that doesn't look the same...
18:42:48 <adamw> nirik: guh...duh?
18:43:08 <mattdm> adamw: no, yeah, it doesn't as I'm looking more
18:43:13 <mattdm> sorry for typing as I think :)
18:43:19 <nirik> let me go do another install and confirm for sure I got your updates (but it must have since it didn't die)
18:45:22 <adamw> nirik: but...if that package didn't get installed it doesn't make any *sense* that it didn't die. oh...except mactel-boot is in the same blob...
18:48:20 <nirik> woah.. traceback this time... "name 'MacEFIGRUB' is not defined"
18:48:45 <mkolman> better and better! :)
18:48:45 * langdon used to hang out at a club with that name
18:49:08 <langdon> Klub MacEFIGRUB: all dance-metal all the time
18:49:20 <Kohane> langdon: What name, better and better? Or MacEFIGRUB?
18:49:41 <adamw> nirik: i just got that in my test script, and now i don't think i know python any more.
18:49:42 * langdon fixed it for Kohane ;)
18:49:49 <Kohane> LOL thanks
18:49:53 <jkurik> nirik: thanks for the testing
18:50:22 <jkurik> so we do not have a fix for the mac bug, right ?
18:50:26 <nirik> so, what do we want to do here? keep the meeting open or just punt?
18:50:28 <coremodule> Late, got the times wrong, but willing to hero tonight should we decide such.
18:50:51 <nirik> we need to slip final further now? or we just miss the rain date?
18:50:54 <adamw> i'm kinda undecided atm.
18:51:16 <jkurik> nirik: we already slipped to rain date the previous week
18:51:19 <adamw> it's really hard to get a feel for exactly how many people are hitting new GNOME crashes. and i'm distracted trying to get this mac fix right.
18:51:42 <nirik> jkurik: thats what I thought. ;(
18:52:05 <nirik> proposal: keep meeting open and revisit tomorrow at same time and see where we are?
18:52:28 <nirik> if we hit any bumps we are doomed and slip a week.
18:52:47 <mattdm> adamw: yeah. is there a reason these aren't showing up in the FAF server, at all?
18:52:54 <adamw> mattdm: i don't know.
18:53:02 <adamw> nirik: sure.
18:53:11 <dustymabe> coremodule: my hero!
18:53:45 <jkurik> if we decide to revisit tomorrow, than: Anyone volunteer to chair the Go/No-Go meeting tomorrow as I am not available tomorrow after 13:00UTC.
18:54:10 <coremodule> dustymabe, Had planned on having openstack installs tested, but got the bloody times wrongs...
18:54:47 <Kohane> jkurik: I will be available at that time.
18:54:56 <nirik> adamw: let me know what to try next and what channel we should coordinate in. ;)
18:54:57 <mattdm> adamw: maybe I can be useful by checking into that
18:54:58 <adamw> nirik: okay, second try coming up
18:55:10 <adamw> nirik: #anaconda i guess
18:55:13 <jkurik> Kohane++
18:55:14 <nirik> ok
18:55:28 <adamw> mattdm: yeah, it would really help if you can investigate and try to come up with some sort of organization of the issues, as it's clearly a confused bug.
18:55:38 <adamw> mattdm: looking at the dupes will help, they all have backtraces.
18:55:54 <adamw> at a quick look it definitely looks like there's multiple different bugs, but *some* of the reports are dupes of each other.
18:55:59 <kalev> I can help debug stuff too if there's something reproducable
18:57:44 <Kellin> given all the equivocations above, we should have a firm no-go; there is too much in the air to land it safely/sanely
18:58:23 * mattdm on it
18:59:20 <jkurik> Kellin: I support your opinion
19:00:23 * Kohane momentarily blind as is cleaning her glasses
19:00:44 <jkurik> mboddu, adamw, nirik: what is your final decision ? do we slip for a week or we keep the meeting open till tomorrow ?
19:01:17 <nirik> well, if it's just me that wants to try things we can slip... sounded like the folks doing the work/testing were ok with trying...
19:01:30 <nirik> if we slip thats to the 28th?
19:02:08 <mboddu> nirik: 28th?
19:02:13 <jkurik> nirik: why 28th ? we should slip for a week
19:02:22 <jkurik> 14th
19:02:30 <nirik> 21st is thanksgiving week.
19:02:49 <nirik> ok
19:03:08 <adamw> mattdm said he'd like to avoid slipping.
19:03:25 <jkurik> nirik:  if we will be "go" today than the GA is on 7th; if we slip than the GA is 14th
19:03:29 <mboddu> adamw: How sure are you that we will have a fix?
19:03:33 <adamw> i'm just a bit overloaded to have sane thoughts right now. i am trying to fix the mac bug.
19:03:34 <Kellin> adamw: I'd like to avoid dying, but sometimes it's inevitable
19:03:40 <adamw> mboddu: for the mac bug? now about 99%.
19:04:02 <Kellin> adamw: being that overloaded further justifies the no-go for trying to hero it in today/tomorrow.
19:04:35 <mboddu> adamw: What about https://bugzilla.redhat.com/show_bug.cgi?id=1508794 ?
19:04:55 <nirik> there is a proposed fix for that too
19:04:58 <nirik> see the last comments
19:05:38 <Kohane> So... what do we do?
19:05:59 <Kellin> but we are making the assumption that all those will work, the first time, not introduce any other issues, etc, etc.
19:06:04 <adamw> Kellin: i mean i'm overloaded trying to do useful stuff about these bugs as opposed to debating here.
19:06:10 <adamw> Kellin: no we aren't.
19:07:09 <adamw> if any of those things turns out not to be true, we just slip.
19:07:22 <adamw> deciding to *try* and sign off tomorrow isn't the same as deciding we *must* sign off tomorrow.
19:07:23 * mattdm votes that we keep the meeting open and poke at things
19:07:28 <mattdm> yeah, that
19:07:40 <adamw> i'm okay to at least leave the door open for a bit
19:07:51 <adamw> see if we can get dracut and anaconda builds quick and run another compose
19:08:01 <adamw> get some more info about the gnome crashes while it's running
19:08:16 <jkurik> proposed #agreed We keep the meeting open till Friday, November 3rd, 17:00UTC when we re-evaluate status of blockers and we make the final decision.
19:08:23 <adamw> +1
19:08:26 <Kohane> +1
19:08:27 <adamw> ack
19:08:39 <coremodule> +1
19:08:45 <coremodule> ack
19:08:52 <jkurik> nirik, mboddu: are you ok with it ^^^
19:08:53 <nirik> ack
19:08:56 <Kellin> -1 / nack
19:09:02 <mboddu> I just want to let you know, the compose takes 8 hrs approximately, and the sync to /pub/alt/stage takes around 4 hrs, so its at the minimum 12 hour task in total and there are things that we do after its a Go. So, if its a go tomorrow, releng has to work on weekend.
19:09:20 <dustymabe> mboddu: yep. and I'll be with you
19:09:21 <kparal> adamw: I'll check tomorrow morning whether the compose is ready or not. please write some email if we should do the hero testing on it
19:09:37 <mboddu> dustymabe: thanks
19:09:52 <mboddu> mattdm: ^^^, what is your call?
19:09:53 <jkurik> mboddu: that is the reason why I am asking you because dgilmore was always against heroing
19:09:57 <mattdm> I think it's useful to do that _anyway_, because otherwise we'll be back to this next week.
19:09:59 <dustymabe> mboddu: that was just me saying /me too
19:10:15 <mattdm> +1
19:10:15 <mboddu> dustymabe: oh okay
19:11:39 <jkurik> mboddu: does that mean you are ok with it ?
19:11:52 <adamw> kparal: will do.
19:12:24 <dustymabe> jkurik: well i'm not officially releng so I can't actually help mboddu do anything other than verify results and complain when things are wrong
19:12:25 <mboddu> jkurik: Yeah, I am also against last minute heroing
19:12:53 * adamw is not pushing anyone else to hero if they don't want to. i'm totally fine with deciding not ot.
19:13:04 <mboddu> jkurik: But at the same time I dont want to delay this
19:13:16 <Kohane> I prefer to delay rather than heroing.
19:13:23 <Kohane> But it's just my opinion.
19:13:44 <jkurik> ok, so how about this then:
19:13:52 <jkurik> proposed #agreed The decision for F27 Final RC 1.2 is "No-Go" due to present blockers. The release slips for a week, having next Go/No-Go meeting on November 9th.
19:13:53 <adamw> mboddu: don't feel guilty about it. it's totally reasonable not to want to work over the weekend just to save the schedule.
19:14:23 <adamw> for qa, we may wind up working late night, but at least once we sign off on the tests, we're basically done, we can go relax till the monay
19:14:27 <Kohane> +1
19:15:54 <jkurik> adamw, nirik: are you fine to slip then ? ^^^
19:16:04 <mattdm> I'm -1, not to slipping if we need to, but I'd still like to hold things open
19:16:09 * langdon sends adamw more underpants
19:16:11 <mboddu> adamw: its not about guilty, I just dont want to delay the reasons for the reasons I understand, at the same time I dont want us to ship something that might be buggy for just the sake of shipping
19:16:22 <nirik> sigh. Could we make a deciscion... instead of deciding and then redeciding.
19:16:37 <Kellin> No go.
19:16:44 <nirik> we are not going to ship something buggy for the sake of shipping
19:16:50 <nirik> that is not what this is about
19:17:27 <adamw> jkurik: i am personally OK with either choice, and QA considers either choice reasonable. i'm giving value to matt's desire not to slip, though.
19:18:16 <mattdm> With the holidays, we basically have one more week to _possibly_ slip without risking turning into "hey it's january now" fiasco
19:18:30 <dustymabe> summary: qa is ok either way, FPL would like to not slip if we don't have to, not slipping means significant people work on the weekend
19:18:58 <mattdm> And we've got to leave some space for Modular Server in there
19:19:07 <Kohane> mattdm: Which holidays?
19:19:08 <mattdm> Because I also don't want *that* to slip to January
19:19:28 <mattdm> Kohane: thanksgiving now, and then in december, half the people who can fix bugs are on end-of-year leave
19:19:38 <Kohane> Ah
19:20:09 <Kohane> mattdm: It's holidays here now. And nothing else until December AFAIK
19:21:12 <dustymabe> mattdm: I guess you have significant concern that we would find something in testing next week that would mean we would not ship on the 14th?
19:21:13 <Kohane> mattdm:  Thanks for the explanation. I always forget about thanksgiving.
19:22:17 <mattdm> dustymabe: Yes, unless we're already planning on having composes and everything ready over the weekend _anyway_
19:22:51 <dustymabe> we could have a 1.3 tomorrow
19:22:51 <mattdm> Based on experience, there's high probability that we won't have a monday compose for whatever reason
19:23:01 <mattdm> and then the tuesday one means testing on wednesday
19:23:11 <mattdm> and we're basically back to this exact situation we are in now by thursday
19:23:14 <mattdm> except a week later.
19:23:57 <mattdm> we basically need compose times to be much shorter and less risky, or have them run automatically and reliably
19:24:14 <dustymabe> mattdm: I completely agree with you
19:24:33 <dustymabe> but we are going to have to focus efforts on that and make that a significant goal
19:24:49 <jkurik> mattdm: do I understand it correctly that you would like to make the go/no-go decision tomorrow and in case the decision id GO then ship it on Nov 14th as releng is not willing to work over the weekend ?
19:25:00 * mkolman remembers a very similar discussion about long compose times causing a lot of pain back in the F20 timeframe
19:25:02 <mattdm> yes.
19:25:16 <dustymabe> mattdm: i'm +1 for that
19:25:16 <jkurik> mattdm: ok, makes sense then
19:25:29 <dustymabe> mboddu: WDYT of that?
19:25:32 <nirik> that seems weird
19:25:49 <nirik> what does it get us? less work on the weekend?
19:25:57 <adamw> mattdm: we can still do a compose today if we slip a week, i think.
19:26:21 <mboddu> dustymabe: that seems weird
19:26:34 <mattdm> adamw: okay, let's do that and stop spending lots of time on this here :)
19:26:56 <mboddu> I am okay with having a go/no-go tomorrow and if its go, I can work on weekend
19:27:14 * nirik is fine doing releng stuff on the weekend if no other releng folks want to.
19:27:41 <mboddu> nirik: thanks
19:27:49 <mattdm> thank you guys
19:27:52 <jkurik> ok, so then we are back at the proposal:
19:27:55 <jkurik> proposed #agreed We keep the meeting open till Friday, November 3rd, 17:00UTC when we re-evaluate status of blockers and we make the final decision.
19:27:56 <mattdm> also, just for the record
19:27:59 <Kellin> I'm going to point out that in three releases, 8 RCs that I have been on releng, we've been asked to work the weekend for each of them.  There is something wrong with this process that forces one team to consistently sacrifice like that.
19:28:00 <mattdm> #link https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tooling/epic/857
19:28:29 <Kellin> so while we're going to do it, that should be strongly considered for the future
19:29:01 <nirik> Kellin: by whom? we really stopped doing this kind of thing after f18... it's pretty rare these days....
19:29:07 <nirik> unless I blotted it out somehow
19:29:12 <adamw> nirik: we've done quite a lot of friday go/no-gos.
19:29:21 <mboddu> mattdm, adamw, nirik : Related to the discussion but off the topic, can we propose a change to have 3 week freezes?
19:29:51 <Kellin> nirik: to a point, mboddu doesn't fill me in when these come in, he does them, because he respects my family time.  but I respect him and it's painful to watch him go through this every release cycle
19:29:53 <mattdm> Kellin: yes, there are number of problems. I identified the long compose time as a crucial one of them.
19:29:59 <jkurik> mboddu: open a FESCo ticket for the meeting tomorrow
19:31:15 <mboddu> jkurik: Okay, I think that will give enough time for QA to test and it gives us enough time for releng to release it, and with no alpha I think we can implement this
19:31:25 <jkurik> mattdm: the problem here is not long compose time, it is the releng work which needs to be done once we are GO
19:32:33 <Kohane> jkurik:  I'm getting confused. The next meeting, when it's going to be? At what time?
19:33:11 <jkurik> Kohane: tomorrow at 17:00UTC
19:33:19 <mattdm> jkurik: all of that stuff is very automatable, and in fact really, really, really should be
19:33:36 <Kohane> jkurik: Good thanks.
19:34:32 <nirik> yeah, automate all the things.
19:34:54 <nirik> compose times are more difficult... since we keep adding tons and tons of new things...
19:35:26 <Kellin> we're off topic at this point, so cutting back to the chase.  tomorrow we decide go /no go based on results from engineers, if go, we compose this weekend.  Anything else relevant?
19:35:40 <jkurik> so how you are about the proposal ?
19:35:44 <jkurik> proposed #agreed We keep the meeting open till Friday, November 3rd, 17:00UTC when we re-evaluate status of blockers and we make the final decision.
19:35:49 <adamw> ack
19:35:53 <mboddu> ack
19:36:03 <Kohane> ack
19:36:03 <dustymabe> ack
19:36:30 <nirik> ack
19:36:35 <jkurik> #agreed We keep the meeting open till Friday, November 3rd, 17:00UTC when we re-evaluate status of blockers and we make the final decision.
19:36:43 <jkurik> #info Kohane will run the Go/No-Go meeting on the Friday as jkurik is not available
19:37:02 <jkurik> one more proposal, please:
19:37:12 <jkurik> proposed #agreed Due to missing RC for the F27 Server Beta release the decision is “No Go”. The F27 Server Beta release slips for one week. F27 Server Final GA date slip to 2018-Jan-09.
19:37:20 <adamw> ack
19:37:52 <mattdm> ack
19:38:04 <jkurik> nirik, mboddu: ^^^
19:38:07 <Kohane> ack
19:38:12 <mboddu> ack
19:38:17 <nirik> january... sad... but ack
19:38:21 <jkurik> ok, thanks
19:38:48 <jkurik> I am keeping the meeting open and Kohane will continue tomorrow...
19:39:00 <jkurik> thank you all for the meeting today
19:39:18 <Kohane> Yes. Thanks to you for chairing jkurik
19:39:37 <mattdm> see you all later
19:40:01 <coremodule> Thank you for chairing jkurik
19:41:42 <adamw> thanks jkurik
19:43:28 <mboddu> thanks jkurik
19:43:34 <mboddu> jkurik: also https://pagure.io/fesco/issue/1790
19:44:10 <jkurik> mboddu: I added the "meeting" tag
19:44:21 <mboddu> jkurik: thanks :)
19:47:00 <adamw> I'm testing the dracut fix now
19:48:21 <jkurik> #chair Kohane
19:48:21 <zodbot> Current chairs: Kohane adamw jkurik kparal mboddu nirik sgallagh
19:52:03 <mboddu> jkurik: isn't the meeting done already?
19:53:03 <jkurik> mboddu: what do you mean ? Agenda for the FESCo meeting tomorrow ?
19:53:31 <jkurik> if so, I just replied to the adam's email
19:59:34 <adamw> mboddu: what we're doing is leaving the meeting running
19:59:39 <adamw> till tomorrow morning
20:05:44 <mboddu> adamw: Oh okay, I thought we will end this and come back tomorrow
20:05:57 <mboddu> jkurik: adamw answered the question
20:06:39 <adamw> technically, we aren't allowed to end this meeting without making a decision
20:06:54 <adamw> so the stupid fudge we came up with a while back is, if we want to make the decision tomorrow, we just...don't end the meeting. :P
20:09:27 <nb> are any other meetings scheduled to use this channel in the meantime?
20:09:29 <nb> .nextmeetings
20:09:29 <zodbot> nb: One moment, please...  Looking up the channel list.
20:09:33 <Kellin> adamw: a certain song comes to mind from grade school
20:09:34 <zodbot> nb: In #fedora-meeting is Diversity Team IRC Meeting (starting in 16 hours)
20:09:37 <zodbot> nb: In #fedora-meeting-2 is Fedora Ambassadors Latam Meeting (starting in 17 hours)
20:09:40 <zodbot> nb: In #fedora-meeting is fesco (starting in 19 hours)
20:09:43 <zodbot> nb: In #fedora-meeting is L10n (starting in 2 days)
20:09:46 <zodbot> nb: In #fedora-meeting-2 is Workstation WG (starting in 3 days)
20:09:57 <nb> I guess not
23:49:52 <dowdle> So what was the decision on the Fedora 27 Final Go/No-Go meeting?
23:50:48 <dowdle> Or where can I find the IRC log?
00:00:48 <nirik> dowdle: the decision was to leave the meeting open (as it is now, hi meeting) and spin a new RC with fixes for the 2 known blockers, retest and then see where we are at 17UTC tomorrow.
00:10:46 <dowdle> nirik: Thanks for the answer.
00:10:54 <nirik> no problem
17:00:39 <lailah> Hello folks.
17:00:45 <lailah> .fas lailah
17:00:47 <zodbot> lailah: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
17:01:11 <adamw> Kellin: what time are we picking up the meeting?
17:01:34 * langdon lurks but doing other things... ping if you need me please
17:01:36 <lailah> I thought it was 17:00 UTC
17:01:37 <mattdm> now, right?
17:01:44 <lailah> I think so.
17:02:41 <nirik> kohane was going to run things I thought... but I don't see them on
17:02:46 <frantisekz> .hello2
17:02:48 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:02:57 <lailah> nirik: I'm here
17:03:08 <nirik> ah, different nick. ok. ;)
17:03:12 <Kohane> Yup
17:03:27 <Kellin> adamw: I thought it was said, 1
17:03:39 <mattdm> It is 1 EDT
17:03:46 <mattdm> 17 UTC
17:03:48 <Kohane> What is EDT?
17:03:52 <mboddu> .hello mohanboddu
17:03:53 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:03:54 <mattdm> Eastern Daylight Time
17:03:56 * kparal is here
17:03:57 <Kohane> Ah
17:04:07 <Kohane> I get lost when it's not UTC
17:04:09 <mattdm> currently, both the same thing
17:04:20 * coremodule is here.
17:04:32 <puiterwijk> Hi
17:04:41 * Kohane feels a bit nervous because never chaired a meeting before.
17:06:10 <mattdm> Kohane: don't worry. It can't be messed up too badly :)
17:06:22 <Kohane> Oh, okay
17:06:26 <Kohane> Thanks mattdm
17:06:31 <mattdm> but I think we're ready to get started, yeah?
17:06:35 <Kohane> Yup
17:07:23 <Kohane> So... we had some bugs from yesterday. Any news on that?
17:07:48 <mattdm> #topic Review of blockers from yesterday
17:08:01 <Kohane> Ah, yeah, thanks.
17:08:03 <Kohane> Sorry.
17:08:04 <mattdm> :)
17:08:30 <mattdm> as i understand it, the mediacheck timeout issue is fixed and in the new rc
17:08:36 <nirik> .chair mattdm
17:08:36 <zodbot> mattdm is seated in a chair with a nice view of a placid lake, unsuspecting that another chair is about to be slammed into them.
17:08:43 <nirik> ha
17:08:43 <kparal> correct
17:08:54 <Kohane> LOL
17:08:56 <mboddu> what?
17:09:01 <nirik> #chair mattdm
17:09:01 <zodbot> Current chairs: Kohane adamw jkurik kparal mattdm mboddu nirik sgallagh
17:09:17 <nirik> perhaps we should do a mini blocker review?
17:09:29 <Kohane> Yes, I think that's the best.
17:09:33 <mboddu> +1
17:09:42 <adamw> sure
17:09:55 <adamw> well
17:10:04 <adamw> then we get into the awkward one without going over the ones for RC-1.3...
17:10:07 <adamw> so for the record:
17:10:40 <Kohane> Yes?
17:10:55 <adamw> #info both the blockers for which RC-1.3 was built - #1508899 and #1508794 - are verified resolved in RC-1.3
17:11:21 <Kohane> How many blockers we had from yesterday?
17:12:07 <mboddu> adamw: What about the bash issue? Has it been resolved?
17:12:10 <adamw> no.
17:12:20 <adamw> jeez, wait for me to get there, already. :P
17:12:23 <Kohane> I don't remember the bash issue...
17:12:27 <adamw> #info moving onto proposed blockers
17:12:43 <adamw> i'll do these backwards, for reasons that will become apparent.
17:12:46 <adamw> #topic (1469813) [abrt] gnome-shell: _g_log_abort(): gnome-shell killed by signal 5
17:12:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1469813
17:12:46 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:13:12 <adamw> so, i spent yesterday afternoon looking into this
17:13:43 <adamw> it appears to me that abrt is treating quite a lot of unrelated Shell crashes as dupes
17:13:57 <Kohane> Doh...
17:14:01 <adamw> when you look at the logs from each case, they're clearly not the same
17:14:10 <Kohane> Any reason why ABRT does this?
17:14:20 <adamw> well
17:14:32 <adamw> all the crashes go through the same last three frames in the traceback
17:15:00 <adamw> because it's a path where glib lets you log a 'fatal' error, which will cause the error message to be logged and then the process to abort
17:15:13 <adamw> i think any time that happens, abrt decides those three frames are enough to call the bug a dupe
17:15:29 <Kohane> Oh, I see.
17:15:48 <adamw> so, it seems like we've rather got several different scenarios in which people have run into Shell crashes, rather than one single big Shell crasher bug we can fix
17:16:03 <adamw> of the dupes, three of them look a lot like the same problem, the others all looked different from each other
17:16:37 <Kohane> Is there any fix at least for one of them?
17:17:05 <adamw> i am not quite sure, as it seems like my damn bug mail isn't arriving properly today...
17:17:06 <mattdm> Yeah, my take on this is "GNOME Shell crashes more than it'd be nice for it to, but not all for the same reason"
17:17:08 <adamw> let me have a look.
17:17:32 <mattdm> We had previously one really common gnome-shell crash whcih turned out to be a problem with the topicons extension
17:18:09 <adamw> no, i don't see fixes for any of them yet.
17:18:18 <mattdm> As noted in the bug, I think -- other than "hey, fix all the bugs ever!" -- the best we can do is ask GNOME devs to prioritize separating the wayland compositor from the shell
17:18:19 <adamw> so, i'm basically in agreement with mattdm's take here
17:18:40 <adamw> i'm clearly -1 blocker on 1469813, since that actual crash appears to happen very rarely
17:18:53 <adamw> we could consider any of the now-unduped "dupes" for blocker status, but i'm not sure any of them alone is worth it.
17:19:11 <Kellin> maybe not alone, but in aggregate?
17:19:23 <adamw> what would it mean to have eight bugs 'in aggregate' block the release?
17:19:28 <adamw> how many of them have to be fixed before we ship?
17:19:50 <adamw> and what's the precedent we're setting? if we can count up enough crasher bugs in gnome-shell at the go/no-go date we slip?
17:20:01 <langdon> should the "bug" in abrt be addressed however?
17:20:06 <adamw> langdon: already is
17:20:09 <mattdm> plus, there are a zillion _other_ gnome-shell crashes that just don't happen to get marked as dupes here
17:20:12 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1509086
17:20:15 <adamw> right, exactly
17:20:16 <langdon> as a blocker i meant..
17:20:25 <adamw> langdon: nah, i don't see that it needs to be a release blocker.
17:20:25 <mattdm> no. no it should not.
17:20:32 * nirik is -1 blocker here also
17:20:49 <adamw> sure, we may get some dupes from users who don't update or hit crashes in the live session, but it's not a disaster. we can just undupe them.
17:21:40 <adamw> so i guess i'd say, we don't really have any indication that any particular Shell crash is going to affect so many people so frequently as to constitute a release blocker.
17:21:49 <adamw> are there crasher bugs in shell? sure. were there in f24, f25, and f26? sure.
17:22:10 <mattdm> There are 559 open bugs against gnome-shell right now
17:22:13 <adamw> do we have any particular information that f27 is massively worse in this regard? nope. we just have a bug report that looks really bad because of this bogus duping issue.
17:22:15 <mattdm> new or assigned state
17:22:35 <Kohane> I'm -1 blocker as well.
17:22:36 <mattdm> 330 of them abrt crashes
17:22:56 <adamw> if anyone *does* have a convincing analysis indicating that there's a particular issue with shell crashes in f27, now would be the time to present it. :P
17:22:58 <sumantrom[m]> -1 blocker
17:25:25 <Kohane> Just for the records: I stumbled upon a very annoying bug in Gnome but it's nothing worth of a blocker. I'll be filing it today and eventually will get fixed I suppose.
17:25:43 <adamw> proposed #agreed 1469813 - RejectedBlocker (Final) - turns out that many unrelated crash reports have been marked as duplicates of this one due to a libreport issue (#1509086). the actual original crash here is clearly too rare to constitute a release blocker. for the record, we also have no indication that any of the dupes is important enough to merit blocker status at this time.
17:25:44 <Kohane> I mean, today. I found that just hours ago.
17:25:51 <mattdm> ack
17:25:54 <Kohane> ack
17:26:17 <coremodule> ack
17:26:31 <adamw> #agreed 1469813 - RejectedBlocker (Final) - turns out that many unrelated crash reports have been marked as duplicates of this one due to a libreport issue (#1509086). the actual original crash here is clearly too rare to constitute a release blocker. for the record, we also have no indication that any of the dupes is important enough to merit blocker status at this time.
17:26:37 <adamw> so now, the one that's gonna make us cry!
17:26:45 <adamw> #topic (1193590) Allow bash to have a default profile without the 'rootfiles' package
17:26:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1193590
17:26:45 <adamw> #info Proposed Blocker, bash, ON_QA
17:26:46 <Kohane> Yeah!
17:26:50 <adamw> this, this is awful.
17:26:56 <mattdm> yes. :(
17:26:58 <adamw> so here is my understanding of this:
17:27:04 <mboddu> Here goes
17:27:05 <Kohane> Oh, now I remember. Yeah.
17:27:12 <mattdm> In retrospect, I think this should have merited a Change filing
17:27:56 <kparal> is there a tldr version?
17:28:10 <adamw> 1) some time earlier in the f27 cycle, bash maintainers decided to have all bash shells source /etc/bashrc directly during startup. previously, bash itself did not do this, but the default ~/.bashrc sourced it.
17:28:43 <mattdm> (which was ugly and weird, since so much system-wide stuff assumes /etc/bashrc to be sourced.)
17:28:52 <adamw> 2) as part of this, the template for ~/.bashrc was changed so it would *not* source /etc/bashrc any more.
17:29:20 <mattdm> (but also terrible because /etc/bashrc includes some random, opinionated stuff inherited from the dawn of time and which at the very least should only be defaults and not mandatory system-wide)
17:29:42 <adamw> 3) this change caused some problems, and as they worked through them, the bash maintainers decided that at least for f27 it was probably too early and should be reverted. so they sent out a bash update which changes things back to how they were: bash no longer sources /etc/bashrc directly, the template for ~/.bashrc does again.
17:29:58 <adamw> that update is currently in updates-testing.
17:30:19 <kparal> sigh
17:30:26 <adamw> now, the biggest problem with all this hilarity is this: if you install Fedora in the *current* state, and create some user accounts, you'll get a ~/.bashrc which doesn't source /etc/bashrc
17:30:42 <adamw> if you then update to the new bash package, your user shells won't source /etc/bashrc at all.
17:30:56 <adamw> situ: good timing, we're just on the bash bug
17:30:58 <kparal> double sigh
17:30:59 <Kohane> Doh...  that's depressing....
17:31:06 <nirik> indeed it is
17:31:18 <adamw> so if we ship RC-1.3 and then push this update at 0-day, we will obviously cause mass carnage.
17:31:23 <rdieter> should've skipped step 2 (/etc/bashrc already has protections for being source'd > 1) <shrug>
17:31:24 <ignatenkobrain> adamw: I asked Siteshwar to join ;)
17:31:28 <adamw> (or, you know, push this update any time later.)
17:31:45 <adamw> rdieter: it actually didn't at first. that was one of the bugs that got worked on. :P
17:32:01 <rdieter> adamw: ok, its a good addition then
17:32:07 <adamw> (or it had some protection but it needed more, i forget the detials)
17:32:12 <adamw> i really can see only two viable options here:
17:32:22 <situ> rdieter: The plan was to source directly from bash, so we removed the code to source it from ~/.bashrc.
17:32:33 <adamw> 1) slip a week, respin with the updated bash, and document the problem for everyone who has an f27 pre-release installed (as all *those* systems will break on update)
17:32:42 <adamw> situ: i just did a summary of the issue
17:32:42 <rdieter> situ: I"m just saying sourcing multiple times isn't necessarily bad
17:32:53 <adamw> situ: i'll paste it to you in privmsg so you can review it for errors
17:32:58 <mattdm> Despite my "we should definitely not delay more" bias, I think this merits fixing.
17:33:00 <situ> adamw: ok, thanks!
17:33:07 * mattdm waits for adam's second option
17:33:10 * nirik too
17:33:42 <adamw> sorry, was pasting to situ
17:33:56 <adamw> 2) just don't do the reversion, stick with the 'bash always sources /etc/bashrc' approach
17:34:11 <adamw> which obviously comes along with all the disadvantages that were the reason for reverting it.
17:34:16 <Kohane> I think we should slip a week and respin the updated bash.  It makes no sense to keep the schedule if it's going to break the system.
17:34:24 <mattdm> *and* we'd still need to do a respin, right?
17:34:27 <adamw> if anyone can think of any other options, i'm dying to hear 'em.
17:34:31 <adamw> mattdm: no, not in that case.
17:34:32 <nirik> mattdm: nope.
17:34:39 <adamw> we'd just withdraw the update and never do it.
17:34:49 <nirik> so what all is in bashrc... the prompt is the obvious ugly one
17:35:05 <mattdm> nirik: it's also sourcing all the /etc/profile.d stuff
17:35:24 <nirik> yeah, that could be rather more important
17:35:29 <adamw> there's...a lot of stuff.
17:35:36 <mattdm> vi won't be vim!
17:35:45 <adamw> i think my preferred choice here is 1), sadly
17:35:50 <adamw> unless anyone can come up with something better
17:36:03 <adamw> the change was clearly not fully-thought-through and i don't think it's a good idea to lock ourselves into it
17:36:04 <Kohane> Yeah, me too. I prefer option 1.
17:36:08 <nirik> situ: what do you think of choice 2 ? there were still reasons to not want to do this now?
17:36:18 <adamw> reverting it will be sad for people who installed f27 pre-releases, but not unmanageable
17:36:25 <adamw> nirik: there's quite a bit of discussion in the bug...
17:36:26 <mattdm> langdon tells me he did a fresh install of f27 and has bashrc sourced -- presumably that happened because he installed before the change first landed?
17:36:38 <nirik> yeah, I didn't get through it all.
17:36:41 <situ> nirik: As adamw said we need to think throughly about it.
17:36:44 <mattdm> so not everyone who installed prereleases will have the problem
17:37:01 <nirik> The change landed in late aug...
17:37:01 <adamw> mattdm: i think so, yes.
17:37:13 * adamw can verify what beta does, while we discuss this
17:37:24 <mattdm> or if people applied updates and got the rollback _before_ creating user accounts
17:37:43 <adamw> mattdm: well, network installs would do that, i guess.
17:37:50 <mattdm> yeah.
17:37:55 <langdon> sorry.. i wasn't looking
17:37:56 <nirik> they could... if you enable updates-testing
17:38:11 <mattdm> if the change landed post-beta, it'd be only people who did fresh installs from nightlies, right?
17:38:12 <adamw> nirik: it's used by default for network installs up until we ship the fedora-release change, iirc.
17:38:13 * Kohane leaves for a moment.
17:38:24 <adamw> mattdm: i'm checking into this.
17:38:32 <nirik> yeah, which we have now.
17:38:41 * mattdm has a bashrc that I've been shipping around from machine to machine since the late 1990s, so is not a good test case
17:38:43 <langdon> fyi.. i installed last week.. new laptop
17:38:52 * nirik is usually a zsh user. ;)
17:38:55 <langdon> and i haven't gotten to fixing my bashrc
17:39:21 * langdon does much of his work shh'd to another machine
17:40:09 <adamw> OK, yes. Beta has 4.4.12-9, which was before the change landed in 27.
17:40:13 * langdon also notes funny freudian slip
17:40:15 * Kohane is back
17:40:41 <Kohane> langdon: Freudian slip? Where?
17:40:57 <langdon> "work shh'd to"
17:41:06 <mboddu> adamw: So, that means it only affects people who updated using updates-testing then?
17:41:11 <mattdm> adamw: okay, so, that means the people in the "sad" category if we go with #1 is liekly to be rather small
17:41:31 <adamw> hopefully, yes.
17:41:33 <mattdm> people who were using updates-testing during the time the change was available _and_ had those updates applied before creating user acounts
17:41:36 <langdon> i only have main and updates enabled... so that seems to jive
17:42:01 <mattdm> okay, I think that tilts pretty heavily towards #1
17:42:18 <nirik> sadly, I think so. we were so close. ;(
17:42:28 * kparal thinks we have to slip
17:42:34 <adamw> to be specific, it would be: people who did network installs with u-t enabled since 2017-09-11, and any user accounts created on an f27 system updated on 2017-09-11 or later with u-t enabled (which was the default until recently).
17:43:04 * mattdm breaks out the "dedicated to quality!" press spiel
17:43:21 <adamw> and anyone who installed from a nightly dated 2017-09-30 or later.
17:43:27 <langdon> "it's releases when it's ready!"
17:43:28 <adamw> (maybe one day after, depends on the exact timing)
17:43:31 <nirik> I know, we can switch the default to zsh! :)
17:43:33 * nirik runs
17:43:38 <langdon> fish!
17:43:38 <adamw> it puts the bashrc in its profile
17:43:38 <mboddu> I am +1 to slip even though I want to get it out next week
17:43:41 <mboddu> nirik: hehe
17:43:43 <smooge> dash
17:44:03 <mattdm> busybox
17:44:08 <adamw> situ: and please, please run things like this through the Change process in future :/
17:44:15 <smooge> do we need a script which "fixes" these people?
17:44:18 <langdon> alpine?
17:44:23 <adamw> oh, i should've mentioned option 3) for the record, even though it's terrible
17:44:26 <situ> adamw: Sure.
17:44:31 <dustymabe> i've been planning to try out nirish (by nirik), but haven't had the time
17:44:37 <langdon> recommend rm -rf / ?/
17:44:41 <Kohane> adamw: What is option 3?
17:44:47 <adamw> option 3) involves some sort of package scriptlet which attempts to 'fix' user profiles. which would be terrible and we shouldn't do that.
17:44:59 <dustymabe> #shipit
17:45:00 <mboddu> adamw: nope
17:45:01 <Kohane> Oh, okay.
17:45:04 <situ> adamw: I would not vote for 3.
17:45:09 <smooge> ah I was going to ask that from the peanut gallery
17:45:20 <adamw> it has a number of obvious problems.
17:45:49 <nirik> It's also against package guidelines... would require a fesco override.
17:45:56 <adamw> yeah.
17:46:04 <adamw> so, it sounds like we're in favour of 1), unfortunately :(
17:46:11 <adamw> which means we would accept this as a blocker.
17:46:13 <nirik> yeah, sadly so
17:46:13 <adamw> so, for the record, +1.
17:46:13 <mattdm> nirik: *and* is terrible.
17:46:19 <mboddu> Yep :(
17:46:21 <mattdm> +1 sadface
17:46:21 <nirik> yes
17:46:23 <dustymabe> +1
17:46:23 <nirik> +1
17:46:25 <Kohane> +1
17:46:33 <frantisekz> +1
17:46:35 <puiterwijk> +1
17:46:37 <nirik> 😭
17:46:41 <coremodule> +1
17:46:43 <mboddu> +1
17:48:36 <mattdm> situ: Could I ask you and other interested people to put together a Change plan for doing this the best possible way in F28? Whatever the best possible way turns out to be?
17:49:02 <situ> mattdm: Yep, I will discuss it with ovasik (setup maintainer) and will let you know the details.
17:49:24 <adamw> proposed #agreed 1193590 - AcceptedBlocker (Final) - this is accepted as a critpath bug that "has a severity rating of high or greater and no reasonable workaround" and "cannot be fixed with a future stable update"; we don't see any reasonable way to ship the bash in RC-1.3 and change the behaviour with a post-release update, and we agree that the current behaviour is too problematic and must be reverted.
17:49:30 <mattdm> situ++
17:49:30 <zodbot> mattdm: Karma for siteshwar changed to 2 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:49:40 <nirik> ack
17:49:45 <Kohane> ack
17:49:46 <frantisekz> ack
17:49:48 <mboddu> ack
17:50:24 <adamw> #agreed 1193590 - AcceptedBlocker (Final) - this is accepted as a critpath bug that "has a severity rating of high or greater and no reasonable workaround" and "cannot be fixed with a future stable update"; we don't see any reasonable way to ship the bash in RC-1.3 and change the behaviour with a post-release update, and we agree that the current behaviour is too problematic and must be reverted.
17:51:19 <dustymabe> should we all agree to go have a good weekend now, or is there value is trudging along?
17:51:25 * nirik has another crazy thing to bring up.
17:51:36 <dustymabe> s/is/in
17:51:40 <mboddu> dustymabe: you can take the day off now ;)
17:51:45 <Kohane> nirik: Yes? What is it?
17:52:19 * mboddu waiting for nirik's crazy thing
17:52:22 <puiterwijk> If nirik's idea isn't the one I have, I got something too
17:52:28 <nirik> Long ago we actually got fesco to agree to allow releases on non tuesdays. :)
17:52:47 <nirik> what about the idea of repinning, testing and releasing on thursday or something
17:52:54 <Kohane> I like it.
17:52:58 <mboddu> nirik: It is crazy for me :)
17:53:11 <sgallagh> nirik: Every time that has been brought up in the last five years, rel-eng has categorically refused it
17:53:19 <adamw> i'm not personally super keen on it either.
17:53:20 <Kohane> nirik: It's crazy but lovely.
17:53:28 <adamw> you're not gonna get me tomorrow, i have tennis all day on saturdays.
17:53:32 <adamw> and my sundays are usually busy too.
17:53:39 <nirik> sgallagh: huh, I thought there were ok with it before
17:53:40 <adamw> but if other folks want to handle the qa end, sure.
17:53:42 <nirik> no no no
17:53:48 <nirik> I don't want anyone to work on the weekend.
17:54:03 <adamw> doing everything for a release between monday and thursday sounds tight.
17:54:18 * langdon kinda sees tennis all day on saturday as pretty much work ;)
17:54:24 <adamw> well, we could run the compose today. but by the time it's done, it's already close of business friday just about everywhere.
17:54:33 <nirik> yeah.
17:54:34 <adamw> so...everything else.
17:54:36 <Kohane> nirik:  I don't mind to work on weekends, if I can do anything that helps...
17:54:37 <dustymabe> this is a slippery slope
17:54:39 <nirik> it would be taking a 5 day thing to 3 days
17:54:46 <dustymabe> we already moved go/no-go to friday
17:54:51 <nirik> sure.
17:55:09 <adamw> i see the 'release not on tuesday' thing as being an alternative to this kind of friday hero'ing, not something we do *after* friday hero'ing failed.
17:55:09 <nirik> I'm fine not doing it. Just thought I would bring it up
17:55:10 <pbrobinson> sgallagh: the release date is little to do with rel-eng, it's primarily marketing that want it on that day due to news wires
17:55:22 <nirik> https://pagure.io/fesco/issue/974 FYI
17:55:32 <mboddu> nirik: I am not 100% positive for Thu release, the reason why we do Tue is for 1, we will give mirrors and the people who maintain them an entire weekend to pick up the new stuff
17:55:34 <langdon> pbrobinson: +1
17:55:44 <nirik> pbrobinson: well, it's staging and mirroring time, websites and marketing and common bugs and press
17:55:47 <sgallagh> pbrobinson: I had a vague memory of it having something to do with mirror agreements too
17:56:05 <mattdm> tuesday remains best according to PR, fwiw
17:56:06 <nirik> and tuesdays are good press days.
17:56:11 <mattdm> jinx
17:56:16 <pbrobinson> sgallagh: well it enables rel-eng to sync it out friday and get it to the mirrors on time
17:56:45 <mattdm> yeah that was probably a bigger deal back when a lot of admins did major-release mirroring manually
17:56:48 <nirik> anyhow, lets just slip a week... I guess it's not practical given the weekend for syncing
17:56:50 <adamw> btw, whoever's in charge, can you change the topic now?
17:56:51 <pbrobinson> but that's a we can't cut it today and have it on mirrors tomorrow, that is more "there needs to be a bunch of time between GO and announce"
17:57:02 <nirik> #topic Open Floor
17:57:10 <Kohane> Yeah, sorry. Thanks nirik
17:57:11 <adamw> i don't think open floor comes next, but oh well. :)
17:57:12 <mattdm> pbrobinson: +1
17:57:25 <mattdm> closed floor, everyone enjoy the weekend?
17:57:39 <mboddu> pbrobinson: +1
17:57:40 <puiterwijk> Well, I have one thing I'd like to point out during open floor.
17:57:45 <nirik> well, I guess we accepted that bug as a blocker, but didn't go/nogo
17:57:48 <pbrobinson> sgallagh: the marketing people don't do mondays and fridays and various other stuff so it's a 100 times more to do with them not rel-eng!!
17:58:14 <Kohane> There was someone who had another idea and was waiting for nirik crazy thing... who was?
17:58:26 <nirik> can we do the formal thing here first
17:58:29 <nirik> then go with puiterwijk's...
17:58:36 <puiterwijk> Sure.
17:58:41 <sgallagh> pbrobinson: OK? So there are plenty of reasons not to change it.
17:58:47 <nirik> #topic Formal Go / No Go decision
17:59:11 <pbrobinson> sgallagh: yup, but most of them aren't rel-eng ;-)
17:59:18 <nirik> There are outstanding accepted blockers, so no go.
17:59:26 <Kohane> I understand that the decision is No Go? Or am I missing something?
17:59:54 <adamw> yeah. given that there is an unaddressed accepted blocker, QA votes no-go.
18:00:00 <adamw> Kohane: we just have to formally vote and declare it.
18:00:16 <mboddu> rel-eng also votes no-go
18:00:36 <Kohane> adamw: Yes, I just wanted to be sure. Because the discussion got messy and I had to leave at some moment.
18:00:50 <adamw> ah i see
18:02:18 <mattdm> fpl votes "not stomping on the ship-it-anyway override" :)
18:03:52 <nirik> #agreed f27 is no-go due to an outstanding blocker bug. We will slip 1 week.
18:03:59 <nirik> #topic Open Floor
18:04:02 <nirik> puiterwijk:
18:04:13 <puiterwijk> Just wanted to point out that seemingly our package retirement scripts do not take freezes into account.
18:04:20 <puiterwijk> We hit this just today, with a pretty crucial package (libnfsidmap, used by nfs-utils) being blocked yesterday, and it's been lucky that that happened just after the RC compose was far enough, or the entire compose would've burned.
18:04:35 <puiterwijk> However, if it wasn't a package used in the compose process, but something that is crucial for a working system, it might severely change the test matrices, even though the package versions are the same.
18:04:43 <adamw> yeah, that's pretty scary.
18:04:57 <adamw> i think openqa would've caught it in testing, but still.
18:05:00 <puiterwijk> I'll look at getting the scripts fixed for that.
18:05:08 <Kohane> :C
18:05:25 <mattdm> puiterwijk++
18:05:26 <puiterwijk> Just wanted to point it out to possible interested folks, that we just had this happen today.
18:05:55 <mboddu> puiterwijk: I guess one thing we can do is, dont run block_retired.py during freeze as part of nightly.sh
18:06:13 <puiterwijk> mboddu: yep. And I am going to submit an FBR now to get that fixed
18:06:24 <mboddu> puiterwijk: oaky
18:06:26 <adamw> though, we might still need a mechanism to do selective retirements
18:06:29 <mboddu> s/oaky/okay/
18:06:30 <puiterwijk> Since I cannot fix this tonight, so for now I'm going to say to just get it removed
18:06:41 <adamw> like the way we wanted to retire fedora-release-notes
18:06:48 <puiterwijk> adamw: right. We can always do manual retirements. But I want to kill the automated tools during freeze
18:06:52 <adamw> okay.
18:07:01 <puiterwijk> So that we are at least aware of it
18:07:10 <adamw> just saying, if that script blocks 'every retired package', we'd need a more granular alternative (or just to do the blocking manually i guess)
18:07:34 <puiterwijk> Right. Making it more granular is what I will work on soon. but I can't get that done tonight
18:07:52 <puiterwijk> So for tonight, I'm filing for disabling the automated script so it won't break again tonight
18:08:13 <adamw> rgr
18:08:59 <puiterwijk> That was what I wanted to discuss. So unless anyone has questions, that's it from me
18:09:39 <Kohane> I have no questions. Not that I can remember at least.
18:09:52 * nirik has nothing else
18:10:06 <adamw> don't think we have anything either.
18:10:16 <adamw> well
18:10:26 <adamw> there's the question of which new FE fixes we want to pull into the respin, if any
18:10:28 <adamw> there are a few
18:10:41 <Kohane> Yes.
18:11:22 <adamw> there's a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1506802 , and a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1508706 , and a new proposed FE with a fix, https://bugzilla.redhat.com/show_bug.cgi?id=1446934
18:11:27 <adamw> do we wanna talk those through?
18:12:38 <adamw> do a quick FE review?
18:12:53 <Kohane> Yeah, I think we should.
18:13:22 <Kohane> Should I put a topic here adamw ?
18:13:29 <adamw> i can do it
18:13:37 <Kohane> Okay
18:13:41 <Kohane> Thanks
18:13:42 <adamw> #info we have some FEs to consider, so let's do a quick FE review
18:13:47 <adamw> #topic (1469813) [abrt] gnome-shell: _g_log_abort(): gnome-shell killed by signal 5
18:13:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1469813
18:13:48 <adamw> #info Proposed Freeze Exceptions, gnome-shell, NEW
18:13:48 <Kohane> But I'm not learning LOL
18:13:57 <adamw> this is the same GNOME crash bug from earlier
18:14:08 <adamw> Kohane: there's an SOP for doing blocker review, it's quite easy - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
18:14:13 <Kohane> Yes, I will end dreaming about it...
18:14:22 <adamw> so i'm a -1 FE on the actual original report here, again
18:14:40 <adamw> i'd consider FE for any Shell crash we actually have a clear safe fix for, but afaics we don't have any like that.
18:14:57 <Kohane> adamw: Thanks for the link.
18:15:28 <nirik> yeah, -1FE
18:15:35 <Kohane> -1 FE
18:16:05 <adamw> proposed #agreed 1469813 - RejectedFreezeException (Final) - the actual original reported crash here is quite rare and we have no information on any possible safe fix for it
18:16:39 <mboddu> ack
18:17:08 <frantisekz> ack
18:17:43 <adamw> #agreed 1469813 - RejectedFreezeException (Final) - the actual original reported crash here is quite rare and we have no information on any possible safe fix for it
18:17:50 <adamw> #topic (1507420) LDB / Samba module version mismatch
18:17:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1507420
18:17:50 <adamw> #info Proposed Freeze Exceptions, samba, MODIFIED
18:18:01 <adamw> if I'm right about this one, there's no need for an FE
18:18:11 <adamw> what's in stable is consistent
18:18:25 <adamw> the problem was only for people who got a libldb from updates-testing without a samba rebuilt against it
18:18:30 <Kohane> I don't see this one as a FE...
18:18:33 <adamw> so, i'm -1, unless anyone knows i'm wrong about it
18:18:43 <frantisekz> -1
18:18:49 <Kohane> -1
18:18:54 <nirik> -1
18:20:54 <mboddu> -1
18:21:03 <adamw> proposed #agreed 1507420 - RejectedFreezeException (Final) - to our best understanding, there is no need for a freeze exception to fix incompatibility between libldb and samba, the versions in stable are consistent. the update is internally consistent and can happily be shipped as a regular post-release update.
18:21:08 <mboddu> ack
18:21:35 <Kohane> ack
18:21:53 <frantisekz> ack
18:22:00 <nirik> ack
18:22:13 <adamw> #agreed 1507420 - RejectedFreezeException (Final) - to our best understanding, there is no need for a freeze exception to fix incompatibility between libldb and samba, the versions in stable are consistent. the update is internally consistent and can happily be shipped as a regular post-release update.
18:22:13 <adamw> <mboddu> ack
18:22:16 <adamw> heh
18:22:27 <adamw> ok, this one's more interesting
18:22:27 <adamw> #topic (1446934) Failure to import Box2D in Sugar Physics
18:22:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1446934
18:22:28 <adamw> #info Proposed Freeze Exceptions, sugar-physics, ON_QA
18:22:36 <mboddu> hehe
18:23:16 <adamw> as the change here is restricted to a Sugar package and it fixes a problem that'll be visible in the Sugar live image, i'm fine with fixing it
18:23:17 <adamw> +1
18:23:29 <frantisekz> +1
18:23:35 <Kohane> +1
18:23:37 <nirik> +1 here too. leaf package, fix in hand, doesn't work at all now.
18:24:34 <adamw> proposed #agreed 1446934 - AcceptedFreezeException (Final) - this fixes an issue in a non-blocking spin that would be a blocker in a blocking spin, and the fix is clearly limited to only affecting Sugar, so should be quite safe
18:24:49 <nirik> ack
18:24:52 <frantisekz> ack
18:24:56 <Kohane> ack
18:25:14 <adamw> #agreed 1446934 - AcceptedFreezeException (Final) - this fixes an issue in a non-blocking spin that would be a blocker in a blocking spin, and the fix is clearly limited to only affecting Sugar, so should be quite safe
18:25:45 <adamw> #info now taking a quick look at a couple of accepted freeze exceptions with fixes to get opinions on whether to include them in RC-1.4
18:25:50 <adamw> #topic (1506802) glibc: Fix regression in handling of x86_64 subdirectories in the ld.so search path
18:25:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1506802
18:25:50 <adamw> #info Accepted Freeze Exceptions, glibc, MODIFIED
18:25:55 <adamw> so i'm a bit leery of this one because...it's glibc
18:26:05 <adamw> however, it is claimed to restore things to how they were pre-f27...
18:26:52 <nirik> does it only have this fix?
18:26:53 * nirik looks
18:27:34 <nirik> yeah, just the one
18:29:02 <nirik> it's not clear how widespread this is...
18:29:15 <adamw> yeah. the bug talks about steam games, but it kinda feels like it maybe could affect more.
18:29:57 <nirik> and I would expect typically people would install then update before installing 3rd party games...
18:30:25 <adamw> so i don't really think i'm in a position to evaluate this super well, but my instinct is -1.
18:30:30 <adamw> well, not -1
18:30:33 <adamw> but just 'let's not pull it in'
18:30:42 * kparal looks up. what, steam games are broken? blocker!
18:30:46 <nirik> yeah. I lean the same way
18:30:49 <adamw> well, it's a library loader thing
18:30:52 <Kohane> nirik: Not if it's a gamer :-P
18:30:58 <adamw> presumably it *could* affect other stuff
18:31:04 <adamw> i'm just not sure what all things actually make use of this mechanism
18:31:14 <Kohane> I usually install the programmes I want/need first, and then update.
18:31:39 <Kohane> Because updating typically takes a lot of time so I want to be able to use the system in the meantime.
18:31:46 <nirik> sure, but even if you did it that way, you likely would try updating to fix it when it didn't work right?
18:31:53 <adamw> so, does anyone want to argue for pulling this in?
18:32:14 <kparal> nope
18:32:25 <Kohane> nirik:  Yeah, of course. If it doesn't work I update, at least the failing programme and see how it goes.
18:32:26 <nirik> not i
18:32:35 <adamw> okay.
18:32:47 <adamw> #info we're inclined not to pull this into RC-1.4 because...glibc
18:34:40 * adamw notes in passing that https://bugzilla.redhat.com/show_bug.cgi?id=1490632 makes him very sad, but doesn't look like we need to do anything about it now.
18:35:22 <adamw> #topic (1508706) No longer works with USB webcam 19ff:0103 , error "Tried to capture in BGR3, but device returned format YUYV"
18:35:22 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1508706
18:35:22 <adamw> #info Accepted Freeze Exceptions, v4l-utils, ON_QA
18:35:26 <adamw> so this is my webcam bug
18:35:43 <Kohane> Oh, I read about this one  in the mailing list.
18:35:51 <adamw> not sure i have a strong opinion on this, it's probably not gonna hurt anything to pull it in, but i'm not sure how useful it is either. handy to be able to use your webcam in a live session, i guess.
18:36:53 <nirik> nice to be able to test hardware...
18:37:48 <nirik> so, weak +1
18:38:09 <Kohane> Well, I guess that someone who uses the webcam a lot, will try it in a live session.
18:38:38 <adamw> any other opinions?
18:39:10 <nirik> I can easily see someone booting a live media on a laptop to test the hardware then assume the camera doesn't work... (but I guess this doesn't really affect any directly internal cameras, only usb externals?)
18:39:23 <Kohane> As for me, I rarely use webcam so it's not something that I test beforehand. It's not my first concern when installing an OS.
18:39:46 <Kohane> Oh, it's only for the external ones?
18:41:28 <Kohane> That explains why mine is working so far.
18:42:46 <puiterwijk> And I think only for specific external ones
18:43:20 <Zy3hZ2L8> just a little confused, isn't it such that being accepted FE it's already decided to include these?  where's the policy for re-reviewing them?
18:43:45 <nirik> not all FE's are included in composes no.
18:44:07 <nirik> It's up to QA which ones are decided are safe to do so.
18:44:15 <nirik> well, with input from everyone else
18:44:36 <Zy3hZ2L8> ok, i understand, especially for those with no karma
18:45:34 <adamw> yeah, i was just asking for informal input to aid the decision as to whether to pull these in
18:45:51 <adamw> Kohane: i don't think it's external vs. internal, it just affects...a few cameras. something to do with color space capability reporting, i think.
18:46:20 <adamw> #info we don't have terribly strong opinions on this, no-one's super enthusiastic about pulling it in or super opposed to it
18:46:25 <adamw> i'll just toss a coin or someting. :P
18:46:29 <adamw> ok, thanks for the input folks, that's all i had
18:47:17 <Kohane> adamw: Oh, okay. Thanks. I understand better now.
18:48:02 <Kohane> adamw:  Should we bet whether the coin falls number or face?
18:48:09 <Kohane> :-P
18:48:54 <Kohane> Now seriously, I'm not really enthusiastic about pulling it but OTOH I can't see a clear reason not to.
18:49:00 <puiterwijk> adamw: python's random.getrandbits(1) returned a "1". Does "1" mean pull or not pull? :)
18:50:23 <Kohane> I would understand it as  "pull"...
18:50:25 <adamw> puiterwijk: wow, that was unlucky - 1) means...
18:50:27 <adamw> .fire puiterwijk
18:50:27 <zodbot> adamw fires puiterwijk
18:51:37 <puiterwijk> Hah. Well, that was certainly unlucky
18:52:36 <adamw> #topic Open floor redux
18:53:52 <mboddu> adamw: When do you think we will have a new RC request?
19:00:16 <adamw> mboddu: in 15 mins or so.
19:00:20 <adamw> so, we're all done here?
19:01:02 * nirik thinks so
19:02:16 <adamw> mboddu: oh, puiterwijk seems to have something he wants to discuss before we do the compose, so maybe a bit longer.
19:02:20 * adamw sets the fuse
19:02:33 <adamw> thanks for coming to the MegaMeeting everyone, sorry we had to slip in the end :/
19:02:52 <frantisekz> thanks for chairing adam!
19:02:57 <Kohane> No worries. I was seeing it coming adamw
19:03:13 <adamw> well, we shared the chairing around a bit :)
19:03:15 <adamw> #endmeeting