15:00:00 <bowlofeggs> #startmeeting FESCO (2018-06-15)
15:00:00 <zodbot> Meeting started Fri Jun 15 15:00:00 2018 UTC.
15:00:00 <zodbot> This meeting is logged and archived in a public location.
15:00:00 <zodbot> The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:00 <zodbot> The meeting name has been set to 'fesco_(2018-06-15)'
15:00:00 <bowlofeggs> #meetingname fesco
15:00:00 <bowlofeggs> #chair nirik, maxamillion, jsmith, jwb, zbyszek, tyll, sgallagh, contyk, bowlofeggs
15:00:00 <bowlofeggs> #topic init process
15:00:00 <zodbot> The meeting name has been set to 'fesco'
15:00:00 <zodbot> Current chairs: bowlofeggs contyk jsmith jwb maxamillion nirik sgallagh tyll zbyszek
15:00:13 <contyk> .hello psabata
15:00:14 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:27 <t8m> .hello tmraz
15:00:29 <zodbot> t8m: tmraz 'Tomáš Mráz' <tmraz@redhat.com>
15:00:37 <sgallagh> .hello2
15:00:38 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:00:59 <nirik> morning
15:01:05 <nirik> .hello kevin
15:01:06 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
15:01:11 <maxamillion> .hello2
15:01:12 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:01:34 <bowlofeggs> alright, quorum established
15:01:56 <jsmith> .hello2
15:01:57 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
15:02:31 <zbyszek> .hello2
15:02:32 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:03:09 <bowlofeggs> alright, let's get this party started
15:03:15 <bowlofeggs> #topic #1820 Adjust/Drop/Document batched updates policy
15:03:15 <bowlofeggs> .fesco 1820
15:03:18 <zodbot> bowlofeggs: Issue #1820: Adjust/Drop/Document batched updates policy - fesco - Pagure - https://pagure.io/fesco/issue/1820
15:03:29 <bowlofeggs> this one i put back on the schedule because it's not really moved in a while
15:03:32 <zbyszek> Pfff, sorry, I didn't do anythign re this.
15:03:47 <bowlofeggs> it's alright, i'm also insanely busy lately and very much understand :)
15:04:01 <zbyszek> If somebody wants to take over, please do.
15:04:20 <bowlofeggs> i'd be willing to document the wiki page, though i will be unable to do so for more than a month or so
15:04:21 <nirik> I think we should just disable batched until we have a plan with qa testing batches, etc ready to go.
15:04:38 <bowlofeggs> nirik: it is effectively disabled right now
15:04:55 <nirik> yeah, although it's a bit confusing...
15:04:55 <bowlofeggs> since the deque job runs daily currently
15:05:08 * jsmith is perfectly fine with the current state of affairs, and still hopes for a better future
15:05:09 <bowlofeggs> well disabling it more than this would be a non-insigificant effort
15:05:14 <bowlofeggs> it's not a setting in bodhi
15:05:23 <zbyszek> There was another proposal for the zchunk format recently. So it's possible that the technology will change a bit too.
15:05:28 <sgallagh> Yeah, I'd rather keep the terminology present so people remain used to it
15:05:48 <nirik> bummer. I hoped it would just be switching things to stable and ignore the batched state for now, but oh well.
15:06:23 <jwb> hi
15:06:31 <jsmith> Proposal: Leave things the way they are now, until we have a plan with QA testing of batches, etc.
15:06:33 <bowlofeggs> the thing i'm more concerned about is the holding pattern things are kind of in - some people only want to re-enable it if i add some features to bodhi, but i don't want to add those features unless i think fesco will ultimately vote to enable, and others don't seem to want to enable it
15:06:44 <maxamillion> jsmith: +1
15:06:55 <bowlofeggs> jsmith: well it sounds like QA doesn't necessarily intend to test batches
15:07:03 <maxamillion> oh
15:07:18 <bowlofeggs> i would counter propose that to get things moving, i should write the wiki that was previously pitched by zbyszek (thoguh i can't for more than a month)
15:07:43 <bowlofeggs> i mostly just want to get some movement on this ticket, even if it's in the direction i personally don't want to go
15:07:55 <jsmith> Proposal (modified): Leave things the way they are now, and wait for bowlofeggs or zbyszek to write up the wiki :-)
15:08:03 <bowlofeggs> jsmith: +1
15:08:06 <zbyszek> jsmith: sadly +1
15:08:09 <nirik> +1
15:08:17 <maxamillion> jsmith: +1
15:08:45 <sgallagh> +1
15:08:49 <jwb> +1
15:09:07 <bowlofeggs> #agreed Leave things the way they are now, and wait for bowlofeggs or zbyszek to write up the wiki :-) (+7, 0, -0)
15:09:10 <bowlofeggs> excellent, thanks!
15:09:22 <bowlofeggs> #topic #1912 Please update Wiki pages and permisions to reflect results of May 2018 elections
15:09:22 <bowlofeggs> .fesco 1912
15:09:23 <zodbot> bowlofeggs: Issue #1912: Please update Wiki pages and permisions to reflect results of May 2018 elections - fesco - Pagure - https://pagure.io/fesco/issue/1912
15:09:29 <bowlofeggs> i believe this is taken care of by zbyszek and nirik
15:09:32 <zbyszek> This is done already, no?
15:09:33 <bowlofeggs> shall we just move on?
15:09:42 <nirik> yep. Should be all done.
15:09:43 <zbyszek> Yep.
15:09:44 <bowlofeggs> cool
15:09:51 <bowlofeggs> #action no action needed
15:09:58 <bowlofeggs> #topic #1900 Stop building freeipa server packages on i686
15:09:58 <bowlofeggs> .fesco 1900
15:10:00 <zodbot> bowlofeggs: Issue #1900: Stop building freeipa server packages on i686 - fesco - Pagure - https://pagure.io/fesco/issue/1900
15:10:03 <sgallagh> bowlofeggs: can we get "FESCo Meeting Time" on the agenda somewhere, BTW?
15:10:19 <sgallagh> We need to decide when we're next meeting sometime today
15:10:25 <bowlofeggs> is this one different from the one i linked in my first comment?
15:10:28 <bowlofeggs> sgallagh: sure!
15:11:01 <frenaud> bowlofeggs: this issue is a consequence of the 389-ds-base issue
15:11:06 <jsmith> With regards to #1900, I don't know what else we can possibly do...
15:11:33 <bowlofeggs> yeah, i think we can just acknowledge it
15:11:43 <fweimer> There isn't a reproducer anyway: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/L6YCA2O62IQRVA2V72RKQHKL624W5EHS/
15:11:44 <bowlofeggs> we knew this was happening when we discussed the 389-ds-base package
15:11:52 <fweimer> (I couldn't get the claimed test suite failures.)
15:11:58 <jwb> +1 to stopping
15:12:09 <sgallagh> I'm fine with this.
15:12:26 <jsmith> Reluctant +1 from me
15:12:38 <contyk> +1
15:12:41 <sgallagh> Frankly, I'd like to see us get to a point where we only build i686 packages for multilib needs, but I know I'm in the minority there
15:12:56 <jwb> you are not!  i subscribe to this newsletter
15:12:58 <contyk> would love to see that, too
15:13:04 <bowlofeggs> fweimer: yeah it seemed there was some difficulty in documenting a reproducer when we looked into this earlier this year
15:13:27 * nirik finds that troubling.
15:13:31 <zbyszek> I don't think we should "accept" this ticket, but instead "acknowledge".
15:13:46 <sgallagh> nirik: "that"?
15:13:56 <jwb> zbyszek, what is the practical difference?
15:14:11 <bowlofeggs> when we discussed this problem in https://pagure.io/fesco/issue/1845 we decided to just ask for a change to be filed, and it was
15:14:21 <nirik> that there is no reproducer for this possible tools issue that could also be affecting other things.
15:14:50 <fweimer> nirik: Oh, we know about the _Atomic alignment problem.
15:14:57 <bowlofeggs> fweimer: do you propose that we do something else than acknowledge this problem?
15:14:58 <zbyszek> jwb: it's not like we could reject it, so I don't like voting on something that implies that.
15:15:25 <fweimer> bowlofeggs: I don't know.  I would have fixed the problem for them if they had a reproducer.
15:15:30 <jwb> zbyszek, ok
15:15:42 <jwb> fweimer, but we don't.  and we have a packaged agenda.  so can we move on?
15:15:49 <jwb> s/packaged/packed
15:15:50 <fweimer> The uint64_t alignment problem on i386 is definitely there.
15:15:52 <bowlofeggs> fweimer: yeah i found this problem frustrating, especially with the difficulty in getting communication on it
15:15:54 <fweimer> Yes, please move on.
15:15:58 <bowlofeggs> jwb: +1
15:16:01 <nirik> fweimer: but thats not so much a bug, but a...limitation right?
15:16:02 <bowlofeggs> let me count votes
15:16:16 <bowlofeggs> i think i see +4?
15:16:23 <nirik> +1 to stopping since we can't do much else
15:16:26 <zbyszek> bowlofeggs: I'm +1 to "accepting", even though I would prefer a different verb
15:16:39 <bowlofeggs> ah i didn't count sgallagh, so that's +7
15:16:55 <sgallagh> I count as +3? :)
15:17:02 <bowlofeggs> #agreed FESCo acknowledges (+7, 0, -1)
15:17:09 <fweimer> nirik: It's definitely an oversight when introducing _Atomic in C11.
15:17:09 <bowlofeggs> sgallagh: haha, well with nirik and zbyszek :)
15:17:10 <zbyszek> sgallagh: you are important
15:17:15 <sgallagh> ;-)
15:17:22 <bowlofeggs> #topic FESCo meeting time
15:17:23 <fweimer> nirik: It's not too hard to work around for application code though.
15:17:47 * bowlofeggs tries to find the link to the calendar poll
15:18:04 <contyk> http://whenisgood.net/i8eam9s/results/sbgf8m9
15:18:33 <bowlofeggs> we still lack 2 responses
15:18:52 <bowlofeggs> maxamillion: ?
15:19:05 <jsmith> That being said, it looks like we're down to one viable time anyway...
15:19:10 <bowlofeggs> and tyll?
15:19:14 <jsmith> Mondays, 15:00 (assuming UTC)
15:19:24 <sgallagh> jsmith: Those are start times, so that's still three viable times
15:19:34 <maxamillion> bowlofeggs: sorry ... bleh
15:19:45 <jsmith> sgallagh: Only if the meetings are limited to 30 minutes
15:19:45 <maxamillion> bowlofeggs: I'm in two meetings right now, reading backlog
15:19:47 <bowlofeggs> yeah, and jsmith can only do the first bit
15:19:59 <sgallagh> jsmith: That's not how WhenIsGood works
15:20:10 <sgallagh> You only list start times, not duration
15:20:32 <jwb> sgallagh, oh.  that was unclear to me entirely
15:20:33 <maxamillion> 1500 UTC on Mondays works for me as well
15:20:37 <bowlofeggs> ah i had actually interpreted it as including duration too, though i didn't really read docs or anything, just an assumption
15:20:44 <jwb> bowlofeggs, same
15:20:44 <bowlofeggs> tyll: 1500 on mondays?
15:20:57 <jwb> also, if this is in UTC then all my answers are wrong
15:21:02 <contyk> it said "duration: 2 hours" above the calendar
15:21:07 <sgallagh> jwb: The results page is in UTC
15:21:09 <contyk> but yeah, the ui isn't the best
15:21:23 <sgallagh> When you submitted your answers, there should have been a drop-down with your TZ
15:21:24 <bowlofeggs> ah right tyll isn't around today
15:21:37 <contyk> a wonderful dropdown :)
15:21:46 <jwb> that's not confusing or anything
15:22:15 * nirik can do 15utc, won't like it, but I can do it.
15:22:19 <bowlofeggs> should we just declare it to be 1500 UTC on mondays, assuming skipping next monday unless we want to double down?
15:22:19 <jwb> honestly, i'd rather just not have a meeting.  i'm not convinced it works.
15:22:19 <sgallagh> But yeah, looks like jwb probably entered his times as UTC :-/
15:22:49 <bowlofeggs> or do we need to recast due to tz confusion?
15:23:01 <bowlofeggs> jwb: do you advocate for ticket voting instead?
15:23:07 <jwb> it's fun talking to you guys and everything, but i feel like we just continually wait to do anything until meeting time when we could probably resolve almost everything in-ticket.
15:23:11 <jwb> bowlofeggs, yes
15:23:19 <nirik> We have used https://framadate.org/ also in other places.
15:23:33 <jwb> bowlofeggs, with an expected response time perhaps.  like, 3 days of a ticket being filed we have to comment/vote
15:23:36 <jwb> or something
15:24:33 <bowlofeggs> jwb: i agree that there are some things we just need to rubber stamp
15:24:41 <zbyszek> jwb: we can try to do that without stopping the meeting, in the beginning at least for simple tickets, and see how that goes.
15:24:43 <nirik> we have tried many times over the years to do more voting in tickets and it never worked, but sure, we could try again. ;)
15:24:45 <bowlofeggs> but there are times i've found the meeting discussion to be helpful to my vote
15:24:54 <zbyszek> bowlofeggs: exactly
15:24:55 <sgallagh> I think there's value in at least having a meeting time for those issues that benefit from a higher communication speed
15:25:01 <jwb> nirik, we did, but never without NOT having a meeting
15:25:02 <nirik> perhaps we could leverage pagure statuses?
15:25:04 <jsmith> jwb: I completely agree, and will try to do better at voting in tickets before the meetings.
15:25:07 <jwb> nirik, which is a crutch we all just lean on
15:25:08 <bowlofeggs> i think it'd be good to vote in-ticket on obvious things though, to save the agenda from them
15:25:49 <nirik> ie, only items marked meeting by someone will be discussed in meeting, all other tickets must be voted in ticket
15:25:54 <jwb> anyway, i can do 15:00 UTC on mondays
15:26:10 <sgallagh> Proposal: Tickets by default are resolved one week after they are submitted by the majority of votes cast in them (minimum three votes) unless a FESCo member adds the "meeting" keyword to indicate that an active discussion must happen.
15:26:27 <jwb> +1
15:26:34 <bowlofeggs> sgallagh: shouldn't it be minimum 5?
15:26:56 <jwb> he was putting a time limit on it to force responses
15:27:06 <sgallagh> Exactly
15:27:08 <jwb> not suggesting we wait for majority
15:27:08 <maxamillion> sgallagh: +1
15:27:20 <sgallagh> As long as at least three votes occur within the week, it's good to go.
15:27:24 <maxamillion> "get your vote in if you want it to count"
15:27:28 <sgallagh> So you have to be responsive, or your vote doesn't count
15:27:33 <bowlofeggs> oh i see
15:27:35 <maxamillion> +1
15:27:37 <nirik> sure. Can give it a go...
15:27:39 <nirik> +1
15:27:41 <contyk> +1
15:27:41 <bowlofeggs> yeah i think i like that, +1
15:27:47 <jwb> i like it, speaking as someone that is probably going to be hurt the most by it.  DO IT
15:27:57 <sgallagh> +1 for the record
15:27:57 * bowlofeggs counts votes
15:27:59 <zbyszek> -0, I'm afraid this won't work, but I won't stand in the way
15:28:23 <bowlofeggs> i see +6 -0
15:28:51 <bowlofeggs> #agreed Tickets by default are resolved one week after they are submitted by the majority of votes cast in them (minimum three votes) unless a FESCo member adds the "meeting" keyword to indicate that an active discussion must happen. (+6, 1 neutral, -0)
15:29:04 <bowlofeggs> are we also agreed on monday 1500?
15:29:16 <bowlofeggs> starting in 10 days, not 3 days?
15:29:21 <jwb> yes
15:29:26 <bowlofeggs> cool
15:29:29 <jwb> will be a good test of our new ticket rule
15:29:33 <sgallagh> bowlofeggs: I think so, yes. Unless anyone else's responses were wrong?
15:30:07 <bowlofeggs> #agreed FESCo meeting will shift to Mondays at 1500 UTC. The next meeting will be on 2018-06-25
15:30:14 <bowlofeggs> ok, next topic
15:30:26 <bowlofeggs> #topic #1902 F29 Self Contained Change: java-11-openjdk - next LTS OpenJDK release and future main JDK in Fedora
15:30:26 <bowlofeggs> .fesco 1902
15:30:29 <zodbot> bowlofeggs: Issue #1902: F29 Self Contained Change: java-11-openjdk - next LTS OpenJDK release and future main JDK in Fedora - fesco - Pagure - https://pagure.io/fesco/issue/1902
15:31:01 <sgallagh> We should probably announce this new policy to devel-announce so people know what to expect from FESCo going forward.
15:31:05 <sgallagh> I can write something up.
15:31:19 <jwb> thanks sgallagh
15:31:23 <maxamillion> sgallagh: +1
15:31:29 <nirik> +1 for java11 and +1 for sgallagh
15:31:31 <jwb> +1 to java stuff
15:31:35 <maxamillion> bowlofeggs: +1 for java
15:31:45 <jsmith> +1
15:31:49 <bowlofeggs> #action sgallagh will document the new fesco voting policy to devel-announce
15:31:54 <sgallagh> +1 java11
15:31:56 <contyk> +1 to java
15:31:59 <bowlofeggs> +1 from me
15:32:03 <zbyszek> +1
15:32:39 * sgallagh will also suggest to jkurik that Self-Contained Changes can go to individual tickets, since we'll be processing them out-of-meeting now.
15:32:56 <bowlofeggs> #agreed Java-11 appoved (+8, 0, 0)
15:33:03 <zbyszek> sgallagh: +1
15:33:10 <bowlofeggs> sgallagh: +1
15:33:18 <bowlofeggs> #topic #1903 F29 System Wide Change: Node.js 10.x as default Node.js interpreter
15:33:18 <bowlofeggs> .fesco 1903
15:33:20 <zodbot> bowlofeggs: Issue #1903: F29 System Wide Change: Node.js 10.x as default Node.js interpreter - fesco - Pagure - https://pagure.io/fesco/issue/1903
15:33:31 <bowlofeggs> should we auto downvote this since sgallagh filed it?
15:33:36 <sgallagh> hehehe
15:33:42 <contyk> :)
15:33:45 <nirik> clearly.
15:33:49 <nirik> +1
15:33:50 <bowlofeggs> +1 from me
15:33:58 <sgallagh> +1 from me, of course
15:33:59 <maxamillion> +1
15:34:04 <zbyszek> +1
15:34:10 <contyk> what about the nodejs:10 module?
15:34:20 <contyk> will it be empty on f29?
15:34:21 <sgallagh> Just a note: the exact implementation of this will depend on my other Change
15:34:34 <jwb> hm
15:34:36 <sgallagh> contyk: Coming up later on
15:34:42 <jwb> +1
15:35:05 <sgallagh> If that one is approved, we will ONLY ship the interpreter as a default module and block if from the traditional repo
15:35:15 <dgilmore> sorry missed the ping on the meeting
15:35:23 <jsmith> +1
15:35:29 <dgilmore> because bowlofeggs excluded me
15:35:41 <contyk> sgallagh: hmm, that would require ursa major being deployed
15:35:44 <bowlofeggs> dgilmore: i think contyk took your seat today :)
15:36:00 <contyk> dgilmore: o/
15:36:00 <dgilmore> bowlofeggs: oh, i thought the elections had not finished yet
15:36:08 <bowlofeggs> contyk: vote?
15:36:09 <dgilmore> that is fine then :D
15:36:19 <jsmith> dgilmore: Elections are finished, results announced...
15:36:26 <contyk> +1 on the change, although the details are fuzzy
15:36:29 <bowlofeggs> dgilmore: yeah they finished about a dayish ago
15:36:33 <jsmith> dgilmore: Thanks for your service, though :-)
15:36:34 * dgilmore missed that totally and did not vote because of it
15:36:56 * dgilmore goes back to his hole
15:37:05 <bowlofeggs> #agreed node.js 10 is approved (+8, 0, -0)
15:37:11 <bowlofeggs> we will miss you dgilmore
15:37:18 <contyk> fyi, ursa major is a service that puts modules in the non-modular buildroot
15:37:38 <bowlofeggs> #topic #1905 F29 System Wide Change: Hide the grub menu
15:37:38 <bowlofeggs> .fesco 1905
15:37:39 <zodbot> bowlofeggs: Issue #1905: F29 System Wide Change: Hide the grub menu - fesco - Pagure - https://pagure.io/fesco/issue/1905
15:37:40 <nirik> yeah, dgilmore++
15:37:41 <zodbot> nirik: Karma for ausil changed to 5 (for the f28 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:37:45 <contyk> if nodejs is only shipped as a module, we would need to deploy that service in Fedora, otherwise people wouldn't be able to build non-modular nodejs packages
15:37:47 <bowlofeggs> alright, now we're getting into a contentious one!
15:38:01 <sgallagh> contyk: OK, I will have to keep that in mind
15:38:11 <bowlofeggs> oh are we not done on the previous? i can go back
15:38:18 <contyk> bowlofeggs: no, we're fine
15:38:21 <bowlofeggs> cool
15:38:24 <bowlofeggs> so... grub
15:38:41 <sgallagh> Does this one have any relationship to the other bootloader ticket?
15:38:41 <bowlofeggs> i honestly don't have a strong opinion on this one. it seems like a lot of other people do though!
15:38:55 <bowlofeggs> sgallagh: which is the other bootloeader one?
15:39:12 <jwb> BLS
15:39:14 <jsmith> While I appreciate the work Hans is doing, I think this is still premature.
15:39:18 <nirik> I am +1 to this now... I think some great tweaks were made to it from feedback
15:39:34 <sgallagh> bowlofeggs: https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
15:39:34 <jwb> sgallagh, i don't think it does
15:39:34 <jsmith> It's definitely getting better based on the feedback, but I'm still not sure it's ready for prime-time
15:39:35 <nirik> sgallagh: I don't think so.
15:39:50 <hansg> jsmith, premature? All the grub changes for this are finished and about to be merged
15:39:57 <zbyszek> +1 too
15:40:14 <sgallagh> I lost track of the thread
15:40:24 <bowlofeggs> i agree that hansg has seemed to do an excellent job listening to feedback and adjusting his plan accordingly
15:40:28 <sgallagh> What's the current quick summary?
15:40:32 <nirik> hansg: how are upgrades handled? they keep the old behavior? or get the new behavior?
15:40:40 <jsmith> hansg: Oh, I didn't realize they were that close to being done.
15:40:55 <hansg> Maybe it helps to be clear, the end goal here is to get Fedora WS to boot looking like this: https://fedorapeople.org/~jwrdegoede/flickerfree-videos/workstation-normal.webm
15:40:58 <nirik> ooh, duh, it's on the change page
15:41:21 <hansg> nirik, the keep the old behavior and right it is on the change page
15:41:27 <bowlofeggs> sgallagh: i think some people just like seeing the grub menu - i think it's fair to say that they can adjust the setting if they want to keep that behavior
15:41:40 <bowlofeggs> i think hansg is realyl proposing changing the defaults? is that right?
15:41:50 <bowlofeggs> default to hidden, unless a crash was detected, i think?
15:41:56 <hansg> Note that for new WS installs disabling this will be a matter of "sudo grub2-envedit - unset menu_auto_hide"
15:42:29 <bowlofeggs> jsmith: what concerns do you have about the change?
15:42:41 <hansg> bowlofeggs, correct, default to show the menu unless a user successfully logged in the previous boot and that user session was active for at least 2 minutes
15:42:55 <sgallagh> hansg: Based on that video,  this isn't just removing the bootloader, it's also killing dracut?
15:43:12 <jsmith> hansg: Just to be clear, I like the idea of flicker-free booting.  My concerns are two-fold, I guess.
15:43:13 * sgallagh wonders where drive decrypt happens
15:43:27 <jwb> sgallagh, s/killing/hiding
15:43:29 <hansg> Erm, so the default is auto-hide, but within that default, the default is to show and only hide if the previous boot was successful
15:43:35 <zbyszek> sgallagh: it's based on a retina scan ;)
15:43:36 <jsmith> 1) Between the BIOS and the GDM screen, how does someone know that the system is still booting and hasn't hung?
15:43:59 <hansg> sgallagh, no dracut is still there, this is a lvm based install, you just don't see it
15:44:05 <jsmith> 2) Is it clear to people how to get back to a GRUB menu?
15:44:06 <hansg> https://fedorapeople.org/~jwrdegoede/flickerfree-videos/laptop-diskcrypt.webm
15:44:43 <sgallagh> hansg: You are well-prepared :)
15:45:50 * nirik really likes the holding down shift thing. Thats one part I would love to see on server as well.
15:45:56 <bowlofeggs> hansg: i also struggle to remember all the details in the (long) thread - there is a way for a user to hold some buttons or something to get to grub manually too iirc?
15:45:57 <hansg> jsmith, currently plymouth will show the splash animation if the boot takes more then 5 seconds, I plan to tweak that a bit to avoid a quick flicker to the bootsplash on a 6 second boot. plymouth records the previous boot time, so the plan is to use that a bit. But a long boot will stoll swithc to the splash
15:45:59 <jsmith> hansg: On the laptop example, I see plymouth between the disk encryption password and GDM, but with the desktop example, I see nothing...
15:46:01 <bowlofeggs> ah shift
15:46:24 <jsmith> hansg: Ah, good to know :-)
15:46:35 <bowlofeggs> the video certainly looks nice
15:46:50 <jsmith> nirik: I too like the "holding down shift" idea...
15:47:03 <hansg> Right, holding shift, or pressing ESC, or pressing F8 will all show grub if it is hidden
15:47:16 <jwb> yeah, +1 to this
15:47:31 <jsmith> OK, in that case, my concerns have been addressed, and I'm now more comfortable voting +1 for this
15:47:39 <sgallagh> As described, I think I'm +1 for this.
15:47:56 <bowlofeggs> cool. the scope says to document the change in release notes - i think it might be good to document the holding shift/esc/f8 thing in the new fedora docs project too
15:48:01 <sgallagh> I'd be okay with it on Server as well, provided there was a hotkey like shift.
15:48:08 <bowlofeggs> for more permanent documentation
15:48:22 <contyk> I hope I'll remember what keys to hold when I run into problems... +1
15:48:39 <jwb> contyk, you are bound to hit one of them while you smash your head into the keyboard.
15:48:41 <bowlofeggs> yeah i like this too, though i'd like to also see the documentation i mentioned above
15:48:48 <sgallagh> contyk: Worst-case as hansg said, you reboot without logging in and it'll work
15:48:54 <fweimer> jwb: Sadly that doesn't work on our console server.
15:49:30 <bowlofeggs> jwb: lol
15:49:40 <hansg> About documents, the plan is to describe how to get the menu and how to disable auto-hide, etc. in the admin guide and then link to that part of the admin guide from the release-notes
15:49:45 <sgallagh> hansg: In addition, I'd like to express admiration for the way you handled the (sometimes... exuberant) disagreement on the devel list.
15:49:46 <jwb> fweimer, i cannot think of a good comeback for that.  you win this round!
15:50:10 <bowlofeggs> hansg: excellent - can you mention that in the scope section?
15:50:18 <jwb> or just do it
15:50:26 <jwb> because that's more important
15:50:28 <hansg> ack will update
15:50:30 <bowlofeggs> hansg: yeah +1 to sgallagh's admiration - you handled the feedback well
15:50:41 <zbyszek> hansg++
15:50:41 <zodbot> zbyszek: Karma for jwrdegoede changed to 1 (for the f28 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:50:48 <sgallagh> hansg++
15:50:51 <zodbot> sgallagh: Karma for jwrdegoede changed to 2 (for the f28 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:50:54 <bowlofeggs> hansg++ indeed
15:50:54 <zodbot> bowlofeggs: Karma for jwrdegoede changed to 3 (for the f28 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:51:03 <bowlofeggs> ok i lost count on votes
15:51:04 <bowlofeggs> i'm +1
15:51:10 <zbyszek> I voted +1
15:51:16 <bowlofeggs> i see +1 from jwb
15:51:20 <zbyszek> nirik also voted +1
15:51:22 <jsmith> +1
15:51:25 <jwb> you guys are mean.  "can you document in the change the plan to document the change" seems cruel.
15:51:28 <jwb> +1
15:51:30 <contyk> also +1
15:51:42 <sgallagh> I was also +1
15:51:48 * nirik was indeed +1
15:51:49 <sgallagh> (Or +3? ;-) )
15:52:03 <bowlofeggs> ok that's 8
15:52:18 <bowlofeggs> #agreed Hiding grub approved (+8, 0, -0)
15:52:19 <jsmith> sgallagh: We can discuss trading my +1 for a sandwich at another time :-)
15:52:22 <bowlofeggs> haha
15:52:31 <bowlofeggs> i can pay you tuesday for a hamburger today
15:52:37 <jsmith> Thanks again for the great communication, hansg
15:52:44 <bowlofeggs> #topic #1906 F29 System Wide Change: Strong crypto settings: phase 2
15:52:44 <bowlofeggs> .fesco 1906
15:52:45 <zodbot> bowlofeggs: Issue #1906: F29 System Wide Change: Strong crypto settings: phase 2 - fesco - Pagure - https://pagure.io/fesco/issue/1906
15:52:54 <bowlofeggs> this one does concern me
15:53:06 <jwb> abstain
15:53:15 <jwb> sorry, i mean i abstain
15:53:36 <t8m> So I shamelessly let it to get to the FESCo to get the FESCo's opinion on this
15:53:48 <bowlofeggs> on one hand, of course stronger crypto is good, but on the other hand i worry about compatibility on the real-world internet
15:54:05 <sgallagh> Yeah, what bowlofeggs said is pretty much my stance as well
15:54:17 <nirik> right, and we don't have the impact that the big browsers have to change people
15:54:32 <bowlofeggs> i actually did hit a problem with an IMAP server i use with F28's increased settings and had to adjust my system policy already
15:54:41 <t8m> so basically do you think it would be good to switch once the big browsers do?
15:54:43 <bowlofeggs> i reported that to the IMAP admin and they "are working on it"
15:55:11 <bowlofeggs> t8m: i think i do lean slightly towards that thought, yeah
15:55:13 <sgallagh> t8m: I'd also be willing to grant a pre-emptive approval to do it mid-stream, yes
15:55:14 <nirik> t8m: yeah, I think we have to kind of move along with them...
15:55:38 <t8m> bowlofeggs, there was some revert during the F28 change, does the current DEFAULT policy still break your IMAP?
15:55:55 <bowlofeggs> t8m: oh i didn't realize that, and so i haven't tried
15:55:57 <t8m> sgallagh, mid-stream?
15:55:58 <bowlofeggs> t8m: i'll try that out
15:56:27 <sgallagh> t8m: Meaning we could ship F29 without it, but if the browsers changed a month later, you could go ahead with the same change without coming back to us
15:56:35 <bowlofeggs> i do like that users can opt into the FUTURE strong settings if they wish
15:56:45 <nirik> yeah.
15:57:04 <jsmith> sgallagh: That sounds reasonable to me :-)
15:57:05 <t8m> The thing is the FUTURE is currently not that useful, but it already has some definition
15:57:22 <bowlofeggs> sgallagh: yeah, since it's security related i'd be into that proposal too
15:57:39 <t8m> So my current plan is to create a policy "UPCOMING" or "NEXT" that would be what is proposed in this change for DEFAULT.
15:57:50 <bowlofeggs> that's a good idea
15:57:56 <nirik> +1
15:58:00 <bowlofeggs> then people can test and give feedback
15:58:27 <zbyszek> We could turn this on for alpha-beta, and then possibly revert before final
15:58:33 <t8m> As the FUTURE is not that useful we might later deprecate it because we do not want to carry too many policies - it would be too confusing
15:58:52 <sgallagh> zbyszek: I don't like the idea of reverting between beta and final, honestly
15:59:03 <bowlofeggs> yeah i also dont like reverting then
15:59:06 <sgallagh> Otherwise what is tested by Beta won't match what we ship
15:59:07 <hansg> jsmith, your welcome
15:59:08 <t8m> zbyszek, we could but the outcome is probably clear
15:59:08 <bowlofeggs> but we could do it between branched and beta?
15:59:56 <sgallagh> Better, I think, would be for that NEXT policy to exist and for us to run a Test Day for it
16:00:05 <zbyszek> sgallagh: yep, that's much better
16:00:09 <bowlofeggs> sgallagh: yeah that's good
16:00:42 <bowlofeggs> sgallagh: would you like to propose your suggestion about waiting for browsers and allowing a mid-release change for a vote?
16:00:51 <t8m> ok, so I'm dropping the change proposal
16:00:52 <sgallagh> Sure, let me phraseeee it...
16:01:02 <t8m> bowlofeggs, sgallagh, I do not think we want that
16:01:13 <bowlofeggs> t8m: no? what would you prefer?
16:01:18 <sgallagh> t8m: Want which?
16:01:27 <t8m> the mid-release change
16:01:58 <t8m> of course unless there is some catastrophic security problem in TLS-1.0 or 1.1 but we would have to handle it as CVE anyway
16:02:04 <bowlofeggs> t8m: would you rather just wait for browsers and then change rawhide at that time?
16:02:10 <sgallagh> t8m: Even if you defer it, I *do* think it would be good to ask QA for a Test Day
16:02:10 <t8m> bowlofeggs, yes
16:02:25 <t8m> sgallagh, ok, we can do
16:02:29 <fweimer> Is it certain that future browser behavior will be replicable in crypto libraries?
16:02:37 <bowlofeggs> t8m: i'm good with that. it's certainly at least less disruptive
16:02:51 <t8m> fweimer, can you be more specific?
16:02:51 <fweimer> Things like fallback (whether secure or not) generally is not due to API differences.
16:04:40 <t8m> still not sure what do you mean - insecure fallback by doing second connection is certainly not something the crypto library can affect - do you mean anything else?
16:05:02 <t8m> some concrete example?
16:05:16 <bowlofeggs> i'm also not quite understanding
16:06:00 <bowlofeggs> we're nearing 15 minutes on this
16:06:09 <fweimer> t8m: Mozilla PSM can do it (and did in the past).  It's a matter of abstraction and how you separate things in alyers.
16:06:32 <bowlofeggs> proposal: Let's defer the change until major browsers make the move first, and then propose it for the next rawhide
16:06:46 <t8m> I do not think anybody wants to reintroduce insecure fallback.
16:07:03 <contyk> +1 to bowlofeggs
16:07:07 <zbyszek> bowlofeggs: +1
16:07:25 <nirik> +1
16:07:31 <sgallagh> bowlofeggs: +1
16:08:32 <bowlofeggs> maxamillion, jsmith, jwb: ?
16:08:57 <maxamillion> +1
16:09:14 <bowlofeggs> ooooh, i meant s/rawhide/release/ in my proposal, or "current rawhide"
16:09:56 <bowlofeggs> let me rephrase since that difference kinda matters
16:10:05 <jsmith> +1
16:10:07 <bowlofeggs> proposal: Let's defer the change until major browsers make the move first, and then propose it as a change for the next release
16:10:11 <t8m> yeah :)
16:10:17 <zbyszek> I read that as "rawhide that will be the next [release]"
16:10:31 <zbyszek> still +1
16:10:42 <bowlofeggs> yeah that's what i had intended, but realized it could be interpreted as meaning yuo ahve to wait for the rawhide after the next branch, which could mean a really long time
16:11:26 <sgallagh> bowlofeggs: Still +1
16:11:38 <bowlofeggs> contyk, nirik, maxamillion: still +1?
16:11:42 <contyk> still
16:11:52 <nirik> +1still
16:12:03 <maxamillion> yes
16:12:20 <bowlofeggs> ok i count +6
16:12:45 <bowlofeggs> or 7 actually
16:12:45 <jwb> i said i abstained
16:12:49 <bowlofeggs> oh right
16:12:51 <bowlofeggs> ok cool
16:13:12 <bowlofeggs> #agreed Let's defer the change until major browsers make the move first, and then propose it as a change for the next release (+7, 1, -0)
16:13:25 <bowlofeggs> #topic #1907 F29 System Wide Change: i686 Is For x86-64
16:13:25 <bowlofeggs> .fesco 1907
16:13:27 <zodbot> bowlofeggs: Issue #1907: F29 System Wide Change: i686 Is For x86-64 - fesco - Pagure - https://pagure.io/fesco/issue/1907
16:13:36 <bowlofeggs> dgilmore has thoughts on this one
16:13:37 <t8m> Thank you for your time and discussion
16:13:39 <t8m> bye
16:13:43 <bowlofeggs> thanks t8m!
16:13:55 <bowlofeggs> fweimer: you are up!
16:14:19 <fweimer> bowlofeggs: Yup.  Do I have to say anything?
16:14:37 <zbyszek> fweimer: first, can this change be renamed to something more informative
16:14:38 <zbyszek> ?
16:14:43 <fweimer> I'm pretty sure that this doesn't require rebuilding i686 packages for the i686 alternative architecture.
16:15:31 <fweimer> zbyszek: What's confusing about it?  It's about clarifying that i686 is for the x86_64 multilib compose.
16:16:01 <fweimer> I can rename it and put SSE2 in the title, but I was worried it would break something.
16:16:04 <nirik> so, if we still build everything we do now, what is the failure mode when someone tries to install a i686 machine that doesn't meet the bar that we raised? I guess it doesn't boot?
16:16:19 <bowlofeggs> fweimer: so this change does not affect the i686 alt arch at all, only the x86_64 arch multi-lib stuff?
16:16:26 <sgallagh> fweimer: As named, it carries with it the implication that we would stop producing images/install trees for the i686 arch
16:16:35 <fweimer> sgallagh: But didn't we do that already?
16:16:36 <sgallagh> (Which I would vote in favor of, but which is clearly NOT the intent of this Change)
16:16:42 <fweimer> sgallagh: I was told so.
16:16:45 <sgallagh> fweimer: No,
16:16:46 <nirik> no.
16:16:50 <bowlofeggs> fweimer: the link tot eh releng ticket seems to be a 404 https://pagure.io/releng/issues/7543
16:17:01 <nirik> we still produce it all, we just do not block release for bugs in it.
16:17:26 <zbyszek> fweimer: IIUC the discussion (and your statement above) correctly, the i686 as still usable on real hardware, as much as they were, assuming that it's not too old.
16:17:28 <nirik> bowlofeggs: remove the s
16:17:35 <nirik> https://pagure.io/releng/issue/7543
16:17:49 <fweimer> zbyszek: Yes, as long as it has SSE2 support.
16:17:58 <zbyszek> fweimer: But the title implies that they are not...
16:18:01 <bowlofeggs> nirik: ah right, i forgot that pagure has an unusual REST structure
16:18:11 <fweimer> zbyszek: In practice, we only test on x86_64 hardware.
16:18:22 <dgilmore> fweimer: We still build i686 images and install media
16:18:23 <bowlofeggs> i'll fix the link in the change
16:18:29 <fweimer> bowlofeggs: Thanks.
16:18:48 <dgilmore> fweimer: the change is just changing the baseline for i686 support
16:18:55 <contyk> do we have any input from the x86 sig?
16:19:28 <zbyszek> Yeah, and a title like "Update i686 baseline to sse2+ (whatever)" would be imho much clearer
16:19:30 <jforbes> Just something to keep in mind, F28 doesn't work on PIII as it is, and the SIG seems to not be putting forth any real effort to fix that
16:19:43 <sgallagh> I'd rename it something like "Drop support for pre-2004 i686 CPUs" (with whatever correct year or identifier makes sense)
16:19:58 <bowlofeggs> yeah i've heard that the x86 sig hasn't been particularly responsive to kernel issues
16:20:00 <fweimer> sgallagh: It's more complicated than that due to multiple vendors/products.
16:20:05 * sgallagh nods
16:20:10 <contyk> jforbes: good to know, thanks
16:20:15 <sgallagh> "Modernize i686 CPU support"
16:20:17 * bowlofeggs runs gentoo on his PIII and it still works...ish
16:20:32 <fweimer> zbyszek: Can I rename the change?  Post the new link to the releng/fesco ticket?
16:20:34 <bowlofeggs> gentoo is on an older kernel though
16:20:56 <fweimer> bowlofeggs: And probably doesn't disable PAE …
16:20:58 <zbyszek> fweimer: You can just edit the title and rename the page in wiki, redirects are created automatically
16:21:02 <jforbes> I would say that the sig did the minimum required to meet the FESCo "functional" definition when it was formed. participation has died down considerably since then, I am not sure it would meet that baseline anymore
16:21:24 <fweimer> zbyszek: Ah, thanks.
16:21:28 <jwb> i'm pretty sure the latest rawhide kernel wasn't even built for i686
16:21:32 <fweimer> This is not TWiki apparently.
16:21:36 <sgallagh> jforbes: Didn't we include a check-in to see if it was still alive as part of the agreement?
16:21:41 <jwb> but that's separate from fweimer's proposal.
16:21:43 <bowlofeggs> jwb: yeah jcline told me that the kernel is currently disabling i686
16:21:49 <jwb> as it should
16:21:50 <jwb> anyway
16:21:52 <fweimer> jwb: After the renaming/retitling anyway.
16:21:53 <zbyszek> fweimer: mediawiki
16:22:05 <jforbes> jwb: it was not, there was a build issue with i686 and it was disabled, that has not been fixed yet
16:22:11 <jwb> +1 for the change, regardless of what it's titled
16:22:28 <jforbes> sgallagh: that was the agreement, yes
16:22:41 <nirik> If we disable the i686 kernel, we need to drop deliverables.
16:23:00 <bowlofeggs> so this change does affect the i686 arch, not just the x86_64 arch multi-lib builds, is that correct?
16:23:06 <jwb> nirik, i said it wasn't built.  i didn't say it was disabled.  the former implies there's still time for the x86 sig to fix it
16:23:11 <dgilmore> jforbes: perhaps that needs a discussion
16:23:19 <jwb> nirik, and i don't want to confuse the kernel issue with what fweimer is proposing
16:23:26 <nirik> jwb: ok. sure
16:23:35 <nirik> bowlofeggs: they are the same rpms...
16:23:42 <jwb> bowlofeggs, not correct.  they are the same
16:23:51 <dgilmore> we can always pull the trigger to drop i686 except for as supporting multilib on x86_64
16:23:56 <nirik> the i686 builds are made, then some of them are adding to x86_64 tree
16:24:05 <bowlofeggs> ah i didn' trealize they were the same builds
16:24:06 <jforbes> bowlofeggs: it does impact the i686 arch, it just doesn't kill it.
16:24:12 <sgallagh> I'm still of the opinion that we should spin off i686 media/deliverables as a remix and the i686 SIG can take full ownership of whether it lives or dies.
16:24:25 <jwb> bowlofeggs, this change causes all i686 RPMs to now allow SSE2, which will cause older hardware to not work with them
16:24:34 <jwb> sgallagh, me too, but that's separate from this proposal.
16:24:45 <sgallagh> Yeah, I know
16:24:51 <bowlofeggs> and i assume it's not simple to start making different rpms for i686 vs x86_64 multi-lib?
16:24:53 <jwb> sgallagh, if we have to kill it "death of 1000 cuts" style, i'll do it
16:24:59 <jwb> bowlofeggs, no
16:25:06 <jsmith> bowlofeggs: No
16:25:14 <zbyszek> bowlofeggs: I think it wouldn't be worth it
16:25:21 <jforbes> bowlofeggs: and is it worth the effort?
16:25:25 <zbyszek> bowlofeggs: double the effort, double the testing
16:25:26 <dgilmore> The biggest historical user of i686 for fedora was the OLPC xo-1 and xo-1.5 this change will mean those are no longer supported
16:25:29 * jsmith has to run... sorry :-(
16:25:36 <bowlofeggs> cool, just want to make sure i understand the decision we are making more fully :)
16:25:39 <dgilmore> I am not sure that is a huge issue at this point
16:25:43 <fweimer> dgilmore: That was AMD Geode, right?
16:25:48 <jwb> yes
16:25:56 <dgilmore> the current x86 baseline is the xo-1
16:25:59 <dgilmore> fweimer: yes
16:26:03 <fweimer> Fedora 28 doesn't run on AMD Geode.
16:26:08 <dgilmore> fweimer: the 1.5 is a via cpu
16:26:14 <fweimer> The x86 SIG didn't have a problem with that.
16:26:25 <bowlofeggs> we have seen that there aren't a lot of people showing up to do the work to support these older machines (thought there are people showing up to complain if we stop supporting them)
16:26:34 <jwb> bowlofeggs, yes
16:26:40 <nirik> always the case. :)
16:26:50 <bowlofeggs> i'm +1 to the proposal
16:26:54 <zbyszek> bowlofeggs: actually, even more if we *declare* that we'll stop supporting them
16:27:02 <bowlofeggs> haha yeah
16:27:06 <jsmith> I'm +1 to the proposal, and sorry again that I have to run.
16:27:15 <bowlofeggs> i think i count +3, me, jsmith, and jwb?
16:27:24 <zbyszek> (I was in the group too, I don't want to drop i686 support just yet, even though I don't use it personally...)
16:27:25 <bowlofeggs> thanks jsmith-away!
16:27:37 <zbyszek> +1 to the proposal
16:27:38 <nirik> +1 to the proposal
16:27:41 <contyk> also +1
16:27:56 <bowlofeggs> maxamillion: ?
16:28:04 <sgallagh> +1 to the proposal
16:28:22 <bowlofeggs> yeah i wish we didn't have to drop it either, but you can't have things if nobody is going to work on them
16:28:25 * nirik thinks people holding on to old gunboat PIII's would do much better to replace them with a small cheap armv7 board. MUCH less power, better in almost every way. But oh well.
16:28:25 <bowlofeggs> sad reality
16:28:29 <dgilmore> I am +1 for what it is worth, I just wanted the language in the change to be better
16:28:36 <bowlofeggs> as said, i do run a PIII still :)
16:28:50 <dgilmore> nirik++
16:29:02 <sgallagh> bowlofeggs: I'll mail you an RPi3+ to replace it. It will be much faster too :)
16:29:09 <bowlofeggs> sgallagh: i accept :)
16:29:13 <jforbes> bowlofeggs: for the performance and power ratio, you could run a rP3 and save a ton of money
16:29:16 <dgilmore> sgallagh: get him a orange pi
16:29:19 <dgilmore> better hardware
16:29:35 <jwb> i'm pretty sure we just approved this.  tally?
16:29:38 * sgallagh wonders if dgilmore thinks I'm made of money
16:29:39 <fweimer> Should I retitle the proposal?
16:29:41 <bowlofeggs> my PIII doesn't run fedora anyway, and is really just kept around for the lols (it was the first computer that was my personal property, as in not a family owned PC)
16:29:48 <dgilmore> sgallagh: they are cheap also
16:30:05 <jwb> let's focus here.  we're 1.5hrs in
16:30:09 <bowlofeggs> i didn't hear from maxamillion but i'll just count him as +0
16:30:14 <bowlofeggs> or just not count at all
16:30:23 <bowlofeggs> #agreed the proposal is approved (+7, 0, -0)
16:30:38 <bowlofeggs> #topic #1908 F29 System Wide Change: NSS load p11-kit modules by default
16:30:39 <bowlofeggs> .fesco 1908
16:30:40 <nirik> fweimer: that would be nice if you could yes
16:30:45 <maxamillion> bowlofeggs: sorry
16:30:45 <zodbot> bowlofeggs: Issue #1908: F29 System Wide Change: NSS load p11-kit modules by default - fesco - Pagure - https://pagure.io/fesco/issue/1908
16:30:45 <jwb> thanks fweimer
16:30:49 <maxamillion> I'm multi-tasking badly
16:31:11 <zbyszek> +1 to the change
16:31:19 <nirik> +1
16:31:26 <jwb> +1
16:31:33 <contyk> +1
16:31:52 <bowlofeggs> +1
16:31:57 <sgallagh> +1
16:32:31 <bowlofeggs> maxamillion: ?
16:33:40 <bowlofeggs> #agreed Approved (+6, 0, -0)
16:33:48 <bowlofeggs> #topic #1909 Allow to have %{?suse_version} condition in spec file
16:33:49 <bowlofeggs> .fesco 1909
16:33:51 <zodbot> bowlofeggs: Issue #1909: Allow to have %{?suse_version} condition in spec file - fesco - Pagure - https://pagure.io/fesco/issue/1909
16:34:03 <contyk> this is a topic for FPC
16:34:07 <bowlofeggs> the policy is pretty clear this isn't allowed
16:34:07 <zbyszek> Yeah
16:34:14 <bowlofeggs> but i also agree that it's more of an FPC decision
16:34:16 <zbyszek> Sorry, my "yeah" was to contyk
16:34:33 <jwb> i think this rule hurts fedora way more than it helps
16:34:37 <sgallagh> Proposal: defer to FPC
16:34:45 <bowlofeggs> sgallagh: +1
16:34:57 <bowlofeggs> jwb: would you like to elaborate?
16:35:17 <sgallagh> jwb: I somewhat agree, but I feel like this decision is something FESCo has clearly delegated to FPC
16:35:31 <jwb> sgallagh, yeah.  but that doesn't mean we can't offer an opinion
16:35:38 <sgallagh> sure
16:35:56 <jwb> bowlofeggs, if i'm a maintainer working across multiple distributions, i very much want to maintain things as commonly as i can
16:35:58 <nirik> It does mean more work and duplication for upstreams
16:36:16 <bowlofeggs> yeah fair enough
16:36:17 <zbyszek> Does anyone have a link to the spec file in questino?
16:36:24 <jwb> bowlofeggs, and the policy is written for readability, which is, frankly, pointless.  the people that read the spec file are the maintainers
16:36:45 <maxamillion> bowlofeggs: I'm sorry, this has been a rough time slot for me
16:36:47 <jwb> initial review gets other eyes on it.  outside of that, 90% of the people working with it are the maintainers
16:36:48 <bowlofeggs> jwb: yeah that's not a bad argument
16:37:10 <nirik> https://github.com/abrt/abrt/blob/master/abrt.spec.in
16:37:21 <jwb> also, technically written a significant portion of our spec files don't ahere to it this because it's totally ambiguous
16:37:30 <jwb> anything with %rhel in it is in violation
16:37:35 <jwb> so it's a dumb and pointless policy.
16:37:52 <bowlofeggs> jwb: do you still agree that it's FPCs call to make though?
16:38:00 <jwb> unfortunately
16:38:03 <sgallagh> Proposal: Defer to FPC, but indicate that FESCo suggests that the "readibility" guidelines can be relaxed.
16:38:10 <nirik> +1
16:38:21 <zbyszek> +1
16:38:29 <bowlofeggs> +1
16:38:41 <contyk> +1
16:39:09 <zbyszek> jwb: looking at that spec file, the use of %suse_version is completely innocuous
16:39:39 <zbyszek> I agree that (at least in this case) the rule hurts more than it helps
16:39:58 <jwb> +1
16:40:08 <sgallagh> +1 to myself, FTR
16:40:31 <sgallagh> err, to my proposal. +1'ing myself would be kind of arrogant
16:40:32 <bowlofeggs> maxamillion: ?
16:40:37 <bowlofeggs> sgallagh: hahah
16:40:45 <contyk> sgallagh++
16:40:45 <zodbot> contyk: Karma for sgallagh changed to 10 (for the f28 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:40:45 <maxamillion> +1
16:40:55 <bowlofeggs> FTR, i think we can safely assume that proposers are +1 to their proposal
16:40:55 <jwb> maxamillion, if you need to tap out, just do so.  then we'll stop pinging you
16:40:58 <sgallagh> Thanks, contyk :)
16:41:17 <bowlofeggs> #agreed Defer to FPC, but indicate that FESCo suggests that the "readibility" guidelines can be relaxed. (+7, 0, -0)
16:41:26 <bowlofeggs> #topic #1910 F29 Self Contained Change: Changes/Update festival to 2.5
16:41:26 <bowlofeggs> .fesco 1910
16:41:27 <zodbot> bowlofeggs: Issue #1910: F29 Self Contained Change: Changes/Update festival to 2.5 - fesco - Pagure - https://pagure.io/fesco/issue/1910
16:41:29 <contyk> +1, finally
16:41:46 <sgallagh> Sure, +1
16:41:50 <bowlofeggs> +1
16:41:53 <nirik> +1
16:42:23 <zbyszek> +1
16:44:28 <bowlofeggs> jwb, maxamillion: ?
16:44:30 <zbyszek> bowlofeggs: ?
16:44:40 <bowlofeggs> waiting on votes, though we do have +5 now...
16:44:44 <maxamillion> +1
16:45:04 <jwb> +1
16:45:14 <bowlofeggs> #agreed approved (+7, 0, -0)
16:45:19 <bowlofeggs> alllright we made it
16:45:27 <bowlofeggs> #topic chair for 2018-06-25
16:45:34 <sgallagh> I haven't done it in a while
16:45:45 <bowlofeggs> #action sgallagh will chair the next meeting
16:45:52 <bowlofeggs> #topic Open Floor
16:45:57 <sgallagh> Which will be on Jun 25th
16:46:25 <bowlofeggs> i will not be present at the next 3 FESCo meetings
16:46:28 <sgallagh> Iff we have any issues not resolved in tickets
16:46:41 <bowlofeggs> because i will be in Oz to straighten dgilmore and ryanlerch out
16:46:44 <sgallagh> bowlofeggs: Nice, long vacation?
16:46:46 <sgallagh> heh
16:46:50 <bowlofeggs> sgallagh: yeah
16:46:51 <zbyszek> and which will include the fine and entertaining ~/.local/bin-in-path topic
16:47:01 <bowlofeggs> i also plan to mess with some dangerous wildlife
16:47:06 <sgallagh> zbyszek: oh lovely
16:47:18 <sgallagh> bowlofeggs: Ah yes, land of the poisonous... everything
16:47:18 <nirik> bowlofeggs: dangerous wildlife is all they have there. ;)
16:47:27 <bowlofeggs> yes, let's not forget to use the new vote-in-ticket and only meeting if needed on the topics :)
16:47:46 <sgallagh> nirik: That's not true, they also have virulent wildlife, brutal wildlife and midly-irritating wildlife
16:47:53 <bowlofeggs> hahaha
16:48:04 <bowlofeggs> i will also be practicing my slang
16:48:09 <sgallagh> I'll write up an announcement draft and sennd it to fesco@ first for review
16:48:14 <bowlofeggs> cool
16:48:16 <sgallagh> nirik: Is fesco@ updated?
16:48:27 <nirik> yes
16:48:27 <contyk> should be
16:48:31 <sgallagh> Great, thanks
16:48:54 <zbyszek> bowlofeggs: If I get to working on the wiki page, I'll keep you updated
16:49:50 <bowlofeggs> zbyszek: cool, and i can do it after ~1 month if you don't have time, no problem
16:50:03 <bowlofeggs> anything else for open floor? closing in 60 s if not
16:50:14 <zbyszek> sgallagh: I think contyk got the mail about meeting time voting, so it should be fine
16:50:21 <sgallagh> zbyszek: I sent that direct
16:50:33 <zbyszek> Ah, OK, nvm then.
16:50:35 <sgallagh> Specifically because I knew the list wouldn't have been updated yet.
16:50:37 <contyk> he did
16:51:05 <bowlofeggs> #endmeeting