15:00:32 <zbyszek> #startmeeting FESCO (2018-03-09)
15:00:32 <zodbot> Meeting started Fri Mar  9 15:00:32 2018 UTC.  The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:32 <zodbot> The meeting name has been set to 'fesco_(2018-03-09)'
15:00:32 <zbyszek> #meetingname fesco
15:00:32 <zodbot> The meeting name has been set to 'fesco'
15:00:38 <zbyszek> .hello2
15:00:39 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:00:46 <sgallagh> #topic Roll Call
15:00:54 <sgallagh> Oh, I'm not chaired.
15:01:00 <nirik> morning
15:01:02 <zbyszek> #chair maxamillion dgilmore nirik  jsmith sgallagh bowlofeggs tyll jwb zbyszek
15:01:02 <zodbot> Current chairs: bowlofeggs dgilmore jsmith jwb maxamillion nirik sgallagh tyll zbyszek
15:01:06 <sgallagh> #topic Roll Call
15:01:11 <sgallagh> .hello2
15:01:12 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:14 <zbyszek> .hello2
15:01:15 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:02:13 <maxamillion> .hello2
15:02:14 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:02:24 <zbyszek> dgilmore jsmith bowlofeggs tyll jwb: fesco meeting in -2
15:02:36 <maxamillion> apologies for my absence the last few meetings, I have a newborn and things are a bit crazy at my house right now
15:02:38 <jwb> hi
15:02:53 <jwb> i'm double booked, but i should be able to pay attention
15:02:54 <jsmith> .hello2
15:02:55 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
15:03:34 <puiterwijk> Hi
15:03:46 <zbyszek> Hello everyone, we have quorum
15:03:57 <zbyszek> I'll wait a minute more, and start
15:04:19 <jsmith> Quorums are good :-)
15:04:35 <zbyszek> spelling is a bitch though ;)
15:04:57 <maxamillion> words are hard
15:05:13 <zbyszek> OK, let's go.
15:05:16 <zbyszek> = Followups =
15:05:16 <zbyszek> #topic #1853 F29 System Wide Change: Enable dbus-broker
15:05:17 <zbyszek> .fesco 1853
15:05:17 <zbyszek> https://pagure.io/fesco/issue/1853
15:05:18 <zodbot> zbyszek: Issue #1853: F29 System Wide Change: Enable dbus-broker - fesco - Pagure - https://pagure.io/fesco/issue/1853
15:05:39 <zbyszek> I think we need to postpone this again. There has been no reply from Change Owners.
15:05:59 <zbyszek> One is on PTO...
15:06:32 <sgallagh> +1 to defer another week
15:06:33 <maxamillion> is there anything by way of the schedule that would make it problematic to postpone again?
15:06:34 * nirik is fine with more (any?) discussion on it.
15:06:38 <sgallagh> There's plenty of time to decide on it before F29
15:06:47 <zbyszek> Yeah, no hurry whatsoever.
15:06:52 <bowlofeggs> .hello2
15:06:54 <bowlofeggs> (sorry for my tardiness - lost track of time)
15:06:55 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:07:08 <zbyszek> Hi!
15:07:13 <zbyszek> #topic #1845 389-ds-base and freeipa on 32 bit arches
15:07:13 <zbyszek> .fesco 1845
15:07:13 <zbyszek> https://pagure.io/fesco/issue/1845
15:07:14 <zodbot> zbyszek: Issue #1845: 389-ds-base and freeipa on 32 bit arches - fesco - Pagure - https://pagure.io/fesco/issue/1845
15:07:31 <zbyszek> Do we have any news here?
15:07:39 <jwb> i don't think so
15:07:45 <bowlofeggs> zbyszek: i tried to follow up on this one but i don't feel like i have the info
15:07:47 <jsmith> I haven't heard anything :-(
15:07:50 * nirik checks bugs
15:07:50 <bowlofeggs> they also still did not file a change
15:07:54 <bowlofeggs> i asked them to
15:07:55 <bowlofeggs> :/
15:08:04 <bowlofeggs> note that there's a bug linked from the bug
15:08:19 <maxamillion> bugs on bugs on bugs
15:08:26 <sgallagh> https://bugzilla.redhat.com/show_bug.cgi?id=1530832#c9 has more info
15:09:12 <jsmith> At least they think it's just i686 that is affected, and not 32-bit ARM
15:09:14 <sgallagh> So it sounds like A) only i686 and B) only in newly-written code since F27
15:09:26 <sgallagh> So there's no way to know yet if it has real-world impact
15:09:37 <sgallagh> But their tests leave them without a warm fuzzy feeling
15:09:37 <bowlofeggs> we have the i686 sig
15:09:43 <bowlofeggs> can we ask them to care about this and move on?
15:09:50 <bowlofeggs> or was that just about the kernel?
15:10:14 <zbyszek> That's a good idea. If i686-sig does not care, then maybe the issue is overblown (or i686-sig does not exist ;))
15:10:28 <bowlofeggs> either way a change should be filed
15:11:18 <bowlofeggs> proposal: kick the issue to i686 sig, and simultaneously get an f28 change filed. the change can be withdrawn if i686 sig can fix this in time
15:11:26 <jwb> hm
15:11:37 <maxamillion> bowlofeggs: +1
15:11:46 <jsmith> bowlofeggs: +1 to your proposal, but what if they don't file a change?
15:11:47 <zbyszek> bowlofeggs: +1
15:11:47 <nirik> well, it's still murky to me where the issue is...
15:11:47 <jwb> if it's just i686, why did they disable arm?
15:11:52 <jwb> or did they not do that
15:11:59 <jsmith> jwb: Exactly what I was trying to get to the root of...
15:12:25 <zbyszek> If they have to write up a change page, it'll have to include those things.
15:12:35 <bowlofeggs> jsmith: can we just decree that the packager has to file the change?
15:12:55 <jwb> i don't want to kick an issue to the i686 sig if it isn't truly i686-only.  that would be mean, for a sig that is rather understaffed/ethereal
15:12:55 <nirik> also note that they blocked the x86 arch blocker bug...which if there is a i686 sig, they should be watching. ;)
15:12:59 <bowlofeggs> basically say they either have to file the change or bring 686 back?
15:13:08 <jsmith> jwb: My gut feeling was that they thought it was a problem with 32-bit atomics and just disabled all 32-bit arches
15:13:11 <bowlofeggs> jwb: they are saying it is 686 only
15:13:17 <jsmith> bowlofeggs: Sounds fair :-)
15:13:25 <bowlofeggs> jwb: https://bugzilla.redhat.com/show_bug.cgi?id=1530832#c9
15:13:32 <bowlofeggs> "apparently"
15:13:39 <bowlofeggs> i guess that's not the strongest statement
15:14:15 <jwb> this is all "we have a problem.  we don't really care about the problem where it surfaces, let's punt on it entirely"
15:14:16 <nirik> they only excluded i686 from the rawhide package
15:14:18 <bowlofeggs> jwb: i think we can kick it to i686 with no penalty if they don't fix it
15:14:33 <bowlofeggs> basically alert them of the problem - if they want to let it get dropped, fine
15:14:45 <jwb> bowlofeggs, yes, but they don't actually understand the issue, do they?  they're just dropping 32-bit
15:14:47 <bowlofeggs> but still give them an opportunity to get involved and keep it working
15:14:50 <bowlofeggs> let it be their choice
15:15:08 <bowlofeggs> jwb: it does sound like the issue isn't fully understood to me
15:16:14 <zbyszek> jwb, nirik, vote on bowlofeggs proposal?
15:16:22 <jwb> bowlofeggs, right.  and since it isn't understood and they've punted and they also included ARM, i don't think we can say "it's the i686 SIGs" problem
15:16:28 <jwb> -1
15:16:57 <jwb> proposal: FESCo leaves this to the maintainers of the packages and architectures to sort out.
15:16:58 <nirik> I'm not all that in favor... I think we should have the tools folks press them for the real issue so it gets fixed... but we can't really force that
15:18:07 <bowlofeggs> jwb: so ARM is included? i thought they were saying it was only i686
15:18:21 <bowlofeggs> oh but i guess arm is why dgilmore filed in the first place?
15:19:12 <zbyszek> https://src.fedoraproject.org/rpms/389-ds/blob/master/f/389-ds.spec:
15:19:18 <zbyszek> # Exclude 32 bit arches
15:19:18 <zbyszek> ExcludeArch: %{ix86}
15:19:33 <zbyszek> So the comment does not match the line below, but it's just i686 right now
15:19:39 <bowlofeggs> haha
15:19:55 <puiterwijk> I think it did also filter out armv7 before
15:19:59 <jwb> i think they did include arm, then when people complained they dropped it.  again, because they don't have root cause
15:19:59 <puiterwijk> But they might've re-added that later
15:20:10 <bowlofeggs> i would be more worried if all 32-bit were excluded. not to sound mean to 386, but if it's just 386 that does seem less bad to me
15:20:36 <jwb> which is why i said just leave it to the maintainers.  FESCo has nothing they can do here
15:20:39 <jsmith> OK, since they only seem to be excluding i686, I'm all for letting them fiture it out.
15:20:59 <maxamillion> yeah, I'm with bowlofeggs in that I thought it to be i686 only but it's possible I'm lacking context
15:20:59 <nirik> zbyszek: huh, 389-ds-base has i686...
15:21:12 <maxamillion> nirik: lol?
15:21:28 <bowlofeggs> yeah i can be ok with that - and i think it could be good ot specifically alert the 686 sig just for their info (i.e., not requiring anything of them, just a friendly highlight of the issue)
15:21:46 <bowlofeggs> they do need a change i think
15:21:48 <zbyszek> 389-ds has no ExcludeArch in F28
15:22:43 <zbyszek> But 389-ds-base has ExcludeArch: i686
15:22:51 <zbyszek> (as nirik said)
15:23:02 <nirik> my worry about this entire thing is that there is a subtle toolchain bug, which ideally would be found and fixed, but it seems this is hard to isolate.
15:23:11 <bowlofeggs> yeah it does look like the exclude is only on rawhide
15:23:22 <bowlofeggs> https://src.fedoraproject.org/rpms/389-ds/blob/f28/f/389-ds.spec
15:23:28 <bowlofeggs> no exclude there
15:23:35 <bowlofeggs> but it is here: https://src.fedoraproject.org/rpms/389-ds/blob/f28/f/389-ds.spec
15:24:06 <zbyszek> bowlofeggs: those are the same links, no?
15:24:12 * jsmith just got confused
15:24:14 <bowlofeggs> whoops
15:24:15 <bowlofeggs> haha
15:24:20 <bowlofeggs> https://src.fedoraproject.org/rpms/389-ds/blob/master/f/389-ds.spec
15:24:21 <bowlofeggs> sorry
15:24:25 <nirik> bowlofeggs: it's excluded in f28 for 389-ds-base
15:24:30 <nirik> https://src.fedoraproject.org/rpms/389-ds-base/blob/f28/f/389-ds-base.spec#_5
15:24:30 <bowlofeggs> that was a middle click vs. ctrl-v error
15:24:41 <zbyszek> But 389-ds Requires 389-ds-base so that cannot work
15:24:53 <bowlofeggs> oh different package
15:24:53 <nirik> right
15:25:17 <zbyszek> I guess 389-ds is not important at all, it's a noarch package.
15:25:44 <zbyszek> 389-ds-base is what counts, and that has ExcludeArch in F28 and rawhide
15:26:00 <jwb> we've spent almost 20 minutes on this.  we have nothing we can actually do about it.  why are we still discussing here?
15:26:47 <bowlofeggs> proposal: FESCo requires a change for f28, the packagers are otherwise free to sort it out
15:27:42 <jwb> +1
15:27:52 <zbyszek> zbyszek: +1
15:28:20 <nirik> sure, +1.
15:29:00 <nirik> note that there might be also releng changes here at some point... since the i386 server images will stop composing. They aren't blocking, but if they don't work we should remove them/stop trying to make them at some point.
15:29:09 <sgallagh> +1
15:29:10 <jsmith> +1
15:29:30 <jsmith> nirik: Good point, but I don't know what else we can do
15:29:31 <bowlofeggs> nirik: oh true. that should be noted in the change, which should be system-wide
15:30:03 <nirik> well, we can remove them after beta, just means some work
15:30:18 <zbyszek> #agree FESCo requires that a Change be filed for F28, and involved are otherwise free to sort out the issue (+6, 0, -0)
15:30:21 <zbyszek> #info If the change is accepted, releng changes will be required
15:30:47 <zbyszek> Another "nice" topic:
15:30:52 <zbyszek> #topic #1820 Adjust/Drop/Document batched updates policy
15:30:52 <zbyszek> .fesco 1820
15:30:52 <zbyszek> https://pagure.io/fesco/issue/1820
15:30:56 <zodbot> zbyszek: Issue #1820: Adjust/Drop/Document batched updates policy - fesco - Pagure - https://pagure.io/fesco/issue/1820
15:30:59 <nirik> fun!
15:31:08 <puiterwijk> Yay
15:31:10 <nirik> note that there were comments this morning just right before the meeting.
15:31:21 <sgallagh> I made a proposal in the ticket.
15:31:21 <zbyszek> nirik: can you summarize the results of the experiment over the last week?
15:31:38 <nirik> and in fact some just now _during_ the meeting
15:31:41 <puiterwijk> zbyszek: I can tell you that I've only seen stable be pushed out on Monday if I recall correctly
15:31:58 <puiterwijk> (not counting Tuesday, and the Monday one I did because of the dhcp one)
15:32:30 <nirik> zbyszek: as puiterwijk said (he was on push duty)...
15:33:10 <bowlofeggs> yeah we can def make the changes requested by sgallagh pretty easily
15:33:19 <nirik> I think we might step back a second and look at our goals here. My understanding is there were 2: 1) less "flood" of updates for users, 2) less metadata changes for users.
15:33:33 <bowlofeggs> i also found a few deficiencies around severity in bodhi this week which i've been working on
15:33:49 <bowlofeggs> like the CLI not supporting them at all (PR filed for that yesterday)
15:33:58 <sgallagh> nirik: Also "less frequent syncs to mirrors"
15:34:11 <bowlofeggs> nirik: and also 3) a way for QA to test the batch
15:34:19 <nirik> sgallagh: sure, I guess that falls under 2 somewhat...
15:34:22 <bowlofeggs> QA doesn't do that yet, but it would be possible now
15:34:56 <bowlofeggs> i don't know if QA wants to do that
15:35:00 <bowlofeggs> haha
15:35:08 <nirik> yeah, that perhaps should be something we find out. ;)
15:35:29 <sgallagh> I know the OSCI people really want that to happen and are working towards it
15:35:49 <pingou> towards testing batches?
15:35:57 <sgallagh> I believe so, yes
15:36:01 <jsmith> Going back to nirik's goal #1 and goal #2,  I think sgallagh's proposal moves us towards those two goals
15:36:05 <pingou> sgallagh: news to me
15:36:27 <nirik> well, the delta repodata would help 2 a fair bit (but that is only in development)
15:36:31 <sgallagh> hmm, I thought I remembered dperpeet and rsibley mentioning it. But it's been a while.
15:36:41 <zbyszek> Dunno, I have to agree with kkofler that batched is not really working right now.
15:36:53 <sgallagh> zbyszek: I agree it's not working in its current incarnation
15:37:06 <sgallagh> I postulated that the reason for that is because it's implementation didn't take best advantage
15:37:12 <zbyszek> If the delta repodata solves #2, then #1 is not enough of motivation, because it is better done on the client side.
15:37:13 <nirik> I think a user end batching might make more sense for users, barring us testing them... which I think couldbe very valuable
15:37:29 <zbyszek> But we would be able to test them the same way
15:37:45 <nirik> do note that all/most workstation users don't see the 'flood of updates' already, since it's batched on client end.
15:38:01 <bowlofeggs> one nice thing i've noticed this week is that i get more drpms
15:38:11 <maxamillion> +1
15:38:11 <bowlofeggs> that's another subtle benefit of batching
15:38:13 <zbyszek> I mean we could install a default dnf-install-batched.timer that fires on (say) Tuesday, and QA would test that batch.
15:38:16 <maxamillion> I do like drpms
15:38:18 <sgallagh> bowlofeggs: +1
15:38:18 <bowlofeggs> (i don't update every day)
15:38:26 <bowlofeggs> (so i used to not get very many drpms)
15:38:33 <zbyszek> bowlofeggs: I did notice more drpms too
15:38:36 <maxamillion> (same, I update weekly)
15:38:42 <sgallagh> That's an advantage we haven't made clear.
15:38:54 <bowlofeggs> yeah it dind't occur to me until just yesterday
15:38:55 <sgallagh> It's a significant decrease in download usage
15:39:05 <nirik> I used to update every day (and still do on my rawhide laptop), but I don't on my other machines anymore... I just update once a week or so.
15:39:07 <sgallagh> Useful for those on metered or slow connections, certainly
15:40:02 <bowlofeggs> i like the idea of a fasttrack repo, i just don't know if we can do it infra wise
15:40:04 <bowlofeggs> like, resource wise
15:40:12 <bowlofeggs> or if the mirrors would bear it storage wise
15:40:16 <nirik> zbyszek: the timer gets into 'do we auto apply updates' also?
15:40:29 <maxamillion> sgallagh: yeah, on that note apparently metered connections are making a comeback ... I've noticed it in the small print of a lot of recent local offers, so that might become a rising concern for users
15:40:47 <maxamillion> which honestly surprised me
15:40:57 <nirik> I think the fasttrack thing adds a lot of complexity and resources for... probibly not too many people.
15:41:19 <bowlofeggs> nirik: yeah that's a good counter point
15:41:23 <nirik> it's hard to say for sure of course
15:41:56 <maxamillion> ultimately on the note of things, I think "bugfixes batch" and "security updates go out immediately" is a good stance, regardless of security severity
15:42:13 <bowlofeggs> i actually think most security updates aren't important
15:42:17 <nirik> some security fixes are very minor.
15:42:18 <sgallagh> The hardest part of a decision like this is that we will *never* hear from the people it benefits.
15:42:18 <puiterwijk> maxamillion: I am not really sure I'd agree with that general a statement on security bugs..
15:42:21 <jwb> most updates aren't important
15:42:32 <sgallagh> But we will never *stop* hearing from the people who disagree.
15:42:36 <nirik> sgallagh: yep
15:42:46 <bowlofeggs> most of them are very difficult to exploit and also give very little benefit when they are exploited
15:42:56 <maxamillion> they might not be, but who's going to "grade" them and make that decision for all packages across the distro at all times?
15:42:57 <sgallagh> maxamillion: I definitely disagree with that statement on security bugs.
15:43:06 <bowlofeggs> also, it's not just secuirty that can be worthy of skipping to stable - think of a real bad data eating bug
15:43:08 <puiterwijk> maxamillion: RH prodsec does so...
15:43:14 <puiterwijk> That's the data I've been using last week
15:43:18 <bowlofeggs> so a bugfix would also warrant going out right away if it's real bad
15:43:19 <nirik> can you use the gnome-software batching without installing a pile of gui?
15:43:20 <sgallagh> If only because we have those at least every 2-3 days. It would render batching basically meaningless.
15:43:27 <maxamillion> puiterwijk: RH prodsec does that for all of Fedora?
15:43:32 <puiterwijk> Look in RHBZ's for ecurity bugs, and tehre's a whiteboard with severity=(low|moderate|important|critical)
15:43:43 <sgallagh> maxamillion: No, only those things RH also ships.
15:43:52 <maxamillion> then I think it's a moot point
15:43:54 <sgallagh> But honestly, that's 99% of the stuff that *really* matters.
15:43:58 <puiterwijk> sgallagh: not per se. I've seen enough prodsec bugs for things that aren't in products
15:44:06 <sgallagh> interesting
15:44:10 <puiterwijk> They follow external things like oss-security and NVD
15:44:18 <sgallagh> Let's settle for "only guaranteed for"
15:44:23 <puiterwijk> True on that
15:44:50 <bowlofeggs> the CVE itself usually has a score too
15:45:04 <puiterwijk> But there's also other sources, like the CVE database and NVD, which have the CVSS score...
15:45:10 <nirik> so as another datapoint:
15:45:31 <puiterwijk> So tehre's a lot of people checking the importance of security issues and publishing them in useful databases
15:45:34 <nirik> fedora infra has all fedora installs we do setup with dnf autoupdate for security stuff.
15:45:49 <zbyszek> But looking at the list from this week, I think that clamav is something that should not be batched, and php def too
15:46:24 <nirik> to pick a random machine, it's applied them 13 times so far this year.
15:46:36 <bowlofeggs> nirik: that is interesting
15:46:49 * misc also have autoupdate on most servers
15:46:51 <sgallagh> That averages to one a week
15:47:02 <bowlofeggs> sgallagh: a possible amendment to your proposal from the ticket: we could also require a justification from packagers when they pick "urgent" on the severity
15:47:04 <sgallagh> err, a bit more than that, sorry
15:47:11 <maxamillion> I guess my main point is that these entities that may or may not "score" things to give us a metric by which we can mark a security update as "important" or "not important" (or some variant of those) are not Fedora contributors, which means that the responsibility will eventually fall on us or others in the community and I don't think anyone just has a pile of spare cycles sitting around
15:47:12 <nirik> but that was bodhi-backend01, machines with more packages will have more
15:47:14 <puiterwijk> zbyszek: note that for the clamav one, there was a few hours between batched and stable, so I didn't even get the time to look at that
15:47:15 <sgallagh> bowlofeggs: I could be fine with that.
15:47:17 <bowlofeggs> sgallagh: like a text box where they type why it's important, and releng can read it
15:47:24 <puiterwijk> zbyszek: same for the PHP one...
15:48:33 <nirik> proposal: implement the severity stuff proposed in bodhi, ask QA about batch testing plans, go back to normal pushes, revisit next week and keep discussing plans ?
15:48:36 <maxamillion> bowlofeggs: who's going to audit the justifications? who has authority to say "yes, that's a valid justification" or "no, that's not"
15:48:58 <nirik> or perhaps if we don't know what we want to do in bodhi yet, drop that
15:49:02 <bowlofeggs> maxamillion: perhaps the push duty person?
15:49:04 <jsmith> nirik: I think that's reasonable.  Consider me +1
15:49:29 <zbyszek> bowlofeggs: I think that's infeasible in the long term, just too much work
15:49:40 <puiterwijk> maxamillion: I'd say we trust the packagers but if the updates they submit consistently get marked as Urgent, maybe someone can take a look and if in doubt, submit to fesco?
15:49:43 <bowlofeggs> nirik: i can +1 with the exception that i can't do that myself in the next week (too much modularity and container and other things on my plate)
15:49:52 <maxamillion> alright
15:49:57 <puiterwijk> (and the data on "who marks things as urgent a lot" is easy to gather)
15:50:03 <nirik> bowlofeggs: fair, we can drop the bodhi part until we decide more anyhow
15:50:08 <maxamillion> I think the whole thing is silly, but consensus says otherwise so I'm going to back away from this item
15:50:42 <bowlofeggs> the bodhi changes aren't too hard, though they technically are backward incompatible so would require an x release bump, unless we carry a fedora-specific patch
15:50:53 <sgallagh> puiterwijk: I think that's a fair middle-ground.
15:50:58 <bowlofeggs> or maybe i could make it a setting which severity levels are allowed...
15:51:13 <nirik> maxamillion: the whole thing being batched updates? or requiring some kind of justification for every update?
15:51:17 <sgallagh> bowlofeggs: Let's leave the justifications out for now until and unless it becomes obvious they're needed
15:51:22 <bowlofeggs> sure
15:51:36 <jsmith> Or, in other words, "assume positive intent" :-)
15:51:45 <sgallagh> yes
15:51:47 <bowlofeggs> yeah that's good
15:52:04 <sgallagh> I also think that reducing the number of choices to "batched" and "urgent" makes it more clear to our users what the fields mean
15:52:30 <jwb> we should probably just tie urgency to whatever the urgency of the bug is
15:52:30 <bowlofeggs> true
15:52:35 <sgallagh> I think that, given the choice, the vast majority of our packagers will do the right thing
15:52:37 <jwb> and not let it be selectable in bodhi
15:52:46 <bowlofeggs> one thing to keep in mind is that yum and dnf also consume this urgency field
15:52:48 <sgallagh> jwb: Not every update has BZs
15:52:53 <jwb> sgallagh, then it isn't urgent
15:52:57 <maxamillion> nirik: requiring justification and the idea that some security updates should be batched instead of sent out as soon as they hit stable
15:53:01 <bowlofeggs> so i actually can't use "standard" i don't think
15:53:04 <sgallagh> jwb: Fair point
15:53:10 <bowlofeggs> but i could probably do medium and urgent or something
15:53:21 <bowlofeggs> i assume that yum/dnf expect certain specific strings there
15:53:24 <bowlofeggs> (not sure)
15:53:37 <sgallagh> bowlofeggs: Well, at the UI layer you could translate those
15:53:39 <nirik> maxamillion: I'm with you on the first part... but having seen some of the things that get CVE's... some security updates are super duper stupid. :)
15:53:40 <maxamillion> nirik: I agree that some security updates don't need everyone to drop everything they're doing and get them tested and pushed out immediately, but it seems silly to me to let them sit and wait for a batch push
15:53:41 <sgallagh> And just store them differently
15:53:48 <bowlofeggs> sgallagh: true
15:54:42 <nirik> proposal: ask QA about batch testing plans, go back to normal pushes, discuss bodhi/other plans on list, revisit next week
15:54:50 <maxamillion> nirik: that's fine, but I don't think we realistically have the people to really monitor and/or police that on a daily basis across all updates so it just makes more sense to me to not follow the Red Hat Errata model
15:54:54 <zbyszek> nirik: +1
15:55:01 <bowlofeggs> maxamillion: some security updates can't be exploited unless other security measures are also broken. in some cases they just can't be exploited at all, but should still be fixed. i think those are obvious to wait
15:55:05 <sgallagh> maxamillion: I've handled plenty of CVEs that boiled down to "first have sudo access on the console"...
15:55:08 <bowlofeggs> maxamillion: ime, most CVEs are in that category
15:55:21 <maxamillion> bowlofeggs: I disagree, I say push them out ... what harm does it do?
15:55:28 <bowlofeggs> i read oss-security and so many CVEs really are like that
15:55:39 <bowlofeggs> maxamillion: well it triggers everyone to download 40 MB
15:55:40 <sgallagh> maxamillion: Unnecessary churn on the mirrors/metadata
15:55:51 <nirik> and more flood of useless updates. ;)
15:55:52 <bowlofeggs> nirik: +1
15:55:54 <maxamillion> sgallagh: how many people copy and paste "sudo curl foo.com | bash" ?
15:56:30 <maxamillion> like I said, I'm stepping away from this item
15:56:46 <sgallagh> maxamillion: My point was that the actual exploit often requires enough access that the exploit itself is meaningless
15:57:05 <zbyszek> sgallagh: but I think that's really up to maintainer to decide
15:57:12 <sgallagh> Sure, I agree
15:57:23 <sgallagh> But it's why I think "security != urgent" in all cases
15:57:23 <zbyszek> We should trust maintainers to do their job, no need to secondguees.
15:57:27 <puiterwijk> zbyszek: agreed. Which is why I think that not all security marked bugs should be treated equal
15:57:32 <sgallagh> zbyszek: We're in violent agreement :)
15:57:36 <zbyszek> Yes!
15:57:41 <puiterwijk> Yeah. That
15:57:54 <maxamillion> sgallagh: I agree that not all security updates are urgent, I attempted to clarify that
15:57:57 <bowlofeggs> and urgent != security too (bad bugs)
15:57:59 <maxamillion> nevermind, stepping away from this one
15:58:02 <zbyszek> OK, so we have +3 to nirik, anyone else?
15:58:07 <sgallagh> OK, I think we're all agreed there
15:58:09 <maxamillion> +1 to nirik
15:58:10 <bowlofeggs> urgent just means... urgent :)
15:58:25 <bowlofeggs> i do think newpackage and enhancement updates should not be urgent
15:58:28 <sgallagh> nirik: +1
15:58:35 <jsmith> +1 to nirik's proposal, in case my vote wasn't clear
15:59:14 <jwb> +1 i suppose
15:59:41 <zbyszek> #agree Ask QA about batch testing plans, go back to normal pushes, discuss bodhi/other plans on list, revisit next week (+6, 0, -0)
15:59:44 <puiterwijk> Oh, can I get one clarification, seeing that I'm still on push duty?
15:59:51 <bowlofeggs> once f28 calms down i can get bodhi to be more in line with these ideas
15:59:59 <zbyszek> #undo
16:00:00 <zodbot> Removing item from minutes: AGREED by zbyszek at 15:59:41 : Ask QA about batch testing plans, go back to normal pushes, discuss bodhi/other plans on list, revisit next week (+6, 0, -0)
16:00:02 <puiterwijk> Do people want me to push out everything today, or is the urgent-only push I did an hour ago good enough?
16:00:19 <nirik> puiterwijk: whats done is fine.
16:00:20 <puiterwijk> zbyszek: sorry. Wasn't meant to revert the vote. Just clarification on when "back to normal pushes" starts
16:00:26 <bowlofeggs> puiterwijk: i think today's push was fine - i think we just go back to normal tomororw
16:00:28 <puiterwijk> nirik: okay. Just wanted to make sure
16:00:32 <zbyszek> Yeah, but I thihk I miscounted
16:00:39 <nirik> I just wanted to go back to normal so we don't have to explain what to do to every other releng person on push duty...
16:01:00 <puiterwijk> nirik: well, we have a simple operation to do it now, so that's simple :)
16:01:00 <zbyszek> #agree Ask QA about batch testing plans, go back to normal pushes, discuss bodhi/other plans on list, revisit next week (+7, 0, -0)
16:01:02 <bowlofeggs> yeah if we want that behavior it'd be better if bodhi did it
16:01:16 <nirik> puiterwijk: oh yeah, truuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuue.
16:01:18 <puiterwijk> bowlofeggs: funny enough, it kinda does. I didn't want to do it manually.
16:01:21 <nirik> argh.
16:01:27 <zbyszek> nirik: wayland?
16:01:32 <bowlofeggs> puiterwijk: yeah that --urgentonly patch :)
16:01:34 <puiterwijk> bodhi-push --urgent-only :)
16:01:47 <zbyszek> OK, let's move on.
16:01:49 <zbyszek> #topic #1745 F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL
16:01:50 <zbyszek> .fesco 1745
16:01:50 <zbyszek> https://pagure.io/fesco/issue/1745
16:01:50 <nirik> my sound card power saving likes to cause a nice delay when it loads in to beep on a highlight.
16:01:52 <zodbot> zbyszek: Issue #1745: F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL - fesco - Pagure - https://pagure.io/fesco/issue/1745
16:02:18 <sgallagh> uh... F27?
16:02:19 <puiterwijk> F27 still? I think that title might need updating
16:02:32 <nirik> it's 28 now.
16:02:37 <nirik> it got deferred
16:02:39 <puiterwijk> Yeah. The title needs updating
16:03:02 <zbyszek> It's ON_QA. I'm not sure if there's anything to discuss here.
16:03:23 <nirik> oh, and it was orig a f26 one that got delayed to f27. ;)
16:03:26 <sgallagh> Well, I think the technicality is that we may not have approved it for F28
16:03:28 <nirik> but yeah, ack +1, move on
16:03:30 <sgallagh> But I'm +1
16:03:44 <Southern_Gentlem> (fyi my f27-20180302 updated isos now show 115M of updates)
16:04:12 <bowlofeggs> +1
16:04:18 <jsmith> +1 from me
16:04:28 <zbyszek> +1
16:04:31 <maxamillion> +1
16:05:21 <zbyszek> #agree F28 System Wide Change: Switch OpenLDAP from NSS to OpenSSL is reapproved (+6, 0, 0)
16:05:31 <zbyszek> #topic FESCo meeting time
16:05:48 <zbyszek> http://whenisgood.net/fesco2018roundtwo/results/ss5khfp
16:06:21 <zbyszek> We only have 8 answers, but there's isn't much more choice.
16:06:32 <zbyszek> proposal: keep current time, stop discussing
16:06:43 <bowlofeggs> +1
16:06:44 <jwb> i was +1 to the OpenLDAP change
16:06:54 <jwb> i'm also +1 to keeping the current time
16:06:56 <nirik> note: Daylight stealing time starts in the US this weekend.
16:07:03 <maxamillion> +1 - that works for me, my availability is pretty open
16:07:12 <nirik> so, do we keep to the same UTC time? or ?
16:07:17 * jsmith is fine with the current time, but would prefer Monday or Tuesday
16:07:20 <bowlofeggs> nirik: oof that'll be real early for you, but not relative to the sun :)
16:07:31 <bowlofeggs> it'll be 9 AM for me (it's 10 now)
16:08:06 <bowlofeggs> i do think it's better for meetings to not change with DST
16:08:21 <bowlofeggs> because DST is not observed in all places and in the places it is observed, it changes on different dates
16:08:25 <bowlofeggs> too complicated
16:08:34 <bowlofeggs> and too US-centric to change with the US schedule
16:08:35 <zbyszek> bowlofeggs: +1
16:08:40 <puiterwijk> Yeah, EU changes I think two weeks later
16:08:55 <nirik> bowlofeggs: well, it's 7am for me now...
16:09:29 <zbyszek> nirik: we could move it to 16:00 UTC
16:09:37 <bowlofeggs> that works for me
16:10:01 <jsmith> works for me as well
16:10:21 <nirik> that would be nice... but I am happy to do whatever works for everyone else. I can get up super early... it's not the end of the world.
16:10:45 <zbyszek> nirik: OK, if you can then let's keep current time, because otherwise we run into problems if the meeting are too long.
16:11:05 <nirik> fair
16:11:17 <zbyszek> Let's move on, I think there's general agreement.
16:11:29 <zbyszek> = New business =
16:11:30 <zbyszek> #topic #1861 F28 Changes not in ON_QA status (<100% completed)
16:11:30 <zbyszek> .fesco 1861
16:11:30 <zbyszek> https://pagure.io/fesco/issue/1861
16:11:32 <zodbot> zbyszek: Issue #1861: F28 Changes not in ON_QA status (<100% completed) - fesco - Pagure - https://pagure.io/fesco/issue/1861
16:13:26 <bowlofeggs> i'm good with retiring the django packages
16:14:06 <zbyszek> propoposal: wait one more week for maintainers of django packages to reply, and retire after
16:14:16 <jsmith> zbyszek: +1
16:14:18 <maxamillion> +1
16:14:32 <nirik> I suppose. I'd be fine with just doing it... it's been a while coming, but +1
16:14:55 <bowlofeggs> +1
16:15:03 <bowlofeggs> i could also +1 just doing it
16:15:09 <bowlofeggs> it's been a real long time
16:15:29 <zbyszek> bowlofeggs: one more week doesn't really change anything, since we're in freeze
16:15:44 <bowlofeggs> true
16:16:21 <zbyszek> jwb ?
16:16:27 <jsmith> Honestly, I could go either way.
16:16:52 <bowlofeggs> it will also cost us a few more minutes x 8 people in next week's meeting if we don't do it now
16:17:01 <bowlofeggs> and it's really unlikely they'll respond after this long
16:17:10 <bowlofeggs> but +1 to either
16:17:17 <zbyszek> No, let's vote now, and retire without talking about it any more
16:17:34 <jsmith> OK, then consider me +1 for "retire now"
16:17:47 <zbyszek> It's just that I opened two more bugs asking maintainers for update/retire, and they need a few days to answer.
16:17:56 <zbyszek> (Even though I don't expect an answer.)
16:18:34 <zbyszek> So, we have +5 to retire in a week. Do you want to vote on retiring now?
16:18:57 <zbyszek> (I'd be against, so it won't pass ;-] )
16:19:11 <sgallagh> Then let's just move on :)
16:19:16 <bowlofeggs> sure
16:19:23 <zbyszek> #agree Django packages which are incompatible with Django2.0 will be retired after one more week (+5, 0, 0)
16:19:36 <zbyszek> #topic #1859 Review of release blocking deliverables for F28
16:19:36 <zbyszek> .fesco 1859
16:19:36 <zbyszek> https://pagure.io/fesco/issue/1859
16:19:37 <zodbot> zbyszek: Issue #1859: Review of release blocking deliverables for F28 - fesco - Pagure - https://pagure.io/fesco/issue/1859
16:19:55 <bowlofeggs> do we not need to talk about the others from the last ticket?
16:20:21 <zbyszek> #undo
16:20:21 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f9b0d6ef550>
16:20:34 <zbyszek> bowlofeggs: of course, sorry, I got carried away
16:21:08 <zbyszek> I think they're all moving forward, so we can just sit back and relax for now
16:21:32 <sgallagh> (Unless you're one of the people helping move it forward, of course!)
16:21:34 <bowlofeggs> i have seen patches for the krb in python one go by recently
16:21:40 <bowlofeggs> so i know that one is making progress
16:22:02 <bowlofeggs> i assume sgallagh can tell us about modularity?
16:22:22 <sgallagh> bowlofeggs: I put an update into the ticket this morning
16:22:24 <bowlofeggs> the s390x one had some performance issues with composing iirc?
16:22:25 <nirik> Getting closer...
16:22:45 <bowlofeggs> i have no idea about the crypto one
16:22:48 <zbyszek> ignatenkobrain says "Replace glibc's libcrypt with libxcrypt" is done
16:22:56 <sgallagh> oh, hmm.. another ticket maybe
16:23:13 <sgallagh> No, it was this one.
16:23:23 <bowlofeggs> oh i see the comments in the fesco ticket
16:23:23 * sgallagh got confused by the quick jump to the next topic
16:23:24 <bowlofeggs> haha
16:23:30 <nirik> Still another pungi change needed today... the fix yesterday caused another issue. Hopefully we will get a f28 / rawhide compose with modular right soon.
16:24:06 <bowlofeggs> there are some bodhi problems that puiterwijk discovered yesterday too :/
16:24:08 <nirik> (well, 28, rawhide currently has no modules actually made for it)
16:24:10 <puiterwijk> Note that we have f28-modular-updates-testing, but last night we found fundamental problems wiht modularity and bodhi which we are resolving
16:24:21 <nirik> and then there's update issue... yeah, that
16:24:40 <ignatenkobrain> rpm -q libxcrypt ;)
16:24:45 <puiterwijk> I have a patch for that that might work, but will proceed working on that on Monday, so then we'll know more
16:24:53 <bowlofeggs> anybody know what the deal with s390x one is?
16:25:28 <nirik> bowlofeggs: we disabled ostree because it was painfully slow. I think the rest were re-enabled and are waiting for us to have a working compose otherwise.
16:25:28 <bowlofeggs> oh there is a comment on the bz fo rthat one
16:25:35 <bowlofeggs> cool
16:25:51 <zbyszek> "Only item remaining is building successfully cloud-base image. Root cause of this failure has been identified. It is failing because time required by imagefactory to finish building image exceeds specified timeout (which is 7200 seconds in koji). Increasing timeout value should give us successful cloud-base image."
16:26:14 <nirik> ah yeah, there's a patch for that pending
16:26:15 <dgilmore> zbyszek: sorry I can not make the current meeting tim for the next few weeks
16:26:17 <bowlofeggs> i'm +1 to waiting another week on these
16:26:36 <zbyszek> bowlofeggs: +1
16:26:40 <jsmith> bowlofeggs: +1
16:26:41 <puiterwijk> Do note that 7200 seconds is already 2 hours.
16:26:49 <puiterwijk> So this means that the composes will become significantly longer
16:27:12 <puiterwijk> (just pointing it out, since "shorter compose times" was also something people wanted)
16:27:21 <dgilmore> puiterwijk: indeed
16:27:35 <dgilmore> puiterwijk: it seems like we should investigate why they are so slow
16:27:45 <zbyszek> dgilmore: can you answer the whenisgood poll?
16:27:50 <dgilmore> zbyszek: no
16:28:02 <zbyszek> ?
16:28:03 <puiterwijk> Note that we also had another suggestion on improving the IO by trying to virtualize an s390x composer.
16:28:06 <dgilmore> zbyszek: I currently do not know my availability
16:28:16 <zbyszek> dgilmore: oh, OK.
16:28:25 <dgilmore> zbyszek: I am in the process of changing jobs and teams
16:28:53 <dgilmore> I will know my new schedule and availability soon
16:29:07 <zbyszek> dgilmore: OK, we should revisit then.
16:29:45 <dgilmore> zbyszek: I expect I will have a bit more free time in the US mornings
16:29:47 <maxamillion> puiterwijk: virtualize or emulate?
16:30:07 <puiterwijk> maxamillion: emulation I guess. Basically, run s390x composes on an x86_64 builder in PHX2
16:30:21 <bowlofeggs> yeah i suggested that in a prior fesco meeting
16:30:25 <puiterwijk> Since the main problem with s390x is just the I/O (the data needs to go across the country from West coast to East coast twice)
16:30:33 <bowlofeggs> not sure if it would be faster or slower though :)
16:30:48 <maxamillion> puiterwijk: yeah, rgr .... I don't think the clarification matters outside my personal curiosity
16:30:53 <bowlofeggs> the CPU tasks would be real slow, but the B/W would be local. so which one wins? :)
16:30:53 <maxamillion> :)
16:30:53 <puiterwijk> bowlofeggs: yeah. I think we should just try it once...
16:30:54 <nirik> and may have bugs/issues working on real hw then
16:31:11 <puiterwijk> maxamillion: yeah, totally fine. I was being too vague.
16:31:19 <bowlofeggs> yeah the emulation itself could be error prone too
16:31:34 <nirik> in general we have been very against emulated stuff or cross compiling.
16:31:45 <puiterwijk> nirik: yeah. Though it is not the actual binary building, "just" the building of images.
16:31:50 <bowlofeggs> it was just a hair brained wacky idea, but could be worth trying if even just to know which is faster
16:32:11 <bowlofeggs> why does the image building require the arch?
16:32:18 <puiterwijk> bowlofeggs: scriptlets
16:32:20 <nirik> sure. Perhaps we could ask the change owner to test. ;)
16:32:21 <puiterwijk> (primarily)
16:32:28 <bowlofeggs> ah
16:32:41 <puiterwijk> Everything else in rpm install is just "extract cpio archive"
16:32:44 <puiterwijk> nirik: yep, agreed
16:32:47 <bowlofeggs> yeah makes sense
16:33:02 <zbyszek> dgilmore, jwb, sgallagh, maxamillion, nirik, vote on bowlofeggs proposal?
16:33:20 <bowlofeggs> (which is to give another week)
16:33:25 <maxamillion> wait, I missed it ... sorry
16:33:26 <maxamillion> +1
16:33:31 <sgallagh> +1
16:34:28 <nirik> +1
16:34:30 <jsmith> +1
16:35:08 <zbyszek> #agree Wait another week for changes not in ON_QA status (+6, 0, -0)
16:35:30 <zbyszek> OK, I think now we can move on.
16:35:31 <zbyszek> #topic #1859 Review of release blocking deliverables for F28
16:35:59 <zbyszek> .fesco 1859
16:35:59 <zbyszek> https://pagure.io/fesco/issue/1859
16:36:00 <zodbot> zbyszek: Issue #1859: Review of release blocking deliverables for F28 - fesco - Pagure - https://pagure.io/fesco/issue/1859
16:36:16 <puiterwijk> Note that I replied to bowlofeggs' question (and added one of my own) a few minutes ago
16:36:32 <puiterwijk> (I had not seen a notification from getting pinged on it)
16:36:54 <sgallagh> Server SIG voted on and updated our deliverables this week
16:37:30 <jwb> i had to drop for a bit, apologies
16:37:34 <sgallagh> We had previously voted to block on issues on three aarch64 boards, so we updated the wiki to reflect this
16:37:49 <nirik> yeah, it looks fine for me except for Modules... are they blocking?
16:38:04 <bowlofeggs> puiterwijk's suggestion is interesting - should we say that a repository is a release blocking deliverable?
16:38:10 <jsmith> My understand was that they weren't blocking...
16:38:20 <jsmith> ... but I could be wrong
16:38:26 <bowlofeggs> i mean, we don't say that about other repos, but i'd think not having the ability to deliver updates would be "release blocking" if that happened for rpm?
16:38:54 <bowlofeggs> like if bodhi suddenly couldn't update f28 normal rpms for some reason, would that be release blocking?
16:39:27 <zbyszek> bowlofeggs: yeah, there's some criterion about being "able to install updates"
16:39:30 <nirik> well, the release critera is kinda about... the release...
16:39:30 <puiterwijk> bowlofeggs: well, there's "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image.
16:39:49 <puiterwijk> I guess that to be able to notify of updates, there must be an ability to ship updates?
16:39:50 <bowlofeggs> alternately, since modules are now "add on", should they be release blocking? couldn't they easily be added after the release if necessary?
16:40:29 <bowlofeggs> like, fedora server will still work if modules aren't ready at release day, right?
16:40:58 <nirik> right.
16:41:30 <nirik> we don't really have any release critera around modules or even testing guidelines right?
16:41:55 <puiterwijk> Not that I could find in any of the official pages
16:42:19 <zbyszek> proposal: approve proposed list, and if modules need to be added, we can do that later when there are testing guidelines and release criteria for them
16:42:24 <bowlofeggs> it does sound like it shouldn't block the release to me, based on my assumption that server can still work without it if it's not ready in time
16:42:33 <nirik> zbyszek: +1
16:42:39 <bowlofeggs> zbyszek: +1
16:42:39 <puiterwijk> Also, I don't think QA has tests for them, at least in openqa
16:42:47 <nirik> we should ask about those things on lists...
16:43:26 <sgallagh> zbyszek: +1
16:43:29 <zbyszek> Any volunteer to ask start the thread?
16:44:33 <zbyszek> jwb, jsmith, maxamillion, vote please
16:44:39 <bowlofeggs> sgallagh: since you work on modules, you wanna start the thread?
16:44:48 <bowlofeggs> i can do it too, but am less familiar with the subject
16:44:58 <jsmith> +1
16:45:21 <sgallagh> bowlofeggs: I can do that next week, probably.
16:45:24 <sgallagh> I'm overloaded today.
16:46:31 <nirik> should be devel and test lists most likely
16:46:36 <maxamillion> +1
16:47:11 <zbyszek> #agree Proposed list is approved. Modular deliverables may be added to the list later when there are testing guidelines and release criteria for them (+6, 0, -0)
16:47:15 <zbyszek> #action sgallagh to start a thread on the mailing lists (devel and test) about the criteria
16:47:16 <bowlofeggs> i kinda feel like modularity shouldn't even delay the beta
16:47:27 <bowlofeggs> imo, it shouldn't be a release blocker since it's an add on now
16:48:07 <zbyszek> OK, let's move on. This we can discuss in the thread ;)
16:48:12 <zbyszek> #topic #1858 Proposed Fedora 29 schedule
16:48:12 <zbyszek> .fesco 1858
16:48:12 <zbyszek> https://pagure.io/fesco/issue/1858
16:48:12 <bowlofeggs> sure
16:48:13 <zodbot> zbyszek: Issue #1858: Proposed Fedora 29 schedule - fesco - Pagure - https://pagure.io/fesco/issue/1858
16:48:31 <bowlofeggs> +1
16:48:36 <zbyszek> +1, I'll go with the crowd
16:48:44 <jsmith> +1 -- looks sane
16:48:50 <nirik> note that with f28 we are trying the 3 week freezes, we don't know if this will help or not yet... :)
16:49:03 <nirik> but sure, +1 and we can revisit later if needed
16:49:24 <sgallagh> 0 (I haven't had a chance to examine it closely and I'm multi-tasking right now)
16:49:53 <maxamillion> +1
16:49:59 <zbyszek> jwb, dgilmore?
16:50:15 <puiterwijk> I would actually suggest putting one day between bodhi activation and freeze start (at least releng/infra freeze). But that might be colored by this time around's results
16:51:44 <bowlofeggs> puiterwijk: were there issues with it being the same day that that would help?
16:51:51 <nirik> puiterwijk: people asked them to be on the same day... :)
16:52:17 <puiterwijk> bowlofeggs: the configuration for f28(m) pushes.
16:52:19 <nirik> but yeah, this cycle was rough with all the modularity attempts
16:52:58 <zbyszek> OK to tally the vote and move on?
16:53:02 <puiterwijk> The code fixes wouldn't have been helped, but configuration updates had to be made. People always forget parts, even if it's in the SOPs. And getting one additional day to fix those might be good..
16:53:30 <puiterwijk> nirik: well, regardless of that, there's the "fedora_28_primary_arches" setting and more that we only found out when we tried to push.
16:53:40 <bowlofeggs> puiterwijk: could we adjust that by just having the infra freeze be one day after the releng freeze (i.e., not in this schedule?)
16:53:44 <puiterwijk> I'm reasonably sure we'll always find a new primary_arches flag
16:53:59 <nirik> bowlofeggs: yeah, thats possible indeed.
16:54:05 <puiterwijk> bowlofeggs: well, releng freeze is for all releng boxes I think.
16:54:37 <puiterwijk> At least, that's how I read it. Which, in my mind, includes bodhi settings. But if that's a misinterpretation on my account, then sure
16:55:16 <nirik> you mean the infrastructure freeze?
16:55:30 <bowlofeggs> yeah i don't know where the line is - i assumed that bodhi cahnges were frozen by infra more than by releng
16:55:30 <nirik> there's not a seperate releng one that I know of...
16:55:43 <bowlofeggs> i thought the releng one was more about which packages can go to stable
16:55:50 <jwb> i haven't had time to look at the f29 schedule
16:55:55 <puiterwijk> I thought I've seen references to a releng freeze. But yeah, that's what I mean with misinterpretation
16:56:14 <bowlofeggs> proposal: one more week so people can look at this schedule
16:56:19 <puiterwijk> So yeah, let's change that to "proposal: infra freeze 1 day later", but that's infra
16:56:21 <bowlofeggs> (since two of us haven't had time yet)
16:56:40 <zbyszek> bowlofeggs: +1
16:56:55 <zbyszek> There isn't any hurry at this point.
16:57:28 <zbyszek> I assume sgallagh is +1 to bowlofeggs
16:57:35 <sgallagh> Yes
16:57:44 <maxamillion> +1 to bowlofeggs
16:57:52 <zbyszek> jwb, jsmith, nirik ?
16:57:55 <nirik> +1 sure
16:58:01 <jsmith> +1 to waiting a week
16:58:15 <jwb> +1
16:58:16 <jwb> please
16:58:56 <zbyszek> #agree Punt on Proposed Fedora 29 schedule for a week to discuss moving "infra freeze" one day after bodhi activation (+7, 0, 0)
16:59:02 <zbyszek> #topic #1860 allow major version bump of rpkg utility
16:59:03 <zbyszek> .fesco 1860
16:59:03 <zbyszek> https://pagure.io/fesco/issue/1860
16:59:05 <zodbot> zbyszek: Issue #1860: allow major version bump of rpkg utility - fesco - Pagure - https://pagure.io/fesco/issue/1860
16:59:10 <bowlofeggs> +1
16:59:11 <zbyszek> +1
16:59:48 <maxamillion> +1
17:00:00 <nirik> +1
17:00:54 <zbyszek> jwb, jsmith, sgallagh?
17:01:00 <jsmith> +1
17:01:06 <sgallagh> I was +1 in the ticket
17:01:37 <zbyszek> Oh, jwb and dgilmore too
17:01:42 <bowlofeggs> we got lots of ticket votes on this one actually
17:01:49 <bowlofeggs> (which is nice!)
17:01:59 <zbyszek> #agree Proposed allow major version bump of rpkg utility is accepted (+8, 0, 0)
17:02:02 <zbyszek> #topic Next week's chair
17:02:28 <zbyszek> Volunteers?
17:02:57 <bowlofeggs> i did it two times ago and you did it the last two times - time for someone else ot step up i say :)
17:03:04 <sgallagh> For US people, this will be an hour earlier, right?
17:03:38 <jsmith> sgallagh: Correct.
17:03:46 <jsmith> sgallagh: (at least I *think* I'm correct)
17:03:50 <puiterwijk> Yes
17:03:52 * jsmith will volunteer if nobody else does
17:03:53 <sgallagh> That's going to be a conflict for me for a couple weeks until Europe catches up
17:03:58 <bowlofeggs> according to thunderbird, it's an hour later actually
17:04:00 <puiterwijk> The same time was kept relating to UTC
17:04:04 <sgallagh> I'll probably be able to join, but not run the meeting.
17:04:07 <bowlofeggs> we switch from UTC-5 to UTC-4
17:04:12 <bowlofeggs> (in EDT)
17:04:48 <puiterwijk> s/relating/relative/
17:05:22 <bowlofeggs> so 15:00 UTC is 10:00 fo rme, but at UTC-4 that becomes 11:00
17:05:25 <sgallagh> If it's an hour later, I can do it
17:05:41 <bowlofeggs> because we shift to become closer to UTC
17:05:59 <jsmith> sgallagh: Why don't I take next week, and you can take the week after that if you're able?
17:06:16 <bowlofeggs> unless you live in arizona (unless you live in one of the many parts of Arizona that *do* observer DST!)
17:06:30 <sgallagh> jsmith: Sounds good
17:06:38 <bowlofeggs> or possibly unless you live in florida, depending on how they vote (current proposal to drop DST there)
17:06:48 <nirik> bowlofeggs: or hawaii. :)
17:06:52 <bowlofeggs> oh right
17:07:01 <sgallagh> MA is also voting to move to Atlantic time with no DST
17:07:18 <bowlofeggs> florida is actually voting to move to permanent DST
17:07:28 <bowlofeggs> so always UTC-4 (which is actually kinda weird)
17:07:38 <bowlofeggs> well, "voting on whether" i mean
17:07:44 <sgallagh> bowlofeggs: That's the same thing as MA; moving to the Atlantic TZ.
17:08:09 <bowlofeggs> i think it makes more sense for the sun to be approximately overhead at 12:00 but that's just me :)
17:08:21 <jwb> sgallagh, when is that happening?
17:08:26 <zbyszek> #action jsmith will chair next meeting
17:08:36 <sgallagh> jwb: It's on the queue; no idea when it'll come up for a vote.
17:08:44 <bowlofeggs> #action jsmith will get the world to stop doing DST and have everyone just switch to UTC
17:08:48 <sgallagh> I think it might be a ballot initiative in Nov. actually
17:09:03 <jsmith> Wow... so much pressure :-)
17:09:08 <bowlofeggs> haha
17:09:08 <jwb> sgallagh, that will be nice for MA.  it will destroy everyone's calendars :)
17:09:14 <zbyszek> OK, let's move on.
17:09:15 <zbyszek> #topic Open Floor
17:09:17 <sgallagh> mwahahahaha
17:09:29 * jsmith has nothing for the open floor
17:09:44 <sgallagh> Same
17:09:46 * zbyszek neither
17:09:54 * bowlofeggs crickets
17:10:03 <zbyszek> I'll close in a minute
17:10:38 <zbyszek> #endmeeting