fesco
LOGS
18:01:50 <mattdm> #startmeeting FESCO (2015-01-14)
18:01:50 <zodbot> Meeting started Wed Jan 14 18:01:50 2015 UTC.  The chair is mattdm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:52 <mattdm> #meetingname fesco
18:01:52 <zodbot> The meeting name has been set to 'fesco'
18:01:54 <mattdm> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza
18:01:54 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza
18:01:56 <mattdm> #topic init process
18:01:58 <mitr> Hello
18:02:02 <mattdm> hello everyone!
18:02:04 <kalev> hello!
18:02:19 <nirik> morning
18:02:34 <pjp> Hello!
18:02:47 <mattdm> so we have a busy feature-filled agenda today
18:02:56 <mattdm> I've invited a lot of people with relevant features
18:02:59 <thozza> hi all
18:03:17 <jwb> hellow
18:03:17 <tyll> Hi there
18:03:17 <moezroy> .hello
18:03:17 <mattdm> We first have a general scheduling strategy question to go through
18:03:17 <zodbot> moezroy: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
18:03:23 <mattdm> and also a bit about fesco replacementprocess
18:03:46 <mattdm> I'll try to call out people when their feature comes up
18:03:56 <mattdm> but I don't know everyone's IRC nick
18:04:02 <mattdm> so we'll see :)
18:04:05 <sgallagh> .hello sgallagh
18:04:06 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:04:13 <jreznik> mattdm: I can help, I hope (with pinging)
18:04:25 <moezroy> .hello moezroy
18:04:27 <zodbot> moezroy: moezroy 'Moez Roy' <moez.roy@gmail.com>
18:04:35 <mattdm> jreznik: okay cool. in fact, if you can handle that, that'd be AWESOME.
18:05:00 <mattdm> shall we get the fesco replacement process item out of the way quickly before we get to the schedule and feature questions?
18:05:36 <nirik> we can try. ;)
18:05:40 <pjp> mattdm: Okay.
18:05:42 <jwb> i'm not sure it will be quick
18:06:08 <mattdm> in that case, should we instead do it _last_ so we can get the urgent schedule question answered?
18:06:33 <sgallagh> yes
18:06:40 <nirik> that might be better, yes
18:06:43 <mattdm> okay then
18:06:50 <mattdm> #topic 1349 Fedora 22 scheduling strategy (and beyond)
18:06:52 <mattdm> .fesco 1349
18:06:54 <mattdm> https://fedorahosted.org/fesco/ticket/1349
18:06:54 <zodbot> mattdm: #1349 (Fedora 22 scheduling strategy (and beyond)) – FESCo - https://fedorahosted.org/fesco/ticket/1349
18:07:02 <sgallagh> /me notes that GCC5 was proposed today, which *will* require a mass rebuild if we accept it
18:07:11 <mattdm> This is reopened because dgilmore noted that the schedule has no realistic time for a mass rebuild
18:07:35 <mattdm> dgilmore: are you here?
18:08:16 <mattdm> hmmm.
18:08:26 <nirik> perhaps we should do changes first then come back to schedule when dgilmore is here?
18:08:38 <mattdm> i think a lot of the changes depend on the bigger picture
18:08:41 <mitr> We are at ~2 weeks mass rebuild to branch, or at worst 3.5 weeks mass rebuild to freeze (requiring fixes on both branches).  Isn‘t at least the second one plausible enough?
18:08:42 <jwb> yes
18:08:58 <jwb> sorry, my yes was to mattdm
18:09:17 <jwb> i'm not sure i understand your question mitr
18:09:29 * mattdm is also re-re-reading mitr :)
18:09:29 <sgallagh> Is there a really compelling reason not to declare freeze upon completion of mass rebuilds?
18:09:36 <sgallagh> Why exactly do we have the gap there?
18:09:37 <mitr> jwb: WRT “realistic time to do a mass rebuild”
18:09:53 <nirik> sgallagh: so people can fix things without process overhead?
18:09:54 <mattdm> sgallagh time to fix mass rebuild fallout, I think.
18:10:02 <mitr> sgallagh: completion of the automated mass rebuild with hundreds of failures, or completion of mass rebuild + required manual fixups?
18:10:07 <nirik> mitr: based on what time for mass rebuild?
18:10:22 <mitr> nirik: https://fedoraproject.org/wiki/Releases/22/Schedule says Jan 30
18:10:43 <nirik> mitr: right, the problem there is things like ruby don't have time to build in side tag before then.
18:10:45 <sgallagh> mitr: I meant inclusive of fixups
18:10:55 <nirik> we haven't even approved the change yet for it.
18:11:22 <nirik> and other changes could come up until the 28th
18:11:31 <nirik> thats our meeting thats a week out from change deadline
18:11:38 <jreznik> yep
18:11:54 <jwb> so realistically, if we don't do a mass rebuild we're pushing gcc, ruby, hardening, and boost (which we already accepted?) to F23
18:12:04 <vondruch> nirik: We can rebuid ruby packages we will be able to build till side tag merge and leave rest for later
18:12:04 <nirik> so if something appears on the 21st that needs a side tag/rebuild, and we only approve it on the 28th... they have less than 2 days to do it.
18:12:24 <jreznik> jwb: more pie/gcc, boost and ruby can be done in side tag
18:12:25 <nirik> jwb: so far I think... yeah
18:12:41 <nirik> jreznik: no, gcc and pie cannot be done in a side tag
18:12:43 <jwb> jreznik, gcc can't be done in a side tag and then merged back.
18:12:51 <jwb> boost and ruby might get away with that
18:13:06 <moezroy> The pie change will require all packages to be rebuilt. Can rel-eng make a script so that if a build fails,  '%global _hardened_build 0' is added to the spec file, and rebuilt immediately after?
18:13:13 <mattdm> I'm also concerned about any feature which has "mass rebuild it back!" as a contingency plan.
18:13:18 <sgallagh> Just to level-set, we had a general agreement last week that the schedule was paramount and that we were willing to defer stuff to keep that schedule. I assume we're sticking to that statement?
18:13:19 <jreznik> nirik, jwb: sorry, wasn't clear - pie/gcc was one part and ruby/boost another
18:13:21 <dgilmore> hey im here
18:13:26 <jwb> moezroy, rel-eng says there is not time at all for a mass rebuild for any reason
18:13:29 <jwb> moezroy, so no
18:13:32 <nirik> mattdm: indeed.
18:13:35 <mattdm> If that contingency plan in practice means "add two weeks to the schedule", that's very drastic.
18:13:56 <mattdm> (At least, if we don't _already_ have those two weeks built in. Which we don't.)
18:13:58 <jwb> sgallagh, i think that's what were figuring out
18:14:02 <jreznik> mattdm: well in some cases it's the only option
18:14:19 <dgilmore> in the past we allowed 4 weeks for mass rebuild and dealing with fallout and getting FTBFS fixed etc.
18:14:23 <mattdm> jreznik: Right, so, logically, if we're sticking to the schedule for this release, we should defer those changes.
18:14:23 <jreznik> sgallagh: yep - be strict or reset schedule once we have all changes in place
18:14:29 <dgilmore> and make sure there is no regressions and dealing with them
18:14:31 <jreznik> mattdm: yep
18:14:49 <mitr> dgilmore: How much of that was actually needed, though?  (I know, impossible to nail down precisely)
18:14:57 <mattdm> I don't know if everyone saw the comments I dropped in the ticket about an hour ago....
18:14:59 <kalev> dgilmore: are the FTBFS fixes that come up in the mass rebuild time critical? can't we continue fixing those up after ALpha?
18:14:59 <dgilmore> we have gotten the build time down from 7-8 days to ~2 days in large part due to having a lot of arm hardware
18:15:19 <dgilmore> but there needs to be time to clean up things find regressions and fix etc
18:15:35 <dgilmore> mitr: it depends on whathappens
18:15:46 <mattdm> Just from looking at the calendar, if we slip into June/July, that pushes the _next_ release back, and probably into 2016.
18:15:55 <dgilmore> but allowing 10 days for the mass rebuild and dealing with teh fallout of it is not at all realistic
18:16:06 <mattdm> So, in that case:
18:16:18 <nirik> f21 was 4 weeks.
18:16:20 <dgilmore> and with ghc and ruby sidetags we will not be able to do the mass rebuild on the day in teh schedule
18:16:22 <nirik> f20 was less.
18:16:26 <kalev> dgilmore: if you say "dealing with teh fallout" do you mean dealing with FTBFS packages that show up during the mass rebuild=
18:16:32 <mattdm> Proposal: we don't have time for a mass rebuild in this cycle. Features which need a mass rebuild should target F23, and we'll do the mass rebuild in rawhide.
18:16:35 <dgilmore> kalev: no
18:16:35 <jreznik> mattdm: we had june releases and then same year second release already as far as I remember
18:16:37 <kalev> dgilmore: is it important to complete these fixes before the Alpha?
18:16:58 <dgilmore> kalev: finding and dealing with regressions. unintyended ABI breaks etc
18:17:02 <sgallagh> mattdm: s/in Rawhide/in Rawhide shortly after the branch/
18:17:24 <dgilmore> kalev: FTBFS can come after, but breakages need to be fixed first
18:17:32 <kalev> makes sense
18:17:44 <jreznik> kalev: it really depends which packages are hit - for leaf, no big deal but there could be anything important that can delay testing and early testing is the way how to avoid slips
18:17:50 <dgilmore> there is a bunch of unknown things that could happen. we need to try and allow for them
18:17:55 * nirik notes gcc maintainer already was complaining if gcc slips to f22
18:18:03 <jwb> nirik, you mean f23?
18:18:05 <mattdm> jreznik: only f11-f12, and that was so long ago i don't remember. And that was early June. Here we might be talking Junly, and that would be f19-f20, and we all remember that not being pleasant. :)
18:18:09 <nirik> sorry, 23yeah
18:18:10 <sgallagh> nirik: Can you elaborate?
18:18:16 <sgallagh> /me missed that conversation.
18:18:20 <pavlix> thozza: .
18:18:23 <jwb> sgallagh, it's in the gcc5 Change thread
18:18:37 <vondruch> mattdm: we can do Ruby if there is no mass rebuild ... this gives us additional one week
18:18:48 <nirik> " It turns Fedora from being one
18:18:48 <nirik> of the first distros to ship the new compilers to one of the last if not the
18:18:48 <nirik> last one."
18:18:50 <jwb> sgallagh, jakub says fedora will fail to be the first to ship gcc5 if we push it out, and it will possibly negatively impact gcc5 itself
18:18:50 <mattdm> vondruch: can or can't?
18:18:52 <nirik> from the devel list.
18:18:52 <jreznik> mattdm: my memory blurs more and more with overy other release :)
18:18:58 <dgilmore> mattdm: we just have a shorter time between F22 going gold and branching for F23
18:19:27 <jreznik> dgilmore: yes, it's not exactly +6 months
18:19:35 <sgallagh> /me disappears to read that thread.
18:19:39 <mattdm> nirik: That's an awfully dramatic statement. But, again going to the calendar argument, trying to shove everything into the imminent release when there's not really time for it actually _slows us down_.
18:19:58 <nirik> mattdm: just repeating it so we had more data. ;)
18:20:04 <rdieter> jakub's quote (if gcc5 gets bumped from f22): ".  It turns Fedora from being one
18:20:05 <rdieter> of the first distros to ship the new compilers to one of the last if not the
18:20:07 <rdieter> last one."
18:20:10 <jwb> mattdm, i don't think it's dramatic tbh
18:20:16 <rdieter> (oops,sorry for the multiline)
18:20:32 <nirik> rdieter: just noted it above. ;)
18:20:39 <rdieter> oh rats
18:20:49 <vondruch> mattdm: can
18:20:59 <mattdm> vondruch: okay, so that's good.
18:21:00 <jreznik> mattdm: f19 was 07-02 and f20 12-17 with quite a lot of slips, I know, it's close to break, but doable
18:21:04 <nirik> anyhow, I guess we need to decide how important gcc is and if there's a way to accomidate it. Not sure there is.
18:21:25 <jwb> nirik, gcc and pie
18:21:35 <jwb> pretty sure pie faces the same scheduling issues
18:21:41 <dgilmore> the pie change may cause more issues than gcc
18:21:48 <nirik> yeah... and we also want to land gcc before pie....
18:21:49 <mattdm> gcc is important. However, I don't see that slowing down _everything_ is worth it.
18:21:53 <nirik> at least according to jakob.
18:22:04 <kalev> nirik: can we ask the gcc people to try to do a test mass rebuild to estimate the amount of breakage gcc 5 might cause?
18:22:17 <dgilmore> kalev: they are planning that
18:22:18 <mattdm> The pie change seems like a good one in general, but it also does not seem urgent.
18:22:19 <jreznik> kalev: they are planning test mass rebuild
18:22:20 <jwb> if we don't accept gcc for f22, i want us to actually PLAN stuff and agree it's a damn important feature for f23
18:22:22 <kalev> and then decide next week, depending on that data if it fits into F22 picture
18:22:41 <mattdm> jwb: yes, I'd be ready to accept it as an F23 feature basically immediately.
18:22:43 <sgallagh> jwb: As previously noted, I think that the mass rebuild for gcc5 should happen within a few days of the branch on Rawhide.
18:22:53 <thozza> kalev: sounds like a good idea to me
18:22:58 <nirik> kalev: yeah, they are planning it, but not sure when.
18:23:05 <sgallagh> (Though there's an argument to be made for waiting until the final .0 release in early April as well.
18:23:21 <jwb> sgallagh, yeah, agreed.  but i want it an officially accepted Change.  not something that just happens and then we approve it 4 months later
18:23:35 <sgallagh> jwb: I can get behind that
18:23:36 <mitr> sgallagh: Heh.  A mass rebuild that breaks rawhide is an innovative way to focus bug fixing on the f22 branch ☺
18:23:42 <jreznik> if they would say now - hey, we have gcc 5 package, we did test rebuild... that would be great but I asked on the list and I did not get even estimate
18:23:53 <dgilmore> sgallagh: we have never done that.  we have always moved to gcc when its at the point it currently is that only regressions get fixed
18:23:58 <jwb> they're also only planning to do their build on x86_64
18:24:01 <mitr> jwb: … and a corresponding draft schedule that is guaranteed to have enough time for it, I presume.
18:24:02 <nirik> jreznik: well, they are waiting for the 'stage4' one I think
18:24:11 <jwb> mitr, yes, that's the PLAN part :)
18:24:11 <mattdm> We're effectively talking about a three month difference here — either a summer F22 including gcc5, or an autumn F23.
18:24:40 <sgallagh> dgilmore: I assume you mean the "wait for .0" part of my statement. I'm fine with building immediately after branch. It was just a thought.
18:24:45 <jreznik> nirik: the question is - even if we say let's slip to june, would it be enough? and slipping more is no way
18:24:59 <sgallagh> (If we're waiting either way, do we wait longer? But I suppose the mass rebuild is the only way to help them *reach* that .0 safely)
18:25:02 * mclasen would be sad to not have the current gcc release included in the developer workstation
18:25:03 <dgilmore> sgallagh: right
18:25:27 <jwb> kalev, them only building on x86_64 and us waiting on that is kind of ignoring ARM, which is still primary
18:25:38 <dgilmore> there is something to be said for having the latest gcc, its something that can attract users
18:25:41 <mattdm> jreznik: Exactly. We need to make sure that any schedule has time for the contingency plan. It doesn't help to create a schedule we know is a lie.
18:25:48 <mitr> jreznik: That really depends on which point in the gcc schedule do we consider to be safe to make the (presumably only) mass rebuild.  stage 4, ga, sometihng else?
18:25:49 <dgilmore> jwb: and i686 b
18:25:54 <dgilmore> s/b/ /
18:26:05 <mattdm> (that just gets us into "no time for contingencies! full steam ahead!"
18:26:38 <mattdm> Sure. I don't dispute that latest GCC is a selling point. But we can't have it just by wishing hard.
18:26:41 <dgilmore> mattdm: thats part of why we have 4 weeks for mass rebuild
18:26:42 <nirik> I don't suppose anyone has ability to summon jakub to the meeting?
18:26:48 <nirik> ha. nice.
18:26:56 <dgilmore> it would be clear early if its horribly broken and we need to revert
18:27:00 <jwb> i don't think this issue is about which gcc code is in use (.0 or otherwise).  i trust the maintainers on that.  this is mostly about the time for the rebuild and fallout itself
18:27:08 <mattdm> jwb: yes.
18:27:13 <jwb> and the current schedule has no time for a rebuild
18:27:21 <dgilmore> jwb: correct
18:27:36 <jwb> so we either change the schedule, or we punt mass rebuild features
18:27:39 <jwb> it's pretty simple.
18:27:51 <nirik> well, it has 1.5 weeks or so...
18:27:53 <jreznik> jwb: we have two options - move schedule (but we don't know how much) or move all mass rebuilds to f23...
18:28:01 <jakubrh> I think I can have initial rpms by tomorrow or so, then we can start the test x86_64 mass rebuild, have it done by Tuesday or so
18:28:01 <jreznik> jwb: you were faster
18:28:05 <jwb> :)
18:28:17 <dgilmore> nirik: we can not do it in the 10 days in the schedule
18:28:20 <mitr> Again, if historically we’ve had 4 weeks for a mass rebuild, and we have drafted 3.5 weeks from rebuild to Alpha freeze, could that not be sufficient?  Yes, doing fixes after the branching would be painful, but it still may be an option.
18:28:46 <nirik> dgilmore: right, I am just saying that there is some time alloted, just not enough. It's not fair to say "there is no time" it's "there is not enough time"
18:28:52 <dgilmore> mitr: it really needs to be done before branching
18:28:57 <mitr> dgilmore: why?
18:28:59 <mattdm> Who would do the work for those fixes? Volunteer packagers?
18:29:02 <jakubrh> so, I think by Jan 30 we can have gcc ready for mass rebuild
18:29:02 <nirik> for f20 we had 17 days it looks like
18:29:22 <jreznik> mitr: potential breakage could slow down testing... and we know early testing is the best way how to avoid slips
18:29:30 <dgilmore> mitr: because if we have to enact teh contingency post branch we have to do it in the branch and rawhide
18:29:31 <jwb> nirik, f20 didn't introduce a new c++ thingy
18:29:47 * jwb is getting all technical now
18:29:55 <nirik> true, just saying it's not always 4 weeks
18:29:56 <sgallagh> dgilmore: Let's assume that the "contingency" is that we slip until everything is fixed.
18:30:02 <mitr> dgilmore: I’d imagine rawhide would just march on with the new setup
18:30:05 <jwb> dgilmore, uh, no you wouldn't.  you'd just do it in the branch
18:30:13 <sgallagh> Reverting from a major GCC change is likely to be similar effort to fixing it
18:30:13 <jwb> rawhide would stay on gcc5 and get fixed
18:30:17 <dgilmore> mitr: not necessarily
18:30:21 <jakubrh> f19 did, f17 etc.
18:30:54 <nirik> jakubrh: is there anything we can do to speed up your mass rebuilding or add arches to it?
18:31:04 <jwb> like armv7hl?
18:31:07 <jwb> or i686?
18:31:11 <nirik> yes
18:32:03 <jakubrh> nirik: if rel-eng has hw and scripts to do that, sure, I can provide rpms hopefully by tomorrow, it is a matter of just doing a test mass rebuild that doesn't bump NVRs
18:32:40 <jakubrh> nirik: doesn't need to store the resulting rpms either, just keep around the log files for later analysis
18:32:57 <nirik> well, we can scrape up some arm socs without much trouble... not sure about x86, but might be able to find something.
18:33:24 <mattdm> I'm really unhappy about accepting a change where the contingency plan is going to add so much to the schedule.
18:33:32 <jakubrh> for x86_64 we just borrowed a couple of beaker boxes and run mock in a loop
18:33:57 <mattdm> jakubrh: did you see my earlier comments re the calendar? Is getting this in an October F23 release really so bad?
18:34:04 <dgilmore> jakubrh: you can do the same for i686 and armv7hl
18:34:20 <mattdm> Because otherwise, we're perpetuating a cycle where the F23 release is likely to be next year (February seems realistic.)
18:34:47 <jakubrh> mattdm: I've used that contingency wording in all earlier GCC features; if you prefer it written as that we'll fix GCC bugs as quickly as possible when they are reported, I can rewrite it the same way
18:35:22 <dgilmore> mattdm: not at all
18:35:22 <jreznik> mattdm: I'd not be that pesimistic but it would be december with high risk of january
18:35:25 <nirik> would it be somewhat possible to land gcc for f23, but once things are somewhat stablized make it available in f22 (but not rebuild everything with it), ie for developers?
18:35:31 <dgilmore> mattdm: we can still say it will be october
18:35:33 <mitr> jakubrh: the wording is not really the concern, it’s what would we _actually do)
18:35:35 <jakubrh> dgilmore: I'm not aware of any powerful armv7hl boxes, and for the first step one arch might be enough anyway, lots of issues will be common to all arches
18:35:55 <dgilmore> mattdm: it just means a shorted window between f22 gold and f23 branching
18:36:16 <mattdm> dgilmore: so... a three month cycle for f23, when we can't hold to 6 for this one? I'm skeptical!
18:36:16 <dgilmore> jakubrh: the same armv7hl boxes as we use as builders are available in beaker
18:36:39 <jreznik> dgilmore: october would be too much, but aiming end of november/early december would be possible - just with high risk of f22 slips and f23 slips -> jan
18:36:42 <jakubrh> dgilmore: like 10-20% of FTBS unrelated to GCC as usually, most packages just building, some needing small changes, and a couple of ICEs
18:36:52 <nirik> dgilmore: also means no mass rebuild for f23. definitely no time there in a short schedule.
18:36:59 <mitr> One possible alternative to worrying about contingencies would be to just do the test mass rebuild _and_ test the resulting images well enough to be comfortable that it will not break any criteria / cause a slip (i.e., essentiall, do the build-breakage-fixes on a branch)
18:37:07 <dgilmore> nirik: right
18:37:34 <dgilmore> nirik: unless we did mass rebuild while still stabalising f22
18:37:36 <jakubrh> the problem I have with October schedule for GCC is that then we are the trailing edge distro as far as compiler technology goes
18:37:46 <nirik> mitr: that would let us decide to have a smaller window for mass rebuild, but how small a window?
18:37:48 <mattdm> I feel like promising that we'll do a short cycle next time is like saying we're going to start our diet on Monday.
18:37:52 <jakubrh> if that becomes the habit, we'll lose developers
18:38:19 <jreznik> mattdm: I should start diet on Monday...
18:38:23 <sgallagh> jakubrh: So for this single release, why not offer GCC5 in a COPR?
18:38:23 <nirik> jakubrh: would it be somemewhat possible to land gcc for f23, but once things are somewhat stablized make it available in f22 (but not rebuild everything with it), ie for developers?
18:38:25 <mattdm> jakubrh: we can't possibly align Fedora releases to _every_ important-to-developers product.
18:38:43 <mattdm> The best thing we can do is keep to a regular cadence of six month releases.
18:38:54 <mitr> nirik: the 40 hours to do an official rebuild?  Or, hell, just create a side tag and do a full mass rebuild there.
18:39:00 <mattdm> And, looking at the calendar, I _really_ don't see another way to get to that from here.
18:39:03 <nirik> mitr: no, I am saying no rebuild.
18:39:06 * mitr expects to get murdered for suggesting this.
18:39:22 <dgilmore> jreznik: i think we could do october 27 release for f23
18:39:26 <nirik> I am asking if we could ship the tools, but not rebuild the distro with it (except as it natually rebuilds)
18:39:39 <jakubrh> nirik: not possible I think, as std::string and std::list change ABI; if package owners do extra work, they can achieve ABI compatibility, or if their APIs don't include those two templates
18:39:48 <dgilmore> but I do not know exactly how that would look with f22 if we added 2 weeks
18:39:54 <nirik> jakubrh: ok. Was a thought. ;(
18:40:02 <jwb> SCL?
18:40:10 <mitr> jakubrh: Um, so this is breaking third-party C++ binaries?  Or is this only a soname change?
18:40:20 <jakubrh> nirik: the ABI change is done in a way that the same libstdc++.so.6 is used and provides both manglings
18:40:40 <mattdm> jwb: +1 to SCL, especially for the available-to-developers side of the story.
18:40:42 <jakubrh> mitr: it isn't a SONAME change
18:40:47 <jreznik> dgilmore: with f22 when? I can put dates to taskjuggler to see what will happen
18:40:55 <thozza> jwb: which are not in Fedora? :)
18:40:55 <nirik> jwb: if thats the question... no? ;)
18:41:12 <jwb> thozza, get on it :)
18:41:18 <dgilmore> jreznik: june 2
18:41:20 <mitr> mattdm: gcc available to developers with half of the library ecosystem incompatible would be… well, something.
18:41:50 <jreznik> dgilmore: with june 2, it would be possible I guess
18:42:19 <nirik> dgilmore: so, you are proposing what? add 2 weeks after the 30th mass rebuild? or move mass rebuild later and add 2 weeks? or ?
18:42:37 <dgilmore> jreznik: that would give us 24 days for mass rebuild  which should be doable
18:42:39 <jwb> i've kind of lost the thread here
18:42:42 <jakubrh> mitr: libstdc++.so.6 is backwards fully ABI compatible, it is just if you have package providing C++ APIs in your shared libraries to other packagesm then you need to decide what you want to do
18:42:59 <jakubrh> mitr: there will be docs available with details
18:43:19 <dgilmore> nirik: that we allow 2 more weeks for mass rebuild  push branching and everythinga fter out 2 weeks
18:43:47 <dgilmore> that we set f22 release date for June 2 and F23 release date for October 27
18:43:51 <mitr> dgilmore: If we do that, can we _also_ get the side tags done and merged in time?
18:43:54 <nirik> dgilmore: ok, one issue with that is that the things wanting to use side tags (ruby, boost) don't have enough time before mass rebuild still.
18:44:29 <dgilmore> mitr: it will be pushing it. but I could exclude the packages in the side tags from the mass rebuild and let the side tag owners deal with them
18:44:34 <mattdm> so that makes a june target. add in 2 more weeks for the contingency and we have an estimated _real_ release of june 16 -- if we're not planning for that, the contingency is lip service.
18:44:47 <mattdm> and asking for _realistic_ contingencies is something we've already agreed to.
18:44:56 <nirik> jwb: I guess the thought was to see after jakubrh's mass rebuild how disruptive gcc 5 is, if it's not too much, try and fit it in this cycle.
18:45:19 <mattdm> and if we have another couple of weeks of slip from that, we're looking at a june 30 release.
18:45:28 <dgilmore> we could always pull things forward if the mass rebuild is really smooth
18:45:38 <dgilmore> we could also only mass rebuild archful packages
18:45:40 <halfline> would it be possible to ship f22 with gcc 4.9 + std::string / std:list backported from gcc 5 ?
18:45:42 <jwb> nirik, didn't we have that thought 15min ago and said it wouldn't cover everything and we'd still run short on time?
18:45:42 <dgilmore> and ignore noarch
18:45:42 * nirik chuckles
18:45:43 <sgallagh> dgilmore: No, we cannot pull forward.
18:45:50 * jwb has no idea what changed since 15min ago
18:45:53 <dgilmore> sgallagh: sure we can
18:45:54 <mitr> mattdm: ISTM that just doing an early release, _and_ getting into the habit of landing all the gccs and rubys _way_ earlier in the cycle (ideally, immediately after branching), would be a win for general stability and having fewer allnighters/slips
18:45:56 <sgallagh> Other groups like QA are dependent upon a no-shorter-than schedule
18:46:01 <sgallagh> s/shorter/sooner/
18:46:11 <sgallagh> And docs, and websites...
18:46:28 <jakubrh> halfline: no, backporting into symbol versioned libraries is a big no-go
18:46:29 <dgilmore> sgallagh: if we feel the mass rebuild is fine and done and we are a week before branching we branch
18:46:46 <mattdm> mitr "early" meaning "schedule as planned"?
18:46:53 <mattdm> If so, yes, I very much agree.
18:46:59 <mitr> mattdm: For F22, yes.
18:47:22 <sgallagh> mattdm: I think he was talking about future plans. I.e. always land big changes like this early in the Rawhide schedule
18:47:29 <sgallagh> post-branch
18:47:30 <dgilmore> sgallagh: yes they are but that would still be after they would have happened before pushing out 2 weeks to allow sufficient time for the mass rebuild
18:47:41 <mattdm> sgallagh: right, so... why not start that _now_?
18:47:47 <mitr> (And separately, getting into the habit of side-tags/branches for all invasive changes, including a gcc rebase, would be well worth trying.  But that’s not happening for F22 obviously either, and again the F23 early mass rebuild would be an interesting time to try.)
18:47:51 <jakubrh> is there enough armv7hl hw, or is that the factor that slows down mass rebuilds?
18:47:59 <sgallagh> dgilmore: What I mean is, we can't give them more time, have them plan on that, then arbitrarily shorten it again
18:48:07 <nirik> jakubrh: it's not the time to do the actual builds.
18:48:10 <sgallagh> mattdm: I didn't say we shouldn't. I agree.
18:48:11 <dgilmore> jakubrh: the arm hardware speeds up the mass rebuild
18:48:13 <sgallagh> I was translating :)
18:48:20 <nirik> it's the time it takes everyone to clean up after them... fix bugs, etc
18:48:31 <dgilmore> jakubrh: f19 mass rebuild was about 5 days and f20 adding arm was about 49 hours
18:48:35 <dgilmore> 40 hours
18:48:46 <kalev> dgilmore, nirik: would it be possible to use koji to do the actual test mass rebuild? like have a side tag with gcc 5, and fire off scratch builds for all packages there?
18:49:10 <dgilmore> kalev: maybe.
18:49:16 <sgallagh> kalev: Again, the bottleneck isn't the build time, it's the human response
18:49:17 <nirik> might work, sure.
18:49:47 <sgallagh> /me quotes "Optimizing anywhere but the bottleneck is an illusion"
18:49:55 <dgilmore> kalev: its likely harder to get the logs for jakub and team to analyse and see what the issues are
18:50:00 <jakubrh> if koji could do that, I think we'd certainly appreciate that; we could then just grab the log files and analyse
18:50:16 <nirik> well, yeah, might be harder to scrape them...
18:50:34 <jakubrh> if they are wgettable, it is fine
18:50:49 <dgilmore> I am happy to try make it easier for jakubrh to get things done
18:50:57 <dgilmore> jakubrh: they are
18:51:06 <mattdm> nirik dgilmore jakubrh What problem are you solving right now?
18:51:34 <dgilmore> mattdm: ways to make sure that teh test mass rebuild tests all arches
18:51:34 <kalev> estimating breakage from gcc 5
18:51:39 <jwb> wedging a gcc5 rebuild into the f22 schedule
18:51:40 <nirik> mattdm: speed at which we can look at gcc5's rebuild and see how many things fail to build... ie, if it looks like there will be a lot of fallout or not
18:51:40 <sgallagh> Since we've now been on this for an hour...
18:51:41 <sgallagh> Proposal: While Fedora prefers to always carry the latest features, FESCo has determined that the Fedora 22 schedule is not compatible with including a mass-rebuild. FESCo would prefer to hold to a time-based schedule.
18:51:42 <sgallagh> Votes?
18:51:49 <dgilmore> to give us higher confidence in the real mass rebuild
18:51:58 <jakubrh> mattdm: find best way how to do test mass rebuild as fast as possible; for that we basically care just about build.log and maybe root.log
18:52:03 <sgallagh> (+1 to my own proposal, for the record)
18:52:14 <dgilmore> -1 I think we shoudl accomodate gcc
18:52:21 <mattdm> jakubrh: does this include fitting that into the existing schedule?
18:52:43 <dgilmore> I think we can accomodate it without sacrificing f23 going into next year
18:52:48 <jakubrh> mattdm: anything that failed in a way not easily understandable from the build.log file can be rebuilt locally in mock
18:53:42 <mattdm> jakubrh: so is that saying Jan 30th rebuild and Feb 10th branch are okay after all?
18:53:45 <jakubrh> mattdm: if the existing schedule is start mass rebuild by Jan 30, then there is hopefully time for the test mass rebuild in the next < week including analysis
18:54:10 * nirik feels conflicted. I should vote +1 to sgallagh I suppose, since I agreed to time based.
18:54:11 <mitr> sgallagh: I would like for $someone to seriously explore a side-tag mass rebuild, and accepting it if the result were a QA-passing image; but assuming that wouldn’t happen, +1
18:54:36 <dgilmore> mitr: we always rebuild in a side tag
18:54:45 <mattdm> dgilmore: so are you agreeing with jakubrh's assesment of time needed?
18:54:48 <mitr> sgallagh: rebuild + _fix up_
18:54:49 <mattdm> I'm +1 to sgallagh btw
18:54:53 <mitr> dgilmore: ^^
18:55:19 <jwb> dgilmore, are you proposing to adjust the schedule to accomodate a mass rebuild?
18:55:25 <dgilmore> mattdm: if jakub says it can be done i will do everything I can to make it happen
18:55:31 <mitr> sgallagh: Alternatively, we could just wait until Jan 29 for the test rebuild results in case we were pleasantly surprised… if the other Change owners can deal with postponing the decision until the very last minute.
18:55:38 <dgilmore> jwb: i already proposed that
18:55:46 <jwb> apparently that was missed
18:55:50 <sgallagh> mitr: I'm opposed to holding off the decision that long.
18:55:58 <sgallagh> It's unfair to projects like Ruby and Boost
18:56:02 <dgilmore> jwb: i proposed setting release date for f22 to June 2 and F23 to October 27
18:56:03 <thozza> what if the results of jakubrh'sgcc5 rebuilds look good? are we going to reconsider it?
18:56:12 <jwb> dgilmore, did anyone vote on that?
18:56:20 <dgilmore> jwb: I do not think so
18:56:29 <mattdm> (so far, 4 for, 1 against sgallagh's proposal)
18:56:36 <mitr> sgallagh: Holding off the decision would be fine with me; but we would have really to do the test mass rebuild _with all the other Changes we plan to include_; i.e. decide on PIE now, then do the test mass rebuild with the PIE or non-PIE configuration we plan to sue.
18:56:37 <nirik> thozza: thats the question I guess...
18:56:38 <jreznik> it would be doable, with risk, but doable
18:56:52 <dgilmore> thozza: if the test rebuild shows a ton of issues then we should wait until f23
18:57:01 <mitr> thozza: ^^ - would we be testing the other mass-rebuild-needing Changes at the same time?
18:57:08 <thozza> dgilmore: I agree
18:57:09 <dgilmore> i am more worried about the pie change causing issues than gcc
18:57:39 <thozza> mitr: well, I guess we should, not to loose time
18:57:49 <nirik> so then the counter proposal is wait until we have test mass rebuild data to decide if we want to try and accomodate it in f22 or punt to f23?
18:57:55 <mattdm> I am -1 to dgilmore's proposal, because I think that there's no way that a june->october schedule will hold.
18:58:00 <sgallagh> Which means a combinatorial explosion of things that might cause the whole thing to go belly-up
18:58:08 <mitr> thozza: that would imply having patches for all of them ready by Saturday.
18:58:11 <jakubrh> e.g. if C11 is a serious issue, I have no problems with adding -std=gnu89 into the default RPM_OPT_FLAGS for f22 and only change that up in f23
18:58:27 <sgallagh> I agree. October 27th is unrealistic and will likely slip into December at least.
18:58:36 <jakubrh> that is not an ABI issue; C++ is more important ABI-wise
18:58:42 <mattdm> jakubrh: I just don't think we have time to play with options like that
18:58:58 <mitr> jakubrh: AFAICS we don’t have to do multiple runs experimenting with combinations of gcc options/Changes until we arrive at something we are happy with.
18:59:04 <jakubrh> mattdm: during the test mass rebuild, why not?
18:59:12 <dgilmore> sgallagh: mattdm: can you please explain why you think it is not realistic to ship F23 Oct 27?
18:59:35 <jakubrh> mattdm: start test mass rebuild, analyze after half a day or day of what it gave
18:59:42 <nirik> it's always the _next_ fedora we plan on doing a short cycle on.
18:59:52 <sgallagh> dgilmore: Assuming a historical two week average slip (pulled out of the air), we realistically have four months to release. I don't buy that.
18:59:52 <moezroy> digilmore: what kind of issues do you think the  PIE change will cause? are these issues other than FTBS?
19:00:02 <jreznik> we are on this one hour and in circle...
19:00:06 <sgallagh> We're witnessing *right now* that we have a heard time sticking to our guns on this
19:00:09 <mattdm> dgilmore: because if f22 slips just a few weeks, then we're at a nominal schedule with 4 months. There's barely time to cram that in. And if _that_ slips, we hit the same holiday-time pain we did this time.
19:00:13 <sgallagh> s/heard/hard/
19:00:30 <jwb> i went along with the time based schedule on the understanding that we'd actually STICK to it
19:00:37 <jwb> so i'm going to go with what we agreed to stick to
19:00:42 <jwb> +1 to sgallagh -1 to dgilmore
19:00:45 * nirik notes we need just one more +1 for sgallagh
19:00:48 <jakubrh> as I said earlier, if you really consider PIE, then you should use GCC 5 for that, otherwise the penalty will be too big even on x86-64
19:00:48 <mattdm> kalev, thozza, t8m?
19:00:57 <thozza> sgallagh: +1
19:01:03 <mattdm> jakubrh: yeah, I think that this would also mean deferring the PIE change
19:01:06 <jakubrh> gcc 5 has some improvements in that area if new enough binutils is used
19:01:07 <dgilmore> mattdm: we are likely to see less change given the shorter time. we do have a precident of it happeninga nd it worked in the past
19:01:17 <sgallagh> jakubrh: The proposal we just agreed to includes postponing PIE
19:01:22 * jwb notes that he and thozza just voted for sgallagh's proposal
19:01:27 <jwb> which means it passed
19:01:34 <sgallagh> That brings it to +6, -1
19:01:37 <mattdm> okay. so we have +6/-1 for this proposal.
19:01:39 <kalev> I am 0 for postponing the mass rebuild -- I think by its own, it's not very risky and doesn't need a lot of time to clean up
19:01:55 <mattdm> okay so +6/-1/0
19:01:56 <kalev> but it can be risky if things like C++ ABI change and other changes are accepted
19:02:14 * mattdm looks up to find the proposal again
19:02:39 <mattdm> shesh that's a lot of scrollback. sgallagh, can you restate?
19:02:40 <sgallagh> #agreed While Fedora prefers to always carry the latest features, FESCo has determined that the Fedora 22 schedule is not compatible with including a mass-rebuild. FESCo would prefer to hold to a time-based schedule. (+6, 1, -1)
19:02:51 <mattdm> sgallagh: thanks :)
19:03:03 <moezroy> jakubrh, is there going to be a GCC 5.x release planned for F23 if GCC 5 gets into F22?
19:03:11 <nirik> so that assumes no mass rebuilding changes... but boost and ruby are ok still?
19:03:33 <mattdm> nirik: we'll need to revisit boost, maybe. vondruch said that ruby doesn't require one.
19:03:50 <jwb> i think it excludes PIE right off the bat
19:03:54 <sgallagh> nirik: With eliminating the mass-rebuild time, if we extend that to landing side-tags, I think those are probably fine.
19:03:56 <mitr> jreznik: Do you have a list of mass-rebuild requiring changes that have been either proposed or already approved handy in some form?
19:04:00 <kalev> jakubrh: is there any way to have GCC 5.x in F22 without needing a mass rebuild?
19:04:11 <sgallagh> jwb: I stated explicitly above that the proposal implied refusing the PIE chagne
19:04:23 <nirik> sgallagh: s/refusing/deffering/ ?
19:04:24 <kalev> jakubrh: something like staying with the 4.x C++ ABI, so that we don't need to rebuild?
19:04:30 <mattdm> nirik: ++++++++
19:04:31 <vondruch> mattdm: ruby needs rebuild of ~150 packages
19:04:33 <sgallagh> kalev: We covered that at length above. Please read the scrollback
19:04:33 <jakubrh> kalev: given that it is backwards compatible, it could be added without a mass rebuild
19:04:55 <jreznik> mitr: as far as I know, it was gcc and pie
19:04:57 <sgallagh> nirik: Yes, that's what I meant. Decision deferred to F32
19:05:02 <sgallagh> Err, F23... :)
19:05:12 <mitr> sgallagh: Or we could just approve it right now for F23.
19:05:15 <thozza> sgallagh: good one :)
19:05:29 <jakubrh> kalev: just with the problem that for some C++ packages, if you rebuild them, you'd also need to rebuild some related packages
19:05:34 <sgallagh> mitr: Maybe defer the decision to the moment the new FESCo is seated?
19:05:48 <sgallagh> Seems unfair to saddle the next group with a decision they have to live with, since it's close and we have time
19:05:51 <jakubrh> kalev: easily detectable at dynamic link time or using a script
19:05:53 <mattdm> I'm okay with approving F23 features now so people can know that they can be worked on.
19:05:54 <kalev> jakubrh: Right, that's the case I meant -- would it be possible to avoid that trap for F22 since we aren't planning the mass rebuild any more?
19:05:59 <mitr> sgallagh: makes sense.
19:06:42 <sgallagh> kalev: The problem is that the mass rebuild and subsequent fix-ups are a big part of how GCC determines that it's ready for stable release.
19:06:52 <jakubrh> kalev: the C++ ABI issue is basically about public inter-src.rpm APIs that exchange std::string or std::list arguments, or classes containing them
19:06:54 <sgallagh> If we don't do that, we might be landing mayhem into the stable updates stream
19:07:00 <jwb> sgallagh, uh... we do that every release
19:07:08 <mattdm> jakubrh: can you rework the feature as a proposal to add it _without_ a mass rebuild? will this be okay?
19:07:08 <jwb> (saddle the next fesco with decisions)
19:07:27 * mattdm notes the clock. there are a lot of other features on the agenda....
19:07:41 <sgallagh> jwb: True enough, but I'm already reaching controversy-exhaustion today.
19:07:45 <jreznik> btw. speaking about new fesco - nominations are open!
19:07:52 <mitr> mattdm: ISTM a gcc5 package would make sense; updating gcc so that rebuilds suddenly change ABI would be pretty bad.
19:08:21 <tyll> Enabling PIE by default could also be done without a mass rebuild, so that newly built packages benefit from it and others will later
19:08:48 <jakubrh> worst case libstdc++ can be configured so that it defaults to the old std::string and std::list (the one not satisfying C++11 requirements)
19:08:49 <sgallagh> tyll: I'd prefer to just stick to the "we recommend you do this" answer for F22
19:08:58 <mattdm> #topic meeting schedule, continued
19:09:30 <mattdm> okay, so, we spent a long time on that, and I hope we at least got to the point where everyoen felt heard even if it isn't the outcome everyone wanted
19:09:32 <jakubrh> if that is what you all prefer, I guess it is doable and we can switch the default for F23 before mass rebuild in there
19:09:38 <mattdm> jakubrh: thanks!
19:09:53 <mattdm> jakubrh: sorry it's not ideal.
19:10:00 <nirik> jakubrh: thanks for coming and all the info. very appreciated.
19:10:11 <mattdm> how are we doing on meeting exhaustion?
19:10:15 <sgallagh> jakubrh: Yeah, none of us *prefer* not having GCC 5, just that the timing is unfortunate
19:10:20 <mattdm> sgallagh++
19:10:29 <jwb> mattdm, i have another meeting at 14:30 i need to attend...
19:10:47 <jwb> i might be able to multi-task, but not sure
19:10:49 <mattdm> okay, so, let's get what we can done in the next 15 minutes.
19:11:02 <mattdm> #topic #1374 SElf Contained Changes
19:11:05 <sgallagh> OK, so let's finish up the schedule. I propose we extend the side-tag time
19:11:07 * pjp notes it's 00:40 hrs for me.
19:11:12 <mattdm> .fesco 1374 Self Contained Changes
19:11:12 <zodbot> mattdm: Error: '1374 Self Contained Changes' is not a valid integer.
19:11:14 <mattdm> https://fedorahosted.org/fesco/ticket/1374
19:11:16 <mattdm> whoo
19:11:22 <mattdm> .fesco 1374
19:11:23 <zodbot> mattdm: #1374 (F22 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1374
19:11:35 <mitr> +1
19:11:36 <sgallagh> To replace the time we previously alotted to the Mass Rebuild.
19:11:40 <mattdm> pjp yeah, sorry :(
19:11:43 <sgallagh> oh well. On to the next.
19:11:51 <thozza> +1
19:11:53 <nirik> +1
19:11:57 <mattdm> jreznik: still around? :)
19:12:03 <sgallagh> +1
19:12:05 <jreznik> mattdm: yep
19:12:07 <mattdm> +1 to both
19:12:19 <kalev> I'm confused, what are we voting on right now?
19:12:21 <jwb> how is "new default console font" not a system change?
19:12:26 <dgilmore> +1 to both
19:12:30 <jwb> i mean... it's the default across the whole distro
19:12:33 <jreznik> but will have to leave soon
19:12:38 <mattdm> jwb only affects the console? :)
19:12:39 <sgallagh> kalev: New console font and Lohit 2 [...]
19:12:46 <drago01> jwb: you don't have to touch 1000 packages to do it
19:12:48 <pjp> kalev: :)
19:12:55 <jreznik> jwb: I was thinking about it but in the end it's somehow contained - but really on the edge
19:13:04 <kalev> sgallagh: thanks, I thought it might have been your schedule proposal
19:13:07 <mitr> jwb: Changing a ~single package, others don’t need to do anything about it to adapt.
19:13:12 <kalev> +1 to both too then
19:13:17 <jwb> drago01, oh, ok.  then i'll propose a self-contained Change to switch to KDE by default because it's just a comps change.
19:13:20 <sgallagh> jwb: I'm comfortable calling this self-contained, as it doesn't require modifying any other packages to change it back
19:13:32 <jwb> way to think really really narrowly guys
19:13:41 <mattdm> jwb: is there particular coordination you think is necessary?
19:14:02 <mattdm> that's the key importance for system wide that I can see
19:14:13 <drago01> jwb: lets ask this way ... whats do we have the distinction between self and non self contained changes?
19:14:15 <mitr> jwb: Supposedly the font will look ~the same, this is not some huge expectation-breaking controversy I hope.
19:14:31 <drago01> *why
19:14:33 <sgallagh> drago01: System-wide means that someone needs to coordinate cross-team conversations
19:14:39 <jwb> perhaps i'm being overly grumpy.  +1 move on
19:14:51 <drago01> sgallagh: ok
19:14:51 <mitr> drago01: “A self contained change is a change to isolated package(s), or a general changes with limited scope and impact on the rest of distribution/project.”
19:15:06 <jwb> it's the limited scope part i was questioning
19:15:11 <jwb> anyway, move on
19:15:15 <sgallagh> Yeah, this is an edge-case.
19:15:38 <drago01> "somehow self contained"
19:15:40 <sgallagh> jwb: If you find it worth shepherding, by all means do so :)
19:15:47 <mattdm> #agreed Lohit2 Odia Telugu self-contained change passes +7/-0
19:16:07 <mattdm> #agreed New Default Console Font self-contained change passes +7/-0
19:16:31 <mattdm> fwiw console font change doesn't affect ec2 :)
19:16:39 * vondruch never understood what is the difference between systemwide and selfcontained ...
19:16:45 <mattdm> #topic #1307 F22 System Wide Change: Default Local DNS Resolver
19:16:47 <mattdm> .fesco 1307
19:16:48 <zodbot> mattdm: #1307 (F22 System Wide Change: Default Local DNS Resolver - https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver) – FESCo - https://fedorahosted.org/fesco/ticket/1307
19:16:49 <mattdm> #link https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
19:16:51 <mattdm> https://fedorahosted.org/fesco/ticket/1307
19:17:11 <mitr> I do want this, but what’s the status?
19:17:27 <mattdm> pjp still awake? :)
19:17:31 <mitr> thozza?
19:17:35 <pjp> mattdm: yes
19:17:40 <nirik> yeah, last time we had questions about docker...
19:17:45 <nirik> but they don't seem answered?
19:17:50 <pjp> mitr: It's already available in F21, but not default yet
19:17:54 <thozza> the unbound + dnssec-trigger + NM interoperability is implemented and working
19:17:57 <thozza> pavlix: ping
19:18:07 <pjp> mitr: it's in good shape, and bugs are being worked on
19:18:11 <pavlix> thozza: yep
19:18:16 <mattdm> I'm super-concerned about "
19:18:16 <mitr> thozza: And init.d/network?
19:18:17 <mattdm> Docker and other users of network namespaces, like systemd-nspawn, would break."
19:18:28 <thozza> I think we don't need to implement full scope to benefit from this in F22 - like the change in libc and "new" resolv.conf for trusted nameservers
19:18:58 <pjp> thozza: nope,
19:18:59 <thozza> mitr: to be honest, I didn't test that ever
19:19:27 <mitr> thozza: So how do we know whether a trusted resolvers is being used?  Default to {yes,no}?
19:19:47 <nirik> you can use the test domain
19:20:20 <pjp> mitr: that is why we have local on 127.0.0.1:53
19:20:35 <jwb> i need to "drop".  if there is a hung vote, please ping me in the channel and i'll jump back in.  otherwise, i'll reply with any important thoughts via email
19:20:37 * pjp hopes I got the question right,
19:20:45 <pavlix> mitr: init.d/network can be tested and adapted (i.e. I can handle it)
19:20:48 <nirik> I guess I am +1 here... but... it would be nice to have a better story for docker/etc. At the very least release notes about it.
19:21:29 <mitr> Do I undestand that the story for docker/etc is “if your docker image doesn’t ship its own resolver it will break”?
19:21:31 * pjp makes a note about it
19:21:43 <dgilmore> I am mostly +1 but I would like to see a better story for docer and other known broken use cases
19:21:43 <sgallagh> I'm +1 on the grounds that I know that the people involved are having the right conversations with the other groups, so I trust them to deliver or invoke the contingency plan appropriately.
19:22:19 <pavlix> mitr: yes, unless the resolv.conf is adapted of course
19:22:36 <nirik> mitr: or does some iptables/interface dance that is not yet documented there. ;)
19:22:39 <mattdm> I think the feature is a little unclear on what "default" means for Cloud/Server/Workstation. I'm tentatively +1, but would like to see cloud added to the scope -- there's concerns about footprint as well, and network trust is a whole different kettle of fish in cloud environments
19:22:46 <mattdm> (a fatalistic kettle of boiled fish, mostly)
19:22:51 <pjp> yes, I'll check with the docker folks to run some tests with F21,
19:23:16 <mattdm> pjp: maybe "don't ship in the cloud image" as a contingency possiblilty?
19:23:25 <mattdm> with all that covered I'm +1
19:23:33 <thozza> mattdm: good for me
19:23:36 <mattdm> which brings us to +4. any other votes?
19:23:39 <nirik> so, I assume this means adding it to comps?
19:23:40 <mitr> mattdm: Note that I didn't find any docker release criterion.
19:23:46 <pjp> mattdm: adding a full daemon to the cloud image is considered tricky
19:23:51 <mitr> +1 based on sgallagh and mattdm being comfortable.
19:23:53 * nirik doesn't see that in the feature page
19:24:16 <mattdm> #action pjp to add some notes about docker and cloud to the feature page :)
19:24:23 <nirik> well, it
19:24:26 * pjp makes a note
19:24:32 <nirik> 's two daemons... ;)
19:24:36 <thozza> #action pavlix to look at init.d/network
19:24:40 <nirik> but they are small. ;)
19:24:53 <kalev> +1 from me as well
19:25:03 <thozza> +1 from me for me
19:25:17 <pavlix> thozza: what's the status of init.d/network in f22 btw [feel free to reply outside this channel]?
19:25:17 <mattdm> #agreed Default Local DNS Resolver accepted for F22 (+7/0/0)
19:25:31 <mattdm> #topic #1379 F22 System Wide Change: Change xorg input stack to use libinput
19:25:32 <mattdm> .fesco 1379
19:25:34 <zodbot> mattdm: #1379 (F22 System Wide Change: Change xorg input stack to use libinput - https://fedoraproject.org/wiki/Changes/LibinputForXorg) – FESCo - https://fedorahosted.org/fesco/ticket/1379
19:25:34 <mattdm> #link https://fedoraproject.org/wiki/Changes/LibinputForXorg
19:25:36 <mattdm> https://fedorahosted.org/fesco/ticket/1379
19:26:02 <nirik> +1 based on the last stuff on the list around this.
19:26:02 <kalev> +1, I think the concerns we had last week got all resolved
19:26:10 <sgallagh> Didn't we already approve this, contingent on it working for KDE?
19:26:19 <dgilmore> +1 to this
19:26:20 <sgallagh> (Well, GNOME + KDE, obviously)
19:26:25 <sgallagh> +1 in any case
19:26:29 <mattdm> sgallagh: new plan is "doesn't work for KDE yet, so only enable for GNOKME for this release"
19:26:30 <mitr> sgallagh: Yeah, and the plan is IIRC that it explicitly won’t work on KDE
19:26:45 <hansg> hi, I'm here to answer any questions you may have ..., but just a long list of +1 votes works too :)
19:26:48 <mattdm> (and it won't _break_ KDE, just not be enabled)
19:26:55 <mattdm> hansg: is my understanding correct?
19:26:56 <jreznik> btw. it may be implemented for F22
19:27:06 <sgallagh> Right, as long as it doesn't break KDE, I'm cool with it.
19:27:07 <jreznik> (in KDE)
19:27:15 <jreznik> there's initial code ready
19:27:18 <thozza> +1
19:27:58 <mattdm> #agreed Change xorg input stack to use libinpu accepted for F22 (+6/0/0)
19:28:04 <hansg> mattdm, that was the plan, but then the Workstation people pointed out that they really want to have KDE working as an option on top of a Workstation install too, so the new plan is to just get KDE working with it too. This seems to not be too hard, Peter put together working patches for this this morning (in a couple of hours)
19:28:23 <mitr> hansg: Great.
19:28:25 <mattdm> (that's including a +1 and assuming no one jumps in with a negative)
19:28:30 <heliocastro> You're talking on KDE 4, right |?
19:28:30 <mitr> (+1 if anyone wants to count that in)
19:28:36 <mattdm> mitr oh sure.
19:28:38 <mattdm> #undo
19:28:38 <zodbot> Removing item from minutes: AGREED by mattdm at 19:27:58 : Change xorg input stack to use libinpu accepted for F22 (+6/0/0)
19:28:43 <mattdm> #agreed Change xorg input stack to use libinpu accepted for F22 (+7/0/0)
19:28:48 <hansg> KDE4 right
19:29:19 <jreznik> hansg: F22 will be very likely KDE 5 but the libinput backend should be easy for both
19:29:20 <mattdm> okay, so, that's all the followup tickets. Do we have energy/quorum for going ahead to new business?
19:29:37 <hansg> jreznik, ack
19:29:45 <mitr> mattdm: Let’s; it won’t be any easier next week.
19:29:47 <thozza> mattdm: I guess I can handle some more
19:29:55 <mattdm> okay, here we go :)
19:29:59 <mattdm> #topic #1382 F22 System Wide Change: Fedora 22 Boost 1.58 Uplift
19:30:01 <mattdm> .fesco 1382
19:30:02 <zodbot> mattdm: #1382 (F22 System Wide Change: Fedora 22 Boost 1.58 Uplift - https://fedoraproject.org/wiki/Changes/F22Boost158) – FESCo - https://fedorahosted.org/fesco/ticket/1382
19:30:03 <mattdm> #link https://fedoraproject.org/wiki/Changes/F22Boost158
19:30:03 <jreznik> and for many we have answer ready :)
19:30:05 <mattdm> https://fedorahosted.org/fesco/ticket/1382
19:30:24 <nirik> +1
19:30:31 <kalev> 1.58 doesn't seem to fit into the schedule
19:30:33 <mitr> sgallagh: You wanted to bring up the side tag schedule, or was that already resolved?
19:30:35 <dgilmore> +!
19:30:36 <dgilmore> +1
19:30:42 <hansg> I'm off guys, just watching this has earned you all some extra respect I had no idea being on FESco was so much hard work, good luck with the other items
19:30:42 <kalev> but +1 if it's 1.57
19:30:56 <dgilmore> mitr: I think the 10 days for mass rebuild were getting added
19:31:03 <mitr> +1
19:31:14 <sgallagh> mitr: Mostly I just wanted us to rubber-stamp giving side-tags the previous mass rebuild time to work with
19:31:31 <sgallagh> It wasn't clear that we'd told jreznik to go ahead and update the schedule in that way
19:31:50 <jreznik> no, it wasn't, I'm just thinking about it
19:32:14 <nirik> so, that would give until 2015-02-09? (branch is on 10th)
19:32:31 <sgallagh> dgilmore: Is that reasonable?
19:33:02 <dgilmore> sgallagh: so long as nothing breaks post merge
19:33:28 <dgilmore> at least 2 days would be better
19:33:35 <dgilmore> either way things will have to get fixed
19:33:36 <nirik> could do friday the 6th?
19:33:41 <jreznik> so, remove mass rebuild, side tags 2015-02-06
19:33:53 <dgilmore> it would mean that if we merged teh day before fixes have to be done twice
19:33:55 <mitr> wfm
19:33:57 <dgilmore> so its doable
19:34:03 <sgallagh> Friday the 6th seems reasonable. This means no other changes to the schedule after that.
19:34:21 <kalev> 6th sounds reasonable to me as well
19:34:26 <sgallagh> (So we're clear. I got pinged privately wondering if I'd been suggesting adding time to the end of the schedule, which I emphatically am not)
19:34:33 <dgilmore> the 6th seems reasonable. gives a few days to deal with any breakages
19:35:22 <mattdm> Is there anything in this conversation that needs to be updated in the change?
19:35:57 <sgallagh> OK, so formally:
19:35:58 <sgallagh> Proposal: Side-tags must be merged into Rawhide by February 6th, with Branch occurring on February 10th as previously scheduled.
19:36:04 <mitr> sgallagh: +1
19:36:05 <sgallagh> +1
19:36:07 <kalev> +1
19:36:12 <mattdm> (so we have +3 for the change so far, and +4 for it if it's limited to 1.57)
19:36:12 <dgilmore> +1
19:36:22 <mattdm> +1 to that
19:36:33 <thozza> +1
19:36:39 <mattdm> #agreed Side-tags must be merged into Rawhide by February 6th, with Branch occurring on February 10th as previously scheduled. (+6/0/0)
19:36:52 <mattdm> and with that understanding I'm +1 as well.
19:37:05 <mattdm> does anyone els have an opinion on the 1.57/1.58 thing?
19:37:27 <sgallagh> mattdm: I'm fine with trusting them to land it if it's ready or defer if it is not.
19:37:31 <nirik> +1 to side tag (sorry)
19:37:40 <mattdm> #undo
19:37:40 <zodbot> Removing item from minutes: AGREED by mattdm at 19:36:39 : Side-tags must be merged into Rawhide by February 6th, with Branch occurring on February 10th as previously scheduled. (+6/0/0)
19:37:44 <mattdm> #agreed Side-tags must be merged into Rawhide by February 6th, with Branch occurring on February 10th as previously scheduled. (+7/0/0)
19:38:00 <thozza> mattdm: +1 for 1.57/1.58
19:38:17 <sgallagh> I'm +1 for the change and ambivalent about the version that lands.
19:38:23 <mitr> mattdm: Per https://svn.boost.org/trac/boost/roadmap it seems 1.58 will arrive too late.
19:38:54 <mattdm> yeah so I'm kind of on the side of just saying target 1.57.
19:38:56 <sgallagh> mitr: If they're comfortable doing the build over the course of three days, let them have it :)
19:39:01 <mitr> sgallagh: yes
19:39:04 <sgallagh> I suspect that this will sort itself out
19:39:30 <mattdm> does _that_ fallback have schedule implications?
19:39:54 <mattdm> eg can that fit into the side-tag schedule or does it mean possible delay later?
19:40:29 * mattdm hears crickets
19:40:40 <sgallagh> mattdm: Boost deps are reasonably well understood
19:40:54 <sgallagh> I think they'll know while doing the side-tag whether or not to bother merging.
19:40:57 <mitr> mattdm: My understanding is that either the side tag is in a good shape and gets merged, or isn’t and doesn't.  With this mechanism I am very comfortable with leaving the package owner to take the safe or risky path as they think appropriate.
19:41:10 <sgallagh> What mitr said
19:41:30 <jreznik> indeed
19:41:42 <mattdm> mitr: okay, I'll buy that, which pushes the full approval forward. kalev do you want to vote -1 or 0 to that?
19:41:58 <kalev> I'm fine with it going forward
19:42:19 <mattdm> kalev: so, 0 if it's listed as 1.58?
19:42:35 <mattdm> this is pendantic and not so importnat, really, just want to keep the vote counts accurate :)
19:42:37 <kalev> sounds good :)
19:43:03 <mattdm> #agreed Boost 1.58 accepted for F22 (+6/-0/1)
19:43:24 <mattdm> #info timing makes 1.57 likely (as page explains)
19:43:30 <sgallagh> mattdm: To clarify my vote: I'm +1 on 1.58 if the Boost SIG deems it worthy. If they don't, I won't lose sleep
19:43:43 <dgilmore> mitr: we merge sidetags in on teh cutoff ready or not
19:43:46 <dgilmore> maybe we shouldnt
19:43:54 <mattdm> sgallagh: right, that's what the change basically says already. (contingency plan is actually a contingency plan :)
19:43:59 <mattdm> #topic #1383 F22 System Wide Change: GHC 7.8
19:44:00 <mattdm> .fesco 1383
19:44:01 <zodbot> mattdm: #1383 (F22 System Wide Change: GHC 7.8 - https://fedoraproject.org/wiki/Changes/GHC_7.8) – FESCo - https://fedorahosted.org/fesco/ticket/1383
19:44:02 <mattdm> #link https://fedoraproject.org/wiki/Changes/GHC_7.8
19:44:04 <mattdm> https://fedorahosted.org/fesco/ticket/1383
19:44:25 <dgilmore> i am +1 here
19:44:28 <sgallagh> This is dependent on a mass-rebuild that we aren't doing.
19:44:29 <sgallagh> So -1
19:44:38 <dgilmore> sgallagh: no its not
19:44:41 <sgallagh> Oh, I misread
19:44:47 <nirik> +1
19:44:48 <sgallagh> Belay that
19:44:55 <kalev> +1
19:45:01 <sgallagh> +1
19:45:10 <mitr> +1
19:45:14 <dgilmore> its dependent on getting a side tag and building in it
19:45:16 <mattdm> so this is another side tag thing, yeah.
19:45:20 <mattdm> +1
19:45:25 <thozza> +1
19:45:30 <mattdm> whooo
19:45:37 <sgallagh> dgilmore: yeah, I saw the phrase "in time for F22 Mass Rebuild" and didn't read closely enough
19:45:52 <mattdm> #agreed GHC 7.8 accepted for F22 (+7/0/0)
19:45:59 <mattdm> #topic #1384 F22 System Wide Change: Harden all packages with position-independent code
19:46:01 <mattdm> .fesco 1384
19:46:02 <zodbot> mattdm: #1384 (F22 System Wide Change: Harden all packages with position-independent code - https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code) – FESCo - https://fedorahosted.org/fesco/ticket/1384
19:46:03 <mattdm> #link https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code
19:46:05 <mattdm> https://fedorahosted.org/fesco/ticket/1384
19:46:08 <mattdm> okay, so *this* one called for a mass rebuild
19:46:16 <thozza> so deferring?
19:46:17 <sgallagh> So definitely -1 for F22
19:46:18 <mitr> Approve for f23, or defer to the new FESCo?
19:46:20 <mattdm> but tyll suggested a fallback of just enabling it and not doing a rebuild
19:46:25 <dgilmore> -1 for f22
19:46:32 <dgilmore> +1 for f23
19:46:40 <sgallagh> mattdm: I'm -1 on enabling it in F22, even without the rebuild.
19:46:41 <dgilmore> it can land right after branching
19:46:46 <nirik> -1 to f22, +1 for f23...
19:46:47 <thozza> -1 for F23; +1 for deferring to new FESCo
19:46:52 <mattdm> sgallagh: k
19:46:55 <sgallagh> But I'm 0 for F23 today.
19:46:59 * mattdm tries to count :)
19:47:03 <mitr> mattdm: That would read to knee-jerk %hardened_build 0 if that package needs any other fixes for release-blocking bugs, rather not.
19:47:06 <thozza> -1 for F22
19:47:16 * thozza sorry for the mistake
19:47:18 <mattdm> mitr: *nod*
19:47:19 <kalev> -1 for f22
19:47:33 <mitr> I guess 0 for f23, but strongly recommending the new FESCo to approve at least for 64-bit architectures.
19:47:35 <mattdm> -1 to f22, +1 to f23
19:48:07 <mattdm> (is there a zodbot "declined" macro?)
19:48:10 <mitr> (and sadly -1 to F22, yeah)
19:48:22 <nirik> mattdm: nope.
19:48:35 <thozza> mattdm: but we agreed :)
19:49:04 <mattdm> #agreed System Wide Change: Harden all packages with position-independent code NOT accepted for F22 (0,-7,0)
19:49:07 <moezroy> I am confused are you voting on F22?
19:49:10 <moezroy> or F223
19:49:14 <dgilmore> clearly we are -1 for f22  but for f23 its a bit messier
19:49:17 <mattdm> moezroy: both at once in a confusing melange!
19:49:46 <mattdm> meh can we revote on f23? i can't sort that all out
19:50:02 <dgilmore> +1 for f23
19:50:03 <kalev> shouldn't it be the next fesco deciding F23 stuff?
19:50:03 <mattdm> +1 for f23
19:50:09 <mattdm> kalev: vote -1 for that
19:50:15 <mitr> 0 on f23, recommending +1 to the new FESCo
19:50:32 <nirik> +1 for f23
19:50:33 <thozza> 0 on F23
19:50:44 <mattdm> (but I'd like to get into the business of deciding things earlier, which inherently means we'll need to vote earlier)
19:51:19 <dgilmore> mattdm: which is why I'm +1 it means it can land as soon as we branch
19:51:21 <sgallagh> I'm only voting 0 because I'm not adequately prepared to make a sensible decision today
19:51:25 <dgilmore> before tehre is a new fesco
19:51:30 <mattdm> jwb: you around to vote for PIC for F23?
19:51:34 <kalev> I'm 0 for F23 as well, for similar reasons as sgallagh
19:51:38 <mattdm> oh okay.
19:51:52 <jwb> one sec.  lemme read scroll back
19:52:03 <moezroy> sgallagh, kalev, what about 64bit only for F23? would that change your vote?
19:52:10 <mitr> dgilmore: We are branching after the electino results are announced.
19:52:14 <mattdm> jwb didn't pass for f22, question is basically "pass for f23 now, or wait until new fesco"
19:52:38 <jwb> i'm +1 for f23
19:52:58 <jwb> the performance hit is real, but i think it is likely worth it
19:53:01 <mattdm> okay so we we have +4 for and 3 abstentions.
19:53:13 <sgallagh> moezroy: No, I'm admitting freely that I'm not read-up enough on this to decide today.
19:53:18 <mattdm> which makes me dig out the fesco voting rules
19:53:33 <sgallagh> That does not preclude me casting a vote next week (or sooner in the ticket)
19:53:50 <dgilmore> mitr: not before they have had a meeting
19:54:37 <nirik> mattdm: so we don't decide anything about f23 now and move on I think...
19:54:40 <mitr> mattdm: https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee 5 votes needed.
19:54:41 <mattdm> I... do not know if that actually passes. I know toshio had put up a _draft_ clarifying this situation but I don't know if we have real rules.
19:54:42 <jwb> nirik, yes
19:54:46 <mattdm> mitr: thanks
19:54:51 <mattdm> okay then.
19:54:56 * nirik nods
19:55:00 <sgallagh> mattdm: This doesn't pass or fail. We agree to defer by a week and move on.
19:55:12 <sgallagh> I'll do my best to read up and cast a formal vote before then, if I can manage it
19:55:25 <moezroy> sgallagh, thanks
19:55:34 * jwb is confused by this "wait for next fesco" thing
19:55:35 <mattdm> sgallagh: okay works for me.
19:55:43 <mattdm> #info F23 decision defered until next week
19:55:55 <dgilmore> jwb: me too especially from mitr who will be on it as his seat is not up for election
19:55:58 <sgallagh> jwb: Red herring. I suggested it, but didn't carry it.
19:56:00 <mattdm> #topic #1385 F22 System Wide Change: Ruby 2.2
19:56:01 <mattdm> .fesco 1385
19:56:02 <zodbot> mattdm: #1385 (F22 System Wide Change: Ruby 2.2 - https://fedoraproject.org/wiki/Changes/Ruby_2.2) – FESCo - https://fedorahosted.org/fesco/ticket/1385
19:56:03 <mattdm> #link https://fedoraproject.org/wiki/Changes/Ruby_2.2
19:56:05 <mattdm> https://fedorahosted.org/fesco/ticket/1385
19:56:17 <nirik> +1
19:56:21 <kalev> +1
19:56:25 <dgilmore> +1
19:56:29 <sgallagh> +1, same mumbo-jumbo about the side tag
19:56:33 <mattdm> vondruch: noted earlier that this didn't need a mass rebuild
19:56:36 <thozza> +1
19:56:36 <mattdm> +1 yeah that
19:56:55 <mattdm> #agreed System Wide Change: Ruby 2.2 accepted for F22 (+6/0/0)
19:56:57 * jwb loves the micro-mass-rebuilds
19:57:04 <mattdm> #topic #1386 F22 System Wide Change: Set sshd(8) PermitRootLogin=no
19:57:06 <mattdm> .fesco 1386
19:57:07 <zodbot> mattdm: #1386 (F22 System Wide Change: Set sshd(8) PermitRootLogin=no - https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no) – FESCo - https://fedorahosted.org/fesco/ticket/1386
19:57:08 <mattdm> #link https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
19:57:10 <mattdm> https://fedorahosted.org/fesco/ticket/1386
19:57:12 <dgilmore> -1
19:57:18 <mattdm> okay now we get to the good times :)
19:57:23 <pjp> :)
19:57:29 <vondruch> thank you ladies and gentlemans :)
19:57:31 <sgallagh> I'll note that the Server SIG discussed this in their meeting and strongly opposes this.
19:57:45 <pjp> sgallagh: why?
19:57:50 <mitr> -1 as proposed.
19:57:55 <sgallagh> To the point that it would be considered to override this in a per-product config if FESCo approved it for the general case.
19:57:58 <mattdm> Speaking for the cloud sig, I think it doesn't matter, as cloud-init manipulates this anyway.
19:58:00 <sgallagh> So -1 from me
19:58:04 <dgilmore> I think they need to go talk with the anaconda guys and come up with good ways to ensure access the box at install time
19:58:08 <mitr> pjp: https://fedorahosted.org/fesco/ticket/1386#comment:1
19:58:13 * pjp clicks
19:58:21 <kalev> sgallagh: I was just writing that I think we should defer this one to the Server WG
19:58:50 <sgallagh> pjp: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-13/fedora-meeting-1.2015-01-13-16.00.log.html (full details)
19:59:00 * pjp clicks
19:59:00 <thozza> after reading the devel-list discussion I don't feel it brings much benefit
19:59:15 <nirik> personally I think it would be great to change the default to be more secure... but, we need to put things in place that handle the install cases that would break.
19:59:21 <mattdm> kalev: do you have a sense of the Workstation view here?
19:59:32 <mattdm> nirik: yeah, I agree with that.
19:59:33 <mitr> The server SIG consensus seems to be that this would be acceptable in principle if there already was a comprehensive plan to deal with the full set of use cases in some way (possibly changing workflows but not otherwise iconveniencing the users)
19:59:39 <nirik> it doesn't matter much there either as it's not running by default
19:59:46 <kalev> mattdm: I think it doesn't matter much either way for Workstation
19:59:57 <pjp> mattdm: workstation does not seem to enable SSH by default
20:00:00 <sgallagh> So that only leaves non-Product spins
20:00:20 <mattdm> I am generally in favor, as this is one of the things I have been grumbling about and changing for the past decade. But better tooling should be ready to go before we approve as a feature
20:00:28 <mitr> I personally (server SIG does not have that consensus) would like to eliminate root’s password entirely, but again that requires someone to shepherd this and deal with all the required tooling.
20:00:34 <mattdm> because we can't _really_ give a mandate for development work that no one is itching to do.
20:00:54 <pjp> mattdm: I plant to discuss this with the respective upstream folks
20:01:09 <mitr> mattdm: Well we do that all the time for mass rebuilds / tooling updates, but yeah, mandates to specific few individuals rarely work
20:01:12 <kalev> I'm with mitr as well, I'd personally would like to eliminate the root password and disable sshd's root login by default, but I'd still like to defer this to the Server WG who's territory this is
20:01:12 <nirik> pjp: yeah, but you can't say they will be able/willing to work on it...
20:01:33 <dgilmore> I am not opposed to making changes here. but I think it needs a lot of work. mostly in anaconda but also other tools that make images to cover all the different use cases
20:01:43 <sgallagh> pjp: My recommendation would be to gather consensus upstream and re-propose some time in the future when it's more concrete. The proposal as it stands would reduce usability far more than it would improve security.
20:01:46 <nirik> If we can find good ways to import ssh keys on install, we could change this. ;) so that means at least anaconda work
20:01:52 <mattdm> pjp: and basically, fesco saying so won't help with that :)
20:02:01 <pjp> nirik: I agree. Yet, if there is wider consensus about it's value in the long term, that'll help it's consideration
20:02:28 <sgallagh> nirik: That, or more prominently support domains, but that still requires a bootstrap of a domain controller...
20:02:40 <nirik> that also I think... yeah.
20:02:52 <pjp> sgallagh: usability concern is only showing in cases wherein only root account is required,
20:02:52 <dgilmore> nirik: well import keys/manage the sshd config file at install time
20:02:54 <sgallagh> pjp: Yes, there's value in the long-term, if the details can be worked out.
20:03:08 <dgilmore> but its work that belongs in the installer
20:03:10 <nirik> dgilmore: sure, but ideally import keys... (more secure than a password)
20:03:11 <sgallagh> pjp: Read the Server SIG meeting notes. We highlighted quite a few such cases
20:03:20 <pjp> sgallagh: okay,
20:03:24 <dgilmore> I can see adding a kickstart option to inster a ssh public key etc
20:03:36 <mitr> sgallagh: ISTM domains are a better long-term bet than ssh keys; and bootstrap is probably widely understood, the failure recovery case for a domain client seems to really be the sticking point.
20:03:41 <dgilmore> i need to type better today
20:03:46 <mattdm> okay, so, we're not going to solve the issues here :)
20:03:59 * nirik nods.
20:04:01 * mitr shuts up
20:04:02 <sgallagh> mitr: Let's put that on next week's Server SIG agenda
20:04:08 <mattdm> shall we do a formal vote?
20:04:20 * dgilmore needs to run in 5 minutes to pick up daughter from school
20:04:22 <dgilmore> mattdm: -1
20:04:27 <nirik> pjp: thanks for bringing this change up in any case and weathering the stormy seas of the devel list about it. ;)
20:04:29 <sgallagh> mattdm: -1
20:04:35 <pjp> Is it possible to hold vote for some time?
20:04:38 <nirik> -1 at this time.
20:04:38 <mattdm> yes, what nirik  said :)
20:04:53 <dgilmore> pjp: it can be improved and resubmitted
20:04:54 <sgallagh> pjp: The F22 schedule is pretty tight. I'd recommend trying for F23
20:05:05 <mattdm> pjp: yeah this isn't necesarily long-term binding
20:05:06 <sgallagh> Or if you work really fast, resubmitting, I guess.
20:05:17 <mattdm> I'm at 0, fwiw. :)
20:05:21 <jwb> -1
20:05:22 <sgallagh> mattdm: Maybe phrase the proposal we're voting on?
20:05:23 <pjp> sgallagh: dgilmore I see, okay
20:05:27 <kalev> I'm 0 as well
20:05:37 <dgilmore> pjp: please talk to the anaconda guys to see ways to work on it.
20:05:44 <mattdm> sgallagh uh, okay :)
20:06:00 <pjp> dgilmore: Yes, I'll start a conversation with them,
20:06:04 <mattdm> #proposal "Set sshd(8) PermitRootLogin=no - https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no" as systemwide default for F22
20:06:28 <mattdm> and I think this has +0/-4/2
20:06:40 <mitr> #info The change text now actually proposes PermitRootLogin=without-password
20:06:49 <pjp> Yes,
20:07:02 <mattdm> mitr thanks. I'll edit the ticket when I close things out.
20:07:07 <pjp> That's as per the discussion on the -devel list,
20:07:17 <mattdm> mitr: did you vote?
20:07:27 <mitr> mattdm: I was -1
20:07:39 <thozza> -1 for F22 as it is now
20:08:15 <mattdm> #agreed "Set sshd(8) PermitRootLogin=no" as systemwide DOES NOT pass for F22
20:08:24 <mattdm> #undo
20:08:24 <zodbot> Removing item from minutes: AGREED by mattdm at 20:08:15 : "Set sshd(8) PermitRootLogin=no" as systemwide DOES NOT pass for F22
20:08:35 <mattdm> #agreed "Set sshd(8) PermitRootLogin=no" as systemwide DOES NOT pass for F22 (+0/-5/2)
20:08:55 <mattdm> okay, so, that's everything that made it onto the agenda this week
20:09:06 <mattdm> although there are others filed after
20:09:11 <mattdm> i think it's time to call it a day
20:09:20 <mattdm> #topic Next week's chair
20:09:25 <dgilmore> mattdm: I need to run but can run next weeks meeting
20:09:43 <mattdm> #info dgilmore is the heroic chair for next week's meeting
20:09:47 <mattdm> #topic Open Floor
20:10:00 <jakubrh> so, is my understanding right that if I rework GCC5 feature not to involve mass rebuild that it has a chance to be accepted (after tweaking the package to be ABI compatible by default)?
20:10:19 <dgilmore> jakubrh: yes
20:10:23 <mattdm> jakubrh: yes -- it's the schedule impact of that that we're worried about.
20:10:25 <nirik> jakubrh: yes, I think so... for f22... we still want to do the mass rebuild for f23
20:10:38 <mattdm> nirik: *nod*
20:10:46 <jakubrh> ok, will work in that direction then
20:10:58 <mattdm> jakubrh: thanks -- appreciate your understanding here!
20:11:12 <mattdm> anyone have anything else? Will close the meeting in a minute.
20:11:41 <kalev> jakubrh: thanks, I think that's a good middle ground here
20:12:12 <mattdm> #endmeeting