16:00:31 <jforbes> #startmeeting FESCO (2017-02-10)
16:00:31 <zodbot> Meeting started Fri Feb 10 16:00:31 2017 UTC.  The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:31 <zodbot> The meeting name has been set to 'fesco_(2017-02-10)'
16:00:49 <jforbes> #meetingname fesco
16:00:49 <zodbot> The meeting name has been set to 'fesco'
16:00:56 <jforbes> #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann
16:00:56 <zodbot> Current chairs: Rathann dgilmore jforbes jsmith jwb kalev maxamillion nirik sgallagh
16:01:07 <nirik> morning
16:01:10 <jforbes> #topic init process
16:01:11 <nirik> .hello kevin
16:01:12 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
16:01:12 <ignatenkobrain> .hello ignatenkobrain
16:01:12 <sgallagh> .hello sgallagh
16:01:14 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
16:01:17 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:01:18 <jforbes> .hello jforbes
16:01:20 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:01:25 <jforbes> morning
16:01:35 <mjw> .hello mjw
16:01:36 <zodbot> mjw: mjw 'Mark Wielaard' <mark@klomp.org>
16:01:58 <dgilmore> hey all
16:02:40 <sgallagh> mjw and Pharaoh_Atem are here to discuss the debuginfo Change with us this week. Let's do that one first, so they don't have to hang around waiting?
16:03:02 <jforbes> sgallagh: sounds good
16:03:42 <kalev> morning
16:04:09 <jforbes> Will give it one more minute to see who shows and we will get started
16:04:25 <cschalle> ajax, kem and aruiz are here too for the glvnd discussion
16:04:25 <torsava> sgallagh, I'm here in case there are any questions about 'Making sudo pip safe again'
16:04:34 <jwb> hi
16:04:38 <sgallagh> torsava: Good to know. Thanks for coming :)
16:04:38 <jwb> sorry for being late
16:04:49 <maxamillion> .hello maxamillion
16:04:49 <torsava> sgallagh, thanks for having me :)
16:04:50 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:04:51 <maxamillion> sorry I'm late
16:05:14 <jforbes> Okay, looks like we have good attendance
16:05:20 <jforbes> #topic #1672 F26 System Wide Change: Separate Subpackage and Source Debuginfo
16:05:26 <jforbes> .fesco 1672
16:05:28 <zodbot> jforbes: Issue #1672: F26 System Wide Change: Separate Subpackage and Source Debuginfo - fesco - Pagure - https://pagure.io/fesco/issue/1672
16:06:02 <Pharaoh_Atem> .hello ngompa
16:06:03 <zodbot> Pharaoh_Atem: ngompa 'None' <ngompa13@gmail.com>
16:06:08 <Pharaoh_Atem> mrrr
16:06:15 <Pharaoh_Atem> w/e
16:06:19 <Pharaoh_Atem> one day, that'll get fixed
16:06:26 <jforbes> Last week there was deadlock on this one, basically I don't think too many felt strongly either way.  Has time changed anything here?
16:06:47 <mjw> So if I understood correctly fesco had some worries about a couple of things. First the "benefit to fedora". I updated the changes page to expand on that a little.
16:07:11 <mjw> Second the disruption to tools and users which might have to fetch/depend on different subpackages. I believe tools are all backward compatible with the changes in location and references, but if not we can introduce an extra symlink. For users the simplest (bridge) would be to introduce a meta debuginfo package that just depends on the split ones.
16:07:49 <Pharaoh_Atem> my thought is that we'll initially have the metapackage and move forward with eliminating that as a requirement for F27
16:07:58 <mjw> Last we didn't talk to or discuss the impact on the repo meta-data. We did indeed not. Sorry. We didn't think that there would be much impact. But we could of course be wrong.
16:08:58 <maxamillion> I do like the upstream and cross-distro work and if the goal of this is to be better in line with those communities then I'm in favor of it
16:09:05 <jforbes> The meta package does make things fairly transparent, but is it worthwhile in this context? most packages have a binary package which matches source enough
16:09:05 <Pharaoh_Atem> that's a huge part of it
16:09:09 <kalev> instead of a metapackage, another possibility would be to add "Obsoletes: old-debuginfo-package < epoch:version-release" to each of the split out subpackages
16:09:14 <sgallagh> Right now, 'gdb' instructs users to do `dnf debuginfo-install foo-devel` and such. That would need to be fixed up or otherwise made to be certain to work as expected.
16:09:18 <Pharaoh_Atem> kalev: that is another option
16:09:22 <kalev> I think that should also ensure that all of the new, split out subpackages get installed
16:09:41 <Rathann> apologies for being late
16:09:52 <ignatenkobrain> kalev: but in this case it will work only for dnf-update
16:10:14 <ignatenkobrain> so I think for F26 we should have metapackage and in f27 when we remove it, we add obsoletes
16:10:16 <jforbes> Right, for kernel with the split we did add a metapackage, but had to rename kernel to kernel-core in order to do so
16:10:18 <mjw> sgallagh, I believe gdb can/should do that based on build-id it finds, and that should work "transparently". But yes, that is one of the test criteria I guess.
16:10:32 <kalev> ignatenkobrain: sure, sounds like a good plan to me
16:10:38 <ignatenkobrain> mjw: we also do Provides buildid()
16:10:41 <ignatenkobrain> so gdb can rely on this
16:10:46 <sgallagh> mjw: OK, as long as that's on your radar, I'm content :)
16:10:57 <ignatenkobrain> s/also do/probably already do/
16:11:04 <Pharaoh_Atem> ignatenkobrain: we will as of F26
16:11:10 <Pharaoh_Atem> the parallel debuginfo stuff adds it
16:11:15 <sgallagh> /me nods
16:11:28 <mjw> sgallagh, Maybe the "how to test" section should be expanded. It currently simply says: "Unfinished. Running a tracer (systemtap), profiler (pref) or debugger (gdb) against a program or core file should suggest the correct debuginfo/sources packages to install. After that the tracing/profiling/debugging session should work as before."
16:11:53 <sgallagh> So, my major opposition last week was the change in user expectation, but what I'm hearing today suggests that's largely addressed.
16:11:54 <nirik> is seperating the source out really that big a win?
16:12:02 * nirik relooks at the change page
16:12:19 <sgallagh> That's the only thing that leaves me slightly concerned.
16:12:20 <maxamillion> nirik: +1
16:12:23 <maxamillion> sgallagh: +1
16:12:24 <maxamillion> same here
16:12:30 <kalev> who would benefit from splitting out the source? that was a question we had last time
16:12:34 <Pharaoh_Atem> nirik: it's important in the context of both parallel debuginfo and split debuginfo
16:12:37 <sgallagh> If I am debugging a process and it tells me to do debuginfo-install, is that instruction going to include the source?
16:12:46 <ignatenkobrain> sgallagh: no AFAIK
16:12:47 <maxamillion> the upstream/cross-distro collaboration I'm all for but I still don't understand the "net win"
16:12:48 <Pharaoh_Atem> currently, we install the source in all cases, even when it's not necessary
16:12:49 <sgallagh> Because not having the source in GDB is a real pain in the neck
16:13:04 <maxamillion> sgallagh: +1
16:13:09 <kalev> Pharaoh_Atem: why is it problematic to install the source?
16:13:30 <ignatenkobrain> sgallagh: although we can adjust debuginfo-install
16:13:35 <mjw> nirik, depends on package and usage. For download not that much because sources compress pretty well. For install it might matter a lot because it gets installed uncompressed. If you tracing/profiling session doesn't need sources it is a win.
16:13:40 <nirik> usually I would expect the source to be prety small...
16:13:42 <Pharaoh_Atem> kalev: because if we do split debuginfo without splitting sources, we need to provide duplicates of sources, which is wasteful
16:13:46 <jforbes> Right, the source is pretty much noise compared to the debuginfo itself
16:14:13 <ajax> Pharaoh_Atem: no, you just need a Requires from the per-binrpm debuginfo package to a per-srpm source package
16:14:15 * jsmith_ is here -- sorry for the tardiness
16:14:28 <kalev> ajax: yep, my thought exactly
16:14:31 <Pharaoh_Atem> for parallel debuginfo, while the package sources are not huge in package, they're big on disk
16:14:51 <Pharaoh_Atem> not having to have them all the time can be useful
16:14:52 <kalev> I just don't want our debugging experience to regress, especially since Workstation is oriented for developers
16:15:09 <Pharaoh_Atem> it will likely be installed by default
16:15:14 <Pharaoh_Atem> probably via Supplements/Recommends
16:15:14 <kalev> and if suddenly gdb no longer shows the source code when debugging, I think that would be a regression
16:15:26 <mjw> ajax, I cannot tell if you agree or disagree with Pharaoh_Atem :)
16:15:33 <sgallagh> Pharaoh_Atem: I'd suggest what ajax just said, but with Recommends on the per-SRPM source package instead of Requires
16:15:39 <sgallagh> So it can be removed if truly not desired.
16:15:45 <maxamillion> ajax: are you in favor of the change or against it? (out of curiosity)
16:15:49 <jforbes> sgallagh: +1
16:15:54 <ajax> mjw: i was disagreeing with his statement "need to provide duplicates of sources"
16:16:22 <Pharaoh_Atem> and on top of it, there are several complaints externally that we force source inclusion of sources for debuginfo symbols
16:16:30 <kalev> from who?
16:16:32 <Pharaoh_Atem> SUSE, Debian, and Ubuntu do not require it
16:16:44 <ajax> maxamillion: for, more or less. i still think debuginfo is properly a network service, but i've only been saying that for the better part of a decade...
16:16:44 <sgallagh> Pharaoh_Atem: Well, that would be resolved by the Recommends: anyone who doesn't want it can skip it explicitly.
16:16:52 <Pharaoh_Atem> yes, but we CANT right now
16:16:58 * kalev agrees with sgallagh.
16:17:01 <mjw> ajax, well... If we do sub-debuginfo-packages without a separate debugsources package, then it all gets very messy. You would have to put the sources somewhere.
16:17:08 <sgallagh> Pharaoh_Atem: What can't we do? (sorry, not enough context)
16:17:12 <Pharaoh_Atem> we can't even disable inclusion of sources for debuginfo right now
16:17:12 <maxamillion> ajax: noted
16:17:17 <ajax> mjw: yes, you would put them in a single -debugsource package
16:17:34 <sgallagh> I think we're talking past each other at the moment.
16:17:34 <Pharaoh_Atem> I've talked to developers about it before, and it's even shown up in places like stackoverflow
16:17:42 <sgallagh> I *think* we're mostly in agreement, though.
16:17:54 <sgallagh> Mind taking a pause while I attempt to summarize and get us on the same page?
16:18:00 <Pharaoh_Atem> sure
16:18:13 <sgallagh> OK, I'll EOF when I finish the summary.
16:18:19 <mjw> ajax, agreed with that. One of the goals is to clean up things so (a previous change did) so that /usr/src/debug and /usr/lib/debug could be provided as a fuse service (like clear linux does).
16:18:55 <sgallagh> 1) Debuginfo packages are large (both in-flight and on-disk) and currently contain more than may be necessary for the person using them
16:19:29 <sgallagh> 2) Not all debugging situations require the source to be available, which is sizeable on disk. Other distros have made it possible to exclude the sources in these situations
16:20:11 <sgallagh> 3) FESCo members seem to be largely in favor of having the sources available *by default*, but we are open to making it possible to exclude them on explicit request.
16:20:48 <sgallagh> EOF
16:20:52 <mjw> And one of the goals is really to put all the tweaks various rpm using distros did to debuginfo package generation upstream and hopefully use the same settings in all distros (over time).
16:20:53 <kalev> Well said
16:21:17 <Pharaoh_Atem> one last bit: external developers, mainly those of proprietaryish applications, would like to be able to provide debug symbols without debug sources
16:21:26 <Pharaoh_Atem> in SUSE, this is easy, in Red Hat/Fedora, this is annoyingly difficult
16:21:46 <sgallagh> Pharaoh_Atem: OK, that's useful information as well. Thanks
16:21:55 <Pharaoh_Atem> part of splitting out debugsources also means that there would be a switch available for people to *not* generate debugsources and have only debuginfo
16:22:10 <kalev> We could have a build time evaluated rpm macro which turns on and off whether the sources subpackage gets produced
16:22:14 <Pharaoh_Atem> exactly
16:22:20 <Pharaoh_Atem> SUSE does this already
16:22:23 <kalev> this should help 3rd party developers who don't want to publish sources
16:22:27 <Pharaoh_Atem> correct
16:22:27 <jforbes> Pharaoh_Atem: I still don't think that is at odds with sgallagh's summary above
16:22:30 <Pharaoh_Atem> it's not
16:22:35 <Pharaoh_Atem> I just wanted to add that bit in
16:22:37 <kalev> but for Fedora packages, we'd enable the sources by default
16:22:38 <sgallagh> jforbes: I think that was supplementary.
16:22:49 <Pharaoh_Atem> I was going to mention it before he started the summary
16:22:53 <Pharaoh_Atem> but he asked me to wait, so I did
16:22:55 <sgallagh> I don't think we were at odds before my summary, I think we were failing to realize we were agreeing :)
16:23:02 <Pharaoh_Atem> :D
16:23:18 <mjw> btw. I don't care about such developers. I think it is unethical to not provide the sources for non-technical reasons.
16:23:26 <ignatenkobrain> IMO this should be controlled by src.rpm / nosrc.rpm
16:23:36 <ignatenkobrain> so if it gets built from nosrc.rpm then it doesn't have debugsource
16:23:41 <Pharaoh_Atem> mjw: yes, yes, but Fedora Workstation has this thing about catering to developers of all flavors
16:23:48 <sgallagh> we don't need to get into the weeds on that.
16:23:57 <mjw> Pharaoh_Atem, that is bad
16:24:03 <mjw> imho
16:24:09 <jwb> weeds
16:24:10 <Pharaoh_Atem> and I've personally been bitten by this issue at work, which is what led me down this rabbit hole to begin with
16:24:11 <sgallagh> I'm fine with the option being available to non-Fedora users. I think it must be forbidden of Fedora packages.
16:24:16 <jforbes> So Proposed: Separate subpackage and source debuginfo is approved with the caveat that by default debuginfo subpackages "Recommends" the source package.
16:24:18 <Pharaoh_Atem> sgallagh: I 100% agree
16:24:47 <jwb> jforbes: +1
16:24:50 <nirik> jforbes: +1
16:25:04 <kalev> jforbes: +1
16:25:11 <maxamillion> jforbes: +1
16:25:13 <sgallagh> jforbes: +1
16:25:48 <Rathann> +1
16:26:16 <kalev> also, unrelated, while you guys are looking at it, could someone devise a scheme please how packagekit could also keep debuginfo up to date? it can't use dnf debuginfo plugin for that because it's not going through libdnf
16:26:50 <jforbes> #agreed Separate subpackage and source debuginfo is approved with the caveat that by default debuginfo subpackages "Recommends" the source package. (7,0,0)
16:27:00 <maxamillion> \o/
16:27:06 <Pharaoh_Atem> *\o/*
16:27:18 <kalev> mjw, Pharaoh_Atem: thanks for coming here and clearing this up
16:27:23 <Pharaoh_Atem> no problem
16:27:24 <sgallagh> Yes, very much appreciated.
16:27:28 <Pharaoh_Atem> happy to do so :)
16:27:28 <mjw> thanks.
16:27:30 <jforbes> #1675 Libglvnd update breaking F25
16:27:38 <jforbes> .fesco 1675
16:27:39 <zodbot> jforbes: Issue #1675: Libglvnd update breaking F25 - fesco - Pagure - https://pagure.io/fesco/issue/1675
16:27:48 <kalev> cschalle: ^^
16:27:55 <cschalle> I am not blind :)
16:27:58 <kalev> :)
16:29:26 <jforbes> There has been a lot of back in forth with this over the week, and there are more high level issues to discuss with this type of update, but the decision from last week was to leave it in updates testing until today's meeting and discuss the push
16:29:55 <nirik> right, the question is: should we grant an exception and let this into stable updates.
16:30:06 <sgallagh> So, the whole point of the Change process is to avoid exactly this situation.
16:30:13 <maxamillion> sgallagh: +1
16:30:21 <jsmith_> sgallagh: +1
16:30:22 <sgallagh> Integration and shaking out the bugs is supposed to happen in Rawhide, not in stable releases.
16:30:30 <cschalle> so ajax, kem and robclark are here to answer any questions as there seemed to be a lot of false claims made on the mailing list to this item
16:30:54 <sgallagh> When the Change was postponed from F25, that really should have been the end of it; it should have been done in Rawhide and worked out logistically there.
16:30:55 <cschalle> sgallagh, but the main issue here was caused by a misundertanding by Dave Airlie, not a bug
16:30:57 <jforbes> I might recommend we discuss the update in particular first, with a determination as to whether or not we allow the stable push for this particular item.  Then follow up with higher level change process discussion
16:32:02 <nirik> Can someone describe the advantage to f25 users? nouveau could work if nvidia driver fails loading? or ? (I can't seem to find the details)
16:32:04 <sgallagh> OK, let's treat it as if the Workstation WG was just coming to us with a request to bypass the Stable Updates policy.
16:32:15 <jforbes> regardless of how we got to this point, as of right now, are there any issues with this update?
16:32:28 <jforbes> meaning things actually broken?
16:32:29 <Pharaoh_Atem> nirik: the idea was that glvnd would allow us to have automatic failback when proprietary driver failed
16:32:30 <ajax> nirik: not quite, but prerequisite for that
16:32:38 <nirik> jforbes: not that I know of
16:32:49 <Pharaoh_Atem> but also to make it so that things don't just get automatically broken when nvidia driver is installed
16:32:51 <sgallagh> jforbes: Well, it's clearly an ABI change in a stable update
16:32:59 <sgallagh> As evidenced by the fact that things *did* break.
16:33:11 <ajax> that's a curious use of the word "abi"
16:33:13 <Pharaoh_Atem> now things like flatpak are going to depend on glvnd for direct GL handling, I think
16:33:23 <Pharaoh_Atem> sgallagh: behavior changed, but not interfaces
16:33:28 <Pharaoh_Atem> that's not ABI or even API
16:33:36 <Pharaoh_Atem> it's something else altogether (do we have a word for that?)
16:33:44 <sgallagh> That's a much higher-level philosophical debate
16:33:47 <jforbes> nirik: it does also make it easier for users to reproduce kernel issues with a non tainted kernel
16:33:48 <nirik> right, but if this is prereq for it, wouldn't it be better to wait for f26 until it actually does stuff? or ?
16:34:06 <jwb> Pharaoh_Atem: semantics?
16:34:31 <nirik> jforbes: how does that process work?
16:34:33 <Pharaoh_Atem> nirik: well, if it's not there, then people's kernel/mesa upgrades can break the bootability of their system
16:34:49 <robclark> there is basically one interface which may change behavior (eglGetDisplay()), since EGL is poorly speced.. and pretty easy to fix (hans was able to fix issues pretty quickly, afaict, once uncovered).. just fwiw
16:34:52 <Pharaoh_Atem> especially with things like Workstation now supporting nvidia wayland
16:34:55 <kalev> Pharaoh_Atem: could you let the xorg team speak? I think they can speak for themselves
16:35:33 <jforbes> the automated fallback doesn't work, but manually doing so, you don't have to dig up the files overwritten by the proprietary driver to get a working system
16:36:08 <ajax> nirik: getting all the way to magic fallback to nouveau if nvidia breaks is kind of a lot of moving pieces
16:36:18 <sgallagh> Pharaoh_Atem: Tell me more about upgrades breaking the boot?
16:36:27 <ajax> nirik: we could update them all at once in f26, or piecewise as they start working
16:36:56 <ajax> as me: i honestly don't care which fedora it lands in, beyond that there are some community members i'll fail to name that if they're annoyed i'm happy
16:36:57 <nirik> ok, fair
16:37:17 <ajax> what i _am_ unhappy about is how this became a discussion about process instead of about bugs
16:37:33 <Pharaoh_Atem> sgallagh: I've personally experienced it about a dozen times with F24 and F25, which is why I mentioned it
16:37:36 <ajax> (and about it landing in fedora without me really being aware of it, but that's my own communication failure)
16:38:02 <Pharaoh_Atem> err, F23 and F24
16:38:26 <Pharaoh_Atem> basically, the nvidia driver wholesale replaces libGL.so.1 and other components
16:38:36 <Pharaoh_Atem> and it also is a kernel module
16:38:42 <jforbes> ajax: which is why I thought we should split the conversation.  So currently, are there any bugs that you are aware of?
16:38:50 <Pharaoh_Atem> when the kernel is upgraded and the module no longer functions, everything breaks
16:38:58 <Pharaoh_Atem> when mesa is upgraded and files are overwritten, everything breaks
16:39:10 <Pharaoh_Atem> and it's tricky to repair depending on which failure case actually occurred
16:39:16 <kalev> ajax: does us switching to glvnd bring any immediate benefits, such as when the nvidia proprietary driver fails to load, they can more easily switch back to the free drivers?
16:39:16 <jforbes> Pharaoh_Atem: it doesn't kill boot, it kills graphical, you can still boot.
16:39:32 <ajax> jforbes: nope. by which i mean, i might be cc'd on something random in bugzilla, but i've not gotten anything directly in my inbox
16:39:35 <Pharaoh_Atem> jforbes: yes, you're right, sorry
16:39:44 <Pharaoh_Atem> from a user experience point of view though, it's pretty bad
16:39:44 * Rathann is curious how  a broken libGL can break boot
16:39:56 <ajax> Rathann: the default login manager is an opengl application
16:39:59 <Pharaoh_Atem> gdm either hangs or crashes, so you can't log in
16:40:17 <jforbes> Rathann: some people don't know that you can switch terminals to log in on cli?
16:40:19 <Rathann> you can switch to a text console, can't you?
16:40:24 <Rathann> ...
16:40:24 <Pharaoh_Atem> most of the time, yes
16:40:26 <Pharaoh_Atem> sometimes no
16:40:31 <Pharaoh_Atem> if gdm hangs, I can't
16:40:33 <Pharaoh_Atem> nothing responds
16:40:42 <kalev> if gdm is restarting in a loop, it can be tricky to switch to text console
16:41:02 <ajax> text consoles are an expert feature
16:41:08 <Rathann> well it shouldn't be restarting in a loop for starters
16:41:21 <jwb> weeds guys
16:41:24 <robclark> (and vt switch is basically a cooperative process between kernel and display manager..  try setting a breakpoint in Xorg process someday ;-))
16:41:24 <nirik> weeds
16:41:26 <nirik> yeah. :)
16:41:37 <ajax> kalev: easier, yes. not automagic, but easier.
16:41:42 <Rathann> ok, I get it, anyway
16:41:51 <Pharaoh_Atem> with the glvnd, Fedora controls the dispatch libGL.so.1
16:42:11 <Pharaoh_Atem> and now when something breaks on the proprietary driver, it fails over the FOSS stack
16:42:18 <Pharaoh_Atem> which means you can log in, and more safely repair the system
16:42:26 <Rathann> that's a very cool feature
16:42:30 <Pharaoh_Atem> it also completely eliminates a whole class of failures related to mesa upgrades
16:42:52 <Pharaoh_Atem> and the kernel is already *very* good about dealing with unavailable kmods
16:43:46 <nirik> anyhow, I guess I am a weak +1 to grant an exception. The kernel thing would be of immediate help...
16:43:49 <kalev> so ajax is saying that an immediate benefit to F25 users is that it's easier to get rid of a non-working nvidia proprietary driver if so desired, when we switch to glvnd
16:43:54 <kalev> and the proprietary driver tends to break quite often due to our kernel rebases
16:44:02 <kalev> we don't get automatic fallback, but switching back to the free drivers would be much easier than it is now
16:44:09 <nirik> and that
16:44:47 <jsmith_> I feel very similarly
16:44:55 <jforbes> So given the major issues are fixed, should we take a vote on this particular exception?  We can follow it up with overall process talk if needed afterwards
16:45:26 <Rathann> I'm willing to let it slide this time as well, with an admonition "never do this in a stable release without proper discussion and FESCo approval again"
16:45:26 <sgallagh> I think I'm +1 because we're already lined up, but if this had been asked before the work was done, I'd have requested deferral to F26.
16:45:41 <kalev> sgallagh: yep, my thoughts exactly
16:46:04 <jsmith_> sgallagh: Agreed :-)
16:46:06 <sgallagh> Actually, I'd like to rephrase that somewhat.
16:46:09 <kalev> also, I'm +1 because it's the Workstation WG asking this and it's their domain
16:46:11 <maxamillion> sgallagh: +1
16:46:23 <sgallagh> Because that sounds a little like encouraging the "ask forgiveness, not permission" approach.
16:46:29 <nirik> There was in fact a change... it just didn't get pushed into the process.
16:46:31 <jsmith_> sgallagh: Quick, reword before anyone else agrees with you :-p
16:47:44 * nirik is still +1 for the record
16:48:25 <jforbes> I would say I am +1 on the merits of the update, I just don't agree with the process of getting us here.  Still, pushing it back would be punitive and not on technical merit at this point.
16:48:38 <sgallagh> Yeah, I'm +1 but I'd *really* prefer that in the future, this get communicated better.
16:48:48 * kalev concurs.
16:49:01 <nirik> mistakes get made, we are humans.
16:49:10 <sgallagh> nirik: I was just typing that :-/
16:49:21 <jsmith_> Proposal: Allow the update, encourage everyone to work through the process better next time
16:49:39 <kalev> jsmith_: +1
16:49:44 <jsmith_> +1 from me
16:49:49 * nirik thought we already voted, but still +1 here
16:50:14 <sgallagh> Ditto. +1
16:50:17 <jforbes> Guess we are voting on the working of jsmith's proposal.. Sure, +1
16:50:26 <kalev> wording
16:50:41 <robclark> just curious (I'm not really an expert in the tools), but is there something that could be done to prevent an update on top of something in updates-testing from landing in stable?  That seemed to be the thing that caused the most drama..
16:51:00 <jwb> +1
16:51:01 <Rathann> jsmith_: +1
16:51:10 <jforbes> #agreed Allow the update, encourage everyone to work through the process better next time (7,0,0)
16:51:18 <jwb> robclark: it's a good question and i think there are some bodhi design changes needed
16:51:28 <jforbes> Okay, is there anything more that needs to be discussed on this before we move on?
16:51:31 <Pharaoh_Atem> robclark: probably not letting it autokarma, and designating a class of things that can't autokarma
16:51:33 <nirik> robclark: yes. I think bodhi should not allow the new update to be made if it can't obsolete the old one
16:51:39 <nirik> I already filed a RFE about that
16:51:51 <nirik> autokarma isn't the problem
16:51:58 <Pharaoh_Atem> no?
16:52:24 <nirik> https://github.com/fedora-infra/bodhi/issues/1266
16:52:28 <Pharaoh_Atem> oh, this
16:52:32 <robclark> ok.. something there (and I'm not really qualified to say what the best soln is) would help I think.. esp w/ devs spread through diff continents and timezones ;-)
16:52:51 <nirik> it's that it allows you to file a new update for something thats 'already in flight' and doesn't always obsolete the older one (because it has different builds or is locked)
16:52:53 <Pharaoh_Atem> this issue is why I wait after an update pushes to stable before pushing out another for my packages
16:53:19 <Pharaoh_Atem> I always thought it was supposed to work that way... *shrugs*
16:53:36 <nirik> what way? anyhow, nothing more from me on this...
16:53:40 <jforbes> It is really a matter of maintainer knowing both the nature of their change, and of the community. For instance we know the kernel community will give karma to updates on the current release before it ever gets pushed to testing, so we keep autokarma off. But we wait longer for rebases.
16:54:20 <jforbes> But yeah, package deps get tricky in bodhi as well.
16:54:36 <jforbes> #topic #1674 F26 System Wide Change: Enable TRIM pass down to encrypted disks
16:54:46 <jforbes> .fesco 1674
16:54:47 <zodbot> jforbes: Issue #1674: F26 System Wide Change: Enable TRIM pass down to encrypted disks - fesco - Pagure - https://pagure.io/fesco/issue/1674
16:55:20 <jforbes> This was punted due to ongoing discussion.
16:56:27 <nirik> I think the questions were answered in ticket...
16:56:32 <jforbes> Does anyone have any discussion on the topic before we vote on the request?
16:56:42 * jsmith_ doesn't have any further questions
16:57:03 <jwb> they were mostly answered in the ticket.  i'm slightly concerned their SSD detection isn't taking everything into account
16:57:06 <kalev> I think the arguments make sense, it's definitely a tradeoff but one I think makes sense to do for new installs
16:57:16 <jforbes> Well, there were open questions in the ticket, but the thread on devel answered most of those
16:57:17 <sgallagh> I'm going to admit that the conversation on devel@ went too deep into the details for me to completely follow
16:57:49 * nirik is +1 for the change.
16:57:51 <jforbes> jwb: from the discussion, it doesn't matter a whole lot.
16:57:57 * kalev is +1 for the change as well.
16:57:59 <jforbes> +1
16:58:17 <jsmith_> +1 from me
16:58:21 * Rathann is 0 due to unanswered questions
16:58:27 <jwb> jforbes: maybe...
16:58:34 <maxamillion> +1 from me
16:58:56 <sgallagh> I'm 0
16:59:09 <kalev> Rathann: what questions would you want answered to change that to +1 ?
16:59:20 <kalev> I'm not providing answers, just curious :)
17:00:38 <jforbes> #agreed  System Wide Change: Enable TRIM pass down to encrypted disks is approved (5,2,0)
17:01:04 <Rathann> well the change owners say "vast majority of users (with SSDs) doesn't want to sacrifice better performance of drive with discard/trim enabled for the sake of secrecy.
17:01:10 <Rathann> "
17:01:19 <Rathann> they say it's a fact
17:01:29 <Rathann> I'm not so sure
17:01:47 <nirik> well, this just makes the option easier
17:01:52 <nirik> it doesn't actually enable fstrim.
17:01:56 <jwb> that's not something they can answer either way
17:02:10 <Rathann> and the other thing is the impact of enabling discard on rotational devices
17:02:14 <nirik> the user would need to do that. (Hopefully after considering that issue)
17:02:31 <jwb> Rathann: they aren't enabling discard on rotational devices iirc
17:02:32 <maxamillion> jforbes: I just realized there's no "key" in the vote count, so I'm not 100% sure which is which ... normally it's notated as (+1: 5, -1: 2, +0: 0)  .... or similar
17:02:43 <maxamillion> jforbes: not a big deal, but thought I'd point it out
17:02:56 <jwb> maxamillion: i'm reading it as +,0,-
17:03:01 <nirik> My understanding is that rotational drives would just go 'nope, sorry, no trim here'
17:03:13 <jforbes> maxamillion: thanks for pointing that out... first time running a meeting, but yes it is (+1,0,-1)
17:03:40 <dgilmore> sorry finished up a different meeting
17:03:51 <jforbes> Okay, moving on
17:04:01 <jforbes> #topic #1635 F26 Self Contained Changes
17:04:04 <maxamillion> jwb: oh, I was reading it as (+, -, 0)
17:04:14 <jforbes> .fesco 1635
17:04:16 <zodbot> jforbes: Issue #1635: F26 Self Contained Changes - fesco - Pagure - https://pagure.io/fesco/issue/1635
17:04:22 <maxamillion> jforbes: no worries :)
17:05:42 * nirik has to run in about 20min. just FYI
17:05:49 <dgilmore> I am +1 to the minimal container, LDC, and replace coolkey with opensc changes
17:05:54 <jforbes> The only one there with any real discussion was the anaconda LVM raid change.  Do we need to discuss it separately or are we ready to vote on all?
17:06:14 <dgilmore> I am not sure on the anaconda lvm change
17:06:34 <dgilmore> jforbes: maybe discuss anaconda, and pip
17:06:34 <nirik> I'd like them to answer cmurphys question. ;)
17:06:38 <dgilmore> and vote on the others
17:06:59 <kalev> I'd like to hear the answer to cmurphy's question as well
17:07:06 <dgilmore> same
17:07:07 <jforbes> Okay, punt on Anaconda LVM And vote on the others?
17:07:19 * Rathann still has reservations on the minimal container image (manual removal of rpm-controlled stuff is a blocker for me)
17:07:23 <dgilmore> what was the questions on pip?
17:07:33 <maxamillion> I am +1 to the minimal container, LDC, and replace coolkey with opensc changes also
17:07:42 <jwb> i guess i don't understand the difference between minimal container and cloud image and atomic image
17:07:44 <dgilmore> Rathann: Cloud and other spins have done it and do it
17:07:51 <jwb> seems like another artifact of all the same content set?
17:07:59 <Rathann> I was unaware
17:08:01 <dgilmore> Rathann: docker base image today strips all the languages
17:08:09 * nirik is also +1 to minimal container, LDC and replace coolkey with opensc.
17:08:21 <dgilmore> we should plan to get the packages fixed in some manner
17:08:25 <Rathann> but it uses the install_langs option, doesn't it?
17:08:38 <kalev> I'm also +1 to minimal container, LDC and replace coolkey with opensc.
17:08:44 <Rathann> that's not what I object to
17:09:16 <sgallagh> Sorry folks, I need to leave for now.
17:09:24 <dgilmore> Rathann: it has not always
17:09:36 <maxamillion> jwb: the minimal container is a small container base image, the atomic host image is considerably smaller than the cloud image and is managed by rpm-ostree instead of dnf, cloud image is basically a released artifact that is similar to server but targeted specifically at cloud-vendors/IaaS (and is tested against those) but is still traditional dnf
17:09:48 <Rathann> ok, +1 to minimal container, LDC and coolkey replacement
17:10:06 <jforbes> So a vote on minimal container, LDC, and opensc
17:10:12 <jforbes> (for those who haven't already)
17:10:17 <jsmith_> +1 to minimal container, LD, and coolkey replacement
17:10:21 <jwb> maxamillion: so... that's a lot of artifacts that are subsets of each other.  who's testing all that?
17:10:59 <jwb> jforbes: +1
17:11:12 <jwb> i'm not opposed to the container thing.  i'm just curious
17:11:17 <dgilmore> jwb: I believe at some point they want the minimal docker base to replace docker base
17:11:30 <dgilmore> they want the new one to enable testing
17:11:32 <maxamillion> jwb: the Cloud WG is
17:11:41 <dgilmore> and provide something sans python thats smaller
17:11:42 <jwb> maxamillion: s/Cloud/Atomic?
17:11:48 <maxamillion> jwb: yes
17:11:53 <maxamillion> jwb: I keep forgetting about the name change
17:11:54 <maxamillion> jwb: https://apps.fedoraproject.org/autocloud/compose
17:12:13 <jwb> well, yay for more containers.
17:12:19 <maxamillion> jwb: AutoCloud will eventually be replaced by Taskotron
17:12:26 <jwb> so i'm told.
17:12:33 <jforbes> #agreed Minimal Container Image, LDC, and opensc are approved (+1:6,0:0,-1:0)
17:12:42 <jforbes> I am +1 on those for the record
17:12:55 <jforbes> Okay, let's discuss pip. It got punted from last week
17:13:24 <jforbes> Are there open questions that need to be addressed?
17:13:48 <kalev> I think the pip change is a step in the right direction. Like someone pointed out in the mailing list, it doesn't fix _all_ the issues we have with mixing rpm/pip controlled stuff, but my understanding is that it makes the situation better
17:14:07 <kalev> and definitely easier to understand, because it changes it so that pip can't overwrite rpm stuff, and vice versa
17:15:23 <pviktori> .hello pviktori
17:15:24 <zodbot> pviktori: pviktori 'Petr Viktorin' <pviktori@redhat.com>
17:15:36 <maxamillion> kalev: +1
17:15:48 <jsmith_> I guess I'm leaning towards +1 on the pip change as well
17:15:52 <jforbes> torsava: any updates here?
17:15:57 <torsava> .hello torsava
17:15:59 <maxamillion> kalev: I am a fan of that in general, I'd like to see similar for other language-ecosystem package managers that don't have a good way of handling that now
17:16:00 <zodbot> torsava: torsava 'Tomas Orsava' <torsava@redhat.com>
17:16:14 <kalev> maxamillion: yes, me too
17:16:15 <nirik> yeah. The big question is if someone already has stuff in /usr/local/... but thats at least less likely than the system level areas
17:16:26 <torsava> jforbes, we've tried to answer all questions on devel@ and we're ready to go ahead with the change
17:16:33 <maxamillion> nirik: +1 - that's a whole other quesiton :)
17:16:57 <pviktori> nirik: the question is if someone already has stuff in /usr/local/ *and* installs things with `sudo pip`
17:17:34 * nirik nods
17:17:38 <jforbes> torsava: do you have any clarity on that?
17:17:38 <pviktori> the first is a fairly advanced use case; the second is mostly following bad tutorials
17:17:52 <nirik> in any case I'm +1 and perhaps we can continue to think of ways to make it better
17:18:17 <jforbes> Okay, sounds like most people agree that this is a decent first step at this point
17:18:20 <maxamillion> if anything, can that scenario at least display a warning of some sort before attempting to carry out the action? or would that just be a weird patch on pip to carry?
17:18:36 <dgilmore> I think I am on the whole okay with sudo pip as long as it plays nice
17:19:29 <jforbes> Well, if pip is there, people are going to run it with sudo. This really seems more about ways to make that safer
17:19:29 <torsava> jforbes, well, if someone compiles python of the same verson X.Y with the prefix /usr/local then they will share site-packages directory with the packaged Python 3's pip, which in itself doesn't pose issues outright, and should be a very rare corner case
17:20:39 <jforbes> Okay, I think we are ready to vote for those who haven't.
17:20:41 <jwb> i'm pretty sure we cannot engineer for all possible cases.  and if they're building their own python runtime stack, all bets are off
17:20:44 <jwb> +1
17:20:56 <dgilmore> +1 also
17:20:56 <jforbes> torsava: maxamillion had an interesting question
17:20:59 <kalev> +1
17:21:02 <jforbes> +1 here
17:21:12 <maxamillion> +1 here
17:21:23 <maxamillion> I would like to see the warning, but it's not a hard requirement for me to +1 on
17:21:51 <Rathann> I'm +1 to fix sudo pip3 change
17:22:06 <torsava> maxamillion, I'll discuss the warning with the rest of the team, it certainly isn't a bad idea
17:22:15 <Rathann> and with that, I have to go AFK for about 15 minutes
17:22:18 <jforbes> #agreed make sudo pip safer is approved (+1:6,0:0,-1:0)
17:22:29 <torsava> Thank you!
17:22:30 <jforbes> Okay, anaconda LVM raid
17:22:31 <Rathann> will read the backlog and vote if necessary later
17:22:44 <maxamillion> torsava: thanks :)
17:22:52 <dgilmore> I would like to see the unanswered questions answered
17:23:06 <maxamillion> dgilmore: +1
17:23:07 <jforbes> Proposal: punt until next week, we would like to see questions answered
17:23:16 <maxamillion> jforbes: +1
17:23:17 <dgilmore> jforbes: +1
17:23:22 <kalev> jforbes: +1
17:23:27 <nirik> =1
17:23:30 <nirik> +1 even
17:23:33 <jforbes> +1 here as well
17:23:36 * nirik has to depart. Sorry.
17:24:12 <jsmith_> +1 from me, if I wasn't clear before
17:24:33 <jforbes> #agreed Discussion on anaconda LVM change is delayed until 2-17 provided open questions get answered (+1:6,0:0,-1:0)
17:24:36 <kalev> I would need to leave soon as well
17:24:42 * jsmith_ does as well
17:24:59 <jforbes> That is going to leave us without enough for a vote.
17:25:14 <jsmith_> I can stay for about 10 more minutes or so
17:25:27 <jforbes> Lets get through what we can
17:25:31 <jforbes> #1676 F26 System Wide Change: GNOME 3.24
17:25:38 <jforbes> .fesco 1676
17:25:41 <zodbot> jforbes: Issue #1676: F26 System Wide Change: GNOME 3.24 - fesco - Pagure - https://pagure.io/fesco/issue/1676
17:25:43 <dgilmore> +1
17:25:44 <kalev> +1
17:25:46 <maxamillion> +1
17:25:47 <jforbes> +1
17:25:48 <jsmith_> +1
17:26:27 <jforbes> #agreed GNOME 3.24 is approved (+1:5,0:0,-1:0)
17:26:43 <jforbes> #1677 F26 System Wide Change: Kerberos KCM credential cache by default
17:26:55 <jforbes> .fesco 1677
17:26:56 <zodbot> jforbes: Issue #1677: F26 System Wide Change: Kerberos KCM credential cache by default - fesco - Pagure - https://pagure.io/fesco/issue/1677
17:27:57 <jsmith_> +1
17:28:28 <dgilmore> +1
17:28:50 <jsmith_> Seems to have had some healthy discussion on the mailing list, which is good :-)
17:29:10 <maxamillion> there seems to be a lot of concerns about this on the mailing lists and I'm not seeing real answers ... there's some "in theory" stuff but I'd like to see real testing done
17:29:56 <maxamillion> actually, nvm ... I see the response I was looking for
17:29:57 <maxamillion> +=
17:29:58 <maxamillion> +1
17:30:02 * maxamillion can't type
17:30:06 <kalev> +1
17:30:06 <sgallagh> /me returns
17:30:14 <jforbes> Yes, and the contingency is there as well
17:30:14 <maxamillion> sgallagh: welcome back
17:30:19 <sgallagh> If there are questions, I may be able to answer some of them.
17:30:24 <kalev> ohh perfect, I was just typing that I need to leave now
17:30:25 <jforbes> +1 here
17:30:41 <kalev> sgallagh can take up my place and there's still quorum :)
17:31:04 <jforbes> sgallagh: vote on the current issue?
17:31:10 <sgallagh> +1
17:31:47 <sgallagh> (I also was the architect of the credential cache approach this is replacing, if that lends any weight to it)
17:32:07 <jforbes> #agreed Kerberos KCM credential cache by default (+1:6,0:0,-1:0)
17:32:37 <jforbes> #topic #1678 F26 System Wide Change: Python Classroom Lab
17:32:43 <jforbes> .fesco 1678
17:32:44 <zodbot> jforbes: Issue #1678: F26 System Wide Change: Python Classroom Lab - fesco - Pagure - https://pagure.io/fesco/issue/1678
17:34:37 <sgallagh> I can't really speak to the value of this, but as long as there's a group that's going to maintain it and it doesn't put too much unnecessary load on rel-eng, I guess I'm +1
17:35:09 <jforbes> From the discussion, I don't know that I see real value either
17:35:16 <jsmith_> Agreed, +1
17:35:18 <maxamillion> sgallagh: same
17:36:03 <jforbes> So outside of the value, I suppose the vote is specifically on approval
17:36:11 <jforbes> +1
17:36:13 <maxamillion> +1
17:36:26 <dgilmore> I am not opposed
17:36:47 <dgilmore> the work on this is more on websites
17:36:57 <maxamillion> the "have a usb you can hand students in an off-line classroom environment and have everything you need" aspect of it I think is nice
17:37:04 <jforbes> dgilmore: so that would make you a 0?
17:37:10 <dgilmore> and the docker side I am not 100% sure on as I did not think we planned to push our layers upstream
17:37:21 <dgilmore> jforbes: +.5
17:37:32 <maxamillion> dgilmore: we will be mirring images to the Docker Hub (for now, no idea about the future)
17:37:34 <jforbes> you don't get your own category :)
17:37:43 <dgilmore> jforbes: :P
17:38:04 <maxamillion> dgilmore: I still need to write the code to add it to the release automation, but it's in the plans
17:38:05 <dgilmore> +1
17:38:43 <jforbes> #agreed Python Classroom Lab is approved (+1:5,0:0,-1:0)
17:38:59 <jforbes> #topic #1679 F26 System Wide Change: SSSD fast cache for local users
17:39:07 <jforbes> .fesco 1679
17:39:08 <zodbot> jforbes: Issue #1679: F26 System Wide Change: SSSD fast cache for local users - fesco - Pagure - https://pagure.io/fesco/issue/1679
17:39:12 <jsmith_> +1 from me
17:39:48 <dgilmore> +1
17:39:58 <sgallagh> Enthusiastic +1
17:40:00 <jforbes> I didn't see much to concern me
17:40:02 <jforbes> _1
17:40:05 <jforbes> +1 even
17:40:22 <sgallagh> jforbes: That implies that you saw a little that did. Care to share?
17:40:30 <dgilmore> jforbes: thats a +1_1 then :D
17:40:56 <maxamillion> +1
17:41:04 <jforbes> sgallagh: not really. There was no discussion because it was well thought out.
17:41:24 <jforbes> I don't see any downsides
17:41:40 <sgallagh> jforbes: OK, just wanted to make sure nothing was going un-considered.
17:42:01 <jforbes> #agreed SSSD fast cache for local users is approved (+1:5,0:0,-1:0)
17:42:10 <jforbes> #topic #1680 Rebase tcpdump in Fedora 25
17:42:19 <jforbes> .fesco 1680
17:42:21 <zodbot> jforbes: Issue #1680: Rebase tcpdump in Fedora 25 - fesco - Pagure - https://pagure.io/fesco/issue/1680
17:42:42 <dgilmore> given the interfaces are not changing i am +1
17:42:44 <jforbes> +1 here
17:43:09 <jsmith_> +1 from me -- looks straightforward
17:43:13 <maxamillion> +1
17:43:39 <sgallagh> I don't think this actually needed our attention. It wasn't a major rebase.
17:43:42 <jforbes> I haven't seen issue with tcpdump in rawhide, and the number of open CVEs against what we have is concerning.  Small issues can lead to big problems
17:43:53 <sgallagh> But +1 and I'm appreciative that they decided to ask
17:44:15 <dgilmore> sgallagh: indeed, if only more did
17:44:23 <jforbes> #agreed tcpdump Rebase in F25 is approved (+1:5,0:0,-1:0)
17:44:37 <jforbes> #topic #1681 Proposed Fedora 27 schedule
17:44:43 <jforbes> .fesco 1681
17:44:45 <zodbot> jforbes: Issue #1681: Proposed Fedora 27 schedule - fesco - Pagure - https://pagure.io/fesco/issue/1681
17:45:24 * dgilmore hides
17:45:31 <maxamillion> dgilmore: ?
17:45:49 <dgilmore> maxamillion: dropping Alpha
17:45:57 <dgilmore> which is briefly mentioned
17:46:25 <jforbes> dgilmore: well, this ticket mentions it, but the schedule still includes it, so we aren't voting on that yet
17:46:27 <dgilmore> though I wish jkurik had not linked to the releng issue about it
17:46:33 <maxamillion> dgilmore: +1
17:46:34 <dgilmore> jforbes: I know
17:47:19 <dgilmore> as i mentioned in the issue, I would rather we drop  (not planned) from the mass rebuild line
17:47:35 <dgilmore> we are supposed to plan for one every release and drop it if not needed
17:47:37 <sgallagh> dgilmore: in favor of actually doing a mass rebuild?
17:47:49 <sgallagh> /me nods
17:48:17 <dgilmore> sgallagh: some people maynot submit a change needing it and delaying because of the wording
17:48:59 <jforbes> So I am inclined to approve the schedule as it is now, knowing that the details may change (though overall schedule wouldn't) based on the alpha discussion
17:49:04 <sgallagh> dgilmore: Well, given that we're dropping the Alpha release, I'd be in favor of using some of the time we reclaim there to just assert that a mass rebuild always happens.
17:49:17 <jsmith_> sgallagh: +1
17:49:33 * Rathann is back
17:49:58 <dgilmore> sgallagh: sure. its supposed to be in the schedule unless like in f25 we said no
17:50:03 <sgallagh> /me has another meeting in 10 minutes
17:50:06 <maxamillion> +1
17:50:12 <Rathann> I'm +1 to a mass rebuild every release
17:50:18 <dgilmore> sgallagh: but I think you are being weirdly nit picking in your words
17:50:19 <sgallagh> dgilmore: I think we're in violent agreement here
17:50:23 <Rathann> until we have koschei enabled by default for all packages
17:50:42 <sgallagh> dgilmore: The reason we have skipped it in the past is due to time constraints.
17:51:05 <sgallagh> If we could replace the Alpha Freeze period with the cleanup of a mass rebuild, we can probably avoid ever skipping the mass rebuild.
17:51:28 <sgallagh> That's the point I was trying to make (though maybe I'm not communicating it well)
17:51:32 <jforbes> I don't know how I feel about the bodhi changes mentioned for rawhide, but again, not part of this ticket, that's a different discussion.
17:51:34 <dgilmore> Rathann: given  modularity it may be unneeded, and given how abusive koschei is to koji I wo uld rather find a different way to achieve what it does
17:51:45 <jsmith_> Anyhooo -- I have to run, folks.  Please mark me as +1 for the schedule, knowing it isn't carved in stone
17:51:59 <dgilmore> but as to the f27 schedule as is I can run with it
17:52:22 <sgallagh> We're voting on the one jkurik provided, not mattdm's reply, yes?
17:52:29 <jforbes> Yes
17:52:31 <dgilmore> sgallagh: yes
17:52:57 <sgallagh> OK, I can be +1 to that
17:53:08 <dgilmore> I would like us to explictly have the  (not planned) removed though
17:53:46 <sgallagh> dgilmore: Agreed
17:53:51 <jforbes> Anyone disagree with removing the (not planned)?
17:54:04 <maxamillion> not I
17:54:15 <Rathann> +1 to removing (not planned)
17:54:46 <maxamillion> +1 to removing (not planned)
17:54:47 <dgilmore> +1 to the schedule with  (not planned) removed
17:54:51 <maxamillion> (for clarification)
17:55:18 <Rathann> so what's the deal with dropping Alpha release?
17:55:22 <jforbes> #agreed jkurik's Fedora 27 schedule is approved with a removal of the "(not planned)' next to the rebuild (+1:6,0:0,-1:0)
17:55:35 <Rathann> hm I didn't say I'm +1 to the schedule
17:55:43 <Rathann> only to the removal of (not planned)
17:55:55 <dgilmore> Rathann: https://fedoraproject.org/wiki/Changes/NoMoreAlpha is the start of the change
17:56:15 <dgilmore> Rathann: that will come next week hopefully
17:56:17 <jforbes> Rathann: oh, sorry, I read that wrong. Are you changing that to something else?
17:56:29 <dgilmore> as I will need to start having it implemented right after branching
17:56:37 <Rathann> cool
17:56:52 <dgilmore> it needs a lot more details yet
17:57:11 <Rathann> do I understand correctly that we are going to update the schedule to skip Alpha once that change is proposed?
17:57:27 <dgilmore> Rathann: that would come if the change is accepted
17:57:46 <dgilmore> we would need to redo the schedule
17:57:56 <Rathann> ok, +1 then to the one jkurik posted
17:57:58 <sgallagh> /me leaves for another meeting
17:58:07 <jforbes> Okay, will leave it as is then
17:58:24 <jforbes> #topic Next week's chair
17:58:54 <maxamillion> I can do it, it's been a while since I last chair'd
17:59:06 <jforbes> thanks maxamillion
18:00:02 <jforbes> #info maxamillion to chair the 2017-02-17 meeting
18:00:06 <jforbes> #topic open floor
18:00:23 <jforbes> Anyone have anything at all?
18:00:28 * dgilmore just notes mass rebuild is running now
18:00:40 <dgilmore> .buildload
18:00:40 <zodbot> dgilmore: An error has occurred and has been logged. Please contact this bot's administrator for more information.
18:00:47 <dgilmore> yippee
18:00:52 <dgilmore> .builders
18:00:53 <zodbot> dgilmore: An error has occurred and has been logged. Please contact this bot's administrator for more information.
18:01:24 <dgilmore> the queue of builds is currently over 3000
18:01:46 <jforbes> #info Mass rebuild is running currently, build queue is over 3000
18:02:07 <jforbes> If nothing else, I will close in 2 minutes
18:02:18 <Rathann> jforbes: https://pagure.io/fesco/issue/1682
18:03:07 <jforbes> Rathann: I think that is for discussion next meeting, to give people some time to go over it
18:03:15 <Rathann> sure
18:03:29 <dgilmore> given that most updates have terrible notes, I suspect anything we said would be ignored
18:03:48 <dgilmore> but we should discuss next week, on the issue
18:04:15 <jforbes> Yeah, I think it will end up being a fairly active discussion
18:04:33 <Rathann> shall I post a link to the ticket in the mailing list?
18:04:34 <jforbes> Okay, closing out. Thanks for coming everyone
18:04:38 <dgilmore> not saying we should not try do better, I just think that a better step would be starting with useful update notes
18:04:39 <jforbes> #endmeeting