16:00:11 <sgallagh> #startmeeting FESCO (2017-03-17)
16:00:11 <zodbot> Meeting started Fri Mar 17 16:00:11 2017 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:11 <zodbot> The meeting name has been set to 'fesco_(2017-03-17)'
16:00:11 <sgallagh> #meetingname fesco
16:00:11 <zodbot> The meeting name has been set to 'fesco'
16:00:11 <sgallagh> #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann
16:00:11 <zodbot> Current chairs: Rathann dgilmore jforbes jsmith jwb kalev maxamillion nirik sgallagh
16:00:11 <sgallagh> #topic init process
16:00:20 <nirik> morning
16:00:24 <kalev> morning
16:00:25 <jsmith> .hellomynameis jsmith
16:00:26 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
16:00:30 <sgallagh> .hello sgallagh
16:00:31 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:00:33 <jforbes> .hello jforbes
16:00:37 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:00:39 <kalev> I sadly have to leave in a few minutes due to a conflicting meeting, sorry :(
16:00:50 <jsmith> (FWIW, I'm on a flight with very terrible wifi, so I may be slow to respond)
16:01:54 * mattdm is here
16:02:31 <linuxmodder> .fas linuxmodder
16:02:31 <sgallagh> I've asked mattdm and codonnel to join us for the schedule discussion, so we'll probably start there.
16:02:31 <zodbot> linuxmodder: linuxmodder 'Corey W Sheldon' <sheldon.corey@openmailbox.org>
16:02:46 * linuxmodder is just staying informed and trying to get back in the loop
16:03:02 <Rathann> hi
16:03:08 <Rathann> .hello rathann
16:03:09 <zodbot> Rathann: rathann 'Dominik Mierzejewski' <dominik@greysector.net>
16:03:25 * codonell waves
16:03:27 <jwb> hello
16:03:44 <codonell> jwb, Hey Josh
16:04:25 <sgallagh> OK, shall we get started?
16:04:42 <sgallagh> #topic #1681 Proposed Fedora 27 schedule
16:04:43 <sgallagh> .fesco 1681
16:04:45 <zodbot> sgallagh: Issue #1681: Proposed Fedora 27 schedule - fesco - Pagure - https://pagure.io/fesco/issue/1681
16:05:01 <sgallagh> This topic will also cover
16:05:01 <sgallagh> .fesco 1693
16:05:01 <dgilmore> hi
16:05:02 <zodbot> sgallagh: Issue #1693: Fedora 27 Mass Rebuild for IEEE-128 support - fesco - Pagure - https://pagure.io/fesco/issue/1693
16:05:27 <mattdm> I asked for this to be reopened in light of the No More Alphas change
16:05:51 <mattdm> It is certainly possible to simply replace the Alpha release with "Check if we are on schedule for Beta" and just move on
16:05:55 <sgallagh> Right, so with no more Alphas *and* a request for a mass-rebuild possibly later than currently scheduled, we have much to discuss here
16:06:05 <jsmith> Aye....
16:06:30 <mattdm> But there are also three things (at least) which I think we coul do better without the alpha
16:06:47 <mattdm> 1. Move branch later, to minimize time spent diverging
16:06:58 <mattdm> 2. Build in a extra week of beta, because we usually slip
16:07:19 <mattdm> 3. Build in a pre-planned "alternate date", so we can look like we know what we're doing
16:07:24 <sgallagh> Is that beta *freeze*?
16:07:28 <sgallagh> (in 2.)
16:07:43 <mattdm> and reduce articles like http://phoronix.com/scan.php?page=news_item&px=Fedora-26-Alpha-Delay-1
16:08:05 <mattdm> sgallagh: Possibly. I think the idea I had for "rain date" might apply to the beta too
16:08:34 <Rathann> mattdm: phonronix is always sensationalizing unremarkable news to attract readership
16:08:36 <mattdm> put in the schedule the target date *and* a rain date, which we would slip to if needed without slipping the final schedule
16:08:39 * nirik is willing to try new things
16:08:59 <Southern_Gentlem> mattdm, backup 2 weeks imho
16:09:00 <Rathann> but anyway, good idea to have
16:09:05 <sgallagh> I mostly ask because in my experience, none of the important issues get fixed *before* Freeze, so maybe we should extend that earlier.
16:09:11 <jforbes> Rathann: true, but it is also somewhat telling that release delays are unremarkable
16:09:20 <mattdm> Rathann: yeah, but it's not just phoronix, and it builds up to a general impression
16:09:42 <mattdm> Southern_Gentlem: I'm thinking one backup week in the beta timeframe, and oen in the final timeframe, giving us two weeks of overall flex
16:09:43 <Rathann> true
16:10:05 <nirik> lwn often now makes comment of things like "the expected slip of" or the like
16:10:27 <mattdm> Right, so instead, we plan for that, and then occasionally release a week or two ahead of schedule
16:10:40 <sgallagh> Perhaps just declaring that release will occur within a two or three-week window, with the no-slip target at the beginning of it?
16:11:08 * codonell waits patiently to get asked a question :-)
16:11:39 <mattdm> sgallagh: Maybe? There's a balance where having a target written down provides incentive, and if we give a three-week target it will be easy to get into the habit of assuming that we really mean the end of that every time
16:11:40 <sgallagh> codonell: Sorry, there are two issues here.
16:11:43 <jwb> i don't think we should plan our release schedule around snarky comments made by various websites
16:11:47 <nirik> "release window is..."
16:12:25 <sgallagh> Well, people seem a lot friendlier to Ubuntu's "we'll release sometime in the month of ..."
16:12:56 <mattdm> jwb: It's not the snarky comments per se, but being seen as consistent
16:12:57 <nirik> thats always the danger of providing a concrete release date. :)
16:13:18 <mattdm> I see this problem e.g. in talking to people internally at Red Hat about the Fedora schedule
16:13:19 <jwb> mattdm: consistent to what end?
16:13:23 <dgilmore> I do want branching to be 2 weeks before we enable bodhi. which I would like a week before Beta freeze
16:13:43 <dgilmore> there will be people who wait until branching to try land change :(
16:13:52 <jwb> mattdm: i've only seen that concern internally on freeze and final release dates.  nobody cares about milestone releases
16:13:53 <nirik> so perhaps we should address the mass rebuild question as it will shape the other parts?
16:13:54 <mattdm> jwb: Primarily, for planning, for 1) us 2) our users 3) our downstreams
16:13:58 <jwb> and we don't slip freeze dates
16:14:18 <mattdm> jwb: yeah, but the thing is right now, the milestone slips slip the whole thing. hence the idea of building in a week
16:14:28 <sgallagh> dgilmore: I've suggested in the past that we should just treat Branched as perpetually frozen starting at Beta Freeze to prevent exactly that sort of behavior
16:14:44 <dgilmore> sgallagh: that is a change we could propose
16:15:01 <mattdm> Anyway I think this is the *less* interesting of my suggestions; the other one is to branch later inthe process
16:15:01 <sgallagh> And if our Rawhide is going to be more stable and gated, it becomes more enticing to work there.
16:15:23 <mattdm> which relates to what sgallagh just said
16:15:24 <sgallagh> mattdm: dgilmore just made a similar proposal
16:15:27 <Rathann> well, glibc seems to have a freeze 1 month before the release, so I guess it should be stable enough just in time for the July mass rebuild, am I correct?
16:15:49 <mattdm> if we're going to freeze it, late branching reduces pain
16:15:52 <sgallagh> codonell: ^^ That's the really big question for this particular release.
16:15:57 <dgilmore> jwb: I think having a mass rebuild to enable the change proposed is good, and if we need to delay it a month from where it currently is to make sure that glibc is ready I am good with that
16:16:18 <jforbes> sgallagh: that means we would have to go through a fe process for every update submitted post branch? Sounds like a PITA for packages which update frequently
16:16:41 <codonell> Rathann, sgallagh, The only guarantee you get from upstream is that the *released* version will provide a stable ABI from which to build a distribution.
16:16:45 <sgallagh> jforbes: That's exactly my point: packages that update too frequently *shouldn't* be doing so once we get to Beta
16:17:02 <codonell> Rathann, sgallagh, An ABI change may yet occur before release (unlikely), and force Fedora to mass rebuild.
16:17:02 <sgallagh> They can release a lot in Rawhide, then bring tested ones in at appropriate intervals to Branched
16:17:04 <jforbes> sgallagh: I beg to differ
16:17:29 <codonell> Rathann, sgallagh, In practice this is vanishingly rare, but I want to call it out.
16:17:39 <sgallagh> /me nods
16:17:53 <fweimer> codonell: But we can usually do just with targeted rebuilds.
16:18:04 <fweimer> Like we did for the sendmsg/recvmsg ABI revert.
16:18:06 <codonell> fweimer, Correct.
16:18:09 <Rathann> ok
16:18:11 <sgallagh> codonell: The issue here is that if we wait until the stable release for the mass-rebuild, we may have to push out the complete schedule by a whole month
16:18:12 <jforbes> sgallagh: we already do that. daily builds in rawhide, weekly in branched, but you lose rawhide testers post branch too
16:18:21 <Rathann> I need to step out for a few minutes, brb
16:18:26 <sgallagh> Because we always do the rebuild in advance of a branch
16:18:39 <nirik> BTW, I am pretty sure I recall when we were discussing the f26 scheule we decided that we didn't want to do a mass rebuild in f27... we can of course change our mind, but thats why it wasn't planned.
16:18:54 <codonell> Rathann, sgallagh, I'm happy with _not_ waiting for glibc to release, for this particular release, as long as we are within the 1 month freeze window for glibc.
16:19:01 <sgallagh> jforbes: Yeah, kernel is kind of a special case and maybe we offer them a blanket exception if we go this route
16:19:17 <sgallagh> codonell: What is the specific date that window starts?
16:19:20 <fweimer> sgallagh: I think the stable release isn't the problem here.  We need the patches from IBM before the mass rebuild.
16:19:37 <codonell> sgallagh, 2017-07-01.
16:19:43 <jforbes> nirik: when we discussed the F27 schedule, we specified that the "Mass Rebuild (not planned)" have the "(not planned)" removed
16:19:57 <codonell> fweimer, sgallagh, I spoke with IBM and they aim to have everything in place for glibc 2.26 and try hard for it.
16:20:00 <sgallagh> codonell: I thought that was the planned *release* date.
16:20:14 <codonell> fweimer, sgallagh, There is a probability of a slip.
16:20:39 <codonell> fweimer, sgallagh, They have 3.5 months of more development time.
16:20:49 <codonell> fweimer, And we need to schedule in some time to help them.
16:20:52 <sgallagh> Oh sorry, I misread. That was 08-01
16:20:58 <sgallagh> I misparsed that
16:21:23 <codonell> sgallagh, So 2017-07-01 is freeze for glibc, we burn down bugs, and release 2017-08-01 and you get your ABI guarantee there.
16:21:27 <sgallagh> OK, but in theory if we had a mass-rebuild sometime in the latter half of July, that would be manageable?
16:21:45 <sgallagh> (Which may be realistic if we're adjusting to a later branch with no alphas)
16:21:48 <codonell> sgallagh, Yes, IBM must have their ABI changes in by 2017-07-01.
16:21:57 <codonell> sgallagh, We can put a go / no-go line in the sand on that date.
16:22:18 <codonell> sgallagh, At which point it shifts out another 6 months, but for us in Rawhide we could flip the switch.
16:22:28 <sgallagh> ack
16:22:39 <sgallagh> That seems workable to me.
16:22:41 <codonell> sgallagh, And prepare for F28 having the new 128-bit float type for long double.
16:22:50 <sgallagh> That even works for the current schedule, if a little tightly.
16:23:46 <codonell> sgallagh, The glibc releases and Fedora schedule dance a "biala de la ABI muerte" :-)
16:24:30 <dgilmore> nirik: we had decided awhile ago to always plan to do one, and not do it if it turns out not needed, we made the choice to not do one for f25, which i think gave jkurik the idea that we would really only plan to do them every other release, but would put it in the schedule always in case, which is why he added (not planned)
16:25:32 <sgallagh> codonell: So it's reasonable to say that if we did a mass-rebuild starting July 5th, that you would either have the patches in place or would have deferred?
16:25:52 <jforbes> Either way, the schedule was approved on the condition that the not planned was removed
16:26:11 <nirik> dgilmore: that is not my recollection. ;) I recall us specifically saying that we had less time in the fall release and we didn't want to do a mass rebuild then... but oh well, water under the bridge.
16:28:07 <sgallagh> OK, so given this conversation, let's proceed with the F27 schedule plan, with a note that the mass-rebuild must occur no earlier than July 5th. Agreed?
16:28:42 <codonell> sgallagh, Yes, by July 5th either the ABI is ready and we can mass-rebuild or it isn't.
16:28:50 <nirik> which plain? mattdm's last one in ticket?
16:28:54 <dgilmore> assuming we have the needed glibc then sure
16:28:59 <codonell> fweimer, Comments?
16:29:23 <sgallagh> nirik: I should have said "planning" not "plan", sorry
16:29:30 <fweimer> codonell: July 5th is very generous. :)
16:29:51 <codonell> fweimer, Generous to whom? :-)
16:29:52 <nirik> the one in ticket has july 12th
16:29:56 <sgallagh> fweimer: generous or ambitious?
16:30:09 <sgallagh> nirik: The plan we originally approved was comment #0
16:30:19 <sgallagh> Which has the mass-rebuild at July 5th
16:31:00 <nirik> yeah and has alpha in it. ;)
16:31:01 <fweimer> sgallagh: I don't know the Fedora side, but it should work out very well on the glibc side.
16:31:04 <sgallagh> Now that we've established that glibc's needs don't force us to delay *that* schedule, we can move back over to discussing mattdm's suggestion to do a later branch
16:31:23 <codonell> sgallagh, OK, do you need Florian and I for any other questions?
16:31:39 <sgallagh> codonell: I don't believe so. Thank you very much for your time.
16:31:49 <codonell> sgallagh, Thank you very much for reaching out over this issue!
16:32:40 <sgallagh> mattdm: So are we currently discussing https://pagure.io/fesco/issue/1681#comment-75536 in specific, or is there a revised version you'd like to propose
16:32:59 <sgallagh> (and, ideally, stick on an etherpad or something so we can address it as a group)
16:33:50 <jwb> sgallagh: wait
16:34:06 <jwb> sgallagh: so can we get a #agreed that we're doing a mass rebuild for f27?
16:34:17 <sgallagh> Reasonable
16:34:23 <jwb> sgallagh: and then we can figure out the schedule
16:34:30 <jforbes> jwb: we pretty much got that when we approved the original schedule
16:34:36 <sgallagh> proposal: A mass-rebuild will occur in Fedora 27 and may occur no earlier than July 5th.
16:34:44 <dgilmore> +1
16:34:50 <sgallagh> jforbes: Reasonable to capture the "no earlier than" piece at least
16:34:53 <jforbes> +1
16:34:54 <jwb> jforbes: no, we said we'd always plan on one.  we didn't say we were going to do one
16:34:59 <jwb> +1
16:35:00 <nirik> sure, +1
16:35:10 * Rathann is back
16:35:28 <sgallagh> +1
16:35:33 <Rathann> ok, +1 from me to the mass-rebuild schedule proposal
16:36:28 <sgallagh> #agreed A mass-rebuild will occur in Fedora 27 and may occur no earlier than July 5th (+6, 0, -0)
16:37:03 <jsmith> +1 from me
16:37:15 <jsmith> (sorry for the latency/connection problems)
16:37:26 * mattdm edits post to reflect adjusted f26 date and mass rebuild
16:37:41 <nirik> so, I like mattdm's proposal... however, I like dgilmore's idea of moving bodhi enablement a week before beta freeze. Which there should be room for no problem
16:37:52 <sgallagh> #undo
16:37:52 <zodbot> Removing item from minutes: AGREED by sgallagh at 16:36:28 : A mass-rebuild will occur in Fedora 27 and may occur no earlier than July 5th (+6, 0, -0)
16:37:55 <sgallagh> #agreed A mass-rebuild will occur in Fedora 27 and may occur no earlier than July 5th (+7, 0, -0)
16:38:22 <nirik> also, dunno if we want to move a bit for flock... given that we don't know for sure when it is yet?
16:38:45 <sgallagh> nirik: I'm also not *too* worried about entering Beta during Flock week
16:39:07 <sgallagh> I figure one of two things will happen: People will get their stuff in early, or they'll resolve it during a hackfest :)
16:39:14 <mattdm> nirik: unless there's a big change, flock is likely to be week of august 27th
16:39:31 <nirik> sure, but then there's all the QA and releng folks who will be... flocking and not testing/making rc's, etc.
16:39:42 <nirik> not that we usually get to rc in the first week
16:39:50 <sgallagh> Exactly what I was about to type
16:39:59 <sgallagh> The RCs would probably hit when people get home the following Monday.
16:40:15 <nirik> but we only get to rc's because QA gets blockers fixed.
16:40:31 <nirik> s/gets/finds, files and gets maintainers to/
16:40:38 <jforbes> It actually could end up working out very well for the schedule
16:40:54 <jforbes> bug people in person to get blockers fixed, etc
16:41:16 <sgallagh> We could even put that into the schedule for the last day of the conference...
16:41:17 <nirik> yeah, but how much time will people have to sit down and test things? (far away from their normal hardware)
16:41:27 <jforbes> And get rc testing fresh on people's minds
16:42:16 <sgallagh> But ok, I suppose we could opt to enter Beta Freeze the next week, but still focus on a pre-freeze bugfixing effort at Flock itself?
16:43:32 <nirik> I think that would be better...
16:43:38 <sgallagh> Or enter Beta Freeze the week before, ask QA to do as much testing before traveling as possible and try to fix things at the con?
16:43:59 <mattdm> shifting the final release back a week now too, or compressing it?
16:44:37 <nirik> I think thats just as bad/worse. ;)
16:45:24 <nirik> "I'd love to go to your talk, but we have to test RC2 and have a go/no go meeting, and I need to find A B and C to fix blockers"
16:45:26 <sgallagh> mattdm: I think we could compress it if we enact my *other* proposal (not exiting Freeze after Beta release)
16:46:07 <dgilmore> sgallagh: I actually do not think that will help any
16:46:08 <sgallagh> Such that once we get to Beta, everything we pull in has been granted a Freeze Exception or addresses a blocker bug
16:46:22 <dgilmore> sgallagh: it will cause a burden on QA and releng
16:46:26 <nirik> that will make 0 day updates even more vast. ;)
16:46:41 <dgilmore> and will result in a massive amount of change sitting there for zero day updates
16:46:42 <sgallagh> nirik: That's a problem no matter what.
16:46:55 <dgilmore> sgallagh: your proposal makes it worse
16:47:07 <jsmith> nirik: +1
16:47:14 <nirik> sure. It will also mean lots of smaller fixes will not be there for release... things we don't find worthy of blocking/freeze break
16:47:16 <sgallagh> It's numerically worse, but I'm not sure it's holistically worse
16:47:32 <jwb> i say... screw it, we'll do it live.  ROLLING RELEASE
16:47:33 <jwb> ;)
16:47:46 <dgilmore> jwb: ++++10000
16:47:49 <nirik> lets get everyone switched to rawhide. ;)
16:47:58 <sgallagh> nirik: Well, we can opt to be more liberal with the FEs as well.
16:48:12 <nirik> but then people have to file, process and ack them...
16:48:28 <jwb> nirik: move to atomic as the model and that becomes much more feasible.  but we're digressing
16:48:31 <jforbes> sgallagh: that is going to put a burden on the people who have to review/ack
16:48:54 <sgallagh> /me nods but notes that he's usually one of those people.
16:48:57 <dgilmore> sgallagh: you realise FE/Blokers is a time consuming manual task
16:49:07 <dgilmore> even with more liberal acceptance
16:49:21 <sgallagh> dgilmore: I am quite aware, yes.
16:49:31 <nirik> so, can we move beta freeze one week later and compress anywhere else?
16:49:32 <jforbes> nirik: keep rawhide, and add a release stream, so there is a place to test more invasive changes first.
16:49:34 <dgilmore> sgallagh: I am telling you I want no part in it.
16:49:39 <mattdm> Since sgallagh is generally very hands-on with that, I'm sure he knows :)
16:49:55 <dgilmore> sgallagh: because its going to fill up a large portion of time, likely 2 days a week
16:50:01 <mattdm> jforbes++
16:50:05 <mattdm> but not for f27 :)
16:50:43 <sgallagh> OK, I am obviously not getting any support for this idea, so let's hear some other ideas.
16:51:05 <dgilmore> sgallagh: you need to ask the teams involved with the FE/blocker process before throwing them under the bus
16:51:13 <nirik> so, how about push beta freeze out a week and drop the beta rain delay one. ;)
16:51:57 <nirik> or... pull one week out between beta release and final freeze
16:52:00 <sgallagh> Whenever we enter Freeze, we're likely to slip. It's practically inevitable if history is any guide.
16:52:39 <dgilmore> sgallagh: I do not think that is true
16:52:39 <nirik> yeah, although if we have more daily compose testing it hopefully becomes less likely over time
16:52:44 <dgilmore> but I do not have numbers
16:53:21 <nirik> one issue is also that sometimes maintainers don't work on the blockers until prodded...
16:53:24 <dgilmore> as we ensure that incoming change is more complete we should reduce the chances of slipping
16:53:36 <dgilmore> nirik: like freeipa for alpha
16:54:52 <nirik> sure. There are other examples tho.
16:55:00 <nirik> anyhow, where are we?
16:55:03 <nirik> in the weeds? :)
16:55:14 <dgilmore> nirik: indeed
16:55:19 <dgilmore> on both counts
16:55:29 <sgallagh> let's at least get agreement on the move of Beta Freeze?
16:55:49 <nirik> proposal: move beta freeze one week later to avoid flock
16:55:49 <sgallagh> Does anyone disagree with the assertion that entering Freeze during or right before Flock is problematic?
16:55:55 <dgilmore> what are the current proposals for beta freeze?
16:56:11 <sgallagh> dgilmore: https://pagure.io/fesco/issue/1681#comment-75536
16:56:35 <dgilmore> sgallagh: having it right after could be problematic also, no one may fix issues the week of flock
16:56:54 <dgilmore> sgallagh: that does not answer the question
16:57:14 <nirik> dgilmore: well, yes,, but we would have the freeze period to fix those...
16:57:16 <dgilmore> sgallagh: there has been a few dates thrown around in the discussion
16:57:24 <dgilmore> I asked for a ummary of them
16:57:35 <sgallagh> dgilmore: The current proposal is nirik's of Sept. 5th
16:57:39 <dgilmore> nirik: sure
16:58:01 <nirik> Move beta freeze from 2017-08-29 to 2017-09-05
16:58:33 <dgilmore> mattdm: flock will be the week of 2017-08-24?
16:59:03 <sgallagh> dgilmore: The final contracts are still being signed, but barring any unlikely show-stoppers, yes.
16:59:29 <jwb> uh
16:59:30 <dgilmore> so the 29th is the tuesday after flook
16:59:33 <jwb> no
16:59:35 <dgilmore> flok
16:59:35 <mattdm> dgilmore, sgallagh Monday Aug 28 - Friday Sept 1, 2017
16:59:38 <dgilmore> gahh
16:59:40 <dgilmore> Flock
16:59:48 <mattdm> flook to foodora!
16:59:49 <jwb> right, flock is the week of Aug 28
16:59:50 <dgilmore> mattdm: okay
17:00:24 <dgilmore> so freezing during flock will not be helpful
17:00:45 <dgilmore> I think nirik's proposal is the right thing to do
17:01:35 <sgallagh> Just to restate it:
17:01:35 <sgallagh> Proposal: Fedora 27 Beta Freeze will occur on September 5th.
17:01:40 <dgilmore> +1
17:01:45 <jforbes> +1
17:01:45 <nirik> +1
17:01:47 <jsmith> +1
17:02:02 <mattdm> ok, pretty clearly the beta dates need to go back a week after that....
17:02:29 <mattdm> so then, how much time between that and final freeze?
17:02:41 <sgallagh> +1
17:02:46 <dgilmore> Beta would be the 19th or perhaps the 26th
17:02:52 <nirik> so we either drop the rain date and make that beta date, or take a week out between final and beta yeah
17:03:03 * nirik is fine with either
17:03:03 <mattdm> right
17:03:18 <dgilmore> me suggests we target Oct 31 for GA
17:03:19 <jsmith> I'm fine with either
17:03:23 <sgallagh> I'd prefer to just cut a week out of the schedule and leave the rain dates in
17:03:28 <mattdm> dgilmore: that's still the target
17:03:39 * mattdm will make a new post with that update
17:03:59 <dgilmore> Final freeze of Oct 10th or 17th
17:04:03 <nirik> and can we move bodhi enable up a week?
17:04:19 <nirik> (I guess that puts it in flock, but still... )
17:04:46 <jforbes> I don't actually see a problem with bodhi enable during flock
17:04:51 <dgilmore> nirik: it does put it in flock. I think that is okay
17:04:59 * mattdm edits
17:05:15 <nirik> yeah, will take a few to enable, but thats not usually that much time.
17:06:26 <mattdm> pagure is being kind of slow
17:06:36 * mattdm twiddles thumbs
17:06:37 * dgilmore got 500 erros from pagure
17:07:21 <Rathann> sgallagh: +1 from me as well
17:07:30 * dgilmore thinks we need to have halloween release 2
17:07:38 <mattdm> ok, so https://pagure.io/fesco/issue/1681#comment-432131
17:07:41 <mattdm> dgilmore++
17:07:41 <zodbot> mattdm: Karma for ausil changed to 9 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:07:54 <sgallagh> #agreed Fedora 27 Beta Freeze will occur on September 5th. (+6, 0, -0)
17:08:27 <nirik> mattdm:  you have bodhi in there twice. :)
17:08:34 <mattdm> nirik: yay!
17:08:36 * mattdm edits again
17:09:22 <mattdm> "could not make edit work"
17:09:25 <mattdm> says pagure :(
17:09:34 <sgallagh> So, the proposed schedule has either two or three weeks between Beta release and Final Freeze. I'm comfortable with that, but is everyone else?
17:09:38 * nirik is trying to think of a better term for 'rain date' but not coming up with much... 'alternate' ?
17:09:49 <jwb> i like rain date
17:09:50 * mattdm will clean up that stuff
17:10:34 <jsmith> My flight is landing, so I'll be losing my internet connection.  I'm making mattdm my proxy for my votes for the rest of the meeting, or at least until I can get back online.
17:10:36 <jforbes> sgallagh: I don't see that as a problem
17:10:52 <nirik> I'm fine with this last draft
17:11:17 <sgallagh> Proposal: FESCo approves https://pagure.io/fesco/issue/1681#comment-432131 as the Fedora 27 schedule
17:11:41 <jsmith> +1 (and then my votes go to mattdm)
17:11:58 <jwb> +1
17:12:00 <sgallagh> +1
17:12:05 <jforbes> +1
17:12:10 <nirik> +1
17:12:23 <Rathann> +1
17:12:25 <nirik> so f26 release on there is one more week than it is now?
17:12:29 <dgilmore> -1
17:12:38 <dgilmore> branching should be at least a week later
17:12:44 <dgilmore> if not two weeks
17:13:37 * nirik looks again.
17:13:51 <dgilmore> I think branching should be 2017-08-15
17:14:01 * nirik also has a call in 15min, so will be less around then.
17:14:04 <dgilmore> thats two weeks before bodhi activation
17:14:24 <sgallagh> dgilmore: Would we move the String Freeze and Change deadline to match?
17:14:32 <Rathann> hm
17:14:41 <nirik> dgilmore: based on the idea that rawhide should be more stableish and we would need less ramp to stablize the branched?
17:14:50 <dgilmore> sgallagh: I think not
17:15:06 <dgilmore> sgallagh: sting freeze is there to enable translations to happen
17:15:06 <mattdm> (is it better for process if I edit or add a new comment?)
17:15:21 <dgilmore> changes will be testable in nightly composes
17:15:26 <Rathann> good point, we had just one week between branch and bodhi activation in F26
17:15:30 <jforbes> dgilmore: but then you are talking about essentially pausing rawhide
17:15:31 <sgallagh> mattdm: As long as it isn't edited after we approve something, I don't think it matters
17:15:54 <dgilmore> jforbes: not pausing
17:15:58 * mattdm is happy to move the branch back
17:16:06 <mattdm> dgilmore: well, what does a string freeze mean then?
17:16:11 <dgilmore> jforbes: we have no real mechanism to enforce string freeze today
17:16:30 <jforbes> Well sure, between string freeze and branch, rawhide has a partial pauce
17:16:33 <jforbes> pause even
17:16:37 <mattdm> it's more of a guideline than actual rules? :)
17:16:41 <sgallagh> The advantage to moving the branch later is that there's less duplication of effort. The disadvantage is that people who want to move on to starting stuff for the next release must wait longer.
17:16:45 <dgilmore> mattdm: its supposed to be when anaconda, comps, gnome, etc strings become unchangeable
17:16:56 <mattdm> dgilmore: I think at the branch makes sense for that
17:17:10 <dgilmore> we have not attempted to strongly enforce string freeze in 6 or 7 years
17:17:49 <jforbes> dgilmore: right, so why not just keep it concurrent with branching so that it is much easier to follow?
17:18:30 <mattdm> and same argument for change checkpoint, i think
17:18:31 <dgilmore> jforbes: well we have 2017-08-22
17:18:32 <dgilmore> Software Translation Deadline
17:18:57 <dgilmore> there is 3 weeks for the software we care about to be translated and have the translations pulle din
17:19:00 <dgilmore> pulled in
17:19:57 <mattdm> proposal -- let's leave that penciled in and get input from the translation team on how much time they need
17:21:12 <dgilmore> mattdm: sure.
17:21:22 <mattdm> what about the change checkpoint?
17:21:38 <mattdm> (and if we push that back, should we also push back the self-contained changes deadline?)
17:21:42 <dgilmore> mattdm: the earlier changes are submitted the better
17:21:43 <mattdm> (sorry to reopen all of that)
17:21:53 <mattdm> ok. so, leave the deadline?
17:22:06 <dgilmore> I think so yes
17:22:11 <mattdm> I guess having the checkpoint earlier is ok too
17:22:24 <dgilmore> after a cycle or two we can evaluate if we need to make changes
17:22:37 <mattdm> definitely
17:22:37 <sgallagh> I agree with keeping the change timeline where it is
17:23:04 <mattdm> ok, so, now, previously almost-voted-on schedule with everything the same but the branch pushed back by two weeks
17:23:06 <mattdm> https://pagure.io/fesco/issue/1681#comment-432135
17:23:38 <dgilmore> +1
17:23:41 <Rathann> ok, +1
17:23:51 <mattdm> +1, wielding jsmith's proxy
17:23:58 <nirik> +1
17:24:55 <sgallagh> +1
17:24:56 <jforbes> +1ish
17:25:03 <sgallagh> jforbes: "ish"?
17:26:15 <jwb> +1
17:26:19 <jforbes> I still don't like the idea of a string freeze sitting on rawhide. In my mind it makes more sense to push the translation deadline forward than to have a freeze on rawhide.  But it isn't enough of an issue to vote against it
17:27:13 <sgallagh> ok
17:27:22 <sgallagh> #agreed FESCo approves https://pagure.io/fesco/issue/1681#comment-432135 as the Fedora 27 schedule (+7, 0, -0)
17:27:37 <mattdm> does someone want to volunteer to talk to translations?
17:28:44 * mattdm will send that messasge then :)
17:28:49 * nirik has to run to call....
17:28:51 <sgallagh> thanks
17:28:53 <sgallagh> #topic #1688 Incomplete (non testable) Changes of F26
17:28:54 <sgallagh> .fesco 1688
17:28:56 <zodbot> sgallagh: Issue #1688: Incomplete (non testable) Changes of F26 - fesco - Pagure - https://pagure.io/fesco/issue/1688
17:29:46 <sgallagh> I asked mkolman to join us to discuss the TRIM support one, because they have a patch ready now but since we are in Freeze...
17:30:31 <sgallagh> (I don't know if he's actually sitting at his keyboard, though)
17:30:49 <mkolman> I'm actually not working on that change
17:31:04 <mkolman> I suggest asking dlehman to join
17:31:22 <sgallagh> Ah, sorry.
17:31:31 <mkolman> np :)
17:31:54 <sgallagh> Well, the crux of the question is whether FESCo wants to do what we did with Python last week and authorize it in late or ask them to defer it.
17:33:09 <sgallagh> I've pinged dlehman, so let's discuss other BZs while we wait to see if he is around.
17:33:17 <sgallagh> #link https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&bug_status=POST&classification=Fedora&list_id=7192328&product=Fedora&query_format=advanced&status_whiteboard=ChangeAcceptedF26&status_whiteboard_type=allwordssubstr&version=26
17:33:59 <sgallagh> A couple of these are obviously complete and just haven't been updated:
17:34:44 <sgallagh> GCC and the compilation flags, for example
17:35:48 <sgallagh> /me wonders if anyone else is still here.
17:36:18 <sgallagh> #info The two RPM debuginfo ones didn't make the cut and are deferred
17:36:28 <sgallagh> (courtesy of mjw)
17:37:08 <jforbes> The trim issue has installer changes, seems a little late?
17:37:17 <sgallagh> jforbes: That was my concern as well.
17:37:20 <jforbes> The gcc is clearly there
17:37:36 <sgallagh> #info GCC and compiler flag changes are sufficiently testable
17:38:28 <sgallagh> The modular compose is running a little late, but it's non-blocking so I think we're okay to let it slide
17:39:02 <dgilmore> the minimal container change is done
17:39:17 <sgallagh> #info minimal container image change is testable
17:39:33 <sgallagh> NM 1.8 isn't built, so we'll defer that.
17:39:51 <sgallagh> #info Network Manager 1.8 has not yet been built in Fedora. Deferring to F27.
17:40:04 <sgallagh> Anyone know the status of FMW?
17:41:18 <Rathann> sgallagh: it was testable at least last week
17:41:22 <dgilmore> sgallagh: not heard anything this week
17:41:35 <Rathann> I remember asking the change owner and he confirmed it
17:41:39 <sgallagh> Thanks
17:41:39 <dgilmore> it was testable in test builds
17:41:45 <dlehman> too late to talk about bug 1421596?
17:41:56 <dgilmore> I neever got a ticket to do signed builds
17:42:39 <sgallagh> .bug 1421596
17:42:39 <zodbot> sgallagh: Bug 1421596 – Enable TRIM pass down to encrypted disks - https://bugzilla.redhat.com/1421596
17:42:47 <dgilmore> dlehman: no.
17:42:47 <sgallagh> dlehman: Not too late
17:43:02 <sgallagh> We postponed discussion to see if you'd turn up
17:43:29 <sgallagh> #info ARM support in FMW is testable
17:43:30 * dlehman has to go in a couple of minutes
17:43:39 <dlehman> I proposed that bug as a FreezeException. I'm planning to do a build w/ a few patches to address other exception bugs for alpha;
17:43:55 <sgallagh> dlehman: So our main concern is dropping new storage features into the installer during Freeze
17:44:13 <sgallagh> The risk of causing a slip seems like it might be fairly high.
17:44:57 <dlehman> Right. However much it helps, that's why I'm doing an ad-hoc patch instead of an upstream release.
17:45:01 * dlehman looks at the patch itself
17:45:55 <dlehman> the whole patch is +37 -0 including unit tests
17:46:19 <dlehman> (unit tests accounting for at least two-thirds of the code
17:46:27 <dlehman> https://github.com/rhinstaller/blivet/pull/550/files
17:46:44 <sgallagh> dlehman: As you are the expert: how confident are you that these changes wouldn't regress our other storage functionality?
17:48:32 <sgallagh> OK, reading that, it looks pretty low-risk to me.
17:49:19 <sgallagh> dlehman: That adds "discard" unconditionally for all LUKS setups?
17:49:37 <dlehman> all LUKS setups created during installation
17:49:47 <sgallagh> Does that have any impact on spinning rust drives?
17:50:00 <dlehman> Not sure TBH.
17:50:13 <sgallagh> That does not inspire great confidence :)
17:50:15 <Rathann> in the e-mail thread it was said to be negligible
17:50:26 <Rathann> I remember asking about some numbers
17:51:08 <sgallagh> Rathann: Did you get them?
17:51:12 <dlehman> Yeah, I assumed that was decided before embarking on this part of the work.
17:51:43 <Rathann> no
17:53:09 <sgallagh> dlehman: How upset would you be if we asked you to defer this to F27 at this point?
17:53:25 <dlehman> Personally? Not at all.
17:53:55 * nirik is now back
17:54:41 <sgallagh> Proposal: FESCo defers the LUKS TRIM support in Anaconda to Fedora 27
17:54:59 <jforbes> +1
17:55:18 <jwb> +1
17:55:30 <sgallagh> I'm a very weak +1. I think it would benefit SSD users, but since we don't have guarantees about the impact on non-SSD systems, I think we should wait
17:55:45 <dlehman> As long as everyone notes this effectively disables Changes/EnableTrimOnDmCrypt by default
17:56:19 <sgallagh> dlehman: Yes, we understand that. I'd encourage you to land it in Rawhide ASAP, of course.
17:56:33 <jforbes> sgallagh: SSD users can always enable it after the fact
17:56:34 <nirik> +1
17:56:42 <sgallagh> jforbes: Also true
17:56:43 <dlehman> blivet did add some tags to drive objects that includes 'ssd' but I wouldn't want to try to hook that up w/ this code in a rush at this point
17:57:19 * mattdm thinks "How to enable trim on your SSD drive" would be a good Fedora Magazine article
17:57:23 <Rathann> +1, though I'm with sgallagh on this one
17:57:23 <mattdm> #help "How to enable trim on your SSD drive" would be a good Fedora Magazine article
17:57:30 <dlehman> yeah, good idea
17:58:14 <sgallagh> https://blog.christophersmart.com/2016/05/12/trim-on-lvm-on-luks-on-ssd-revisited/ is a good resource, FWIW
17:59:16 <sgallagh> #agreed FESCo defers the LUKS TRIM support in Anaconda to Fedora 27 (+5, 0, -0)
17:59:35 <dlehman> noted -- thanks, everyone
17:59:37 <sgallagh> OK, I *think* we've covered all of these now.
17:59:47 <sgallagh> dlehman: Thank you for coming and discussing it with us
18:00:10 <dgilmore> thanks dlehman
18:00:38 <sgallagh> As we're running long, shall we defer the self-contained changes discussion for today and just cover the two time-sensitive issues under New Business? (Unresponsive maintainer and my ProvenPackager request)?
18:01:21 <dgilmore> sgallagh: what are the self contained changes?
18:01:30 <sgallagh> #topic #1690 F27 Self Contained Changes
18:01:30 <sgallagh> .fesco 1690
18:01:33 <zodbot> sgallagh: Issue #1690: F27 Self Contained Changes - fesco - Pagure - https://pagure.io/fesco/issue/1690
18:01:52 <sgallagh> Bodhi non-RPM artifacts and Noarch erlang
18:01:55 <dgilmore> +1 to both
18:02:04 <sgallagh> +1 to both
18:02:12 <sgallagh> (I suppose neither of these are controversial)
18:02:14 <jforbes> +1 to both here too
18:02:34 * mattdm isn't going to use jsmith's proxy unless we need to have another +1 for some reason
18:02:35 <nirik> +1
18:02:38 <nirik> +1
18:03:09 <jwb> +1
18:03:24 <sgallagh> #agreed Bodhi non-RPM artifacts and Noarch erlang are both accepted for Fedora 27 (+5, 0 ,-0)
18:03:24 <sgallagh> (counting nirik only once)
18:03:31 <Rathann> +1
18:03:35 <sgallagh> #undo
18:03:35 <zodbot> Removing item from minutes: AGREED by sgallagh at 18:03:24 : Bodhi non-RPM artifacts and Noarch erlang are both accepted for Fedora 27 (+5, 0 ,-0)
18:03:38 <sgallagh> #agreed Bodhi non-RPM artifacts and Noarch erlang are both accepted for Fedora 27 (+6, 0 ,-0)
18:03:51 <sgallagh> #topic #1691 Unresponsive maintainer: jpo
18:03:51 <sgallagh> .fesco 1691
18:03:52 <zodbot> sgallagh: Issue #1691: Unresponsive maintainer: jpo - fesco - Pagure - https://pagure.io/fesco/issue/1691
18:04:14 <sgallagh> proposal: Orphan jpo's packages
18:04:15 <sgallagh> +1
18:04:27 <dgilmore> +1
18:04:37 <dgilmore> though it sounds like they need retired
18:04:54 <Rathann> hm, he's POC of many other packages
18:04:55 <dgilmore> at least the ones listed in the issue
18:05:26 <nirik> 31 packages poc
18:05:40 <jforbes> Right, the real issue is that those need to be retired, and he hasn't done so.  Orphaning other packages may or may not be the right thing to do
18:05:51 <dgilmore> proposal: retire perl-ZeroMQ perl-ZMQ-LibZMQ2 perl-ZMQ-LibZMQ3 and orphan the rest of jpo's packages
18:06:18 <nirik> sure, although the reporter offered to do the retiring. ;)
18:06:23 <nirik> +1 in any case
18:06:28 <jforbes> +1
18:06:31 <Rathann> ok, +1
18:06:37 <sgallagh> Which are we +1ing right now?
18:06:53 <sgallagh> I'm +1 to either mine or dgilmore's proposal
18:07:10 <jforbes> I think the end result is the same either way since reporter offered to retire them if orphaned
18:07:19 <nirik> I'm +1 to either, but prefer orphan them all and let the reporter of the ticket retire... since it's less work for... probibly me.
18:07:25 <sgallagh> Yes, but I have to put something in the notes :)
18:07:46 <jforbes> nirik: makes a good point
18:07:51 <jforbes> +1 sgallagh
18:07:54 <dgilmore> nirik: we just need to make sure they get retired
18:09:25 <dgilmore> i do not think either is that different
18:09:36 <dgilmore> we can let the reporter do the retiring
18:09:42 <dgilmore> we just need to verify its done
18:09:53 <sgallagh> ok
18:10:24 <sgallagh> #agreed Orphan jpo's packages and ensure that perl-ZeroMQ perl-ZMQ-LibZMQ2 perl-ZMQ-LibZMQ3 are retired (+5, 0, -0)
18:10:33 <sgallagh> nirik: Would you do the honors?
18:10:44 <nirik> sure.
18:10:47 <sgallagh> Thanks
18:10:55 <sgallagh> #action nirik to perform the orphaning
18:10:59 <sgallagh> #topic #1692 Requesting provenpackager permission to address
18:10:59 <sgallagh> -Werror=format-security issues
18:10:59 <sgallagh> .fesco 1692
18:11:00 <zodbot> sgallagh: Issue #1692: Requesting provenpackager permission to address -Werror=format-security issues - fesco - Pagure - https://pagure.io/fesco/issue/1692
18:11:50 <jforbes> +1
18:11:56 <Rathann> I'm surprised you don't already have pp status
18:11:57 <Rathann> +1
18:12:12 <sgallagh> Rathann: I do
18:12:42 <sgallagh> It's specifically about being able to just make these simple changes without dealing with mass bug filing and all the extra bureaucracy
18:12:47 <nirik> This is weird to me, since I thought we turned that flag on a long time ago... but sure +1 to just patch/fix.
18:12:51 <dgilmore> sgallagh: its not clear to me who you are requesting proven packager for
18:13:17 <dgilmore> sgallagh: yourself or psabata
18:13:24 <sgallagh> dgilmore: I'm asking for a decision we can point at if anyone complains that we edited their package without talking to them.
18:13:29 <Rathann> hm psabate has pp status too
18:13:40 <Rathann> *psabata
18:13:41 <sgallagh> For this *specific* set of fixes.
18:13:52 <dgilmore> sgallagh: huh
18:13:53 <sgallagh> I'm not asking for new pp status for anyone
18:14:08 <sgallagh> I'm asking permission in advance to deal with possibly dozens of packages to fix this issue.
18:14:11 <misc> so, wouldn't each case where it doesn't build also requires a CVE ?
18:14:21 <dgilmore> sgallagh: I read the request as asking for proven packager permission for someone
18:14:29 <sgallagh> dgilmore: Poor phrasing on my part, sorry.
18:14:40 <Rathann> sgallagh: do you really need a FESCo decision? I thought fixing FTBFS where the fix is obvious doesn't need approval from FESCo, especially if you are a pp
18:14:43 <dgilmore> I am -1 to approving a unclear poorly worded request
18:14:44 <nirik> misc: depends.
18:14:53 <sgallagh> misc: Not necessarily.
18:15:19 <Rathann> right, -1 from me in this case
18:15:23 <sgallagh> dgilmore: "I am asking permission from FESCo to authorize that myself and Petr Šabata ( @contyk) may use our provenpackager permissions to apply patches to these packages without waiting for maintainer correspondence."
18:15:40 <sgallagh> The subject line is poorly worded, but I thought the request in the body was reasonably clear.
18:15:44 <dgilmore> sgallagh: that does not need FESCo approval
18:15:52 <Rathann> exactly
18:16:17 <jforbes> It technically does not, but I see where he is coming from
18:16:42 <sgallagh> dgilmore: Clearly many of our packagers do not understand this, because I am constantly berated by them for touching their packages, even for little stuff like this.
18:17:05 <sgallagh> So I am filing this bug to point at and say "go complain to them and let me get my damn work done"
18:17:20 <dgilmore> sgallagh: point them at the policy
18:17:45 <sgallagh> dgilmore: Everyone believes they are special and it doesn't apply to *their* package.
18:17:52 <dgilmore> sgallagh: I have seen that doing alternative arch work as well
18:18:05 <dgilmore> sgallagh: I get where you are coming from.
18:19:07 <dgilmore> I just don't want to set some precident where everyone asks fesco to sign off on their work
18:19:15 <dgilmore> and that may be taking it too far
18:19:40 <dgilmore> I think that everything is already covered
18:19:46 <Rathann> I consider this case to be: https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages#Minor.2C_general_or_cleanup_changes
18:20:01 <Rathann> so, announce if not done already and fire away
18:20:05 <dgilmore> sgallagh: I would suggest that you send an email to devel-announce explaining what happened and what you are doing and be done with that
18:20:28 <sgallagh> Very well
18:20:46 <sgallagh> #action sgallagh will send an announcement to devel-announce and just go to work.
18:21:21 <sgallagh> #topic Next week's chair
18:21:46 <Rathann> I have to drop off now, guys
18:21:57 <Rathann> thanks for chairing, sgallagh
18:22:00 <Rathann> bye
18:22:37 <sgallagh> Who wants this delightful duty next week?
18:22:47 <dgilmore> I guess I can
18:23:00 <sgallagh> #info dgilmore to chair 2017-03-24 meeting
18:23:02 <sgallagh> Thanks dgilmore
18:23:07 <sgallagh> #topic Open Floor
18:24:33 <sgallagh> Anyone?
18:24:37 <sgallagh> Yeah, me neither.
18:24:51 <sgallagh> #endmeeting