18:01:50 #startmeeting FESCO (2015-01-14) 18:01:50 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:52 #meetingname fesco 18:01:52 The meeting name has been set to 'fesco' 18:01:54 #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:01:54 Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:01:56 #topic init process 18:01:58 Hello 18:02:02 hello everyone! 18:02:04 hello! 18:02:19 morning 18:02:34 Hello! 18:02:47 so we have a busy feature-filled agenda today 18:02:56 I've invited a lot of people with relevant features 18:02:59 hi all 18:03:17 hellow 18:03:17 Hi there 18:03:17 .hello 18:03:17 We first have a general scheduling strategy question to go through 18:03:17 moezroy: (hello ) -- Alias for "hellomynameis $1". 18:03:23 and also a bit about fesco replacementprocess 18:03:46 I'll try to call out people when their feature comes up 18:03:56 but I don't know everyone's IRC nick 18:04:02 so we'll see :) 18:04:05 .hello sgallagh 18:04:06 sgallagh: sgallagh 'Stephen Gallagher' 18:04:13 mattdm: I can help, I hope (with pinging) 18:04:25 .hello moezroy 18:04:27 moezroy: moezroy 'Moez Roy' 18:04:35 jreznik: okay cool. in fact, if you can handle that, that'd be AWESOME. 18:05:00 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 we can try. ;) 18:05:40 mattdm: Okay. 18:05:42 i'm not sure it will be quick 18:06:08 in that case, should we instead do it _last_ so we can get the urgent schedule question answered? 18:06:33 yes 18:06:40 that might be better, yes 18:06:43 okay then 18:06:50 #topic 1349 Fedora 22 scheduling strategy (and beyond) 18:06:52 .fesco 1349 18:06:54 https://fedorahosted.org/fesco/ticket/1349 18:06:54 mattdm: #1349 (Fedora 22 scheduling strategy (and beyond)) – FESCo - https://fedorahosted.org/fesco/ticket/1349 18:07:02 /me notes that GCC5 was proposed today, which *will* require a mass rebuild if we accept it 18:07:11 This is reopened because dgilmore noted that the schedule has no realistic time for a mass rebuild 18:07:35 dgilmore: are you here? 18:08:16 hmmm. 18:08:26 perhaps we should do changes first then come back to schedule when dgilmore is here? 18:08:38 i think a lot of the changes depend on the bigger picture 18:08:41 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 yes 18:08:58 sorry, my yes was to mattdm 18:09:17 i'm not sure i understand your question mitr 18:09:29 * mattdm is also re-re-reading mitr :) 18:09:29 Is there a really compelling reason not to declare freeze upon completion of mass rebuilds? 18:09:36 Why exactly do we have the gap there? 18:09:37 jwb: WRT “realistic time to do a mass rebuild” 18:09:53 sgallagh: so people can fix things without process overhead? 18:09:54 sgallagh time to fix mass rebuild fallout, I think. 18:10:02 sgallagh: completion of the automated mass rebuild with hundreds of failures, or completion of mass rebuild + required manual fixups? 18:10:07 mitr: based on what time for mass rebuild? 18:10:22 nirik: https://fedoraproject.org/wiki/Releases/22/Schedule says Jan 30 18:10:43 mitr: right, the problem there is things like ruby don't have time to build in side tag before then. 18:10:45 mitr: I meant inclusive of fixups 18:10:55 we haven't even approved the change yet for it. 18:11:22 and other changes could come up until the 28th 18:11:31 thats our meeting thats a week out from change deadline 18:11:38 yep 18:11:54 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 nirik: We can rebuid ruby packages we will be able to build till side tag merge and leave rest for later 18:12:04 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 jwb: more pie/gcc, boost and ruby can be done in side tag 18:12:25 jwb: so far I think... yeah 18:12:41 jreznik: no, gcc and pie cannot be done in a side tag 18:12:43 jreznik, gcc can't be done in a side tag and then merged back. 18:12:51 boost and ruby might get away with that 18:13:06 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 I'm also concerned about any feature which has "mass rebuild it back!" as a contingency plan. 18:13:18 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 nirik, jwb: sorry, wasn't clear - pie/gcc was one part and ruby/boost another 18:13:21 hey im here 18:13:26 moezroy, rel-eng says there is not time at all for a mass rebuild for any reason 18:13:29 moezroy, so no 18:13:32 mattdm: indeed. 18:13:35 If that contingency plan in practice means "add two weeks to the schedule", that's very drastic. 18:13:56 (At least, if we don't _already_ have those two weeks built in. Which we don't.) 18:13:58 sgallagh, i think that's what were figuring out 18:14:02 mattdm: well in some cases it's the only option 18:14:19 in the past we allowed 4 weeks for mass rebuild and dealing with fallout and getting FTBFS fixed etc. 18:14:23 jreznik: Right, so, logically, if we're sticking to the schedule for this release, we should defer those changes. 18:14:23 sgallagh: yep - be strict or reset schedule once we have all changes in place 18:14:29 and make sure there is no regressions and dealing with them 18:14:31 mattdm: yep 18:14:49 dgilmore: How much of that was actually needed, though? (I know, impossible to nail down precisely) 18:14:57 I don't know if everyone saw the comments I dropped in the ticket about an hour ago.... 18:14:59 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 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 but there needs to be time to clean up things find regressions and fix etc 18:15:35 mitr: it depends on whathappens 18:15:46 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 but allowing 10 days for the mass rebuild and dealing with teh fallout of it is not at all realistic 18:16:06 So, in that case: 18:16:18 f21 was 4 weeks. 18:16:20 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 f20 was less. 18:16:26 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 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 kalev: no 18:16:35 mattdm: we had june releases and then same year second release already as far as I remember 18:16:37 dgilmore: is it important to complete these fixes before the Alpha? 18:16:58 kalev: finding and dealing with regressions. unintyended ABI breaks etc 18:17:02 mattdm: s/in Rawhide/in Rawhide shortly after the branch/ 18:17:24 kalev: FTBFS can come after, but breakages need to be fixed first 18:17:32 makes sense 18:17:44 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 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 nirik, you mean f23? 18:18:05 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 sorry, 23yeah 18:18:10 nirik: Can you elaborate? 18:18:16 /me missed that conversation. 18:18:20 thozza: . 18:18:23 sgallagh, it's in the gcc5 Change thread 18:18:37 mattdm: we can do Ruby if there is no mass rebuild ... this gives us additional one week 18:18:48 " It turns Fedora from being one 18:18:48 of the first distros to ship the new compilers to one of the last if not the 18:18:48 last one." 18:18:50 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 vondruch: can or can't? 18:18:52 from the devel list. 18:18:52 mattdm: my memory blurs more and more with overy other release :) 18:18:58 mattdm: we just have a shorter time between F22 going gold and branching for F23 18:19:27 dgilmore: yes, it's not exactly +6 months 18:19:35 /me disappears to read that thread. 18:19:39 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 mattdm: just repeating it so we had more data. ;) 18:20:04 jakub's quote (if gcc5 gets bumped from f22): ". It turns Fedora from being one 18:20:05 of the first distros to ship the new compilers to one of the last if not the 18:20:07 last one." 18:20:10 mattdm, i don't think it's dramatic tbh 18:20:16 (oops,sorry for the multiline) 18:20:32 rdieter: just noted it above. ;) 18:20:39 oh rats 18:20:49 mattdm: can 18:20:59 vondruch: okay, so that's good. 18:21:00 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 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 nirik, gcc and pie 18:21:35 pretty sure pie faces the same scheduling issues 18:21:41 the pie change may cause more issues than gcc 18:21:48 yeah... and we also want to land gcc before pie.... 18:21:49 gcc is important. However, I don't see that slowing down _everything_ is worth it. 18:21:53 at least according to jakob. 18:22:04 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 kalev: they are planning that 18:22:18 The pie change seems like a good one in general, but it also does not seem urgent. 18:22:19 kalev: they are planning test mass rebuild 18:22:20 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 and then decide next week, depending on that data if it fits into F22 picture 18:22:41 jwb: yes, I'd be ready to accept it as an F23 feature basically immediately. 18:22:43 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 kalev: sounds like a good idea to me 18:22:58 kalev: yeah, they are planning it, but not sure when. 18:23:05 (Though there's an argument to be made for waiting until the final .0 release in early April as well. 18:23:21 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 jwb: I can get behind that 18:23:36 sgallagh: Heh. A mass rebuild that breaks rawhide is an innovative way to focus bug fixing on the f22 branch ☺ 18:23:42 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 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 they're also only planning to do their build on x86_64 18:24:01 jwb: … and a corresponding draft schedule that is guaranteed to have enough time for it, I presume. 18:24:02 jreznik: well, they are waiting for the 'stage4' one I think 18:24:11 mitr, yes, that's the PLAN part :) 18:24:11 We're effectively talking about a three month difference here — either a summer F22 including gcc5, or an autumn F23. 18:24:40 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 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 (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 sgallagh: right 18:25:27 kalev, them only building on x86_64 and us waiting on that is kind of ignoring ARM, which is still primary 18:25:38 there is something to be said for having the latest gcc, its something that can attract users 18:25:41 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 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 jwb: and i686 b 18:25:54 s/b/ / 18:26:05 (that just gets us into "no time for contingencies! full steam ahead!" 18:26:38 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 mattdm: thats part of why we have 4 weeks for mass rebuild 18:26:42 I don't suppose anyone has ability to summon jakub to the meeting? 18:26:48 ha. nice. 18:26:56 it would be clear early if its horribly broken and we need to revert 18:27:00 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 jwb: yes. 18:27:13 and the current schedule has no time for a rebuild 18:27:21 jwb: correct 18:27:36 so we either change the schedule, or we punt mass rebuild features 18:27:39 it's pretty simple. 18:27:51 well, it has 1.5 weeks or so... 18:27:53 jwb: we have two options - move schedule (but we don't know how much) or move all mass rebuilds to f23... 18:28:01 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 jwb: you were faster 18:28:05 :) 18:28:17 nirik: we can not do it in the 10 days in the schedule 18:28:20 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 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 mitr: it really needs to be done before branching 18:28:57 dgilmore: why? 18:28:59 Who would do the work for those fixes? Volunteer packagers? 18:29:02 so, I think by Jan 30 we can have gcc ready for mass rebuild 18:29:02 for f20 we had 17 days it looks like 18:29:22 mitr: potential breakage could slow down testing... and we know early testing is the best way how to avoid slips 18:29:30 mitr: because if we have to enact teh contingency post branch we have to do it in the branch and rawhide 18:29:31 nirik, f20 didn't introduce a new c++ thingy 18:29:47 * jwb is getting all technical now 18:29:55 true, just saying it's not always 4 weeks 18:29:56 dgilmore: Let's assume that the "contingency" is that we slip until everything is fixed. 18:30:02 dgilmore: I’d imagine rawhide would just march on with the new setup 18:30:05 dgilmore, uh, no you wouldn't. you'd just do it in the branch 18:30:13 Reverting from a major GCC change is likely to be similar effort to fixing it 18:30:13 rawhide would stay on gcc5 and get fixed 18:30:17 mitr: not necessarily 18:30:21 f19 did, f17 etc. 18:30:54 jakubrh: is there anything we can do to speed up your mass rebuilding or add arches to it? 18:31:04 like armv7hl? 18:31:07 or i686? 18:31:11 yes 18:32:03 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 nirik: doesn't need to store the resulting rpms either, just keep around the log files for later analysis 18:32:57 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 I'm really unhappy about accepting a change where the contingency plan is going to add so much to the schedule. 18:33:32 for x86_64 we just borrowed a couple of beaker boxes and run mock in a loop 18:33:57 jakubrh: did you see my earlier comments re the calendar? Is getting this in an October F23 release really so bad? 18:34:04 jakubrh: you can do the same for i686 and armv7hl 18:34:20 Because otherwise, we're perpetuating a cycle where the F23 release is likely to be next year (February seems realistic.) 18:34:47 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 mattdm: not at all 18:35:22 mattdm: I'd not be that pesimistic but it would be december with high risk of january 18:35:25 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 mattdm: we can still say it will be october 18:35:33 jakubrh: the wording is not really the concern, it’s what would we _actually do) 18:35:35 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 mattdm: it just means a shorted window between f22 gold and f23 branching 18:36:16 dgilmore: so... a three month cycle for f23, when we can't hold to 6 for this one? I'm skeptical! 18:36:16 jakubrh: the same armv7hl boxes as we use as builders are available in beaker 18:36:39 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 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 dgilmore: also means no mass rebuild for f23. definitely no time there in a short schedule. 18:36:59 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 nirik: right 18:37:34 nirik: unless we did mass rebuild while still stabalising f22 18:37:36 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 mitr: that would let us decide to have a smaller window for mass rebuild, but how small a window? 18:37:48 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 if that becomes the habit, we'll lose developers 18:38:19 mattdm: I should start diet on Monday... 18:38:23 jakubrh: So for this single release, why not offer GCC5 in a COPR? 18:38:23 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 jakubrh: we can't possibly align Fedora releases to _every_ important-to-developers product. 18:38:43 The best thing we can do is keep to a regular cadence of six month releases. 18:38:54 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 And, looking at the calendar, I _really_ don't see another way to get to that from here. 18:39:03 mitr: no, I am saying no rebuild. 18:39:06 * mitr expects to get murdered for suggesting this. 18:39:22 jreznik: i think we could do october 27 release for f23 18:39:26 I am asking if we could ship the tools, but not rebuild the distro with it (except as it natually rebuilds) 18:39:39 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 but I do not know exactly how that would look with f22 if we added 2 weeks 18:39:54 jakubrh: ok. Was a thought. ;( 18:40:02 SCL? 18:40:10 jakubrh: Um, so this is breaking third-party C++ binaries? Or is this only a soname change? 18:40:20 nirik: the ABI change is done in a way that the same libstdc++.so.6 is used and provides both manglings 18:40:40 jwb: +1 to SCL, especially for the available-to-developers side of the story. 18:40:42 mitr: it isn't a SONAME change 18:40:47 dgilmore: with f22 when? I can put dates to taskjuggler to see what will happen 18:40:55 jwb: which are not in Fedora? :) 18:40:55 jwb: if thats the question... no? ;) 18:41:12 thozza, get on it :) 18:41:18 jreznik: june 2 18:41:20 mattdm: gcc available to developers with half of the library ecosystem incompatible would be… well, something. 18:41:50 dgilmore: with june 2, it would be possible I guess 18:42:19 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 jreznik: that would give us 24 days for mass rebuild which should be doable 18:42:39 i've kind of lost the thread here 18:42:42 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 mitr: there will be docs available with details 18:43:19 nirik: that we allow 2 more weeks for mass rebuild push branching and everythinga fter out 2 weeks 18:43:47 that we set f22 release date for June 2 and F23 release date for October 27 18:43:51 dgilmore: If we do that, can we _also_ get the side tags done and merged in time? 18:43:54 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 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 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 and asking for _realistic_ contingencies is something we've already agreed to. 18:44:56 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 and if we have another couple of weeks of slip from that, we're looking at a june 30 release. 18:45:28 we could always pull things forward if the mass rebuild is really smooth 18:45:38 we could also only mass rebuild archful packages 18:45:40 would it be possible to ship f22 with gcc 4.9 + std::string / std:list backported from gcc 5 ? 18:45:42 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 and ignore noarch 18:45:42 * nirik chuckles 18:45:43 dgilmore: No, we cannot pull forward. 18:45:50 * jwb has no idea what changed since 15min ago 18:45:53 sgallagh: sure we can 18:45:54 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 Other groups like QA are dependent upon a no-shorter-than schedule 18:46:01 s/shorter/sooner/ 18:46:11 And docs, and websites... 18:46:28 halfline: no, backporting into symbol versioned libraries is a big no-go 18:46:29 sgallagh: if we feel the mass rebuild is fine and done and we are a week before branching we branch 18:46:46 mitr "early" meaning "schedule as planned"? 18:46:53 If so, yes, I very much agree. 18:46:59 mattdm: For F22, yes. 18:47:22 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 post-branch 18:47:30 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 sgallagh: right, so... why not start that _now_? 18:47:47 (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 is there enough armv7hl hw, or is that the factor that slows down mass rebuilds? 18:47:59 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 jakubrh: it's not the time to do the actual builds. 18:48:10 mattdm: I didn't say we shouldn't. I agree. 18:48:11 jakubrh: the arm hardware speeds up the mass rebuild 18:48:13 I was translating :) 18:48:20 it's the time it takes everyone to clean up after them... fix bugs, etc 18:48:31 jakubrh: f19 mass rebuild was about 5 days and f20 adding arm was about 49 hours 18:48:35 40 hours 18:48:46 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 kalev: maybe. 18:49:16 kalev: Again, the bottleneck isn't the build time, it's the human response 18:49:17 might work, sure. 18:49:47 /me quotes "Optimizing anywhere but the bottleneck is an illusion" 18:49:55 kalev: its likely harder to get the logs for jakub and team to analyse and see what the issues are 18:50:00 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 well, yeah, might be harder to scrape them... 18:50:34 if they are wgettable, it is fine 18:50:49 I am happy to try make it easier for jakubrh to get things done 18:50:57 jakubrh: they are 18:51:06 nirik dgilmore jakubrh What problem are you solving right now? 18:51:34 mattdm: ways to make sure that teh test mass rebuild tests all arches 18:51:34 estimating breakage from gcc 5 18:51:39 wedging a gcc5 rebuild into the f22 schedule 18:51:40 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 Since we've now been on this for an hour... 18:51:41 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 Votes? 18:51:49 to give us higher confidence in the real mass rebuild 18:51:58 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 (+1 to my own proposal, for the record) 18:52:14 -1 I think we shoudl accomodate gcc 18:52:21 jakubrh: does this include fitting that into the existing schedule? 18:52:43 I think we can accomodate it without sacrificing f23 going into next year 18:52:48 mattdm: anything that failed in a way not easily understandable from the build.log file can be rebuilt locally in mock 18:53:42 jakubrh: so is that saying Jan 30th rebuild and Feb 10th branch are okay after all? 18:53:45 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 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 mitr: we always rebuild in a side tag 18:54:45 dgilmore: so are you agreeing with jakubrh's assesment of time needed? 18:54:48 sgallagh: rebuild + _fix up_ 18:54:49 I'm +1 to sgallagh btw 18:54:53 dgilmore: ^^ 18:55:19 dgilmore, are you proposing to adjust the schedule to accomodate a mass rebuild? 18:55:25 mattdm: if jakub says it can be done i will do everything I can to make it happen 18:55:31 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 jwb: i already proposed that 18:55:46 apparently that was missed 18:55:50 mitr: I'm opposed to holding off the decision that long. 18:55:58 It's unfair to projects like Ruby and Boost 18:56:02 jwb: i proposed setting release date for f22 to June 2 and F23 to October 27 18:56:03 what if the results of jakubrh'sgcc5 rebuilds look good? are we going to reconsider it? 18:56:12 dgilmore, did anyone vote on that? 18:56:20 jwb: I do not think so 18:56:29 (so far, 4 for, 1 against sgallagh's proposal) 18:56:36 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 thozza: thats the question I guess... 18:56:38 it would be doable, with risk, but doable 18:56:52 thozza: if the test rebuild shows a ton of issues then we should wait until f23 18:57:01 thozza: ^^ - would we be testing the other mass-rebuild-needing Changes at the same time? 18:57:08 dgilmore: I agree 18:57:09 i am more worried about the pie change causing issues than gcc 18:57:39 mitr: well, I guess we should, not to loose time 18:57:49 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 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 Which means a combinatorial explosion of things that might cause the whole thing to go belly-up 18:58:08 thozza: that would imply having patches for all of them ready by Saturday. 18:58:11 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 I agree. October 27th is unrealistic and will likely slip into December at least. 18:58:36 that is not an ABI issue; C++ is more important ABI-wise 18:58:42 jakubrh: I just don't think we have time to play with options like that 18:58:58 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 mattdm: during the test mass rebuild, why not? 18:59:12 sgallagh: mattdm: can you please explain why you think it is not realistic to ship F23 Oct 27? 18:59:35 mattdm: start test mass rebuild, analyze after half a day or day of what it gave 18:59:42 it's always the _next_ fedora we plan on doing a short cycle on. 18:59:52 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 digilmore: what kind of issues do you think the PIE change will cause? are these issues other than FTBS? 19:00:02 we are on this one hour and in circle... 19:00:06 We're witnessing *right now* that we have a heard time sticking to our guns on this 19:00:09 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 s/heard/hard/ 19:00:30 i went along with the time based schedule on the understanding that we'd actually STICK to it 19:00:37 so i'm going to go with what we agreed to stick to 19:00:42 +1 to sgallagh -1 to dgilmore 19:00:45 * nirik notes we need just one more +1 for sgallagh 19:00:48 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 kalev, thozza, t8m? 19:00:57 sgallagh: +1 19:01:03 jakubrh: yeah, I think that this would also mean deferring the PIE change 19:01:06 gcc 5 has some improvements in that area if new enough binutils is used 19:01:07 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 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 which means it passed 19:01:34 That brings it to +6, -1 19:01:37 okay. so we have +6/-1 for this proposal. 19:01:39 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 okay so +6/-1/0 19:01:56 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 shesh that's a lot of scrollback. sgallagh, can you restate? 19:02:40 #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 sgallagh: thanks :) 19:03:03 jakubrh, is there going to be a GCC 5.x release planned for F23 if GCC 5 gets into F22? 19:03:11 so that assumes no mass rebuilding changes... but boost and ruby are ok still? 19:03:33 nirik: we'll need to revisit boost, maybe. vondruch said that ruby doesn't require one. 19:03:50 i think it excludes PIE right off the bat 19:03:54 nirik: With eliminating the mass-rebuild time, if we extend that to landing side-tags, I think those are probably fine. 19:03:56 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 jakubrh: is there any way to have GCC 5.x in F22 without needing a mass rebuild? 19:04:11 jwb: I stated explicitly above that the proposal implied refusing the PIE chagne 19:04:23 sgallagh: s/refusing/deffering/ ? 19:04:24 jakubrh: something like staying with the 4.x C++ ABI, so that we don't need to rebuild? 19:04:30 nirik: ++++++++ 19:04:31 mattdm: ruby needs rebuild of ~150 packages 19:04:33 kalev: We covered that at length above. Please read the scrollback 19:04:33 kalev: given that it is backwards compatible, it could be added without a mass rebuild 19:04:55 mitr: as far as I know, it was gcc and pie 19:04:57 nirik: Yes, that's what I meant. Decision deferred to F32 19:05:02 Err, F23... :) 19:05:12 sgallagh: Or we could just approve it right now for F23. 19:05:15 sgallagh: good one :) 19:05:29 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 mitr: Maybe defer the decision to the moment the new FESCo is seated? 19:05:48 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 kalev: easily detectable at dynamic link time or using a script 19:05:53 I'm okay with approving F23 features now so people can know that they can be worked on. 19:05:54 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 sgallagh: makes sense. 19:06:42 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 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 If we don't do that, we might be landing mayhem into the stable updates stream 19:07:00 sgallagh, uh... we do that every release 19:07:08 jakubrh: can you rework the feature as a proposal to add it _without_ a mass rebuild? will this be okay? 19:07:08 (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 jwb: True enough, but I'm already reaching controversy-exhaustion today. 19:07:45 btw. speaking about new fesco - nominations are open! 19:07:52 mattdm: ISTM a gcc5 package would make sense; updating gcc so that rebuilds suddenly change ABI would be pretty bad. 19:08:21 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 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 tyll: I'd prefer to just stick to the "we recommend you do this" answer for F22 19:08:58 #topic meeting schedule, continued 19:09:30 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 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 jakubrh: thanks! 19:09:53 jakubrh: sorry it's not ideal. 19:10:00 jakubrh: thanks for coming and all the info. very appreciated. 19:10:11 how are we doing on meeting exhaustion? 19:10:15 jakubrh: Yeah, none of us *prefer* not having GCC 5, just that the timing is unfortunate 19:10:20 sgallagh++ 19:10:29 mattdm, i have another meeting at 14:30 i need to attend... 19:10:47 i might be able to multi-task, but not sure 19:10:49 okay, so, let's get what we can done in the next 15 minutes. 19:11:02 #topic #1374 SElf Contained Changes 19:11:05 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 .fesco 1374 Self Contained Changes 19:11:12 mattdm: Error: '1374 Self Contained Changes' is not a valid integer. 19:11:14 https://fedorahosted.org/fesco/ticket/1374 19:11:16 whoo 19:11:22 .fesco 1374 19:11:23 mattdm: #1374 (F22 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1374 19:11:35 +1 19:11:36 To replace the time we previously alotted to the Mass Rebuild. 19:11:40 pjp yeah, sorry :( 19:11:43 oh well. On to the next. 19:11:51 +1 19:11:53 +1 19:11:57 jreznik: still around? :) 19:12:03 +1 19:12:05 mattdm: yep 19:12:07 +1 to both 19:12:19 I'm confused, what are we voting on right now? 19:12:21 how is "new default console font" not a system change? 19:12:26 +1 to both 19:12:30 i mean... it's the default across the whole distro 19:12:33 but will have to leave soon 19:12:38 jwb only affects the console? :) 19:12:39 kalev: New console font and Lohit 2 [...] 19:12:46 jwb: you don't have to touch 1000 packages to do it 19:12:48 kalev: :) 19:12:55 jwb: I was thinking about it but in the end it's somehow contained - but really on the edge 19:13:04 sgallagh: thanks, I thought it might have been your schedule proposal 19:13:07 jwb: Changing a ~single package, others don’t need to do anything about it to adapt. 19:13:12 +1 to both too then 19:13:17 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 jwb: I'm comfortable calling this self-contained, as it doesn't require modifying any other packages to change it back 19:13:32 way to think really really narrowly guys 19:13:41 jwb: is there particular coordination you think is necessary? 19:14:02 that's the key importance for system wide that I can see 19:14:13 jwb: lets ask this way ... whats do we have the distinction between self and non self contained changes? 19:14:15 jwb: Supposedly the font will look ~the same, this is not some huge expectation-breaking controversy I hope. 19:14:31 *why 19:14:33 drago01: System-wide means that someone needs to coordinate cross-team conversations 19:14:39 perhaps i'm being overly grumpy. +1 move on 19:14:51 sgallagh: ok 19:14:51 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 it's the limited scope part i was questioning 19:15:11 anyway, move on 19:15:15 Yeah, this is an edge-case. 19:15:38 "somehow self contained" 19:15:40 jwb: If you find it worth shepherding, by all means do so :) 19:15:47 #agreed Lohit2 Odia Telugu self-contained change passes +7/-0 19:16:07 #agreed New Default Console Font self-contained change passes +7/-0 19:16:31 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 #topic #1307 F22 System Wide Change: Default Local DNS Resolver 19:16:47 .fesco 1307 19:16:48 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 #link https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver 19:16:51 https://fedorahosted.org/fesco/ticket/1307 19:17:11 I do want this, but what’s the status? 19:17:27 pjp still awake? :) 19:17:31 thozza? 19:17:35 mattdm: yes 19:17:40 yeah, last time we had questions about docker... 19:17:45 but they don't seem answered? 19:17:50 mitr: It's already available in F21, but not default yet 19:17:54 the unbound + dnssec-trigger + NM interoperability is implemented and working 19:17:57 pavlix: ping 19:18:07 mitr: it's in good shape, and bugs are being worked on 19:18:11 thozza: yep 19:18:16 I'm super-concerned about " 19:18:16 thozza: And init.d/network? 19:18:17 Docker and other users of network namespaces, like systemd-nspawn, would break." 19:18:28 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 thozza: nope, 19:18:59 mitr: to be honest, I didn't test that ever 19:19:27 thozza: So how do we know whether a trusted resolvers is being used? Default to {yes,no}? 19:19:47 you can use the test domain 19:20:20 mitr: that is why we have local on 127.0.0.1:53 19:20:35 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 mitr: init.d/network can be tested and adapted (i.e. I can handle it) 19:20:48 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 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 I am mostly +1 but I would like to see a better story for docer and other known broken use cases 19:21:43 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 mitr: yes, unless the resolv.conf is adapted of course 19:22:36 mitr: or does some iptables/interface dance that is not yet documented there. ;) 19:22:39 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 (a fatalistic kettle of boiled fish, mostly) 19:22:51 yes, I'll check with the docker folks to run some tests with F21, 19:23:16 pjp: maybe "don't ship in the cloud image" as a contingency possiblilty? 19:23:25 with all that covered I'm +1 19:23:33 mattdm: good for me 19:23:36 which brings us to +4. any other votes? 19:23:39 so, I assume this means adding it to comps? 19:23:40 mattdm: Note that I didn't find any docker release criterion. 19:23:46 mattdm: adding a full daemon to the cloud image is considered tricky 19:23:51 +1 based on sgallagh and mattdm being comfortable. 19:23:53 * nirik doesn't see that in the feature page 19:24:16 #action pjp to add some notes about docker and cloud to the feature page :) 19:24:23 well, it 19:24:26 * pjp makes a note 19:24:32 's two daemons... ;) 19:24:36 #action pavlix to look at init.d/network 19:24:40 but they are small. ;) 19:24:53 +1 from me as well 19:25:03 +1 from me for me 19:25:17 thozza: what's the status of init.d/network in f22 btw [feel free to reply outside this channel]? 19:25:17 #agreed Default Local DNS Resolver accepted for F22 (+7/0/0) 19:25:31 #topic #1379 F22 System Wide Change: Change xorg input stack to use libinput 19:25:32 .fesco 1379 19:25:34 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 #link https://fedoraproject.org/wiki/Changes/LibinputForXorg 19:25:36 https://fedorahosted.org/fesco/ticket/1379 19:26:02 +1 based on the last stuff on the list around this. 19:26:02 +1, I think the concerns we had last week got all resolved 19:26:10 Didn't we already approve this, contingent on it working for KDE? 19:26:19 +1 to this 19:26:20 (Well, GNOME + KDE, obviously) 19:26:25 +1 in any case 19:26:29 sgallagh: new plan is "doesn't work for KDE yet, so only enable for GNOKME for this release" 19:26:30 sgallagh: Yeah, and the plan is IIRC that it explicitly won’t work on KDE 19:26:45 hi, I'm here to answer any questions you may have ..., but just a long list of +1 votes works too :) 19:26:48 (and it won't _break_ KDE, just not be enabled) 19:26:55 hansg: is my understanding correct? 19:26:56 btw. it may be implemented for F22 19:27:06 Right, as long as it doesn't break KDE, I'm cool with it. 19:27:07 (in KDE) 19:27:15 there's initial code ready 19:27:18 +1 19:27:58 #agreed Change xorg input stack to use libinpu accepted for F22 (+6/0/0) 19:28:04 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 hansg: Great. 19:28:25 (that's including a +1 and assuming no one jumps in with a negative) 19:28:30 You're talking on KDE 4, right |? 19:28:30 (+1 if anyone wants to count that in) 19:28:36 mitr oh sure. 19:28:38 #undo 19:28:38 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 #agreed Change xorg input stack to use libinpu accepted for F22 (+7/0/0) 19:28:48 KDE4 right 19:29:19 hansg: F22 will be very likely KDE 5 but the libinput backend should be easy for both 19:29:20 okay, so, that's all the followup tickets. Do we have energy/quorum for going ahead to new business? 19:29:37 jreznik, ack 19:29:45 mattdm: Let’s; it won’t be any easier next week. 19:29:47 mattdm: I guess I can handle some more 19:29:55 okay, here we go :) 19:29:59 #topic #1382 F22 System Wide Change: Fedora 22 Boost 1.58 Uplift 19:30:01 .fesco 1382 19:30:02 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 #link https://fedoraproject.org/wiki/Changes/F22Boost158 19:30:03 and for many we have answer ready :) 19:30:05 https://fedorahosted.org/fesco/ticket/1382 19:30:24 +1 19:30:31 1.58 doesn't seem to fit into the schedule 19:30:33 sgallagh: You wanted to bring up the side tag schedule, or was that already resolved? 19:30:35 +! 19:30:36 +1 19:30:42 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 but +1 if it's 1.57 19:30:56 mitr: I think the 10 days for mass rebuild were getting added 19:31:03 +1 19:31:14 mitr: Mostly I just wanted us to rubber-stamp giving side-tags the previous mass rebuild time to work with 19:31:31 It wasn't clear that we'd told jreznik to go ahead and update the schedule in that way 19:31:50 no, it wasn't, I'm just thinking about it 19:32:14 so, that would give until 2015-02-09? (branch is on 10th) 19:32:31 dgilmore: Is that reasonable? 19:33:02 sgallagh: so long as nothing breaks post merge 19:33:28 at least 2 days would be better 19:33:35 either way things will have to get fixed 19:33:36 could do friday the 6th? 19:33:41 so, remove mass rebuild, side tags 2015-02-06 19:33:53 it would mean that if we merged teh day before fixes have to be done twice 19:33:55 wfm 19:33:57 so its doable 19:34:03 Friday the 6th seems reasonable. This means no other changes to the schedule after that. 19:34:21 6th sounds reasonable to me as well 19:34:26 (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 the 6th seems reasonable. gives a few days to deal with any breakages 19:35:22 Is there anything in this conversation that needs to be updated in the change? 19:35:57 OK, so formally: 19:35:58 Proposal: Side-tags must be merged into Rawhide by February 6th, with Branch occurring on February 10th as previously scheduled. 19:36:04 sgallagh: +1 19:36:05 +1 19:36:07 +1 19:36:12 (so we have +3 for the change so far, and +4 for it if it's limited to 1.57) 19:36:12 +1 19:36:22 +1 to that 19:36:33 +1 19:36:39 #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 and with that understanding I'm +1 as well. 19:37:05 does anyone els have an opinion on the 1.57/1.58 thing? 19:37:27 mattdm: I'm fine with trusting them to land it if it's ready or defer if it is not. 19:37:31 +1 to side tag (sorry) 19:37:40 #undo 19:37:40 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 #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 mattdm: +1 for 1.57/1.58 19:38:17 I'm +1 for the change and ambivalent about the version that lands. 19:38:23 mattdm: Per https://svn.boost.org/trac/boost/roadmap it seems 1.58 will arrive too late. 19:38:54 yeah so I'm kind of on the side of just saying target 1.57. 19:38:56 mitr: If they're comfortable doing the build over the course of three days, let them have it :) 19:39:01 sgallagh: yes 19:39:04 I suspect that this will sort itself out 19:39:30 does _that_ fallback have schedule implications? 19:39:54 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 mattdm: Boost deps are reasonably well understood 19:40:54 I think they'll know while doing the side-tag whether or not to bother merging. 19:40:57 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 What mitr said 19:41:30 indeed 19:41:42 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 I'm fine with it going forward 19:42:19 kalev: so, 0 if it's listed as 1.58? 19:42:35 this is pendantic and not so importnat, really, just want to keep the vote counts accurate :) 19:42:37 sounds good :) 19:43:03 #agreed Boost 1.58 accepted for F22 (+6/-0/1) 19:43:24 #info timing makes 1.57 likely (as page explains) 19:43:30 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 mitr: we merge sidetags in on teh cutoff ready or not 19:43:46 maybe we shouldnt 19:43:54 sgallagh: right, that's what the change basically says already. (contingency plan is actually a contingency plan :) 19:43:59 #topic #1383 F22 System Wide Change: GHC 7.8 19:44:00 .fesco 1383 19:44:01 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 #link https://fedoraproject.org/wiki/Changes/GHC_7.8 19:44:04 https://fedorahosted.org/fesco/ticket/1383 19:44:25 i am +1 here 19:44:28 This is dependent on a mass-rebuild that we aren't doing. 19:44:29 So -1 19:44:38 sgallagh: no its not 19:44:41 Oh, I misread 19:44:47 +1 19:44:48 Belay that 19:44:55 +1 19:45:01 +1 19:45:10 +1 19:45:14 its dependent on getting a side tag and building in it 19:45:16 so this is another side tag thing, yeah. 19:45:20 +1 19:45:25 +1 19:45:30 whooo 19:45:37 dgilmore: yeah, I saw the phrase "in time for F22 Mass Rebuild" and didn't read closely enough 19:45:52 #agreed GHC 7.8 accepted for F22 (+7/0/0) 19:45:59 #topic #1384 F22 System Wide Change: Harden all packages with position-independent code 19:46:01 .fesco 1384 19:46:02 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 #link https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code 19:46:05 https://fedorahosted.org/fesco/ticket/1384 19:46:08 okay, so *this* one called for a mass rebuild 19:46:16 so deferring? 19:46:17 So definitely -1 for F22 19:46:18 Approve for f23, or defer to the new FESCo? 19:46:20 but tyll suggested a fallback of just enabling it and not doing a rebuild 19:46:25 -1 for f22 19:46:32 +1 for f23 19:46:40 mattdm: I'm -1 on enabling it in F22, even without the rebuild. 19:46:41 it can land right after branching 19:46:46 -1 to f22, +1 for f23... 19:46:47 -1 for F23; +1 for deferring to new FESCo 19:46:52 sgallagh: k 19:46:55 But I'm 0 for F23 today. 19:46:59 * mattdm tries to count :) 19:47:03 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 -1 for F22 19:47:16 * thozza sorry for the mistake 19:47:18 mitr: *nod* 19:47:19 -1 for f22 19:47:33 I guess 0 for f23, but strongly recommending the new FESCo to approve at least for 64-bit architectures. 19:47:35 -1 to f22, +1 to f23 19:48:07 (is there a zodbot "declined" macro?) 19:48:10 (and sadly -1 to F22, yeah) 19:48:22 mattdm: nope. 19:48:35 mattdm: but we agreed :) 19:49:04 #agreed System Wide Change: Harden all packages with position-independent code NOT accepted for F22 (0,-7,0) 19:49:07 I am confused are you voting on F22? 19:49:10 or F223 19:49:14 clearly we are -1 for f22 but for f23 its a bit messier 19:49:17 moezroy: both at once in a confusing melange! 19:49:46 meh can we revote on f23? i can't sort that all out 19:50:02 +1 for f23 19:50:03 shouldn't it be the next fesco deciding F23 stuff? 19:50:03 +1 for f23 19:50:09 kalev: vote -1 for that 19:50:15 0 on f23, recommending +1 to the new FESCo 19:50:32 +1 for f23 19:50:33 0 on F23 19:50:44 (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 mattdm: which is why I'm +1 it means it can land as soon as we branch 19:51:21 I'm only voting 0 because I'm not adequately prepared to make a sensible decision today 19:51:25 before tehre is a new fesco 19:51:30 jwb: you around to vote for PIC for F23? 19:51:34 I'm 0 for F23 as well, for similar reasons as sgallagh 19:51:38 oh okay. 19:51:52 one sec. lemme read scroll back 19:52:03 sgallagh, kalev, what about 64bit only for F23? would that change your vote? 19:52:10 dgilmore: We are branching after the electino results are announced. 19:52:14 jwb didn't pass for f22, question is basically "pass for f23 now, or wait until new fesco" 19:52:38 i'm +1 for f23 19:52:58 the performance hit is real, but i think it is likely worth it 19:53:01 okay so we we have +4 for and 3 abstentions. 19:53:13 moezroy: No, I'm admitting freely that I'm not read-up enough on this to decide today. 19:53:18 which makes me dig out the fesco voting rules 19:53:33 That does not preclude me casting a vote next week (or sooner in the ticket) 19:53:50 mitr: not before they have had a meeting 19:54:37 mattdm: so we don't decide anything about f23 now and move on I think... 19:54:40 mattdm: https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee 5 votes needed. 19:54:41 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 nirik, yes 19:54:46 mitr: thanks 19:54:51 okay then. 19:54:56 * nirik nods 19:55:00 mattdm: This doesn't pass or fail. We agree to defer by a week and move on. 19:55:12 I'll do my best to read up and cast a formal vote before then, if I can manage it 19:55:25 sgallagh, thanks 19:55:34 * jwb is confused by this "wait for next fesco" thing 19:55:35 sgallagh: okay works for me. 19:55:43 #info F23 decision defered until next week 19:55:55 jwb: me too especially from mitr who will be on it as his seat is not up for election 19:55:58 jwb: Red herring. I suggested it, but didn't carry it. 19:56:00 #topic #1385 F22 System Wide Change: Ruby 2.2 19:56:01 .fesco 1385 19:56:02 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 #link https://fedoraproject.org/wiki/Changes/Ruby_2.2 19:56:05 https://fedorahosted.org/fesco/ticket/1385 19:56:17 +1 19:56:21 +1 19:56:25 +1 19:56:29 +1, same mumbo-jumbo about the side tag 19:56:33 vondruch: noted earlier that this didn't need a mass rebuild 19:56:36 +1 19:56:36 +1 yeah that 19:56:55 #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 #topic #1386 F22 System Wide Change: Set sshd(8) PermitRootLogin=no 19:57:06 .fesco 1386 19:57:07 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 #link https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no 19:57:10 https://fedorahosted.org/fesco/ticket/1386 19:57:12 -1 19:57:18 okay now we get to the good times :) 19:57:23 :) 19:57:29 thank you ladies and gentlemans :) 19:57:31 I'll note that the Server SIG discussed this in their meeting and strongly opposes this. 19:57:45 sgallagh: why? 19:57:50 -1 as proposed. 19:57:55 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 Speaking for the cloud sig, I think it doesn't matter, as cloud-init manipulates this anyway. 19:58:00 So -1 from me 19:58:04 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 pjp: https://fedorahosted.org/fesco/ticket/1386#comment:1 19:58:13 * pjp clicks 19:58:21 sgallagh: I was just writing that I think we should defer this one to the Server WG 19:58:50 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 after reading the devel-list discussion I don't feel it brings much benefit 19:59:15 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 kalev: do you have a sense of the Workstation view here? 19:59:32 nirik: yeah, I agree with that. 19:59:33 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 it doesn't matter much there either as it's not running by default 19:59:46 mattdm: I think it doesn't matter much either way for Workstation 19:59:57 mattdm: workstation does not seem to enable SSH by default 20:00:00 So that only leaves non-Product spins 20:00:20 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 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 because we can't _really_ give a mandate for development work that no one is itching to do. 20:00:54 mattdm: I plant to discuss this with the respective upstream folks 20:01:09 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 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 pjp: yeah, but you can't say they will be able/willing to work on it... 20:01:33 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 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 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 pjp: and basically, fesco saying so won't help with that :) 20:02:01 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 nirik: That, or more prominently support domains, but that still requires a bootstrap of a domain controller... 20:02:40 that also I think... yeah. 20:02:52 sgallagh: usability concern is only showing in cases wherein only root account is required, 20:02:52 nirik: well import keys/manage the sshd config file at install time 20:02:54 pjp: Yes, there's value in the long-term, if the details can be worked out. 20:03:08 but its work that belongs in the installer 20:03:10 dgilmore: sure, but ideally import keys... (more secure than a password) 20:03:11 pjp: Read the Server SIG meeting notes. We highlighted quite a few such cases 20:03:20 sgallagh: okay, 20:03:24 I can see adding a kickstart option to inster a ssh public key etc 20:03:36 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 i need to type better today 20:03:46 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 mitr: Let's put that on next week's Server SIG agenda 20:04:08 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 mattdm: -1 20:04:27 pjp: thanks for bringing this change up in any case and weathering the stormy seas of the devel list about it. ;) 20:04:29 mattdm: -1 20:04:35 Is it possible to hold vote for some time? 20:04:38 -1 at this time. 20:04:38 yes, what nirik said :) 20:04:53 pjp: it can be improved and resubmitted 20:04:54 pjp: The F22 schedule is pretty tight. I'd recommend trying for F23 20:05:05 pjp: yeah this isn't necesarily long-term binding 20:05:06 Or if you work really fast, resubmitting, I guess. 20:05:17 I'm at 0, fwiw. :) 20:05:21 -1 20:05:22 mattdm: Maybe phrase the proposal we're voting on? 20:05:23 sgallagh: dgilmore I see, okay 20:05:27 I'm 0 as well 20:05:37 pjp: please talk to the anaconda guys to see ways to work on it. 20:05:44 sgallagh uh, okay :) 20:06:00 dgilmore: Yes, I'll start a conversation with them, 20:06:04 #proposal "Set sshd(8) PermitRootLogin=no - https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no" as systemwide default for F22 20:06:28 and I think this has +0/-4/2 20:06:40 #info The change text now actually proposes PermitRootLogin=without-password 20:06:49 Yes, 20:07:02 mitr thanks. I'll edit the ticket when I close things out. 20:07:07 That's as per the discussion on the -devel list, 20:07:17 mitr: did you vote? 20:07:27 mattdm: I was -1 20:07:39 -1 for F22 as it is now 20:08:15 #agreed "Set sshd(8) PermitRootLogin=no" as systemwide DOES NOT pass for F22 20:08:24 #undo 20:08:24 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 #agreed "Set sshd(8) PermitRootLogin=no" as systemwide DOES NOT pass for F22 (+0/-5/2) 20:08:55 okay, so, that's everything that made it onto the agenda this week 20:09:06 although there are others filed after 20:09:11 i think it's time to call it a day 20:09:20 #topic Next week's chair 20:09:25 mattdm: I need to run but can run next weeks meeting 20:09:43 #info dgilmore is the heroic chair for next week's meeting 20:09:47 #topic Open Floor 20:10:00 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 jakubrh: yes 20:10:23 jakubrh: yes -- it's the schedule impact of that that we're worried about. 20:10:25 jakubrh: yes, I think so... for f22... we still want to do the mass rebuild for f23 20:10:38 nirik: *nod* 20:10:46 ok, will work in that direction then 20:10:58 jakubrh: thanks -- appreciate your understanding here! 20:11:12 anyone have anything else? Will close the meeting in a minute. 20:11:41 jakubrh: thanks, I think that's a good middle ground here 20:12:12 #endmeeting