17:01:19 <bcotton> #startmeeting F30 Final Go/No-Go meeting
17:01:19 <zodbot> Meeting started Thu Apr 25 17:01:19 2019 UTC.
17:01:19 <zodbot> This meeting is logged and archived in a public location.
17:01:19 <zodbot> The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:19 <zodbot> The meeting name has been set to 'f30_final_go/no-go_meeting'
17:01:21 <bcotton> #meetingname F30-Final-Go_No_Go-meeting
17:01:21 <zodbot> The meeting name has been set to 'f30-final-go_no_go-meeting'
17:01:25 <bcotton> #topic Roll Call
17:01:31 <nirik> morning
17:01:38 <frantisekz> .hello2
17:01:39 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:01:45 <mkonecny> .hello zlopez
17:01:46 <coremodule> .hello2
17:01:46 <lbrabec> .hello2
17:01:46 <zodbot> mkonecny: zlopez 'Michal Konečný' <michal.konecny@packetseekers.eu>
17:01:49 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
17:01:52 <zodbot> lbrabec: lbrabec 'Lukas Brabec' <lbrabec@redhat.com>
17:01:54 <coremodule> Good morning bcotton
17:01:56 <mboddu> .hello mohanboddu
17:01:57 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:02:02 <Lailah> hello lailah
17:02:08 <Lailah> fas lailah
17:02:23 <Lailah> .fas lailah
17:02:26 <zodbot> Lailah: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
17:02:28 <pwhalen> .hello2
17:02:30 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
17:03:03 <dmoluguw> .hello2
17:03:04 <zodbot> dmoluguw: dmoluguw 'Dinesh Prasanth Moluguwan Krishnamoorthy' <dmoluguw@redhat.com>
17:03:05 <sgallagh> .hello2
17:03:05 <adamw> .hello adamwill
17:03:07 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:03:10 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:03:18 <cverna> greetings
17:03:29 * Lailah waves to all
17:03:43 * satellit listening
17:03:55 * mhroncok lurking
17:04:24 <bcotton> okay, i'll get through the copypasta as folks come on
17:04:32 <bcotton> #topic Purpose of this meeting
17:04:34 <bcotton> #info Purpose of this meeting is to check whether or not F30 is ready for shipment, according to the release criteria.
17:04:35 <bcotton> #info This is determined in a few ways:
17:04:40 <bcotton> #info 1. No remaining blocker bugs
17:04:41 <bcotton> #info 2. Release candidate compose is available
17:04:43 <bcotton> #info 3. Test matrices for Beta are fully completed
17:04:45 <bcotton> so!
17:04:51 <bcotton> #topic Current status — blocker bugs
17:04:52 <bcotton> #link https://qa.fedoraproject.org/blockerbugs/milestone/30/final/buglist
17:05:05 <mboddu> bcotton: "#info 3. Test matrices for Beta are fully completed"?
17:05:18 <bcotton> mboddu: d'oh
17:05:20 <bcotton> #undo
17:05:20 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f7e60145790>
17:05:23 <bcotton> #undo
17:05:23 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f7e5fae0c10>
17:05:27 <bcotton> #undo
17:05:27 <zodbot> Removing item from minutes: INFO by bcotton at 17:04:43 : 3. Test matrices for Beta are fully completed
17:05:35 <bcotton> #info 1. No remaining blocker bugs
17:05:37 <bcotton> #info 2. Release candidate compose is available
17:05:38 <bcotton> #info 3. Test matrices for Final are fully completed
17:05:46 <mboddu> bcotton: Just saying, I am not shipping beta again ;)
17:05:56 <bcotton> mboddu: why not? all the work is already done :-D
17:05:59 <bcotton> #topic Current status — blocker bugs
17:06:00 <bcotton> #link https://qa.fedoraproject.org/blockerbugs/milestone/30/final/buglist
17:06:15 <bcotton> #info 3 Proposed Blockers
17:06:17 <bcotton> #info 1 Accepted Blockers
17:06:24 <bcotton> so let's review
17:06:28 * adamw is juggling here
17:06:38 <bcotton> #topic (1702419) toolbox does not work in F30
17:06:40 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1702419
17:06:41 <bcotton> #info Proposed Blocker, buildah, ASSIGNED
17:07:19 <sgallagh> As noted in the BZ, this issue doesn't affect a blocking desktop. It is worth fixing as an FE if we end up slipping for any other reason
17:07:31 <bcotton> silverblue isn't a blocking deliverable, so that makes it an easy call imo
17:07:33 <sgallagh> -1 blocker / +1 FE
17:07:37 <adamw> yeah, this is straightforward, -1 blocker, +1 FE
17:07:42 <bcotton> -1 blocker, +1 FE
17:07:44 <mboddu> -1 Blocker, +1 FE
17:07:47 <nirik> -1 B/+1FE yeah
17:07:49 <frantisekz> -1B, +1 FE
17:07:53 <pwhalen> -1 Blocker, +1 FE
17:07:53 <lbrabec> -1B/+1FE
17:08:01 <Lailah> -1 Blocker +1 FE
17:08:23 <mkonecny> -1B/+1FE
17:09:08 <mkonecny> bcotton: Why Silverblue is not blocking?
17:09:18 <jlanda> -1b +fe
17:09:29 <sgallagh> mkonecny: Because the Workstation WG has never listed it as blocking.
17:09:31 <bcotton> mkonecny: because no one ever proposed to make it a blocker, i guess
17:09:43 <mkonecny> ok, thanks
17:09:44 <adamw> it's not really ready to be the primary desktop, i don't think.
17:09:50 <adamw> whenever desktop team thinks it is, they can propose it.
17:09:52 * nirik nods
17:09:56 <adamw> bcotton: next comes proposed agreed =)
17:09:59 <bcotton> proposed #agreed 1702419 - RejectedBlocker(Final), AcceptedFreezeException(Final) - Silverblue is not a blocking deliverable, but it would be good to have this fixed
17:10:05 <mboddu> ack
17:10:05 <bcotton> adamw: yep, just have to type :-)
17:10:12 <sgallagh> ack
17:10:14 <jlanda> And toolbox is essential on silverblue.  But wks?
17:10:14 <lbrabec> ack
17:10:16 <Lailah> ack
17:10:17 <jlanda> ack
17:10:22 <nirik> ack
17:10:41 <bcotton> #agreed 1702419 - RejectedBlocker(Final), AcceptedFreezeException(Final) - Silverblue is not a blocking deliverable, but it would be good to have this fixed
17:10:41 <mkonecny> jlanda: I don't use it that much, but it's nice
17:10:41 <adamw> ack
17:10:50 * jlanda just reached hone from a 10h roadtrip and there is enough quorum to vote, I'll be semi afk
17:10:50 <pwhalen> ack
17:11:01 <adamw> jlanda: take it easy!
17:11:02 <bcotton> #topic (1703152) initial-setup fails with no network - AttributeError: 'NoneType' object has no attribute 'upper'
17:11:04 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1703152
17:11:05 <bcotton> #info Proposed Blocker, initial-setup, NEW
17:11:16 <adamw> so this showed up this morning
17:11:21 <adamw> pwhalen and I are digging into it right now
17:11:22 <nirik> so, the question here is how widespread this is... just no network armv7?
17:11:25 <adamw> we are not yet sure how common it will be
17:11:46 <pwhalen> this is an aarch64 board, the pine64_plus. It does not affect the rpi3
17:11:59 <sgallagh> Is it a race?
17:12:25 <pwhalen> I dont know how common it is, I usually test with network connected. dgilmore found it this morning
17:12:33 <sgallagh> Does it ever happen with network connected?
17:12:34 <pwhalen> with network, initial-setup starts
17:12:39 <mkonecny> It looks like missing brackets
17:12:42 <pwhalen> sgallagh, not that I have seen
17:12:52 <sgallagh> If not, I'm inclined to deny this as a blocker and just Common Bugs it
17:13:00 <pwhalen> sgallagh, me too
17:13:07 <jlanda> +1 commonbugs
17:13:31 <dgilmore> sgallagh: I suspect that rpi works only because of wifi, anything without wifi I expect will not work without a network cable plugged in
17:13:33 <Lailah> I think it's a blocker but I'm not sure if it only affects one architecture or if it's widespread
17:13:35 <pwhalen> but I dont know if it affects more than arm, like an anaconda install with no network, there was a similar issue in beaker as noted in the bug
17:13:43 <bcotton> for beta, i'd be absolutely on board with rejectedblocker, commonbugs. but for final, i'm only like 75%?
17:13:44 * mboddu has couple of pine64_plus boards sitting at home though
17:13:46 <adamw> mkonecny: missing brackets?
17:14:06 <sgallagh> pwhalen: I can do a quick test in a VM without network. Hang on
17:14:07 <dgilmore> it should effect any system with no network plugged in and running initial-setup
17:14:19 <adamw> dgilmore: i'm not sure that's right.
17:14:28 <adamw> dgilmore: the code is looking for a mac address, effectively.
17:14:35 <adamw> it should be able to get one whether or not the device is plugged into a network.
17:14:45 <mkonecny> adamw: My mistake, I only noticed the missing attribute upper
17:14:48 <adamw> also anaconda calls the same thing
17:14:49 <mhroncok> so it hits devices without a network interface?
17:15:06 <pwhalen> adamw, and the other bug was in anaconda , noted at the bottom
17:15:10 <adamw> so we need to know whether this might affect anaconda. though the anaconda codepath is less new.
17:15:19 <jlanda> We just know a device thst hits, another one that don't hit mhroncok
17:15:22 <adamw> there's a lot of unknowns here, basically...
17:15:49 <adamw> the worst case, i guess, is if networkmanager has started returning None for this in some situation where it previously didn't.
17:15:49 <nirik> yeah, so perhaps we should delay a bit and explore it and defer go/nogo for a bit to do that?
17:16:04 <jlanda> Yeah
17:16:06 <Lailah> I think that's a good idea
17:16:08 <mboddu> nirik: +1
17:16:16 <sgallagh> FWIW, it appears to install fine on x86_64 via anaconda with no network devices installed in a VM
17:16:37 <adamw> sgallagh: i'd expect that, because there's no network device to have or not have an hwaddr property in that case. :P
17:16:56 <jlanda> The test needs a card, but no cable
17:17:00 <adamw> the affected case is not 'no network device' but 'network device present but not connected to a network'. but that's not hte whole story for sure
17:17:02 <sgallagh> ok, retrying
17:17:07 <jlanda> Or a broken one might work too
17:17:14 <adamw> since we know at least one other ARM system with device present but not connected to network works
17:17:43 <bcotton> should we continue discussing this or come back to it after reviewing the other blockers?
17:17:51 <jlanda> +1
17:17:52 <adamw> sgallagh: also, might be an idea to do a KDE install without creating a user so you get initial-setup on first boot...
17:17:58 <sgallagh> bcotton: Are there other blockers to discuss?
17:17:59 <adamw> i'd help, only i'm also trying to test two other things at the same time...
17:18:02 <adamw> sgallagh: there aer
17:18:11 <sgallagh> I'll pull the KDE installer as well, then
17:18:20 <coremodule> bcotton, newly proposed blocker here... sorry!
17:18:20 <Lailah> adamw:  Is that possible in KDE?
17:18:35 <coremodule> .bug 1670396
17:18:36 <zodbot> coremodule: 1670396 – KSieve fails to start - https://bugzilla.redhat.com/1670396
17:18:40 <adamw> Lailah: is what possible in KDE?
17:18:49 <adamw> coremodule: it's OK, i'm refreshing blockerbugs right now
17:18:56 <Lailah> adamw: Last time I forgot to create a user in KDE it just failed to login.
17:18:57 <coremodule> oh cool
17:18:58 <adamw> bcotton: reload your blockerbugs tab
17:19:16 <adamw> Lailah: if you don't create a user during install, then initial-setup should run on first boot.
17:19:25 <bcotton> we're going the wrong way!
17:19:38 <bcotton> #info We'll move on to the other blocker bugs and come back to this one
17:19:43 <Lailah> adamw:  Oh. Okay.
17:19:53 <Lailah> bcotton: okay
17:19:55 <bcotton> #topic (1670396) KSieve fails to start
17:19:57 <Lailah> Sorry
17:19:57 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1670396
17:19:58 <bcotton> #info Proposed Blocker, pim-sieve-editor, NEW
17:20:24 <jlanda> We banned the wrong guy, poor kparal, handcuffed and all, and the guilt one is coremodule
17:20:28 <Lailah> It's a blocker to me.
17:20:36 <Lailah> jlanda: LOL
17:20:45 <Lailah> Free kparal !
17:21:20 <nirik> and of course thats in the default menus?
17:21:26 <coremodule> nirik, yes
17:21:41 * nirik sighs
17:21:45 <bcotton> dang. is that new? I don't see it in my F29 KDE machine
17:21:53 <bcotton> doesn't matter, i guess
17:22:09 <adamw> well
17:22:18 <adamw> there is a potential argument to waive this, if we really want to release
17:22:21 <bcotton> nevermind anyway, i found it
17:22:23 <coremodule> only just tested for it this morning, but it's there on the beta... dunno why it didnt get proposed earlier, but... this is what we've got!
17:22:24 <nirik> I guess it's a blocker... by critera.
17:22:25 <bcotton> adamw: i'm listening
17:22:35 <adamw> let me find the receipts
17:22:38 <coremodule> adamw, the fact that it was proposed two months ago and no one has found it until now?
17:22:51 <Lailah> nirik:  To me is a blocker
17:23:19 <bcotton> coremodule: the fact that it wasn't proposed before the start of the meeting :p
17:23:34 <Lailah> I don't have pim-sieve-editor but maybe that's because I deleted Kontakt long ago.
17:23:42 * mboddu agrees with nirik
17:24:08 <adamw> well dang it now i can't find it
17:24:11 <adamw> bcotton: basically that
17:24:32 * nirik wonders if there's enough kde sig cycles these days to keep kde release blocking... I know rex is pretty busy
17:24:40 <adamw> gah
17:24:43 <coremodule> bcotton, ahhhh! a loophole! you must have worked in law before!
17:24:48 <bcotton> nirik: that's a can of worms we're not opening today :p
17:24:51 <Lailah> adamw: What happened?
17:24:52 <sgallagh> I'm really not convinced that a mail filter editor is critical functionality for the desktop
17:24:56 <nirik> sure, just musing.
17:25:02 <adamw> i know we agreed some wording at some point regarding considering timeframes when deciding on blocker status
17:25:04 <adamw> but i can't find it
17:25:16 <adamw> sgallagh: the basic justification for this criterion is that it's a polish criterion
17:25:28 <bcotton> nirik: fwiw, i think that is a question for us to ask
17:25:28 <adamw> if we're shipping something in the default menus it ought to work, because people click around on stuff
17:25:30 <frantisekz> sgallagh++
17:25:32 <zodbot> frantisekz: Karma for sgallagh changed to 17 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:25:49 <adamw> "remove the package from the image" is always considered an acceptable solution to violations of this criterion
17:25:58 <adamw> anyway, so, the point here is: this was apparently discovered in february
17:25:59 <jlanda> yep
17:26:01 <pwhalen> it might not have been proposed because of time constraints. People generally dig in for an RC
17:26:02 <adamw> but was not proposed as a blocker then
17:26:29 <sgallagh> Put another way, if this is the sole reason we'd slip, I'd be quite annoyed by it.
17:26:38 <adamw> if i could find that damn policy, i'm sure it says something about blockers being proposed in a reasonable time frame...
17:26:43 <Lailah> sgallagh: agree
17:26:46 <adamw> january, even
17:26:52 <coremodule> adamw, was it in a blocker meeting or on the lists?
17:27:01 <adamw> no, but that's kinda the point
17:27:12 <adamw> since we knew about this in january, why didn't we propose it as a blocker until just now?
17:27:21 <bowlofeggs> would it be difficult to remove from the image?
17:27:27 <adamw> no, but it requires a respin
17:27:31 <bowlofeggs> yeah
17:27:38 <bowlofeggs> and that's difficult in itself ☺
17:27:42 <jlanda> remove, fire rc2 and delay the go/no-go to tomorrow like in bet? Is just a package removal
17:27:44 <adamw> i mean, not difficult, but time consuming
17:28:00 <bowlofeggs> yah
17:28:07 <bowlofeggs> i think that seems reasonable
17:28:11 <sgallagh> Is it a leaf package?
17:28:13 <bcotton> but i have lunch plans tomorrow :-(
17:28:23 <adamw> ok, so the policy i'm thinking about is "Blocker bug process proposal: waiving late-discovered blockers to next release"
17:28:31 <adamw> that was a mailing list thread from 2017
17:28:38 <bowlofeggs> proposal: cancel bcotton's calendar for the next 24x7
17:28:49 <Lailah> That's a bit too old, adamw , isn't it?
17:28:53 <adamw> well
17:29:00 <adamw> i'm trying to figure out if we actually agreed to put that into production
17:29:01 <bcotton> bowlofeggs: you wouldn't like me when i'm hangry
17:29:06 <bowlofeggs> haha
17:29:12 <frantisekz> I would love to see this one waived ...
17:29:20 <adamw> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/Q46M75GUKRHMI5IMNGBNL6XHLD5GLLTS/
17:29:34 <bcotton> #link https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/Q46M75GUKRHMI5IMNGBNL6XHLD5GLLTS/
17:29:46 <sgallagh> adamw: My read of that thread (just found it too) is that we basically left it a judgement call.
17:30:05 <jlanda> Partial composing would be great for this :(
17:30:09 <nirik> I'd be ok waving this on the 'not proposed in time nor did anyone care about it for months'
17:30:23 <adamw> it seems i wrote a second draft of this policy and then...never actually put it into production
17:30:28 <adamw> i guess i forgot about it. :/
17:30:34 <coremodule> "we agreed at the F26 Final go/no-go meeting to draft up some formal policy for this so we can make such decisions consistently and not in an ad hoc way that might lead to it becoming a loophole that gets abused" - then adamw proposed a formal policy... I take that to mean the policy is in place
17:30:36 <nirik> adamw: how did you notice this bug?
17:30:55 <adamw> nirik: it's in the matrix
17:31:06 <adamw> lruzicka marked the desktop_menus test for kde as a 'fail' and referenced this bug
17:31:16 <adamw> but for some reason did not propose it as a blocker. i don't know why and he's not online to ask him
17:31:40 <bowlofeggs> agree with nirik
17:31:42 <adamw> coremodule: it's not really in place unless it's in the wiki, arguably
17:32:03 <nirik> adamw: ahhh... ok. and that was today/rc1?
17:32:08 <adamw> yes
17:32:15 <mboddu> I am inclined to waiving it off, if its the only blocker remaining
17:32:16 <adamw> i just checked testcase_stats and it was not reported as a fail before today
17:32:19 <adamw> https://www.happyassassin.net/testcase_stats/30/Desktop/QA_Testcase_desktop_menus_Release_blocking_desktops___lt_b_gt_x86___x86_64_lt__b_gt_.html
17:32:34 <coremodule> hmmmm, it was agreed on to produce some kind of policy, the policy was produced... dang, I can see it both ways.
17:33:00 * nirik is fine waving it even if it's not the last blocker. ;)
17:33:07 <adamw> so this is awkward, but, i guess i should forewarn that even if we blockerjutsu out all the blockers, i am going to raise the idea that we should not ship rc1 at least yet
17:33:16 <adamw> i was saving that for later, but...
17:33:18 <nirik> sure, thats fine. :)
17:33:40 <adamw> it worries me that it has existed for all of, oh, about 18 hours or something at this point? and it has a new kernel build and stuff in it
17:33:44 * nirik is -1 Blocker (due to long time/no proposal/no one cared about it) and +1 FE
17:33:51 <bowlofeggs> if we don't ship rc1 and do make an rc2, we could drop this package from the image
17:33:52 <adamw> i am not sure it's responsible to sign it off for release on less than 24 hours worth of testing
17:34:02 <bowlofeggs> then we satisfy the formal conditions
17:34:08 <pwhalen> adamw, I would agree.
17:34:14 <adamw> i dunno what everyone else thinks about that, but i figured i'd mention it in case it affects how much blockerjutsu we are inclined to do
17:34:19 <mboddu> adamw: I totally agree with your point
17:34:24 <Lailah> So...  +1FE adamw?
17:34:26 <bcotton> adamw: istr we proposed a rule like that for f29 and people were like "nahhhh, it's fiiiiiine"
17:34:26 <frantisekz> adamw: I understand that, but also, I think it's not worth it to delay go/no-go for entire week
17:34:28 <Lailah> Or what?
17:34:59 <adamw> bcotton: i'm not saying it should be a rule, it's more of a feeling. :P i don't necessarily mind shipping an RC5 that's only existed for 12 hours if it's barely different from an RC4 that got three days of solid testing
17:35:02 <pwhalen> I find it very difficult to get the testing done in time for the meeting, and likely missing things along the way. like no network in initial-setup
17:35:03 <adamw> but that's not the case we're in here
17:35:11 <coremodule> bcotton, that's true, we did come to that conclusion for f29... but we had a little more than 18 hours if i recall correctly...
17:35:13 <jlanda> We have two conditional blockers where we're not sure what to doo
17:35:29 <adamw> frantisekz: yeah, that's a consideration
17:35:43 <sgallagh> I'm still trying to replicate one of them. I'd suggest not making a final decision yet.
17:35:46 <adamw> i also know sgallagh suggested that we might not want to release *one* week later, for some reason
17:35:48 <sgallagh> Do we have other proposed issues?
17:36:00 <bcotton> we have at least two more ;-)
17:36:06 <sgallagh> adamw: We'd be releasing on the first day of Red Hat Summit.
17:36:07 <nirik> how about we do all the proposed and then discuss overall?
17:36:10 <sgallagh> Guaranteed to have no press.
17:36:11 <adamw> 1697591, but that's addressed
17:36:14 <bcotton> shall we return to this one as well?
17:36:18 <pwhalen> at one point we had agreed to auto slip if we didnt have an RC by Tuesday.
17:36:30 <adamw> pwhalen: how quaint :P
17:36:47 <adamw> yeah, i'm +1 for cycling back to this
17:36:53 <nirik> bowlofeggs: I think kf5-libksieve has a number of other deps... kmail/kdepim-libs
17:36:53 <bcotton> #info We'll come back to this one, too
17:37:13 <nirik> so removing it is likely to take a swath of other things
17:37:18 <bcotton> #topic (1697591) modesetting driver on some Intel hardware fails to start after kernel 4.20.13 update
17:37:20 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1697591
17:37:21 <bcotton> #info Proposed Blocker, xorg-x11-server, ON_QA
17:37:37 <bowlofeggs> nirik: oh that sounds less feasible then
17:38:14 <nirik> so, we have a fixed kernel in hand for this? or not entirely?
17:38:21 <bcotton> this one has a purported fix. did it make it into the compose?
17:38:28 <adamw> nirik: fun. we'd have to unpick the app from the menus then.
17:38:33 <adamw> bcotton: yes.
17:38:38 <adamw> this is addressed in RC1.
17:38:43 <Lailah> Oh, this one...
17:38:44 <nirik> adamw: yeah, or fix it from crashing.
17:38:46 <adamw> we haven't had confirmation that it's fixed yet, but i'm pretty confident it should be.
17:38:49 <adamw> nirik: pshaw
17:38:58 <bcotton> #info BZ 1697591 has a potential fix in RC1
17:39:08 <Lailah> adamw:  Why are you so confident?
17:39:22 <nirik> lets just ship kernel + nethack... would narrow the test matrix so much!
17:39:34 <bcotton> well i suppose let's put it to a vote just in case
17:39:40 <bowlofeggs> nirik: and it'd be more fun too!
17:39:41 <jlanda> yeah +1 nethack pid 1
17:39:43 * sgallagh adds nethack to the Server Edition
17:39:50 <adamw> Lailah: because it's the same "fix" (more a workaround) we had in f29
17:39:56 <adamw> just put back into f30
17:40:18 <Lailah> adamw:  fair point
17:40:19 <adamw> deciding blocker status for this is actually quite hard as we never figured out precisely how much hardware is affected
17:40:20 <sgallagh> FWIW, I'm not convinced this is a blocker (if it's not fixed, I don't think I'd slip for an unknown subset of hardware).
17:40:42 <adamw> but it seems like it's a reasonable amount, and of cards that have always worked before
17:40:53 <adamw> i'm really on the fence about this one, have been all along
17:41:06 <bcotton> this can has been kicked a few times
17:41:13 <adamw> yeah
17:41:16 <nirik> so really it's not gotten too much testing to make sure it's now 'fixed' in rc1 right?
17:41:20 <mboddu> circling back to adamw suggestion of slipping, we should do more testing
17:41:29 <adamw> nirik: like I said above: no, but i'm pretty confident it must me
17:41:45 <adamw> must be*
17:42:10 <adamw> the story here is basically that a kernel workaround (a reversion) was shipped as a downstream patch in f29 and earlier
17:42:24 <adamw> it got took out of f30 as the kernel team didn't want to carry it forever, on the basis that the bug should get fixed properly in x11
17:42:31 <jlanda> This one is not easy to test, we need specific hw, not all gpus of those series hit this, just some vendor setups
17:42:40 <Lailah> So...  is this fixed or not?
17:42:41 <adamw> that's what the bug report is for: it basically says 'hey x people, this workaround got taken out of the kernel, you need to fix the bug properly now'
17:42:49 <adamw> in the end that didn't happen and the kernel revert patch got put back in
17:42:56 * nirik is +1 blocker I guess then.
17:43:13 <Lailah> +1 Blocker
17:43:20 <adamw> i asked tibbs to check the fix (he has an affected system) but he hasn't replied yet
17:44:44 <Lailah> adanw:  When did you ask?
17:44:50 <bowlofeggs> it does sound like more testing time is wise here
17:45:02 <bcotton> so i see +1 from nirik and Lailah, and what i take to be -1 (or -0.5?) from sgallagh. anyone else want to commit to a position on this one?
17:45:27 <frantisekz> -1
17:45:47 <nirik> I think if we had this in f29 we need to carry the workaround until it's fixed in the X11 side. Dropping it and breaking things for some subset of people is poor and we should avoid it.
17:45:49 <adamw> Lailah: yesterday and again about half an hour ago
17:46:02 <sgallagh> Yeah, I'm revising my vote to a weak +1
17:46:03 <adamw> nirik: i think in the end ajax just upstreamed the kernel reversion, in fact, but that's a side note
17:46:13 <adamw> +0.2
17:46:31 <bcotton> adamw: you should see the face i'm making at you right now
17:46:33 <jlanda> And the integer thing? :D
17:46:35 <jlanda> +1
17:46:35 <sgallagh> I don't like it, but regressing is bad.
17:46:41 * mboddu agrees with nirik and +1 blocker
17:46:46 <pwhalen> +0.5 :(
17:46:47 <sgallagh> If this turns out not to fix the issue, we need to find a way to do it.
17:46:50 <adamw> bcotton: you just need to find the repo for my highly advanced fuzzy vote counter
17:47:04 <mkonecny> +1
17:47:07 <bowlofeggs> +1
17:47:40 <bowlofeggs> adamw: is it written for quantum computing so it can do fuzzy physics too?
17:47:53 <Lailah> adamw:  okay, maybe he needs some time to answer. He could be stuck in Alpha Centauri or something, without connection.
17:47:55 <bcotton> proposed #agreed 1697591 - AcceptedBlocker(Final) - This bug prevents a number of common hardware configurations (some generations of Intel graphics) from booting to a functional X server.
17:48:04 <mboddu> ack
17:48:17 <sgallagh> ack
17:48:18 <Lailah> ack
17:48:25 <pwhalen> ack
17:48:38 <nirik> sure, ack
17:48:50 <adamw> ack
17:48:51 <bcotton> #agreed 1697591 - AcceptedBlocker(Final) - This bug prevents a number of common hardware configurations (some generations of Intel graphics) from booting to a functional X server.
17:48:58 <mkonecny> ack
17:49:15 <bcotton> one already accepted blocker:
17:49:18 <bcotton> #topic (1693409) gdm/X start fails on 'nomodeset' UEFI boot on multiple bare metal systems: "Cannot run in framebuffer mode. Please specify busIDs          for all framebuffer devices"
17:49:20 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1693409
17:49:21 <bcotton> #info Accepted Blocker, xorg-x11-drv-vesa, ON_QA
17:49:28 <bcotton> i believe this is in RC1, too?
17:49:46 <adamw> yes, and fix has been confirmed i believe
17:49:55 <Lailah> Oh, this again.
17:50:04 <bcotton> #info Fix is in RC1 and confirmed
17:50:18 <bcotton> well that's the end of our stalling tactics, back to the ones we passed on
17:50:25 <adamw> just confirmed 2.4.0-6.fc30 is in rc1, so we're good there
17:50:44 <adamw> oh, i was figuring we'd come back to them after deciding whether testing was sufficiently complete, or something
17:50:52 <bcotton> okay, we can do that :-)
17:51:11 <bcotton> #topic Current status — release candidate
17:51:13 * nirik has a radical proposal he can offer on the more testing front.
17:51:24 <bcotton> #info RC1 is available
17:51:26 <mboddu> nirik: no testing? :P
17:51:34 * Lailah is all years to nirik proposal
17:51:41 <Lailah> is all ears *
17:51:43 <Lailah> sorry
17:51:50 <mhroncok> let's make rawhide beta quality, skip beta next time
17:51:54 <bowlofeggs> nirik: is it that we don't release until RMS says it's good to go?
17:52:13 <bcotton> nirik: go ahead
17:52:21 <adamw> RADICAL
17:52:28 <bowlofeggs> radical sabbatical
17:52:39 <nirik> say no go today due to lack of testing coverage. have next go/no-go monday. If go, release thursday. If no go next meeting thursday.
17:53:07 <nirik> I suspect it will discombobulate everyone tho, since we have always done tuesday releases.
17:53:07 <adamw> don't we have some rules somewhere about how long slips can be?
17:53:10 <bcotton> nirik: that is radical. let's discuss at the end if we decide to be No/Go
17:53:28 <mboddu> nirik: That is radical and I prefer Tue releases
17:53:41 <adamw> so, anyway, formal assessment:
17:53:44 <bowlofeggs> it's always tuesday somewhere in the galaxy…
17:53:48 <nirik> we did, we relunctantly agreed we could release on non tue if we wanted (at least fesco did)
17:53:57 <cverna> why do we have Tue releases ? is that just historical ?
17:54:05 <adamw> matrices are mostly complete, we are missing install_to_sas as per ye olde traditions
17:54:17 <mboddu> cverna: Part of it for mirrors to pick up the content over the weekend
17:54:22 <bcotton> adamw: should i #topic Test coverage now?
17:54:30 <adamw> oh yes, please
17:54:40 <cverna> mboddu: ah ok :)
17:54:42 <Lailah> cverna: I wonder the same
17:54:47 <bcotton> #topic Current status — test matrices
17:54:49 <bcotton> #link https://fedoraproject.org/wiki/Category:Fedora_30_Test_Results
17:55:04 <Lailah> What's so special about Tuesday?
17:55:15 <sgallagh> Taco day.
17:55:19 <nirik> cverna: tuesday is the best day for press.
17:55:20 <adamw> TRADITION!
17:55:27 <jlanda> It's unique cause is after monday and before wednesday
17:55:27 <adamw> did i get a chair? can I #info ?
17:55:29 <bcotton> okay, let's leave tuesday alone for a moment so adamw can wow us with test reports
17:55:32 <nirik> weekend gives time for mirrors to sync up and stage content
17:55:39 <bcotton> you can info iirc, but i'll chair you anyway
17:55:42 <bcotton> #chair adamw
17:55:42 <zodbot> Current chairs: adamw bcotton
17:55:42 <mboddu> Lailah: Cheaper movie tickets to celebrate :)
17:55:52 <adamw> #info matrices are near completion
17:55:55 <Lailah> sgallagh: Does Fedora comes with tacos if released on Tuesday?
17:55:59 <adamw> #info install_to_sas is missing like it always is
17:56:13 <adamw> #info install_to_fcoe (fiber channel) is missing as our one tester with access to HW to test it hasn't done it yet
17:56:41 <bcotton> (i'm impressed that fcoe is even a thing we have on the matrix)
17:56:46 <adamw> #info realmd_join_kickstart for Active Directory is missing, but all other combinations have been tested which we usually figure means that will work too
17:56:49 <bowlofeggs> Lailah: fedora only comes with the source code to make your own tacos (GPLv3)
17:56:50 <cverna> we are starting the 30 cycle we could decide to release all 3X on Thursdays :P
17:57:03 <bowlofeggs> Lailah: oh sorry, i meant gentoo :P
17:57:13 <adamw> #info xen_paravirt is missing, i am trying to run that ATM
17:57:26 <Lailah> bowlofeggs: now I'm confused... will I get tacos or not?
17:57:31 <sgallagh> Yeah, if the FreeIPA kickstart join works and the Cockpit AD join works, there shouldn't be any codepath the AD kickstart can fail on
17:57:52 <adamw> xen_paravirt and fcoe have not been run throughout the f30 cycle, so those worry me a bit
17:58:35 * nirik meant to install on his macbook, but didn't get around to it. ;(
17:58:42 <coremodule> adamw, I started to run the xen test at the start of the meeting, have hit a roadblock but dont want to say anything just yet...
17:59:35 <Lailah> Okay, guys, sorry, but I have to go. See you in a bit.
17:59:48 <adamw> coremodule: the roadblock being you can't get a xen kernel booted?
17:59:52 <adamw> yeah, i think it hasn't been ported to BLS
18:00:16 <coremodule> aye, tis the one
18:00:49 <adamw> so, it's looking like xen is at least somewhat busted.
18:01:20 <adamw> xen is a kind of standing pain in the ass
18:01:28 <sgallagh> That's us running in a Xen guest or as a Xen host?
18:02:03 <adamw> 'domU'
18:02:11 <adamw> which i think in Xen-speak means it has to work as a guest, right?
18:02:15 <nirik> 'guest'
18:02:16 <nirik> yes
18:02:25 <sgallagh> Right, our blocker criteria is about running as a guest
18:02:26 <adamw> so i guess this doesn't technically violate it, but unless me and coremodule can work around the problem we dunno if it works as a guest yet
18:02:41 <adamw> so anyway, so far as  coverage goes...this isn't covered yet
18:02:50 <adamw> so i would say we are close to sufficient coverage but not there yet
18:02:59 <adamw> we can probably get everything but FCoE tested by later today
18:03:10 <adamw> (i guess just xen)
18:03:17 <coremodule> yeah, I'm going to keep messing with it till i can figure something more concrete out
18:03:40 <bcotton> any other questions or comments on test coverage?
18:03:51 <adamw> coremodule: probably just hacking up a /boot/loader/entries file for it would do the trick
18:03:57 <adamw> however
18:04:10 <adamw> #info on formal test matrix coverage, we are nearly complete but missing two things, one of which can be complete by end of day
18:04:46 <adamw> #info on not-so-formal test coverage, QA is concerned that this RC has only existed for less than a day, and has substantial changes compared to most recently nightlies (including a newer kernel version)
18:05:17 <adamw> #info we have not yet had sufficient time to fully investigate the proposed initial-setup blocker bug
18:05:29 <adamw> over
18:05:37 <bcotton> thanks, adamw
18:06:12 <sgallagh> To report, I installed KDE, pulled the plug, rebooted and i-s worked fine.
18:06:32 <sgallagh> So the problem is not generic to all devices with unplugged network cables
18:06:46 <adamw> i kinda figured it wasn't, it has to be something weirder
18:06:48 <adamw> sure is weird though
18:06:59 <bcotton> alright, let's get back into the paused blockers
18:07:02 <nirik> perhaps it's 'no network device at all'
18:07:08 <adamw> maybe others have thoughts about test coverage first?
18:07:11 <adamw> nirik: no, we tried that.
18:07:24 <sgallagh> nirik: I tried that first
18:07:30 <nirik> ok.
18:07:33 <adamw> nirik: it worked for sgallagh and also the code that crashes definitely should crash when there *is* a device, not when there *isn't* one.
18:07:39 <bcotton> adamw: i asked. no one took the bait :-)
18:07:49 <nirik> I'd definitely like to see more general testing, especially given all the kernel changes.
18:07:52 <adamw> (it crashes if there's a device but networkmanager gives us None when we ask it for a 'hardware_address' and/or 'permanent_hardware_address')
18:08:09 <adamw> bcotton: sorry, i'm in thrashing-around mode here :P
18:08:10 <sgallagh> I'd definitely support delaying the decision by one day to make QA more comfortable
18:08:21 <bcotton> adamw: we need to work on your threading :-)
18:08:29 <sgallagh> But as of right now, I'm not strongly swayed that we need to respin.
18:08:33 <bcotton> #topic (1703152 revisited) initial-setup fails with no network - AttributeError: 'NoneType' object has no attribute 'upper'
18:08:33 <adamw> from puiterwijk import cluster_mode
18:08:42 <nirik> yeah, we could just keep the meeting open...
18:09:14 <adamw> i think i'd be happy with an extra day to make the call regardless whether we respin, yes
18:09:38 <adamw> i think if we can figure out a fix for ksieve relatively fast i'd like an rc2 with ksieve and the initial-setup bug fixed, as an option...
18:09:45 <mboddu> Yeah, I agree with it, wait until tomorrow for QA to be more comfortable
18:09:46 <adamw> but we can decide that part later i guess
18:09:57 <bcotton> yeah, let's decide on this last two blockers first
18:10:27 <nirik> well, I don't think we have enough info to decide right now, do we?
18:10:44 <mboddu> At least not on initial-setup one
18:11:05 <bcotton> if we choose not to decide, we still have made a choice
18:11:10 <adamw> the funny thing there is, it's probably easier to just *fix* it than figure out why it's happening
18:11:12 <adamw> the fix is super easy
18:11:17 <mboddu> For Ksieve, either we can remove the package (which is easier) or fix it
18:11:18 <adamw> it's just the cost of respinning for it that sucks
18:11:25 <adamw> mboddu: removing the package may not be practical
18:11:29 <adamw> that's what we need to figure out next
18:11:30 <bcotton> (if we don't decide now, we're deciding it's a rejectedblocker)
18:11:31 <sgallagh> bcotton: Rushing to judgement?
18:11:42 <bcotton> sgallagh: peart-y much
18:11:51 <adamw> well, we can accept them as FEs then ignore the rule that we don't respin for FEs only :P
18:11:56 <nirik> so: a) keep meeting open, reconvene tomorrow same time and discuss again, b) no go today due to lack of coverage testing, reconvene tomorrow again at same time
18:11:58 <adamw> (which we've done once or twice before)
18:13:00 <sgallagh> I'd be fine with just deleting the .desktop file for KSieve if everyone else thinks that's actually worth blocking on.
18:13:11 <sgallagh> The package can stay (so we don't have to worry about its deps)
18:13:14 <bcotton> hey, a respin is between QA and RelEng. I just want to cross these two off the list
18:13:15 <mboddu> adamw: Ahhh, I like the idea (less work for me) but I dont like it (principles) :(
18:14:07 <mboddu> bcotton: I am happy to respin if we have the fixes in time
18:14:09 <nirik> well, are we sure other things that depend on KSieve also actually work?
18:14:14 <sgallagh> If we're respinning for FEs, I'd like the swid-tags one in
18:15:01 <bcotton> we could call this a blocker just for the purposes of getting a resping
18:15:37 <adamw> sgallagh: which one was that
18:15:43 <adamw> bcotton: yeah, process jutsu!
18:15:47 <adamw> now you're thinking like a monkey
18:15:56 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=1703066
18:15:58 <pwhalen> I am -1 blocker for the initial-setup issue. I think it can be documented for the affected hardware. Also no one has noticed it prior to this morning.
18:16:03 <nirik> (it's only proposed, not accepted)
18:16:09 <adamw> pwhalen: but PROCESS JUTSU
18:16:10 <mboddu> adamw: https://bugzilla.redhat.com/show_bug.cgi?id=1703066
18:16:13 <bcotton> 🙊
18:16:19 <sgallagh> Right that one
18:16:24 <pwhalen> adamw, everything else has been kung fu kicked
18:16:26 <adamw> that is the current topic in fact :P
18:16:28 <mboddu> ^swid-tags
18:16:32 <nb> A topic that is not really for this meeting but I would like to see, is how to get the new boot experience on installs that you upgrade
18:16:39 <bcotton> i am also -1 blocker, +1 FE
18:16:56 * nb agrees with bcotton, -1 blocker +1 FE
18:16:56 <nirik> nb: there was info on that in the feature page or on the devel list.
18:17:20 <adamw> that one has enough votes to be accepted, i just marked it as such
18:17:45 <adamw> i am not yet convinced enough about the exact causes of this to be -1 blocker on it
18:17:56 <adamw> i'd be a lot happier monkey if it was fixed, given how simple the fix is. at least if i'm right about that
18:18:02 <adamw> (pwhalen is testing it for me)
18:18:11 * pwhalen goes back to that
18:18:18 <bcotton> testing the proposed fix?
18:18:26 <adamw> we just don't know where this None return is coming from and whether anaconda could hit it too somehow
18:18:34 <adamw> bcotton: yeah
18:18:47 <bcotton> shall we skip this one again and hit the other one?
18:18:58 <bcotton> while pwhalen tests
18:19:45 <nirik> sure
18:19:48 <adamw> well, let's at least agree that it's FE?
18:19:53 <adamw> everyone's +1 FE i guess
18:20:02 <mboddu> I guess I am +1 FE for initial-setup
18:20:27 <sgallagh> +! FE
18:20:33 <nirik> +1 FE sure
18:20:34 <zbyszek> +1 too
18:20:43 <mboddu> And +1 Blocker for KSieve (so that we can do a respin and include both these fixes including the swid-tags)
18:20:52 <pwhalen> +1 FE for initial-setup
18:21:08 <lbrabec> +1 fe for initial-setup
18:21:29 <bcotton> proposed #agreed 1703152 - AcceptedFreezeException(Final) - This appears to hit a narrow case, but can't be fixed in an update. We defer a decision on blocker status
18:21:43 <nirik> ack
18:21:48 <frantisekz> ack
18:21:49 <mboddu> ack
18:21:56 <lbrabec> ack
18:21:58 <pwhalen> ack
18:22:02 <nb> ack
18:22:06 <bcotton> #agreed 1703152 - AcceptedFreezeException(Final) - This appears to hit a narrow case, but can't be fixed in an update. We defer a decision on blocker status
18:22:23 <bcotton> #topic (1670396 revisited) KSieve fails to start
18:22:53 <bcotton> mboddu, i know you're +1
18:23:06 <mboddu> bcotton: Yes
18:23:24 <bcotton> it's pretty inarguable (although we should definitely finalize the "must be submitted before the meeting starts" rule)
18:23:27 <bcotton> +1 from me
18:23:42 <adamw> voting +1 is committing us to a respin, i guess...
18:23:44 * nirik is kinda still -1 due to the time thing, but meh, I guess...
18:23:48 <adamw> but i want one, so hey, +1
18:24:02 <adamw> i might argue the time thing harder if i didn't want a respin and we'd ever actually put it in the damn wiki
18:24:07 <mboddu> adamw: Hehe, same reasons here :D
18:24:25 <nirik> I'm worried that it's not going to be trivial to fix.
18:24:41 <mboddu> adamw: Although do we have a fix for it?
18:24:54 <mboddu> At least for initial-setup, we sorta have a fix
18:24:56 <coremodule> +1
18:26:04 <bcotton> okay, that's +4/-1
18:26:14 <bcotton> proposed #agreed - 1670396 - AcceptedBlocker(Final) - Violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
18:26:44 <coremodule> ack
18:26:51 <bowlofeggs> ack
18:26:53 <lbrabec> ack
18:27:32 <bcotton> #agreed - 1670396 - AcceptedBlocker(Final) - Violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
18:28:08 <bcotton> pwhalen: have test results for the initial-setup fix yet?
18:28:18 <adamw> nirik: if we can't drop the package we can at least patch out the desktop file...
18:28:48 <pwhalen> sorry, not quite
18:28:51 <nirik> I guess, I'm worried that other things that use it are broken too.
18:29:28 <bcotton> pwhalen: is it worth waiting or should we just move on knowing it's already accepted as an FE?
18:29:58 <adamw> nirik: if they don't use it at run time or in 'basic operation', we're fine. :P
18:30:25 <pwhalen> bcotton, you can move on, I'll report to adamw in qa
18:30:29 <bcotton> ok
18:30:32 <nirik> adamw: well, kdepim and kmail link to it's libraries... but might be when you pull up some seive pref or soemthing?
18:31:04 <bcotton> #topic Go/No-Go decision
18:31:30 <bcotton> so normally i'd just immediately start polling, but it sounds like we want to discuss our options
18:31:41 <pwhalen> bcotton, adamw, that worked
18:31:45 <adamw> nirik: that's what i'm assuming, yes. but i'll actually test kmail myself in a bit.
18:31:47 <adamw> pwhalen: yay, thanks
18:31:48 <bcotton> pwhalen++
18:32:04 <adamw> it sounds like people were generally in favour of 'leave it a day', right? that's good for me
18:32:16 <sgallagh> adamw: +1
18:32:27 <bcotton> i'm a little bothered by taking out a default app without giving the KDE team a chance to weigh in
18:32:46 * nirik is too
18:32:48 <bcotton> even though that's the shortest route to being technically in line with release criteria
18:32:49 <mboddu> pwhalen++
18:32:50 <zodbot> mboddu: Karma for pwhalen changed to 9 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:32:55 * nb is a little bothered by blocking on KDE anyway
18:33:17 <nb> since that's not one of our default editions
18:33:18 <bcotton> nb well there's that, but that's not a decision we can make here
18:33:25 <nirik> well, we have a blocker now, so it's no-go right now.
18:33:37 <bcotton> right
18:34:11 <adamw> rdieter signed out 40 minutes ago
18:34:13 <bcotton> so the question becomes do we reconvene tomorrow or do we kick it to next week in order to engage with the kde team about their blocker
18:34:15 <mboddu> revote on Ksieve? :P
18:34:17 <adamw> really should've poked him before them. sigh.
18:34:49 <nb> mboddu, I like that idea
18:34:55 <nb> since it was just proposed
18:36:11 <nirik> well, our normal process is punt a week. Thats not great this time tho...
18:36:39 <bcotton> yeah, i've heard secondhand that a particular downstream would really like us to not release on the 7th
18:36:43 <mboddu> nirik: Yes, but we dont have the right fix for KSieve
18:37:06 <nirik> right, we don't know what that is yet for sure...
18:37:52 <nirik> so, I see our options as: a) try again tomorrow, b) try again monday for thursday release c) punt a week and not care about releasing on the 7th, d) punt 2 weeks! :)
18:38:11 <bcotton> okay, so let's do this. i'm going to 'proposed #agreed' that we're no-go because that's pretty clear. and then we can decide about tomorrow versus next week for the next decision
18:38:18 <nb> ack
18:38:22 <zbyszek> ack
18:38:24 <adamw> sure.
18:38:24 <frantisekz> ack
18:38:26 <lbrabec> ack
18:38:27 <pwhalen> ack
18:38:33 <nirik> ack
18:38:34 <bcotton> proposed #agreed Fedora 30 is NO-GO
18:38:42 <bcotton> look all all of those acks, okay!
18:38:43 <mboddu> ack
18:38:44 <pingou> anyone else than rdieter could help untangle this?
18:38:50 <bowlofeggs> ack
18:38:52 <bcotton> #agreed Fedora 30 is NO-GO
18:39:20 <bowlofeggs> only 2 more releases until we have a power of 2 fedora version!
18:39:27 <bowlofeggs> there's not been one of those in a while
18:39:35 <bowlofeggs> and we get a prime number next too
18:39:44 <mboddu> bowlofeggs: 1 more branching, if you are on rawhide ;)
18:39:56 <nirik> BTW, I found: https://pagure.io/fesco/issue/974 "change our release policy such that releases must be on Tuesday, Wednesday, or Thursday, but always pick Tuesday by default unless there's a specific reason not to"
18:40:15 <bowlofeggs> tru
18:40:22 <bcotton> so...assuming we can get a compose to complete on time after whatever we do to fix the KDE bug, do we reconvene friday or next thursday?
18:40:34 <adamw> kkofler isn't around any more
18:40:36 <adamw> as much
18:40:51 <jlanda> we just push the .desktop file change to the compose?
18:41:05 <jlanda> Or something bigger?
18:41:37 <nirik> I think others can test the dependent apps more and find the scope of the problem for sure.
18:42:15 <zbyszek> What time would the koji build with the fix for pim-sieve-editor bug would have to finish?
18:42:18 <jlanda> tomorrow seems to early, we don't have a fix right now and the rc took half a day
18:42:29 <bcotton> jlanda: that's what i'm thinking
18:42:35 <coremodule> I do agree, tomorrow seems too soon
18:42:53 <nb> I like kevin's proposal
18:42:54 <nb> try again monday for thursday release
18:43:01 <jlanda> monday sounds feasible, if we hit a fix tomorrow
18:43:08 <jlanda> We can test and sync on weekend
18:43:20 <zbyszek> Yep, Monday seems feasible.
18:43:35 <mboddu> nirik: Then what about mirrors? Are they gonna be happy?
18:43:45 <jlanda> But we need a fix tomorrow
18:43:48 <mboddu> ^ If we meet on Monday for Thu release
18:43:53 * mattdm parachutes in
18:44:07 * nb doesn't see why mirrors would be upset
18:44:08 <dmoluguw> I'm not sure if this is the right meeting to bring this up. This is NOT a blocker for f30 but f31+. is there a proposed solution for java packages that were affected: https://fedoraproject.org/wiki/SIGs/Stewardship
18:44:36 * bowlofeggs lays down supressing fire for mattdm to ward off non-free software
18:44:37 <adamw> zbyszek: i am doing the anaconda fix right now
18:44:39 <nirik> mboddu: if we stage monday, that gives 3-4days... just like if we staged friday
18:44:41 <adamw> was gonna look at sieve next
18:44:48 <adamw> dmoluguw: not the right meeting, sorry
18:45:02 <mattdm> bowlofeggs: hehe nice
18:45:10 <adamw> i'm not opposed to tomorrow tbh
18:45:19 <adamw> an RC2 with only specific targeted fixes is less scary than RC1 was for me
18:45:31 <adamw> and i do think we can get something done about both i-s and sieve in the next hour or two
18:45:32 <sgallagh> adamw: How targeted are we talking?
18:45:37 <nb> mattdm, what are your thoughts? we are discussing having a go/no-go tomorrow or having one monday and then if monday, having thursday release
18:45:48 <sgallagh> Just i-s and sieve, or also some FEs?
18:45:55 <adamw> sgallagh: i-s, sieve, the swid thing i guess
18:46:01 <sgallagh> Cool, thanks.
18:46:07 * adamw is writing the i-s patch now
18:46:10 <mattdm> thursday release would be worth doing in this case, I think
18:47:04 <mattdm> I have been, ehm, Suggested To that Red Hat marketing would be fairly unhappy if we release during RH Summit
18:47:11 * nirik nods
18:47:35 <mattdm> but it'd also be nice to have it out the door to give out / talk about _at_ Summit
18:48:17 <bcotton> mboddu: you seemed opposed when this was brought up earlier. is releng okay with a thursday release?
18:48:21 <nirik> yeah, thats why I was suggesting a thursday release.
18:48:33 <nirik> but if we cna go tomorrow we could try for tuesday
18:48:45 <mboddu> bcotton: Yeah, I am okay with it, but I think we should try for Tue
18:48:47 <adamw> i'd like to keep the option open
18:49:03 <adamw> shall we agree to reconvene tomorrow, and if we're no-go then, we can consider thursday?
18:49:09 <bcotton> okay, so what i'm hearing is that we'll do this again tomorrow and if that doesn't work, we'll try again on monday?
18:49:35 <sgallagh> That sounds like our most versatile option
18:49:40 <pingou> worst case tomorrow will be a quick meeting or could even be just emails?
18:49:44 <mattdm> and monday might be okay for a release _that_ thursday? (The 9th?)
18:50:03 <mboddu> Since there is only one blocker remaining, lets try RC 1.2 with i-s,KSieve,swid-tags fixes tonight, and if we face lot of issues with .desktop file for KSieve fix, then based on the testing, we can revote on KSieve and *probably* release RC 1.1
18:50:38 <bcotton> pingou: yeah, i'll check with folks in the (US Eastern) AM to see. if it's clear that anyone will be no-go, I'll cancel it
18:50:46 <adamw> mboddu: yeah, that's basically what i'm thinking
18:50:49 <adamw> let's have rc2 as an option
18:51:16 <sgallagh> mattdm: No, we're talking about monday for releasing the 2nd
18:51:37 <sgallagh> mboddu: +1
18:51:50 <bcotton> proposed #agreed Next Go/No-Go meeting will be on Friday 2091-04-26 at 1700 UTC in #fedora-meeting-1. bcotton will cancel the meeting if it's clear the decision will be No-Go and we will try again on Monday 29 April
18:51:50 * nirik is on board with that.
18:51:54 <nb> ack
18:51:59 <nb> nack
18:51:59 <zbyszek> ack
18:52:02 <nb> 2019
18:52:06 <nb> :)
18:52:08 <frantisekz> ack
18:52:09 <nirik> it does mean more churn/heroics/meetings
18:52:16 <bcotton> nb, we're slipping big time
18:52:25 <adamw> btw, does anyone in this meeting have an FCoE setup in their back pocket?
18:52:33 <bcotton> proposed #agreed Next Go/No-Go meeting will be on Friday 2019-04-26 at 1700 UTC in #fedora-meeting-1. bcotton will cancel the meeting if it's clear the decision will be No-Go and we will try again on Monday 29 April
18:52:35 <mboddu> ack
18:52:35 * adamw puts on cape
18:52:36 <nb> ack
18:52:42 <bcotton> (same as above but with the right year)
18:52:48 <nirik> ack
18:52:53 <mattdm> adamw: think of it as your "dodging red hat summit cape"
18:52:53 <sgallagh> patch
18:52:58 <bcotton> sgallagh: go ahead
18:53:14 <sgallagh> proposed #agreed Next Go/No-Go meeting will be on Friday 2019-04-26 at 1700 UTC in #fedora-meeting-1. bcotton will cancel the meeting if it's clear the decision will be No-Go and we will try again on Monday 29 April with a new release date of Thu May 02
18:53:23 <bcotton> ack
18:53:28 <nb> ack
18:53:30 <pwhalen> ack
18:53:30 <mboddu> ack
18:53:35 <bowlofeggs> ack
18:53:35 <sgallagh> Well, the date formats are inconsistent, but the point is made
18:53:39 <nirik> ack
18:53:47 <lbrabec> ack
18:54:09 <adamw> nack ISO date standards required
18:54:14 <adamw> :P
18:54:15 <adamw> ok fine, ack
18:54:17 <bowlofeggs> adamw is a hero that *does* wear a cape
18:54:18 <bcotton> sorry adamw, i couldn't hear you
18:54:21 <sgallagh> .fire adamw for pedantics
18:54:21 <zodbot> adamw fires adamw for pedantics
18:54:22 <bcotton> #agreed Next Go/No-Go meeting will be on Friday 2019-04-26 at 1700 UTC in #fedora-meeting-1. bcotton will cancel the meeting if it's clear the decision will be No-Go and we will try again on Monday 29 April with a new release date of Thu May 02
18:54:36 <adamw> sgallagh: i mean if you could be fired for being pedantic i wouldn't have lasted two weeks
18:54:47 <mattdm> neither would have sgallagh!
18:54:53 <bowlofeggs> or jcline
18:54:56 <bcotton> #action bcotton to announce decision
18:55:05 <sgallagh> Or anyone who just listed a person who would fail that test :-P
18:55:09 <x3mboy> .hello2
18:55:10 <zodbot> x3mboy: x3mboy 'Eduard Lucena' <eduardlucena@gmail.com>
18:55:30 <bcotton> #action adamw to finish implementing "late blocker submission" change to the policy
18:55:42 <adamw> you can't make me!
18:56:13 <bcotton> adamw: ssshhhhh. nobody is supposed to know i'm powerless
18:56:24 <jcline> I'm not *always* pedantic
18:56:38 <bcotton> anything else to say before we see each other again in 22 hours (and also in 4 minutes for the release readiness meeting)?
18:57:03 <adamw> jcline pointed out, pedantically
18:57:18 <zbyszek> bcotton: "see you soon"?
18:57:22 <bowlofeggs> sgallagh: haha
18:57:35 <bcotton> zbyszek++
18:57:36 <zodbot> bcotton: Karma for zbyszek changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:57:36 <jcline> I didn't say I wasn't being pedantic there
18:57:38 <mboddu> See ya everyone in 3 min :)
18:57:55 <bowlofeggs> jcline pointed out, pedantically
18:58:08 <bowlofeggs> time for some la croix
18:58:24 <nirik> use those 3 minutes wisely!
18:58:24 <bcotton> #endmeeting