17:00:03 <jkurik> #startmeeting F28 Beta Go/No-Go meeting
17:00:03 <zodbot> Meeting started Thu Mar 22 17:00:03 2018 UTC.  The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:03 <zodbot> The meeting name has been set to 'f28_beta_go/no-go_meeting'
17:00:05 <bowlofeggs> .hello2
17:00:06 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
17:00:09 <jkurik> #meetingname F28-Beta-Go-No-Go-meeting
17:00:09 <zodbot> The meeting name has been set to 'f28-beta-go-no-go-meeting'
17:00:11 <nirik> morning
17:00:16 <jkurik> #topic Roll Call
17:00:22 <jkurik> .hello jkurik
17:00:24 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
17:00:28 <jkurik> #chair nirik adamw sgallagh mboddu
17:00:28 <zodbot> Current chairs: adamw jkurik mboddu nirik sgallagh
17:00:44 <jkurik> hi everybody
17:00:50 <frantisekz> .hello2
17:00:51 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:00:57 <kparal> .hello2
17:00:58 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
17:01:22 <jkurik> #topic Purpose of this meeting
17:01:28 <jkurik> #info Purpose of this meeting is to check whether or not F28 Beta is ready for shipment, according to the release criteria.
17:01:34 <jkurik> #info This is determined in a few ways:
17:01:37 <sgallagh> .hello2
17:01:38 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:01:41 <jkurik> #info * No remaining blocker bugs
17:01:46 <jkurik> #info * Release candidate compose is available
17:01:53 <jkurik> #info * Test matrices for Beta are fully completed
17:01:59 <jkurik> #topic Current status
17:02:12 <jkurik> As far as I am aware, the RC for F28 Beta is not yet ready as there are several blockers:
17:02:25 <jkurik> https://qa.fedoraproject.org/blockerbugs/milestone/28/beta/buglist
17:02:26 <mboddu> .hello mohanboddu
17:02:27 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:02:33 <jkurik> As such, we do not have test matrices for the RC.
17:02:34 <nirik> spoiler alert: we are not going to be go today. ;)
17:02:38 <adamw> .hello adamwill
17:02:39 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:02:45 <jkurik> Anyone wants to add something ?
17:03:03 <x3mboy> .hello2
17:03:04 <zodbot> x3mboy: x3mboy 'Eduard Lucena' <eduardlucena@gmail.com>
17:03:10 <mattdm> .hello
17:03:11 <zodbot> mattdm: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
17:03:15 <mattdm> .hello2
17:03:16 <zodbot> mattdm: mattdm 'Matthew Miller' <mattdm@mattdm.org>
17:03:19 <nirik> it might be of use to do a quick blocker review so we can possibly make an rc in the next few days...
17:03:25 <jkurik> #info The RC for F28 Beta is not yet ready
17:03:33 <jkurik> #link https://qa.fedoraproject.org/blockerbugs/milestone/28/beta/buglist - F28 Blockers
17:03:43 <jkurik> #info As we have no RC there are subsequently no Test Matrices for the F28 Beta RC
17:03:44 <adamw> yeah, i was assuming we're going to do blocker review here.
17:03:51 <jkurik> Let's do at least Mini-blocker review
17:04:03 <jkurik> adamw: may I ask you please to chair the mini-blocker review ?
17:04:05 <jkurik> #topic Mini-Blocker Review
17:04:06 <adamw> sure.
17:04:10 <adamw> did you #chair me ?
17:04:11 <mboddu> I think everyone knows its no go, better do a blocker review
17:04:16 <jkurik> yes
17:04:33 <jkurik> adamw: yes, you have the chair
17:04:43 <adamw> thanks
17:04:53 <adamw> #topic (1558906) AttributeError: 'DiskDevice' object has no attribute 'isDisk'
17:04:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1558906
17:04:54 <adamw> #info Proposed Blocker, anaconda, ON_QA
17:06:01 <adamw> this is basically a showstopper for intel firmware raid, +1 for me
17:06:06 <nirik> +1 blocker
17:06:09 <adamw> i'm building an iso with both fixes for testing
17:06:17 <frantisekz> +1 Blocker I guess
17:06:24 <sgallagh> I voted +1 blocker in the ticket
17:06:36 <kparal> +1
17:06:41 <jkurik> +1
17:07:03 <bowlofeggs> +1 if i get a vote
17:07:12 <mboddu> +1 Blocker
17:07:14 <bowlofeggs> (do i get a vote? haha)
17:07:15 <sgallagh> bowlofeggs: Everyone gets a vote at blocker meetings
17:07:18 <bowlofeggs> ah cool
17:07:21 <sgallagh> It's consensus-based.
17:07:34 <adamw> there is a Highly Advanced Vote Counting Formula
17:07:44 <bowlofeggs> HAVCF
17:07:47 <x3mboy> +1
17:07:59 <adamw> it exists entirely in my head
17:08:01 <jsmith> +1 frome me
17:08:02 <adamw> and is impossible to document
17:08:36 <adamw> proposed #agreed 1558906 - AcceptedBlocker (Beta) - accepted as a violation of "The installer must be able to detect and install to hardware or firmware RAID storage devices"
17:08:37 <mboddu> bowlofeggs: like we dont have enough abbreviations :D
17:08:50 <sgallagh> ack
17:08:54 <jkurik> ack
17:08:59 <jsmith> ACK
17:09:08 <adamw> #agreed 1558906 - AcceptedBlocker (Beta) - accepted as a violation of "The installer must be able to detect and install to hardware or firmware RAID storage devices"
17:09:16 <adamw> #topic (1559180) hangs on launch
17:09:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1559180
17:09:17 <adamw> #info Proposed Blocker, anaconda, NEW
17:09:25 <frantisekz> just FYI, I'll secretalize (kparal said :D )
17:09:28 <adamw> so i'm just finishing my comment on this, but it's basically 'can't reproduce anyway'
17:09:32 <adamw> anywhere*
17:09:36 <adamw> thanks frantisekz
17:09:56 <adamw> so -1
17:10:00 <sgallagh> Yeah, I tried as well
17:10:01 <sgallagh> -1
17:10:07 <nirik> this is the memory thing?
17:10:14 <frantisekz> -1
17:10:23 <mboddu> If its specific hardware or some scenario then -1
17:10:24 <x3mboy> -1
17:10:25 <bowlofeggs> he said he had 3 GB
17:10:38 <bowlofeggs> not having tried it, i'm -1 due to failure to reproduce
17:10:45 <nirik> the virt def has 2gb
17:10:57 <nirik> <currentMemory unit='KiB'>2097152</currentMemory>
17:11:17 <adamw> he said later he tried with 3
17:11:23 <adamw> openqa uses 2 anyway, iirc, and that works
17:11:32 <nirik> huh.
17:11:33 <frantisekz> I've hit a similar issue, on 2gig of RAM but I did some dnf installs on the live media
17:11:42 <adamw> oh, yeah, that eats memory
17:11:51 <adamw> anything that changes the filesystem is applied to a memory overlay
17:12:10 <jkurik> -1
17:12:15 <x3mboy> If you install stuff in live media, they will go to memory, yes or yes
17:12:28 <adamw> note, it *does* look to me like something in the package stack is using more memory in f28
17:12:35 <adamw> from a quick look at some numbers this morning
17:12:41 <adamw> still, -1.
17:12:43 <kparal> the problem is probably packagekit running by default and downloading metadata
17:12:44 <nirik> -1 based on what we know, but might be good to isolate
17:13:00 <adamw> proposed #agreed 1559180 - RejectedBlocker (Beta) - no-one else is able to reproduce this in testing on various systems, so it does not appear to be a blocker
17:13:02 <nirik> kparal: I was thinking it might be because we don't have the preseeded cache
17:13:05 <frantisekz> ack
17:13:14 <bowlofeggs> ack
17:13:16 <mboddu> ack
17:13:17 <jkurik> ack
17:13:18 <kparal> ack
17:13:18 <sgallagh> ack
17:13:39 <adamw> kparal: even the installer images appear to use substantially more memory during early anaconda phase than f27 ones did
17:13:44 <adamw> but we should look into that manually and confirm
17:13:51 * adamw just checked openqa records
17:14:03 <nirik> is that anaconda memory graphing thing still in anaconda?
17:14:08 <adamw> #agreed 1559180 - RejectedBlocker (Beta) - no-one else is able to reproduce this in testing on various systems, so it does not appear to be a blocker
17:14:12 <adamw> nirik: yes. that's what openqa uses.
17:14:27 <nirik> nice. should be easy to see what and how it's spiking
17:14:37 <adamw> nirik: but the original logs from f27 final are lost unfortunately, i didn't have things set up to save them from garbage protection. some numbers can still be found in the compose check emails, though.
17:14:38 <adamw> nirik: yeah.
17:14:45 <adamw> well
17:14:51 <adamw> the log just shows 'anaconda' as using the memory
17:15:10 <adamw> this is because anaconda doesn't run dnf externally but imports it
17:15:13 <adamw> (i think)
17:15:21 <adamw> #topic (1557659) aacraid: Host adapter abort request
17:15:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1557659
17:15:21 <adamw> #info Proposed Blocker, kernel, NEW
17:15:22 <nirik> ah, thats not as helpfull as I remember it being
17:15:50 <adamw> nirik: it's useful when it's things that run *during the package install* that use memory
17:15:53 <adamw> as those things show up separate
17:15:59 <nirik> ok
17:16:15 <adamw> so, on this one, -1 since we appear to have a usable and document-able workaround
17:16:39 <nirik> -1 yeah
17:17:01 <mboddu> -1 then
17:17:09 <frantisekz> -1
17:17:11 <jkurik> -1
17:17:39 <sgallagh> -1
17:18:07 <bowlofeggs> -1
17:18:35 <adamw> proposed #agreed 1557659 - RejectedBlocker (Beta) - this is specific to one particular type of RAID adapter, and we have a reasonable workaround, so we don't consider this a serious enough violation to be a Beta blocker
17:18:45 <bowlofeggs> ack
17:18:50 <mboddu> ack
17:18:56 <frantisekz> ack
17:19:07 <adamw> #agreed 1557659 - RejectedBlocker (Beta) - this is specific to one particular type of RAID adapter, and we have a reasonable workaround, so we don't consider this a serious enough violation to be a Beta blocker
17:19:09 <jkurik> ack
17:19:15 <adamw> #topic (1559174) Locally-changed booleans not preserved on upgrade from F27 to F28, cannot be set permanently after upgrade
17:19:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1559174
17:19:15 <adamw> #info Proposed Blocker, policycoreutils, MODIFIED
17:19:23 <adamw> i'm going to submit the update for this soon, fwiw.
17:19:49 <nirik> +1 blocker
17:20:03 <sgallagh> +1, as noted in the ticket I am concerned that this would have other effects beyond how it was discovered
17:20:12 <frantisekz> +1
17:20:13 <adamw> i'm a weak +1, approx. same rationale as sgallagh
17:20:13 <bowlofeggs> +1
17:20:26 <bowlofeggs> i think this actually hit me but i didn't realize it
17:20:46 <bowlofeggs> i thougth maybe there was just a change to policy, didn't realize my bools had gotten switched
17:20:53 <mboddu> +1 Blocker
17:21:05 <adamw> yeah, it'd affect an awful lot of folks IRL, i think
17:21:08 <x3mboy> +1
17:21:14 <jkurik> +1
17:21:22 <kparal> +1
17:21:37 <adamw> proposed #agreed 1559174 - AcceptedBlocker (Beta) - accepted as a violation of the upgrade criteria applied to release-blocking server roles (as noted in the bug)
17:21:41 <mboddu> ack
17:21:43 <adamw> we really should propose that criteria change, sigh
17:21:45 <bowlofeggs> ack
17:21:52 <nirik> ack
17:21:57 <jkurik> ack
17:22:04 <sgallagh> adamw: Which change?
17:22:19 <frantisekz> ack
17:22:21 <adamw> sgallagh: to officially state that the upgrade requirements apply to release-blocking roles
17:22:34 <adamw> sgallagh: at present that's not really stated, though we agreed in 2017 that we thought it should be
17:23:01 <kparal> ack
17:23:06 <adamw> #agreed 1559174 - AcceptedBlocker (Beta) - accepted as a violation of the upgrade criteria applied to release-blocking server roles (as noted in the bug)
17:23:25 <adamw> should we also do the proposed freeze exceptions, or leave those for monday?
17:23:41 <sgallagh> adamw: Probably not worth bothering with now, with server roles going away
17:24:13 <adamw> sgallagh: eh...it's an easy tweak and it'd make us less likely to forget about it when revising the criteria for roles going away.
17:24:55 <sgallagh> Could we do https://bugzilla.redhat.com/show_bug.cgi?id=1466093 if only because it's got a build ready?
17:25:08 <adamw> i figure if we're gonna do one let's just do 'em all
17:25:10 <adamw> there's only 4
17:25:17 <adamw> #info doing proposed freeze exceptions quickly
17:25:22 <jkurik> adamw: ok. go on
17:25:24 <adamw> 4, 5...they're close
17:25:29 <adamw> #topic (1559188) Failed to initialize security module
17:25:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1559188
17:25:29 <adamw> #info Proposed Freeze Exceptions, abrt, NEW
17:26:10 <adamw> seems reasonable to ease crash reporting from lives
17:26:24 <nirik> yeah, +1 FE
17:26:26 <kparal> we should have a criterion that bug reporting has to work, right?
17:26:27 <bowlofeggs> +1 FE
17:26:37 <frantisekz> +1
17:26:41 <adamw> kparal: there's a criterion for reporting installer crashes
17:26:51 <adamw> not for post-install, i think on the theory 'we can fix that with updates'
17:26:54 <jkurik> +1 FE
17:26:56 <mboddu> +1 FE
17:27:14 <x3mboy> +1
17:27:25 <kparal> ok
17:27:40 <adamw> proposed #agreed 1559188 - AcceptedFreezeException (Beta) - this would ease reporting of crashes on live images, and immediately after install
17:27:42 <kparal> so how do you report crashed anaconda from Live?
17:27:49 <kparal> without FAF
17:28:00 <adamw> kparal: anaconda uses a different flow, i think
17:28:06 <adamw> it's still libreport, but...different
17:28:08 <bowlofeggs> ack
17:28:11 <jkurik> ack
17:28:12 <mboddu> ack
17:28:12 <kparal> alright
17:28:15 <kparal> ack
17:28:16 <frantisekz> ack
17:28:41 <adamw> kparal: i mean, if you want to test it, please do :) don't think i have
17:28:45 <adamw> #agreed 1559188 - AcceptedFreezeException (Beta) - this would ease reporting of crashes on live images, and immediately after install
17:28:53 <adamw> #topic (1557511) annobin: failure building wxGTK3 in F28
17:28:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1557511
17:28:54 <adamw> #info Proposed Freeze Exceptions, annobin, ON_QA
17:29:52 <adamw> i ran into this weeks ago, in fact
17:29:58 <adamw> thought i'd filed a bug but having trouble finding it
17:30:10 <bowlofeggs> does this need an FE when we have BROs?
17:30:19 <bowlofeggs> (build root overrides ☺)
17:30:21 <sgallagh> Not particularly, no
17:30:36 <adamw> well, in theory no, but then, i don't like the inconsistency bros cause
17:30:47 <adamw> if we build something for beta with a package that's not *in* beta itself, that kinda sucks
17:30:52 <bowlofeggs> i could see an argument for FE
17:30:54 <nirik> well, also, can't we just do this after beta is in the can?
17:30:57 <bowlofeggs> because we'll need a long-term BRO otherwise
17:31:07 <adamw> this is kind of a generic issue with BROs, admittedly.
17:31:41 <bowlofeggs> i do dislike the inconsistency i feel when i hang out with too many bros…
17:31:48 <adamw> haha
17:31:57 <bowlofeggs> i would +0 FE
17:31:58 <sgallagh> If only we had some sort of mechanism that would allow us to set BROs for individual builds. We could call these builds "modules"...
17:32:02 <adamw> so, i mean, i'm kinda a weak +1 just for consistency between buildroot and beta compose
17:32:05 <adamw> sgallagh: =)
17:32:09 <bowlofeggs> not opposed, but also i don't see a strong case for
17:32:13 <adamw> sgallagh: (or, you know, tags)
17:32:14 <mboddu> sgallagh: :D
17:32:49 <sgallagh> annobin isn't in any of the default installs, right?
17:32:56 <sgallagh> It's really only a build-time dep
17:33:05 <adamw> no idea. i'd guess not.
17:33:33 <sgallagh> Which would make it functionally irrelevant if it was in stable vs. BRO
17:33:42 <adamw> not really, it'd be in Everything for beta.
17:34:02 <sgallagh> Right, but if it's only ever a build-time dep, what's the problem?
17:34:04 <adamw> if anyone treats the Beta as an artefact, it's inconsistent. it's a small point.
17:34:26 <adamw> it's not like our releases are very reproducible really anyway, but every little helps. :P
17:34:35 <adamw> just vote something and let's move on?
17:35:18 <bowlofeggs> so far nobody is -1
17:35:22 <nirik> I guess weak +1
17:35:24 <bowlofeggs> so we could just allow it a FE
17:35:58 <adamw> bowlofeggs: oh, i forgot, the basic element of the Highly Sophisticated Voting Algorithm is that it always needs at least +3
17:35:59 <jkurik> I do not really know, so I am +0
17:36:00 <adamw> (or -3)
17:36:21 <adamw> so everyone gets to sit around till we have at least three votes in either direction, or i get bored and propose we just punt it. :P
17:36:43 <mboddu> adamw: How about +0.5 FE? :)
17:36:56 <adamw> in theory we're supposed to require a vote from QA, one from releng and one from devel, i think, but several years ago i decided that we all plausibly represent all three anyway, so any old vote will do. :P
17:37:12 <adamw> mboddu: welp, now we're at +2.5...:P
17:37:13 <sgallagh> I'm +1 on the grounds that it will likely stay in the buildroot anyway
17:37:17 <sgallagh> So might as well be consistent'
17:37:24 <nirik> zenos paradox of FE...
17:37:30 <nirik> 2.999999999999
17:37:53 <adamw> proposed #agreed 1557511 - AcceptedFreezeException (Beta) - this is accepted as a freeze exception on the basis it's needed to build some packages, and pulling it in as an FE rather than using a buildroot override keeps the contents of the composes more consistent
17:38:04 <mboddu> ack
17:38:06 <nirik> ack
17:38:08 <jkurik> ack
17:38:14 <frantisekz> ack
17:38:22 <adamw> #agreed 1557511 - AcceptedFreezeException (Beta) - this is accepted as a freeze exception on the basis it's needed to build some packages, and pulling it in as an FE rather than using a buildroot override keeps the contents of the composes more consistent
17:38:22 <sgallagh> ack
17:38:47 <adamw> .fire sgallagh late acks will be punished
17:38:47 <zodbot> adamw fires sgallagh late acks will be punished
17:38:53 <adamw> #topic (1466093) Decommissioning domain controller role fails when role deployed on Fedora 25 then system upgraded to Fedora 26
17:38:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1466093
17:38:53 <adamw> #info Proposed Freeze Exceptions, firewalld, MODIFIED
17:39:14 <adamw> hum, i should update that topic.
17:39:45 <bowlofeggs> adamw: haha
17:39:52 <sgallagh> The real problem here is a bug in firewalld that cannot handle removing firewall services with overlapping entries
17:39:54 <adamw> true summary is "Decommissioning domain controller role fails if system is rebooted after deployment (due to firewalld bug)"
17:40:02 <nirik> +1 FE.
17:40:09 <sgallagh> In this case, "freeipa-ldap" and "freeipa-ldaps"
17:40:18 <sgallagh> +1 FE, as I said in the ticket
17:40:27 <jkurik> +1 FE as well
17:40:30 <adamw> well
17:40:33 <mboddu> +1 FE
17:40:37 <adamw> there's an argument that, why does it need to go in the compose
17:40:41 <frantisekz> +1 FE
17:40:45 <adamw> since it requires a reboot, the system *really* ought to get updated
17:40:54 <adamw> putting it in the compose basically helps openQA and not much else.
17:41:27 <adamw> since the update is a whole new version of firewalld...
17:42:09 <adamw> should we really pull it in?
17:42:46 <sgallagh> adamw: https://www.firewalld.org/2018/03/firewalld-0-5-2-release
17:42:55 <sgallagh> Looks like a pretty constrained bugfix release
17:42:56 <jkurik> adamw: I would say that for beta we can take the risk
17:43:55 <adamw> ok, then
17:44:30 <adamw> proposed #agreed 1466093 - AcceptedFreezeException (Beta) - decommissioning isn't actually part of the release criteria, but is a significant function of server roles, and pulling this in will improve openQA test coverage
17:44:38 <mboddu> ack
17:44:40 <frantisekz> ack
17:44:42 <jkurik> ack
17:45:25 <sgallagh> ack
17:45:50 <kparal> ack
17:46:53 <jsmith> ACK
17:48:27 <adamw> #agreed 1466093 - AcceptedFreezeException (Beta) - decommissioning isn't actually part of the release criteria, but is a significant function of server roles, and pulling this in will improve openQA test coverage
17:48:35 <adamw> #topic (1546743) gfortran internal compiler error when compiling cp2k-5.1 on ppc64le
17:48:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1546743
17:48:35 <adamw> #info Proposed Freeze Exceptions, gcc, NEW
17:51:33 <jkurik> hmm... I am not sure how many people will be affected by a bug in fortran compiler
17:51:34 <adamw> well, everyone saw 'fortran' and immediately passed out, it seems
17:51:38 * adamw goes around with the smelling salts
17:52:13 <jkurik> but as it might affect c++ (if I understand the comment from Jakub) then I am +1 FE
17:52:24 <frantisekz> :D (adam, go ahead and do rand(-1,1) for a few times and you have your votes)
17:52:30 <adamw> i mean, i guess, to be consistent with the previous one, +1.
17:52:32 <mboddu> jkurik: And also only on ppc64le arch
17:52:55 <jkurik> ah, right; ppc64le only
17:52:57 <adamw> they apparently haven't actually submitted an update for this, though.
17:53:36 <mboddu> So, I am soft -1, just because its fortran and just ppc64le
17:54:54 * mattdm notes that fortran is still very important to scientific computing
17:55:55 <adamw> i mean, since this has a BRO already thus anything we pull in will be built with it anyway, i'd say +1 for the consistency argument
17:56:06 <sgallagh> Yeah, I'm fine with adamw's perspective. +1
17:56:08 <adamw> well...the bro expired
17:56:12 <nirik> well, some people may want to try beta for building their stuff too
17:56:14 <adamw> it was in force from 03-16 to 03-20
17:56:31 <adamw> so anything built between those dates that we pulled in, was built with it
17:56:36 <adamw> anything built since was built with the old one again
17:56:37 <adamw> yay consistency
17:56:47 <mboddu> adamw: Yeah, just realized its BRO, so +1
17:56:48 <nirik> so, yeah, +1 FBR
17:57:56 <adamw> proposed #agreed 1546743 - AcceptedFreezeException (Beta) - accepted on the same principle as the annobin bug (1557511) - buildroot/compose consistency
17:57:59 <mboddu> ack
17:58:03 <nirik> ack
17:58:06 <jkurik> ack
17:58:14 <frantisekz> ack
17:59:06 <adamw> #agreed 1546743 - AcceptedFreezeException (Beta) - accepted on the same principle as the annobin bug (1557511) - buildroot/compose consistency
17:59:14 <adamw> last one:
17:59:14 <adamw> #topic (1558510) "Star" feature missing in Nautilus
17:59:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1558510
17:59:14 <adamw> #info Proposed Freeze Exceptions, nautilus, NEW
17:59:46 <jsmith> What's the critereon for this one?
17:59:46 <adamw> eh, seems like there may even be no bug here?
17:59:56 <adamw> jsmith: it's a proposed FE, there are no criteria for FEs.
18:00:11 <adamw> just https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process#Freeze_exception_bug_principles
18:00:23 <jkurik> jsmith: every app needs to have at least one star
18:00:32 <jsmith> Ah, right... silly me.
18:00:35 <jsmith> -1 to FE
18:00:57 <jsmith> Can easily be dealth with after the freeze, if there's anything to be done
18:01:13 <sgallagh> -1
18:01:20 <kparal> -1, not even clear whether this is a bug, no fix ready
18:01:22 <sgallagh> It's not even clear that this is a bug
18:01:23 <nirik> is this touted as a gnome feature with the new release?
18:01:37 <nirik> yeah, pretty unclear
18:01:54 <nirik> -1 for now
18:01:57 <jkurik> -1 FE
18:02:19 <mboddu> -1 for now, probably fixed by an update
18:02:32 <adamw> well, we can't fix it on the live image with an update, of course
18:02:42 <adamw> and presumably the idea is people may use the live to showroom gnome 3.28
18:03:03 <mboddu> adamw: Ah right
18:03:17 <adamw> if people are voting -1 on the basis that it's not clear if there's actually a bug, how about we just punt to clarify that?
18:03:25 <adamw> it'll come up again at monday's meeting and hopefully should be clear by then
18:03:35 <jkurik> adamw: ack
18:03:53 * nirik nods
18:03:54 <mboddu> adamw: Better, +1 punt
18:04:07 <sgallagh> fine
18:04:54 <adamw> proposed #agreed 1558510 - punt (delay decision) - we suspect there's actually no bug here, but we agreed to just punt it till Monday's meeting, hopefully by then it'll be clear whether there's actually a bug and it merits FE status
18:05:00 <mboddu> ack
18:05:07 <jkurik> ack
18:05:08 <frantisekz> ack
18:05:09 <kparal> ack
18:05:12 <nirik> ack
18:05:21 <adamw> #agreed 1558510 - punt (delay decision) - we suspect there's actually no bug here, but we agreed to just punt it till Monday's meeting, hopefully by then it'll be clear whether there's actually a bug and it merits FE status
18:05:25 <adamw> OK, that's all the proposals
18:05:26 <adamw> thanks folks
18:05:33 <jkurik> #topic Test Matrices coverage
18:05:37 <jkurik> #info As there is no RC yet, Test matrices are not ready as well
18:05:43 <jkurik> #info We are skipping the Test Matrices coverage check
18:05:49 <jkurik> #topic Go/No-Go decision
18:06:01 <jkurik> proposed #agreed Due to missing RC for the F28 Beta release and presence of blocker bugs, the decision is “No Go”. The Beta release slips for one week to “Target #1” date (April 3rd). We are not going to slip the Final GA yet.
18:06:32 <jkurik> nirik, mboddu, adamw, and other folks ^^^
18:06:44 <nirik> yep. ack
18:06:45 <jsmith> +1 from me
18:06:47 <frantisekz> ack
18:07:20 <kparal> ack
18:07:36 <mboddu> ack
18:07:50 <jkurik> #agreed Due to missing RC for the F28 Beta release and presence of blocker bugs, the decision is “No Go”. The Beta release slips for one week to “Target #1” date (April 3rd). We are not going to slip the Final GA yet.
18:07:56 <adamw> sure
18:07:59 <jkurik> #action jkurik to publish the Go/No-Go result
18:08:07 <jkurik> #action jkurik to organize second round of Go/No-Go meeting for F28 Beta on Thursday, March 29th at 17:00UTC
18:08:12 <jkurik> #topic Open floor
18:08:18 <jkurik> anything else to discuss today on this meeting ?
18:08:29 <sgallagh> I'd like to note that the status on Blocker fixes is moving ahead really well, so next week seems favorable
18:09:12 <mboddu> sgallagh: Yeah, we are in a far better shape than we were 2 weeks before
18:09:12 <nirik> oh man, now you jinxed it! :)
18:09:51 <adamw> hum
18:09:54 <adamw> actually i'd like to propose another FE
18:10:01 * mboddu proposes the usage of "yak" instead of "ack" to make adamw happy :)
18:10:14 <sgallagh> nak ;-)
18:10:26 <jkurik> adamw: for Monday ?
18:10:38 <adamw> now, if possible
18:10:38 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1559341
18:10:49 <adamw> it's proposed as a final blocker, but feels like something we should fix for beta
18:10:55 <adamw> and there's an selinux-policy that fixes it in koji
18:11:18 <nirik> ah yeah, Ihit that
18:11:21 <nirik> +1 FE
18:11:26 <jkurik> #topic SELinux blocks bluetooth from working
18:11:30 <sgallagh> Yeah, I can get behind that
18:11:33 <jkurik> #link https://bugzilla.redhat.com/show_bug.cgi?id=1559341
18:11:53 <sgallagh> (Didn't we have a proposal to treat blockers for future releases as presumed FEs for current ones?)
18:12:07 <nirik> it's really anoying in gnome at least... interface wise.
18:12:09 <sgallagh> FE doesn't mean we *have* to take it
18:12:10 <adamw> i'm not sure we did, and if it was proposed, i don't think i'd agree.
18:12:39 <jkurik> +1 FE
18:12:43 <frantisekz> +1 FE
18:12:50 <mboddu> +1 FE
18:12:57 <sgallagh> +1 FE, in case it was unclear
18:13:29 <adamw> proposed #agreed 1559341 - AcceptedFreezeException (Beta) - this is a significant functionality issue that will affect lives etc., would be good to fix it for the compose
18:13:33 <mboddu> ack
18:13:41 <jkurik> ack
18:13:43 <mboddu> We have a fix, then why not include it in beta itself
18:13:44 <frantisekz> ack
18:14:08 <adamw> #agreed 1559341 - AcceptedFreezeException (Beta) - this is a significant functionality issue that will affect lives etc., would be good to fix it for the compose
18:14:22 <jkurik> thanks adamw
18:14:23 <adamw> thanks
18:14:35 <jkurik> anything else for the meeting today ?
18:14:49 <jkurik> otherwise I will close the meeting in a minute...
18:15:03 <mboddu> adamw: Thanks
18:15:27 <frantisekz> thanks adam
18:15:34 <adamw> nah, just that we're trying to get everything fixed and get to an rc.
18:16:03 <nirik> it would be lovely to get an rc tomorrow before the weekend.
18:16:19 <jkurik> Thank you all folks for being here and lets meet in 45mins on Readiness (some of us).
18:16:25 <jkurik> #endmeeting