16:00:04 <sgallagh> #startmeeting FESCO (2017-02-03)
16:00:04 <zodbot> Meeting started Fri Feb  3 16:00:04 2017 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:04 <zodbot> The meeting name has been set to 'fesco_(2017-02-03)'
16:00:04 <sgallagh> #meetingname fesco
16:00:04 <zodbot> The meeting name has been set to 'fesco'
16:00:04 <sgallagh> #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann
16:00:04 <sgallagh> #topic init process
16:00:04 <zodbot> Current chairs: Rathann dgilmore jforbes jsmith jwb kalev maxamillion nirik sgallagh
16:00:14 <sgallagh> .hello sgallagh
16:00:15 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:00:22 <jforbes> .hello jforbes
16:00:23 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:00:33 <maxamillion> .hello maxamillion
16:00:34 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:00:42 <nirik> .hello kevin
16:00:45 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
16:02:23 <Rathann> hi
16:02:32 <sgallagh> OK, that makes quorum.
16:02:33 <jwb> on a phone call, so not really here
16:02:42 <sgallagh> /me nods
16:02:54 <kalev> .hello klev
16:02:55 <zodbot> kalev: Sorry, but you don't exist
16:03:03 <kalev> ehh,  key doesn't work
16:03:13 <kalev> .hello kalev
16:03:13 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:03:15 <sgallagh> heh
16:03:20 <sgallagh> #topic #1669 F26 System Wide Change: Parallel Installable Debuginfo
16:03:21 <sgallagh> .fesco 1669
16:03:22 <zodbot> sgallagh: Issue #1669: F26 System Wide Change: Parallel Installable Debuginfo - fesco - Pagure - https://pagure.io/fesco/issue/1669
16:03:49 <sgallagh> From dgilmore's latest message, it sounds like approving this would necessitate a slip to let gcc finish up.
16:04:04 <nirik> no, thats unrelated.
16:04:15 <nirik> gcc is not ready no matter if we approve this or not.
16:04:20 <nirik> (at least thats my understanding)
16:04:23 <kalev> looks like we have a few options, but I think the most important is that we state that it shouldn't block the mass rebuild so that releng can continue
16:04:24 <jforbes> sgallagh: I got that the gcc slip was happening anyway, so this might make the rebuild
16:04:33 <sgallagh> nirik: Oh, that was unclear from the phrasing then
16:04:49 <nirik> https://pagure.io/releng/issue/6577#comment-71793
16:05:32 <sgallagh> /me sighs
16:05:48 <sgallagh> ok, I suppose we need to formally slip the schedule a week, then.
16:06:18 <nirik> yeah, I think we should move ahead with mass rebuild once gcc is ready.
16:06:20 <sgallagh> Which should give mjw time to finish this Change and get it into the mass-rebuild
16:06:29 <nirik> ideally.
16:06:48 <sgallagh> nirik: When I spoke to him, he expected to have it done Monday or Tuesday.
16:06:55 <Rathann> agreed, gcc is most important and we should start the mass rebuild as soon as it's ready
16:06:56 <sgallagh> So if we slip the mass-rebuild to Thursday...
16:07:34 <jforbes> And while it might be nice to have the full rebuild, but regardless, I don't think we should wait for F27 to get it in. There aren't compatibility issues with it and a lot of the packages where it really matters will be rebuilt before release anyway
16:07:35 <sgallagh> I think for logistical reasons, if we slip at all, it should be a full week.
16:08:01 <Rathann> f26-boost seems to be ready to merge back
16:08:10 <Rathann> https://pagure.io/releng/issue/6605#comment-71736
16:08:17 <nirik> I'm ok with formally moving a week, but we should still start the mass rebuild when things are ready (give people a few more days hopefully)
16:08:24 <nirik> it is yeah
16:08:28 <kalev> yup, what nirik said
16:09:06 <sgallagh> nirik: I'm on the fence there. Rebuilding "as soon as gcc is ready" puts pressure on them, and uncertainty on the debuginfo efforts.
16:09:19 <sgallagh> (There's no way to predict which day it will actually start)
16:09:31 <nirik> well, if they are ready monday or tuesday I see no point in sitting there waiting until thursday to start...
16:09:35 <sgallagh> But if we're going to assert that we don't care whether a mass rebuild happens for debuginfo...
16:09:50 <kalev> so, my opinion with what to do with the change is to state the following: 1) releng can continue with the mass rebuild without waiting for the parallel installable debuginfo, 2) it's fine to put it in F26 after the rebuild, *but* FESCo would prefer to see it in by the time of the rebuild if possible
16:10:38 <sgallagh> kalev: It's that last part that isn't really fair to them, if there's no schedule for the rebuild
16:11:15 <kalev> sure, but fesco can give recommendations I think, it's not a hard requirement
16:11:41 <sgallagh> kalev: A recommendation that they don't understand how to follow is worthless :)
16:11:55 <sgallagh> I'm fine if we want to agree that this feature lands after mass-rebuild
16:12:04 <sgallagh> (And that if it lands before, that's okay too)
16:12:08 <kalev> right, so we could maybe try to set a tentative target for the mass rebuild? tuesday?
16:12:40 <jforbes> sgallagh: but if they are going to be ready by Monday or Tuesday, aren't we basically arguing wording that won't matter anyway?
16:13:00 <sgallagh> jforbes: Engineers are bad at estimating (especially coming back from a conference)
16:13:11 <nirik> kalev: sure.
16:13:22 <jforbes> sgallagh: point
16:13:56 <sgallagh> Anyway, I'm fine if we want to simply say "It's fine if this lands whenever it's ready"
16:13:57 <kalev> if we have Tuesday set as a rebuild target then the gcc people can also better plan their work
16:14:05 <sgallagh> Or if we want to say "it must land by Tuesday or miss the bus"
16:14:08 * nirik is interested to see how long things will take this time... we have fewer ppc64{le}/aarch64 builders than x86 or armv7...but they are faster, so we will see.
16:14:11 <sgallagh> But we need to pick one of those
16:14:47 <sgallagh> I don't suppose the armv7-on-aarch64 builders will be ready in time?
16:15:04 <sgallagh> pbrobinson was suggesting we were nearly there when I spoke to him last week
16:15:11 <nirik> don't think so... yeah, they are close now.
16:15:15 <jforbes> nirik: from a kernel standpoint, armv7 is always what we are waiting on anyway
16:15:41 <nirik> jforbes: yeah. In mass rebuilds they actually really help because we have so many and they can do all the small noarch packages...
16:15:48 <nirik> but they are definitely the slowest.
16:17:08 <sgallagh> Proposal: Parallel Installable Debuginfo is approved and is permitted to land after the mass-rebuild starts. The mass-rebuild start is tentatively rescheduled for Tuesday at 1700 UTC.
16:17:14 <sgallagh> (straw-man)
16:17:42 <Rathann> are we not expressing preference for having it land before the mass rebuild?
16:17:43 <nirik> sgallagh: sure, +1... also we bump the schedule a week right?
16:17:53 <sgallagh> ah, right. /me amends
16:18:07 <sgallagh> Proposal: Parallel Installable Debuginfo is approved and is permitted to land after the mass-rebuild starts. The mass-rebuild start is tentatively rescheduled for Tuesday at 1700 UTC. The formal Fedora 26 schedule slips by one week.
16:19:10 <kalev> weren't we going to express preference to have this land before the mass rebuild? this sounds a lot like fesco is _asking_ it to land after
16:19:25 <Rathann> Proposal: Parallel Installable Debuginfo is approved and while we'd prefer it to be ready before the mass-rebuild, it is permitted to land after it starts. The mass-rebuild start is tentatively rescheduled for Tuesday at 1700 UTC. The formal Fedora 26 schedule slips by one week.
16:19:49 <kalev> I'd rather go with Rathann's wording, if that's ok with sgallagh
16:19:54 <sgallagh> Works fine for me.
16:20:03 <sgallagh> Rathann: +1
16:20:03 <nirik> Rathann: +1
16:20:04 <Rathann> +1
16:20:04 <kalev> +1 to Rathann's proposal then
16:20:06 <maxamillion> Rathann: +1
16:20:09 <jforbes> Rathann: +1
16:20:34 <sgallagh> #agreed Parallel Installable Debuginfo is approved and while we'd prefer it to be ready before the mass-rebuild, it is permitted to land after it starts. The mass-rebuild start is tentatively rescheduled for Tuesday at 1700 UTC. The formal Fedora 26 schedule slips by one week. (+6, 0, -0)
16:20:41 <sgallagh> #topic #1635 F26 Self Contained Changes
16:20:41 <sgallagh> .fesco 1635
16:20:43 <zodbot> sgallagh: Issue #1635: F26 Self Contained Changes - fesco - Pagure - https://pagure.io/fesco/issue/1635
16:21:28 <sgallagh> We have reservations about the sudo pip change
16:21:38 <sgallagh> Anyone opposed to any of the others?
16:21:43 <nirik> did we hear back on transdiff ?
16:22:06 <nirik> ah yes, they updated it
16:22:14 <kalev> I haven't read up on the pip changes, but I think the motivation there makes a lot of sense -- to change the paths so that pip-managed files are in a separate location from dnf-managed ones
16:22:19 <kalev> +1 to the rest
16:23:02 <Rathann> transdiff is targeted at F27 according to the wiki page
16:23:03 <nirik> transdiff is moved to f27...
16:23:05 <nirik> yeah
16:23:24 <jforbes> I would agree that sudo pip is the only one I cant +1 yet. And I echo jwb's thoughts on adding spins in general
16:23:31 <nirik> ok, I am +1 to all but the sudo pip thing since we have outstanding questions on it.
16:23:33 <sgallagh> #info transdiff Change Proposal has been deferred to F27
16:24:41 <sgallagh> Proposed: FESCo approves LXQt spin, Docker Overlay 2 and NetworkManager 1.8
16:24:48 <maxamillion> sgallagh: +1
16:24:51 <nirik> +1
16:24:53 <kalev> +1
16:24:54 <sgallagh> +1
16:24:56 <Rathann> +1
16:25:20 <sgallagh> #agreed FESCo approves LXQt spin, Docker Overlay 2 and NetworkManager 1.8 (+6, 0, -0)
16:25:29 * nirik wonders if the lxde spin should get dropped, but that can be discussed on list or elsewhere.
16:25:29 <sgallagh> (including jsmith from the ticket)
16:25:40 <Rathann> right
16:26:01 <sgallagh> #info FESCo has unanswered questions about the sudo pip proposal and will discuss them on devel@
16:26:05 <sgallagh> (Fair?)
16:26:11 * nirik nods
16:26:18 <Rathann> yes
16:26:20 <maxamillion> +1
16:26:25 <kalev> fair, as long as someone actually has question -- I personally don't know what to ask and don't know what's wrong with it since I haven't read up on it :)
16:26:37 <kalev> seemed fine to me from a quick glance
16:27:14 <sgallagh> I'll admit to not being fully read up on it. (Busy couple weeks)
16:27:20 <sgallagh> I will attempt to rectify this.
16:27:31 <sgallagh> For now, let's move on. We have a full agenda today.
16:27:37 * kalev nods.
16:27:38 <sgallagh> #topic #1675 Libglvnd update breaking F25
16:27:39 <sgallagh> .fesco 1675
16:27:41 <zodbot> sgallagh: Issue #1675: Libglvnd update breaking F25 - fesco - Pagure - https://pagure.io/fesco/issue/1675
16:27:57 <sgallagh> So, the necessary packages have been pushed stable, but this was not an ideal situation
16:28:20 <sgallagh> I personally don't think a change this disruptive should have been anywhere *near* a stable release.
16:28:29 <kalev> so, nirik and I dealt with the immediate problem of broken deps, but the broken deps we had for a few days had some bad publicity and fallout on reddit and other social media
16:28:50 <nirik> yeah.
16:28:50 * Rathann sighs and looks at https://fedoraproject.org/wiki/Updates_Policy
16:29:10 <maxamillion> sgallagh: +1
16:29:34 <kalev> I don't have a strong opinion either way; I totally understand that we _need_ that change to use the nvidia binary driver, but I guess it should be fine to have it in F26+ as well
16:29:34 <jforbes> The broken deps are a big issue. The nature of the change sounds a lot like it needed more testing.
16:29:39 <sgallagh> Do we want to take any sort of preventative action at this time, or just acknowledge that people make mistakes and hope that this is its own lesson?
16:30:23 <nirik> well, there were a number of unfortunate steps that happened in a row to make this happen...
16:30:32 <jforbes> sgallagh: What kind of preventative action could be taken?  Other than perhaps force a dep check independent of separate updates?
16:30:50 <nirik> I think a bodhi change could help prevent this...
16:31:37 <sgallagh> jforbes: I honestly don't know; that was meant to encourage brainstorming :)
16:31:42 <nirik> If you try and submit a new update for something that is part of an existing update with multiple packages in it, it just rejects it and maintainers have to talk and edit things.
16:31:53 <kalev> yes! that!
16:31:55 <nirik> but that may annoy some people
16:32:30 <sgallagh> nirik: It sounds sensible to me.
16:32:46 <sgallagh> Though it may require more frequent provenpackager involvement
16:32:49 <nirik> as for if we should allow this update to go out now, not sure. It not by the policy, but hans did a lot of work getting things all fixed up now.
16:32:50 <kalev> can we make a fesco recommendation to bodhi maintainers that this is a reasonable thing to do?
16:32:53 <Rathann> I say let them be annoyed and ask for provenpackager or co-maintainer status for their interdependent packages, then
16:32:57 <jwb> i think we need to be less worried about annoying people and more focused on not breaking things
16:33:08 <sgallagh> jwb++
16:33:12 * kalev agrees.
16:33:21 <Rathann> interdependent updates should be coordinated either way
16:34:07 <Rathann> +1 to nirik's proposal of bodhi change
16:34:15 <sgallagh> Proposal: FESCo formally requests that Bodhi prevent the creation of new updates for a package that is present in another update but not yet pushed stable.
16:34:23 <kalev> +1
16:34:25 <nirik> to be fair, I think hans suggested it first. :0
16:34:39 <Rathann> +1 either way
16:34:43 <kalev> ok, maybe slight edit
16:34:53 <sgallagh> (And I'll politely ask nirik to phrase that better in a Bodhi bug report)
16:34:55 <kalev> "... but not yet pushed stable OR queued stable."
16:35:07 <jforbes> +1
16:35:12 <maxamillion> +1
16:35:19 <sgallagh> kalev: Right, that's what I meant to indicate, but didn't phrase it well.
16:35:22 <nirik> well, there's a number of cases.
16:35:36 <sgallagh> I don't know that we have to solve them all in this meeting
16:35:56 <nirik> bodhi cannot obsolete the old updates where it's locked (being pushed) or has other builds in it or is stable or ...
16:36:39 <nirik> anyhow, I can file a bug
16:36:43 <sgallagh> please do
16:37:13 <sgallagh> #action nirik to file a ticket with Bodhi to improve interaction between multi-package updates and obsoletes.
16:37:20 <sgallagh> Are we good on this topic, then?
16:37:42 <sgallagh> /me takes silence as consent
16:37:46 <sgallagh> #topic #1674 F26 System Wide Change: Enable TRIM pass down to encrypted disks
16:37:47 <sgallagh> .fesco 1674
16:37:48 <zodbot> sgallagh: Issue #1674: F26 System Wide Change: Enable TRIM pass down to encrypted disks - fesco - Pagure - https://pagure.io/fesco/issue/1674
16:37:59 <nirik> no wait
16:38:04 <sgallagh> #undo
16:38:04 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fe38439e4d0>
16:38:14 <sgallagh> nirik: go ahead
16:38:21 <nirik> we didn't say if that update can go stable or if we want to unpush it because it goes against policy
16:38:33 <nirik> or something else.
16:39:52 <maxamillion> yeah, I think we should be able to unpush it
16:39:55 <nirik> I'm kinda torn.
16:40:05 <sgallagh> Well, we can't unpush it at this point.
16:40:12 <maxamillion> right, I mean in the process
16:40:13 <sgallagh> At best, we can force a downgrade with epoch
16:40:16 <nirik> no.
16:40:17 <nirik> we can
16:40:24 <sgallagh> I thought parts of it made it stable
16:40:31 <maxamillion> like the ability to pull an update before pushing a next one if we can't push a new one without a stable update going
16:40:36 <jforbes> epoch is such a horrible thing to use unless absolutely necessary
16:40:38 <nirik> the actual change is not currently in updates.
16:41:00 <nirik> there was a mesa with the change that went out, but kalev built another one without and we pushed that out to fix deps
16:41:15 <nirik> so, all the changes are in testing now
16:41:17 <nirik> https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e
16:41:19 <maxamillion> ah ok
16:41:39 <nirik> mesa, libglvnd, wlc (to fix sway)
16:41:56 <nirik> as far as i know there's no outstanding breakage with it now.
16:42:05 <nirik> (the fesco ticket was filed by the sway maintainer)
16:42:27 <sgallagh> ah... hmm
16:43:39 <Rathann> we should stress that adding new dependencies should be avoided, especially in critpath packages
16:43:42 <sgallagh> OK, so what's the advantage to this change? It still seems rather disruptive for a stable release to me
16:43:56 <Rathann> which is basically what the updates policy says
16:43:58 <kalev> it makes it easy to install nvidia binary driver
16:43:59 <nirik> sgallagh: it abstracts the gl stuff...
16:44:11 <kalev> before, the nvidia binary driver replaced libGL.so.1
16:44:30 <nirik> so, nvidia and nouveau can both use this and if nvidia craps out or whatever, nouveau can still work, so people don't get blank screens.
16:44:35 <kalev> this changes it so that it can happen without the nvidia driver having to replace system isntalled files
16:44:43 * kalev nods.
16:44:44 <nirik> yeah
16:45:09 <jforbes> It also makes it a lot easier to get people to test kernels without the nvidia driver when they have a problem on a tainted kernel.
16:45:09 <kalev> so it's a very nice change, the only question is if it's too big for F25
16:45:12 <sgallagh> Sounds like something that would be most useful on the initial install
16:45:13 <Rathann> that's a big advantage, but it doesn't justify the change in a stable release in my opinion
16:45:39 <sgallagh> jforbes: That's... a really compelling argument
16:45:43 <kalev> I'll note that we have a big workstation feature planned around this for F26
16:45:56 <nirik> was discussed in https://blogs.gnome.org/uraeus/2016/11/01/discrete-graphics-and-fedora-workstation-25/ for more details
16:46:55 <Rathann> meh
16:47:07 <nirik> perhaps we should say this isn't acceptable for a stable update, but hans can ask for an exception and he can make his case to us?
16:47:09 <sgallagh> I'm coming down slightly on the side of asking that this be held off until F26
16:47:44 <sgallagh> nirik: That seems reasonable to me
16:48:08 <kalev> I'll note that if we ask this to be pulled from updates-testing, then this needs to be done properly, so that people who already have this installed from updates-testing will get switched back to mesa libGL.so.1 provider, otherwise there's a lot of broken deps involved again
16:48:09 <nirik> currently it's in testing and autokarma is off.
16:48:10 <maxamillion> jforbes: from the kernel perspective, you think this compelling enough to go in to F25?
16:48:39 <kalev> I like nirik's suggestion as well, plus, I think it would benefit from one extra week in -testing
16:49:04 <Rathann> the discussion around libglvnd in F25 and subsequent mesa update was under "review request" topic, so it probably flew under the radar
16:49:14 <kalev> I think I'm slightly leaning towards allowing it in F25 fwiw
16:49:23 <kalev> but with some more updates-testing time
16:49:25 <jforbes> maxamillion: tough call really. I mean it sucks that it is basically hard for anyone to test with nouveau once they have installed nvidia...
16:49:31 * nirik is also slightly leaning that way
16:49:49 <maxamillion> jforbes: right
16:50:00 <jforbes> maxamillion: Extra testing to limit the impact seems the best action there.
16:50:03 <maxamillion> jforbes: I'm on the fence, because I see the appeal and the concern from different perspectives
16:50:09 <maxamillion> jforbes: +1
16:50:19 <sgallagh> I'd be pretty much against it if not for the kernel argument, honestly.
16:51:22 <Rathann> IMHO Hans should've asked specifically if it's OK to do this in a stable release on the mailing list
16:52:15 <Rathann> I have to admit I'm extremely wary of updates introducing new dependencies
16:52:35 <nirik> Rathann: well, there's an exception process, you are supposed to as fesco. ;)
16:52:37 <Rathann> or even switching to different graphics toolkits in a stable release
16:52:47 <nirik> but yeah
16:53:19 <Rathann> i.e. firewall-applet switching first from gtk to qt4 and then to qt5
16:53:53 <Rathann> *sigh*
16:53:59 <sgallagh> Since we're kind of deadlocked, I propose: Request that this update remains in u-t until the next FESCo meeting. Ask Hans to mail the devel list with a description of the change and an argument for why it should be allowed in a stable release.
16:54:12 <maxamillion> sgallagh: +1
16:54:16 <kalev> sgallagh: +1
16:54:18 <Rathann> +1
16:54:27 <nirik> +1
16:54:40 <maxamillion> is there any way to enforce in bodhi that it doesn't go to stable until we meet again? (accidentally or otherwise)
16:54:42 <jforbes> +1
16:55:25 <sgallagh> maxamillion: autokarma is turned off. It can only happen if it's pushed manually.
16:55:40 <sgallagh> If that happens after FESCo says not to, that's probably grounds for censure.
16:55:48 <maxamillion> sgallagh: +1
16:58:08 <sgallagh> #agreed FESCo asserts that the GL update must remain in updates-testing until the next FESCo meeting. FESCo asks the GL maintainer to send an email to devel@lists.fp.o describing the change and why they feel it should be accepted into a stable release.
16:58:11 <sgallagh> #undo
16:58:11 <zodbot> Removing item from minutes: AGREED by sgallagh at 16:58:08 : FESCo asserts that the GL update must remain in updates-testing until the next FESCo meeting. FESCo asks the GL maintainer to send an email to devel@lists.fp.o describing the change and why they feel it should be accepted into a stable release.
16:58:20 <sgallagh> #agreed FESCo asserts that the GL update must remain in updates-testing until the next FESCo meeting. FESCo asks the GL maintainer to send an email to devel@lists.fp.o describing the change and why they feel it should be accepted into a stable release. (+6, 0, -0)
16:58:32 <sgallagh> #topic #1674 F26 System Wide Change: Enable TRIM pass down to encrypted disks
16:58:32 <sgallagh> .fesco 1674
16:58:33 <zodbot> sgallagh: Issue #1674: F26 System Wide Change: Enable TRIM pass down to encrypted disks - fesco - Pagure - https://pagure.io/fesco/issue/1674
16:58:48 <sgallagh> There's active discussion on this topic on devel@, so I propose we defer for this week.
16:58:54 <maxamillion> +1
16:58:59 <nirik> sure. +1
16:59:02 <Rathann> yes, I didn't get answers to my questions in the thread
16:59:05 <Rathann> +1 to defer
16:59:15 <jforbes> +1 to defer
16:59:23 <kalev> +1 to defer
16:59:27 <sgallagh> +1 (for the record)
16:59:50 <sgallagh> #agreed FESCo will defer this decision for a week due to ongoing discussion on the devel@ mailing list
16:59:56 <sgallagh> #topic #1673 F26 System Wide Change: Modular Server Preview
16:59:56 <sgallagh> .fesco 1673
16:59:57 <zodbot> sgallagh: Issue #1673: F26 System Wide Change: Modular Server Preview - fesco - Pagure - https://pagure.io/fesco/issue/1673
17:01:04 <sgallagh> I am available to answer questions
17:01:12 <maxamillion> I'm +1 for this change
17:01:23 <nirik> +1
17:01:31 <jforbes> +1
17:01:40 <maxamillion> I was a little concerned since there's been little to no coordination with RelEng, but we discussed much of this at DevConf
17:02:06 <maxamillion> and since it's kind of a one-off "tech preview" with branding/TM approval from the Council, then +1
17:02:12 <sgallagh> maxamillion: Yeah, that was troubling. The short version was that the people who were supposedly talking to rel-eng didn't realize that Factory 2.0 != rel-eng
17:03:20 <maxamillion> sgallagh: right, which to be fair was a mistake in the Change process docs which we should improve the section of "Contact RelEng" with an official means of how to actually do that (file a ticket in releng pagure) ... iirc, dgilmore is doing that but I'll follow up
17:03:57 <maxamillion> mostly just a communications breakdown, but the Change Owner did everything in the process as it is written ... process just needs improvements :)
17:04:07 <sgallagh> ack
17:04:13 <sgallagh> Anyway, biased +1
17:04:20 <Rathann> ok, +1 from me
17:04:33 <sgallagh> jsmith had +1 in the ticket
17:04:51 <kalev> +1
17:04:58 <sgallagh> #agreed Modular Server "Boltron" Preview is approved (+7, 0, -0)
17:05:23 <sgallagh> Two more tickets to go
17:05:26 <sgallagh> #topic #1672 F26 System Wide Change: Separate Subpackage and Source Debuginfo
17:05:27 <sgallagh> .fesco 1672
17:05:28 <zodbot> sgallagh: Issue #1672: F26 System Wide Change: Separate Subpackage and Source Debuginfo - fesco - Pagure - https://pagure.io/fesco/issue/1672
17:07:11 <Rathann> well, same as parallel debuginfo
17:07:51 <sgallagh> I'm honestly not sure what the value is here, other than slightly smaller downloads (at the risk of not getting everything you need to actually debug)
17:07:51 <jforbes> I see this as less relevant than parallel debuginfo, but I don't have a problem with the change either.
17:08:14 <jforbes> It does need docs because people won't be expecting it otherwise
17:08:20 <maxamillion> sgallagh: I'm with you on this, I don't really see the point but I'm also not really against it
17:08:22 <kalev> sgallagh: exactly my thoughts :)
17:08:35 <Rathann> sgallagh: smaller downloads are a big plus in my opinion
17:09:09 <sgallagh> Rathann: but debuginfo is a developer-only feature
17:09:33 <jforbes> and source is typically a very small fraction of debuginfo
17:09:47 <sgallagh> jforbes: Yeah, that exactly
17:10:24 <Rathann> granted
17:10:38 <nirik> this also seems to depend on the other one?
17:10:45 <nirik> "This depends on some of the cleanups introduced by the ParallelInstallableDebuginfo change. "
17:11:00 <jforbes> nirik: Yeah, sounds like it
17:11:19 <sgallagh> Who exactly is asking for this Change?
17:11:21 <Rathann> though IIUC this also means that debuginfo will be split into subpackages
17:11:32 <sgallagh> (Not who is proposing it; who is going to take advantage of it?)
17:11:51 <sgallagh> Rathann: Oh good, huge increase in the yum repo metadata :-/
17:12:15 <kalev> sgallagh: right, I'd also be interested who benefits from the changes
17:12:56 <kalev> I guess the retrace server may need to download less stuff and can omit the source files?
17:13:03 <Rathann> sgallagh: I've heard there's some progress on differential metadata updates?
17:13:25 <jforbes> Rathann: for F26?
17:13:34 <Rathann> no, in general
17:13:35 <kalev> I've heard there's some ideas being floated around, nothing more concrete
17:13:58 <kalev> but I'm not on the dnf team so I may have gotten the wrong idea
17:14:00 <sgallagh> The people who could answer these questions are at FOSDEM today, unfortunately.
17:14:03 <Rathann> ok
17:14:49 <jforbes> I would say ask those questions and defer, but this would benefit from being in the rebuild if approved
17:14:50 <sgallagh> The "Benefit to Fedora" section really doesn't impress me, honestly.
17:15:09 <maxamillion> sgallagh: +1
17:15:29 <sgallagh> jforbes: If we take a vote today, I'm -1 based on what we know.
17:16:08 <sgallagh> I'm not convinced the advantages A) exist and B) exceed the risks and change in user expectation
17:17:13 <jforbes> sgallagh: I would agree there
17:17:55 <Rathann> I am +1, though the increase in yum repo metadata and some example debuginfo-install before and after sessions should be documented, showing the expected numbers
17:18:01 <jforbes> TBH, I don't see any advantage personally, but I am willing to admit that I could be missing something
17:18:38 <maxamillion> sgallagh: +1
17:18:48 <Rathann> I remember that installing glibc-debuginfo took ~1GB on disk
17:18:51 <maxamillion> jforbes: same here
17:19:13 <jforbes> So -1, if you really to try, make a better case and prep it for F27?
17:19:16 <sgallagh> Rathann: no, it takes 76MiB
17:19:16 <Rathann> and it's a lot less now due to glibc debuginfo split (currently manual)
17:19:27 <sgallagh> oh
17:19:28 <maxamillion> Rathann: right, but how much of that wouldn't be downloaded after this change? ... if it's still ~995MB, was it worth the change?
17:19:31 <Rathann> this proposal makes it automatic IIUC
17:20:08 <Rathann> "A couple of packages already have hand-written sub-debuginfo packages (notably the kernel, glibc and gcc). We will work with those packages to adopt the new standard approach. "
17:21:30 <sgallagh> Proposal: FESCo doesn't feel that the "Benefit to Fedora" exceeds the risks and change in user expectation that would accompany this Change.
17:21:31 <Rathann> maxamillion: if the numbers show small decrease in debuginfo-install downloads and large increase in yum repodata then I'll be -1
17:22:40 <maxamillion> Rathann: fair
17:22:46 <sgallagh> Rathann: Well, repodata will *definitely* increase, if only because at least two sub-packages are being produced where one used to be
17:22:59 * nirik suspects almost no one downloads debuginfo. ;)
17:23:07 <sgallagh> That said, it'll affect the debuginfo repos, not the main ones
17:23:25 <sgallagh> nirik: Maybe, but it still has to get mirrored
17:23:26 <jforbes> <- almost no one
17:23:43 <nirik> sure.
17:23:51 <Rathann> nirik: then the impact of metadata size increase on users will be small, too
17:24:17 <sgallagh> Rathann: Well, the impact on the set of users who use debuginfo will be significant
17:24:19 <nirik> well, since most of them never enable the repo...
17:24:41 <sgallagh> And again, mirror networks won't be thrilled
17:24:45 <nirik> anyhow, I guess I am a weak +1.
17:24:55 <Rathann> that's why it's be good to see the numbers
17:25:04 <Rathann> which probably requires a mass rebuild first
17:25:23 <Rathann> unless someone does that for one arch on their own servers (or maybe copr?)
17:25:37 <sgallagh> nirik: To the Change or to my proposal?
17:26:00 <Rathann> sgallagh: your proposal is a bit vague
17:26:09 <nirik> to the change...
17:26:11 * nirik reads up
17:26:12 <jforbes> Rathann: I am pretty sure infra would kill somone for trying a mass rebuild of fedora on copr
17:26:45 <Rathann> I'd mention that numbers regarding the increase in yum metadata and decrease of typical debuginfo-install downloads would help a lot.
17:26:45 <sgallagh> nirik: Feel free to make a counter-proposal
17:27:20 <sgallagh> Rathann: Off the cuff, I'd say it would be at least double
17:27:24 <nirik> so really it sounds like we all want more info, but don't want to punt due to the mass rebuild ?
17:28:01 <Rathann> well, it can wait until F27 but then there's no mass rebuild scheduled for F27, so effectively F28
17:28:02 <maxamillion> nirik: pretty much
17:28:14 <Rathann> unless we schedule one for F27
17:28:44 <nirik> well, or it could just land and packages change as they are rebuilt.
17:28:56 <nirik> this change didn't claim to be dependent on mass rebuild.
17:29:26 <Rathann> that too
17:29:29 <jforbes> nirik: if they do the meta package. Otherwise it would be weird having to choose which method of installing debuginfo to use based on package build time
17:29:55 <kalev> why is there no mass rebuild for F27? can't we schedule one? it's seems like a good thing to have to ensure fedora stays rebuildable
17:30:04 <kalev> the boost maintainer has been complaining quite a bit that most of the rebuild failures during the boost update were actually unrelated to the boost update
17:30:11 <kalev> and I guess that's partially because we didn't have a mass rebuild last cycle and people weren't aware things don't build
17:30:22 <sgallagh> kalev: We haven't been doing rebuilds in the autumn schedule because we have less time
17:30:24 <nirik> I think we were trying to make the f27 schedule a bit shorter.
17:30:41 <kalev> right, but we could maybe have a rebuild without the 4 week cleanup period
17:30:51 <kalev> just a best effort one
17:31:05 <sgallagh> kalev: That... doesn't make any sense.
17:31:10 <kalev> anyway, that's a bit off topic right now
17:31:36 <kalev> sgallagh: what doesn't make sense? that we find out build failures when we do mass rebuilds?
17:32:11 <sgallagh> kalev: If things break, we don't give time to fix them before branching. That's needlessly hostile to maintainers
17:32:19 <sgallagh> Anyway, we're off topic
17:32:32 <Rathann> kalev: doesn't koschei catch a lot of FTBFS as soon as they happen?
17:32:33 <kalev> ohh, but it's not that things break _more_ after a rebuild. it's more just that failures are _detected_ due to it
17:32:35 <sgallagh> How do we want to proceed? I'm pretty comfortable saying "no" to this Change for F26
17:32:47 <kalev> Rathann: I think it does, and it definitely helps
17:33:40 * nirik notes not everything is enabled in koschei... perhaps more things should be.
17:33:52 <Rathann> I'm +1, but I'm not opposed to postponing to F27 since there are no numbers about the concerning stuff
17:35:18 <nirik> ok, looking more at it, I guess I am now a weak -1 to the change, since I don't really see all that much advantage to it. Barring better info about advantages.
17:35:53 <maxamillion> I'm also a weak -1
17:36:22 <sgallagh> OK, that's +1, 0, -3 so far.
17:36:51 <jforbes> I will go with weak -1 because I don't see any real advantage at this point
17:36:56 <sgallagh> Sorry, +2, 0, -3 (assuming jsmith's vote stands)
17:37:28 <sgallagh> +2, 0, -4
17:37:37 <sgallagh> jwb: Care to chime in?
17:38:20 <jwb> no
17:38:55 <sgallagh> OK, so that leaves us at +2, 1, -4
17:39:06 <sgallagh> Not enough to call a "decision", so I guess we have to defer
17:39:09 <jwb> will comment in ticket.  likely not to have a strong opinion
17:40:04 <sgallagh> #info FESCo defers a decision on this Change this week due to deadlock
17:40:34 <sgallagh> Oh, I suppose kalev might have changed things, but he seems to have dropped
17:40:46 <sgallagh> If he resurfaces, we can revisit.
17:41:00 <sgallagh> #topic #1636 centralizing default index.html (from httpd/nginx/etc)
17:41:00 <sgallagh> .fesco 1636
17:41:01 <zodbot> sgallagh: Issue #1636: centralizing default index.html (from httpd/nginx/etc) - fesco - Pagure - https://pagure.io/fesco/issue/1636
17:41:03 <sgallagh> Last one.
17:41:12 <sgallagh> I think this is basically just looking for a shepherd.
17:41:16 <sgallagh> Any volunteers?
17:42:29 <sgallagh> ...
17:42:48 * nirik doesn't think he has time for it currently. I think it's a good idea tho
17:42:54 <sgallagh> Yeah, I'm in the same boat.
17:43:04 <sgallagh> Rathann: You made the proposal, want to own the consequences? :)
17:43:12 <Rathann> I could take it, but can't promise any deadline right now
17:43:24 <Rathann> if that's fine then assign to me
17:43:39 <sgallagh> Works for me.
17:43:42 <sgallagh> There's no urgency to it
17:43:48 <Rathann> I have a good idea what needs to be done
17:43:50 <sgallagh> #action Rathann to shepherd this effort
17:44:06 * Rathann adds to his todo list
17:44:25 <sgallagh> #topic Next week's chair
17:44:37 <sgallagh> /me pulls the pin, tosses the grenade into the air.
17:44:39 <sgallagh> Catch!
17:45:03 * Rathann will probably be out sick
17:45:13 <Rathann> I caught some cold or flu yesterday
17:45:15 <jforbes> I can do it
17:45:19 <Rathann> getting worse today :(
17:45:31 <sgallagh> #info jforbes to chair 2017-02-10 FESCo meeting
17:45:35 <sgallagh> #topic Open Floor
17:45:35 <Rathann> thanks jflory7
17:45:41 <Rathann> I mean thanks jforbes
17:45:45 <maxamillion> thanks jforbes :D
17:46:00 <sgallagh> Rathann: ah, heh. I thought you were thanking jflory7 for giving you the flu ;-)
17:46:23 <sgallagh> Anything for Open Floor, or shall we call it a day?
17:46:26 <Rathann> no, just too quick on the keyboard
17:46:47 <jforbes> feel better Rathann
17:46:52 <Rathann> thanks
17:46:59 <sgallagh> OK, I'll close the meeting in 120s
17:47:27 <Rathann> I'll be dropping off now, then
17:47:43 <Rathann> thanks sgallagh, thanks everyone
17:47:53 <maxamillion> thanks sgallagh for hosting!
17:48:02 <jforbes> thanks sgallagh
17:48:15 <sgallagh> You're welcome
17:48:26 <sgallagh> #endmeeting