15:01:14 <jsmith> #startmeeting FESCO (2018-03-16)
15:01:14 <zodbot> Meeting started Fri Mar 16 15:01:14 2018 UTC.  The chair is jsmith. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:14 <zodbot> The meeting name has been set to 'fesco_(2018-03-16)'
15:01:14 <jsmith> #meetingname fesco
15:01:14 <zodbot> The meeting name has been set to 'fesco'
15:01:14 <jsmith> #chair maxamillion dgilmore nirik jsmith sgallagh bowlofeggs tyll jwb zbyszek
15:01:14 <jsmith> #topic init process
15:01:14 <zodbot> Current chairs: bowlofeggs dgilmore jsmith jwb maxamillion nirik sgallagh tyll zbyszek
15:01:16 <bowlofeggs> .hello2
15:01:17 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:01:19 <jsmith> .hello2
15:01:20 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
15:01:24 <nirik> morning
15:01:25 <zbyszek> .hello2
15:01:26 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:01:39 <maxamillion> .hello2
15:01:39 <sgallagh> .hello2
15:01:40 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:01:43 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:02:08 <jsmith> Yay, we have a quorum.
15:02:11 <jwb> hello again
15:02:20 <tyll> .hello till
15:02:21 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
15:02:31 <jsmith> Let's gets started, as I have a hard stop at 16:00 UTC (one hour from now), and someone else may have to finish the meeting for me.
15:02:37 <bowlofeggs> we should start a quorum forum where we discuss quorum
15:02:47 <jsmith> #topic #1745 F28 System Wide Change: Switch OpenLDAP from NSS to OpenSSL
15:02:47 <jsmith> .fesco 1745
15:02:47 <jsmith> https://pagure.io/fesco/issue/1745
15:02:49 <zodbot> jsmith: Issue #1745: F28 System Wide Change: Switch OpenLDAP from NSS to OpenSSL - fesco - Pagure - https://pagure.io/fesco/issue/1745
15:03:03 <zbyszek> Is there anything to discuss here?
15:03:28 <sgallagh> This was approved last week
15:03:28 <bowlofeggs> we approved this last week right?
15:03:29 <jsmith> I don't think so -- but it still had the meeting tag, so I  wanted to make sure.
15:03:30 <sgallagh> Let's move on
15:03:35 <jsmith> #agreed move on
15:03:48 <jsmith> #topic #1820 Adjust/Drop/Document batched updates policy
15:03:48 <jsmith> .fesco 1820
15:03:48 <jsmith> https://pagure.io/fesco/issue/1820
15:03:52 <zodbot> jsmith: Issue #1820: Adjust/Drop/Document batched updates policy - fesco - Pagure - https://pagure.io/fesco/issue/1820
15:03:55 <bowlofeggs> oh my
15:03:59 <bowlofeggs> haha
15:04:17 <bowlofeggs> i participated a bit too much in debate in this one
15:04:42 * nirik was hoping to get some time to think more on this, but it's just been really busy. ;(
15:04:48 <zbyszek> Same here
15:05:04 <zbyszek> I'm slowly starting to lean against, but I haven't had time to investigate...
15:05:11 <sgallagh> zbyszek: Why?
15:05:32 <bowlofeggs> i think the experiment week did show value in it
15:06:28 <orc_fedo> lots of heat there, but not much light -- it seems possible to ship two sets of config files, 1) for security at once and the rest on a Patch tuesday; and 2)  as they get promoted, and then default to one, but also permit the end comsumer to choose enable one or the other?
15:06:42 <zbyszek> Ideally, we would have efficient meta-data delivery and batching on the lcient side. So batching on the server side is just a stop-gap measure. And it's not really saving that much server resources, and it's consuming noticable *human* resources.
15:07:15 <zbyszek> All in all, I was hoping it'd have much clearer effects than it does right now.
15:08:04 <sgallagh> zbyszek: I'll reiterate that the effects are made unclear by the fact that batched isn't enforced (and made clear when it should be bypassed)
15:08:05 <nirik> so I think I asked last time, but don't know if I saw an answer... if you use pkcon command line can you use the same batching as gnome-software does for updates? or that will get you the dnf behavior...
15:08:06 <jsmith> Whether we batch on the client side or the server side (and I too am starting to lean client-side), I think we need a better-documented plan
15:08:17 <sgallagh> So people are just skipping it
15:08:18 <kalev> nirik: that will get you dnf behaviour
15:08:40 <nirik> kalev: ok
15:08:44 <kalev> gnome-software has its own scheduler that drives packagekit
15:09:25 <kalev> with my gnome-software developer hat on, I'd much prefer having distro side batching than client side, because that enables testing
15:09:48 <kalev> with distro side batching it would be possible to test the batch before pushing it out every week; with client side batching it is not
15:09:57 <nirik> yeah, we were going to ask qa about that, did anyone? ;) perhaps we should action someone today to do so
15:10:11 <bowlofeggs> client side batching won't have the drpm benefits that server-side batching has, and it also won't have the (potential) QA benefits
15:10:13 <nirik> sure, but we aren't currently and it's unclear if we will
15:10:37 <jsmith> Exactly my point -- until we have a better (and more documented) plan in place, we're just thrashing
15:10:46 <maxamillion> jsmith: +1
15:10:58 <bowlofeggs> the drpm benefit was pretty evident to me too though
15:11:00 <sgallagh> There's also a perception issue to consider
15:11:05 <tyll> kalev: we can still test the update set when it is on the client side, just test the packages that you would update on the client side according to the default configuration
15:11:18 <sgallagh> People look at Fedora's updates and interpret it as "churn" (deserved or not)
15:11:21 <zbyszek> tyll: exactly!
15:11:27 <kalev> tyll: sure, but then _I_ have to test it, not someone else (Fedora QA)
15:11:55 <kalev> if it's server side batching, then we can gather rpms-to-be-pushed out, test that they work together, and only then push them out
15:12:05 <sgallagh> I have spoken to people at conferences and such that avoid Fedora specifically because they are concerned that so many updates makes it hard to keep track of what they are getting
15:12:07 <kalev> if it's client side it's still random firehose
15:12:10 <jsmith> But again, if Fedora QA isn't testing it either...
15:12:31 <kalev> how does Atomic solve this problem? They have 2 week releases where they test stuff before putting them out.
15:12:39 <bowlofeggs> almost all updates are also not important
15:12:46 <jwb> i think we're focusing on the wrong problem
15:12:53 <nirik> depending on tests we could also in theory just test all updates every time we push no?
15:12:55 <tyll> kalev: are you talking about manual or automated tests?
15:13:00 <jsmith> So, I'm going to make a proposal -- maybe slightly controversial, but I want to try to move us forward, as we have a long agenda today.
15:13:01 <kalev> tyll: both
15:13:35 <tyll> kalev: but with batched there is no time for manual tests. the package set is determined at the time of the push
15:13:41 <nirik> jsmith: how about we punt another week and someone agrees to talk to qa about this and get their feedback?
15:13:43 <jsmith> Proposal: Don't enforce batching (but still encourage developers to batch non-urgent/security updates) until there's a more formal process and plan in place.
15:14:00 <maxamillion> jsmith: +1
15:14:06 <zbyszek> jsmith: +1
15:14:07 <jsmith> nirik: I like that, but I think we need more than just a discuss with QA.
15:14:09 <nirik> sure, +1 in absense of a actual plan.
15:14:10 <zbyszek> nirik: +1
15:14:11 <sgallagh> jsmith: -1
15:14:17 <tyll> jsmith: +1
15:14:18 <jsmith> We need someone to take point, make a plan, documented it, etc.
15:14:22 <bowlofeggs> we've punted this every week for a long time
15:14:22 <sgallagh> If it's not enforced, batched is entirely usesless
15:14:27 <nirik> right.
15:14:32 <jsmith> In the absence of someone stepping up, we're just thrashing
15:14:33 <kalev> tyll: sure, but that's just the current implementation. it doesn't have to be like that. I could outline an idea I've had for a while if you guys are willing to listen a few minutes while I type it out
15:14:38 <jwb> -1
15:15:04 <kalev> I'll just talk until someone tells me to stop :)
15:15:10 <jsmith> kalev: Sure, I'm willing to listen.  Would it make sense to come back with it written up next week?
15:15:24 <tyll> kalev: or add it to the ticket?
15:15:34 <kalev> sure, I can do that
15:15:37 <jsmith> We've spent almost fifteen minutes on this already, and we've got a long agenda today (and I have a hard stop)
15:15:42 <jsmith> kalev: Thanks :-)
15:15:46 <kalev> thanks :)
15:15:50 <jwb> i think we need to step back and actually figure out what problem(s) we're trying to solve
15:16:14 <jsmith> jwb: I agree...
15:16:31 * nirik nods.
15:16:43 <jsmith> Can we all agree to kick the can down the road another week, but keep the discussion going in the ticket and on the mailing list?
15:16:53 <jsmith> (and not just wait until next week's meeting to pick it up again?)
15:17:08 <zbyszek> Yes.
15:17:17 <zbyszek> Who'll ask QA?
15:17:19 <jsmith> Proposal: Discuss on the ticket and mailing list this week.  Try to identify concrete goals and concrete plans to get us there.
15:17:34 <bowlofeggs> #action bowlofeggs will talk to QA about batching
15:17:41 <zbyszek> bowlofeggs++
15:17:41 <zodbot> zbyszek: Karma for bowlofeggs changed to 14 (for the f27 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:17:49 <jsmith> Thanks bowlofeggs
15:18:08 <zbyszek> jsmith: +1 to the latest proposal too
15:18:41 <bowlofeggs> i'm +0 because i think the discussion is now circular
15:18:44 <jsmith> #action kalev to share his ideas on batching in the ticket
15:18:53 <bowlofeggs> but i'm not opposed
15:19:10 <jsmith> I'm open to alternative proposals, but we need to move on
15:19:22 * zbyszek thinks that it's been a very busy period, too busy for people to have time to think about this
15:19:31 <bowlofeggs> alright, +1
15:19:32 <bowlofeggs> haha
15:19:51 <jsmith> That makes us +3 on the latest proposal...
15:20:09 <jwb> it's a non-proposal
15:20:25 <jwb> there's no need to vote to simply continue doing what we've already done
15:20:51 <jsmith> Fine, let's move on then...
15:20:58 <zbyszek> Ack.
15:21:15 <jsmith> #agreed Continue the discussion on the mailing list and ticket this week.  Try to identify concrete goals and concrete plans to get us there.
15:21:33 <jsmith> #topic #1853 F29 System Wide Change: Enable dbus-broker
15:21:33 <jsmith> .fesco 1853
15:21:33 <jsmith> https://pagure.io/fesco/issue/1853
15:21:40 <maxamillion> +1
15:21:47 <zodbot> jsmith: Issue #1853: F29 System Wide Change: Enable dbus-broker - fesco - Pagure - https://pagure.io/fesco/issue/1853
15:22:08 <nirik> +1 (still have a todo to test this here)
15:22:16 <bowlofeggs> +1
15:22:21 * zbyszek is running with dbus-broker and it seems all good
15:22:24 <zbyszek> +1
15:22:33 <jsmith> I wasn't clear before whether this was just "enable" or make it the default, but to be clear, this is about making it the default in F29
15:22:56 <zbyszek> Yes, the change page has been renamed, it's just the fesco ticket that hasn't.
15:23:05 <jsmith> I'm running with it as well, and haven't encountered any issues so far
15:23:21 <sgallagh> Seems okay to me, but I'd like to have the Proposal Owners add "coordinate with FreeIPA" to make sure they don't break the custodia/oddjob/SSSD-infopipe stuff
15:23:40 <sgallagh> Because we get enough blockers from FreeIPA already, thankyouverymuch ;-)
15:23:59 <jsmith> sgallagh: +1 to that :-)
15:24:26 <zbyszek> Is FreeIPA even working right now?
15:24:28 <sgallagh> With that added to the testing section, I'd be +1.
15:24:33 <sgallagh> zbyszek: nope! :-P
15:25:13 <jsmith> Proposal: Accept the dbus-broker change for F29, with the caveat that the team should coordinate with FreeIP to ensure they don't break custodia/oddjob/SSSD-info pipe stuff
15:25:32 <bowlofeggs> +1
15:25:56 <jsmith> (and for the record, it is fairly easy to test)
15:26:07 <maxamillion> wait
15:26:21 <maxamillion> FreeIPA doesn't work right now, but we're going to block on a new feature to make sure it doesn't break FreeIPA?
15:26:29 <maxamillion> wat
15:26:33 <sgallagh> maxamillion: FreeIPA is a blocking feature of Server
15:26:39 <sgallagh> We won't ship Beta or GA without fixing it
15:26:53 <sgallagh> I'm asking that we make sure we deal with potential blockers early on
15:26:58 <bowlofeggs> we're more just asking them to communicate with/consider freeipa
15:26:59 <jsmith> I think we can safely assume that we'll get FreeIPA working before F29, though, right?
15:27:12 <jsmith> We're talking about an F29 change here...
15:27:13 <sgallagh> jsmith: We can't ship F28 without it working, so that's a safe bet
15:27:14 <nirik> last I read they had a proposed set of updates that was working... so hopefully it will be working very soon.
15:27:22 <maxamillion> alright
15:27:40 <maxamillion> +1 to jsmith's proposal
15:27:46 <sgallagh> jsmith: +1
15:28:53 <nirik> still +1 to the change
15:29:12 <jsmith> jwb, tyll, zbyszek?
15:29:27 <zbyszek> What exactly does it mean "don't break ... stuff"?
15:29:31 <jwb> i voted on this in the ticket
15:29:53 <jsmith> jwb: Right, thanks for the reminder :-)
15:30:06 <tyll> jsmith: +1
15:30:10 <zbyszek> If the new implementation is correct according to standard, but freeipa breaks for some odd reasons, who is to blame?
15:30:27 <bowlofeggs> do we need to blame?
15:30:30 <sgallagh> zbyszek: I asked for coordination
15:30:45 <sgallagh> So they test this early and can work out how to fix it on whichever side needs to
15:30:46 <jsmith> Can't we assume positive intent, and simply ask that they coordinate if and when there is an issue?
15:31:02 <zbyszek> OK, so +1 to jsmith
15:31:13 <tyll> jsmith++
15:31:13 <zodbot> tyll: Karma for jsmith changed to 8 (for the f27 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:31:41 <jsmith> #agreed (+1:7,+0:0,-1:0) Accept the dbus-broker change for F29, with the caveat that the team should coordinate with FreeIP to ensure they don't break custodia/oddjob/SSSD-info pipe stuff
15:31:49 <zbyszek> FTR, I assume positive intent, but I have similar doubts as maxamillion
15:31:58 <jsmith> #topic  #1858 Proposed Fedora 29 schedule
15:31:58 <sgallagh> zbyszek: In short, I just want to highlight a use-case they may not have considered that we know has a high potential for schedule impact
15:31:58 <jsmith> .fesco 1858
15:31:58 <jsmith> https://pagure.io/fesco/issue/1858
15:32:00 <zodbot> jsmith: Issue #1858: Proposed Fedora 29 schedule - fesco - Pagure - https://pagure.io/fesco/issue/1858
15:32:35 <sgallagh> I'm generally good with it, but I was wondering one additional thing:
15:32:49 <jsmith> Didn't get much feedback on this item this week -- do we want to add "infra freeze" to the schedule itself?
15:32:55 <sgallagh> We've had a lot of problems in the last several releases with Wallpapers not getting delivered in time for Beta/GA
15:33:15 <sgallagh> Should we add an earlier deadline for those, and if so how do we encourage/enforce it?
15:33:17 <nirik> well, thats not typically been part of the official schedule...
15:33:36 <bowlofeggs> i don't think infra freeze needs to be on the official schedule
15:33:40 <nirik> it's been something infrastructure does. I guess we could add it, or just leave it to infra?
15:33:45 <bowlofeggs> it mostly just affects infra members
15:33:54 <bowlofeggs> i think leave it to infra
15:33:57 * sgallagh is in favor of leaving that to infra
15:34:08 <jsmith> Proposal: Accent the schedule as-is
15:34:10 <zbyszek> sounds fine to me
15:34:13 <zbyszek> jsmith: +1
15:34:16 <bowlofeggs> +1 to accept as is
15:34:33 <sgallagh> jsmith: Cockney or Elizabethan?
15:34:41 <sgallagh> +1 to accept as-is
15:34:52 <jwb> -1
15:34:57 <sgallagh> jwb: ?
15:35:02 <jsmith> sgallagh: Only if you do Cockney Rhyming Slang :-)
15:35:06 <jwb> i want the infra freeze added
15:35:32 <pingou> jwb: what do you think it brings/
15:35:34 <pingou> ?
15:35:58 <jwb> it typically impacts only infra, but it also is a key point where any required infra changes have to be made by.  if there are infra changes required for something landing in a release, people should see that date in the schedule
15:36:12 <nirik> I guess I don't care too much either way...
15:36:31 <jwb> plus, it was important enough to defer this an entire week which means i think it's important enough to add
15:37:02 <nirik> yeah, I'm not sure why we did that, but ok.
15:37:10 <bowlofeggs> jwb: the people who need to make those changes know the infra schedule though imo
15:37:16 <bowlofeggs> since they are usually infra members
15:37:19 <maxamillion> +1 to schedule
15:37:33 <jsmith> To be honest, I'm more worried about rel-eng changes than infra changes...
15:37:40 <sgallagh> bowlofeggs: In fairness "cargo cult knowledge" is a justification, not a reason ;-)
15:37:41 <bowlofeggs> that said, i don't see harm in including infra on the schedule, but i don't see a need for it either
15:37:42 <nirik> My only concern would be that it means more pain if infra decides to move/change things... ie, consult fesco, get schedule changed, but we could do that
15:38:10 <jsmith> nirik: I trust the existing infra freeze exception process
15:38:13 <jwb> bowlofeggs, the people that *don't* know about it but would require something from infra are who i'm worried about
15:38:20 <jsmith> nirik: No need to get FESCo involved in that, I don't think
15:38:44 <nirik> jsmith: but if it's in the schedule, it would need fesco approval, no?
15:39:06 <jsmith> nirik: That's exactly my point -- I think we have an existing process for dealing with things that show up late.  No need to get FESCo involved.
15:39:07 <jwb> i voted -1 and explained why.  if nobody else agrees with me, record my vote and move on.  this is not something we should debate for another 20min
15:39:28 * jsmith counts votes quickly
15:39:30 <bowlofeggs> yeah i don't think we have to be unanimous
15:39:44 <jwb> nirik, no.  freeze exceptions don't need fesco involvement.  i just want the date on the schedule per release
15:39:47 <bowlofeggs> i'm not against putting infra on this schedule but i'd prefer to leave it to infra
15:39:53 <nirik> note also, that the freeze starts when the freeze email goes out... which isn't a time to put in a schedule, but I guess could just say that
15:40:03 <nirik> no, not freeze exceptions.
15:40:22 <nirik> I am saying if we decide to not freeze until... friday of the week of freeze, we would have to get that changed on the schedule
15:40:42 <jsmith> (If I'm counting correctly, we're at +4, -1)
15:41:37 <tyll> aren't infra freezes dependent on Beta/Final freeze anyhow?
15:41:45 <jsmith> jwb: So if I'm understand you correctly -- you just want the information about the infra freeze in the announcement, but no change in policy/procedure?
15:41:46 <tyll> I thought they always start together
15:41:54 <bowlofeggs> tyll: they are related but not identical
15:42:03 <jsmith> tyll: They used to be when I was FPL.  Not sure if that's still the case
15:42:13 * nirik isn't sure he voted, but +1... either with or without noting the infra freeze
15:42:32 <bowlofeggs> tyll: the freeze starts/ends when nirik e-mails us, which is usually near the releng package freezes on this schedule
15:42:42 <jsmith> OK, that puts us at +5, so I think we can move on.
15:42:47 <bowlofeggs> and imo that process works
15:43:06 <jsmith> #agreed (+1:5,+0:0,-1:1) FESCo accepts the F29 schedule.
15:43:19 <pingou> jwb: thanks for explaining
15:43:20 <tyll> bowlofeggs: but that is the same with the other items, too, BOdhi activation also requires to actually flip the switch in Bodhi
15:43:21 <nirik> freeze starts at 00:00tuesdays, infra freezes wed when the email goes out (which allows for me to ask everyone if they have anything they need to land first). And also infra freeze lasts a day after release.
15:43:44 <jsmith> #topic #1861 F28 Changes not in ON_QA status
15:43:44 <jsmith> .fesco 1861
15:43:44 <jsmith> https://pagure.io/fesco/issue/1861
15:43:49 <zodbot> jsmith: Issue #1861: F28 Changes not in ON_QA status (<100% completed) - fesco - Pagure - https://pagure.io/fesco/issue/1861
15:43:58 <bowlofeggs> tyll: yeah, bodhi activation is kinda a weird releng/infra combination thing, but it is def on the schedule formally (which is good)
15:44:49 <zbyszek> jsmith: I think we should discuss them one by one
15:44:49 <tyll> nirik: I see, I guess it does not hurt to document this in the schedule page and keep it as it is :-)
15:44:56 <jsmith> We still have four F28 changes not in ON_QA status
15:45:05 <nirik> zbyszek: +1
15:45:22 <maxamillion> jsmith: one of them is a doozy ;)
15:45:32 <jsmith> maxamillion: I know, right?!?
15:45:51 <jsmith> Shall we tackle them one at a time?
15:45:52 <bowlofeggs> so the krb one is partially complete, but i agree is ok to ship as such
15:45:52 <sgallagh> Oof, I was going to update the Modularity one before this meeting and forgot
15:46:11 <zbyszek> bowlofeggs, sgallagh: hold your horses
15:46:15 <bowlofeggs> shoudl we formally move the krb one to f29 while allowing what was partially complete to ship with f28?
15:46:21 <nirik> proposal: Kerberos in Python modernization - ask change owner to update change with what will be shipped in f28 and file last changes in f29 change?
15:46:30 <jsmith> nirik: +1
15:46:46 <bowlofeggs> nirik: +1
15:46:55 <sgallagh> nirik: +1
15:47:01 <zbyszek> nirik: +1
15:47:16 <tyll> nirik: +1
15:47:38 <nirik> +1 my own proposal
15:48:30 <jsmith> #agreed (+1:6,+0:0,-1:0) Kerberos in Python modernization - ask change owner to update change with what will be shipped in f28 and file last changes in f29 change
15:48:32 <zbyszek> proposal: retire python-urllib2_kerberos
15:48:54 <jwb> +1 to nirik's proposal above
15:48:57 <jwb> (sorry_
15:49:06 <jsmith> OK, let's talk about add-on modularity
15:49:13 <zbyszek> jsmith: wait
15:49:26 <zbyszek> What about voting on https://bugzilla.redhat.com/show_bug.cgi?id=1546836 right now?
15:49:46 <zbyszek> It's been 2 weeks without reply from package owner.
15:50:31 <sgallagh> I assume rharwood means "retire", not "orphan"
15:50:38 <jsmith> zbyszek: Because there hasn't been a formal non-responsive maintainer ticket for it?
15:51:32 <sgallagh> I'm asking if it's a drop-in replacement.
15:51:34 <bowlofeggs> if we're delaying to f29 i think it's ok to wait on this one
15:51:46 <jsmith> bowlofeggs: +1
15:51:50 <sgallagh> If it is, we as FESCo can probably just vote to allow them to Obsoletes: it
15:51:55 <jsmith> (delaying the rest of the work, for clarification)
15:52:06 <zbyszek> OK.
15:52:27 <maxamillion> bowlofeggs: +1
15:52:49 <zbyszek> Right, let's move on.
15:52:51 <jsmith> OK, can we move on to the 800 pound ticket?
15:53:01 <jsmith> sgallagh: Can you give us an update on Add-on Modularity?
15:53:08 <nirik> should we do the other 2 first? or I guess it doesn't matter
15:53:24 <jsmith> I'm just going in the order they were in the ticket, for some kind of consistency
15:53:27 <sgallagh> jsmith: Short version: I was going to update this BZ before the meeting, then forgot. I think we're ready to call it ON_QA
15:53:45 <jsmith> sgallagh: That's great news!
15:53:50 <sgallagh> Minus one hiccup with last night's compose, I think we're in shape for actual testing come tomorrow
15:53:58 <zbyszek> sgallagh: Great news.
15:54:00 <nirik> if we are blocking on this (and we should), I'd like to know what exactly we are blocking on...
15:54:38 <bowlofeggs> i agree with nirik: there should be release criteria if it blocks the release
15:54:51 <zbyszek> IIUC, F28 will mostly have the mechanism in place, and a few showcase modules. It'd be great to clarify this into a concrete list.
15:54:52 * jsmith has a hard stop in five minutes (giving a presentation!) -- can someone else take over for the rest of the meeting?
15:54:52 <bowlofeggs> i've also been persuaded that it does block the release :)
15:55:20 <bowlofeggs> jsmith: sure i can do it
15:55:23 <nirik> for example, do we have to have updates pushing working for beta? or just before final?
15:55:29 <dgilmore> hi I am finally free
15:55:37 <zbyszek> dgilmore: perfect timing
15:55:44 <nirik> I assume we want all the dnf module <whatever> operations to work on the repo
15:55:50 <bowlofeggs> updates pushing does not work correctly right now i can say :)
15:56:00 <maxamillion> fun :)
15:56:22 <bowlofeggs> i think patrick will have a patch ready to fix it soon though
15:56:38 <bowlofeggs> and i think that's the last known bodhi issue (i'm sure there are unknown issues)
15:56:41 <nirik> yeah, but we need to know if we are blocking on that...
15:56:47 <dgilmore> nirik: beta would be better, but before final freeze would work
15:56:48 <bowlofeggs> i think we should block on that
15:57:04 <jsmith> nirik: Beta blocker or final blocker?
15:57:05 <bowlofeggs> updates are crucial to have working
15:57:12 <bowlofeggs> and if we can't test that wtih the beta that would be bad
15:57:18 <bowlofeggs> (imo)
15:57:27 <sgallagh> Yeah, I'm inclined to agree with bowlofeggs here
15:57:46 <sgallagh> There's also a side-effect in that it allows us an easier way to land new modules.
15:57:47 <bowlofeggs> but i also think we can probably have it fixed "soon", possibly next week
15:57:54 <nirik> I'm a bit torn... could go either way
15:58:07 <sgallagh> Right now, we have to open a releng ticket to have them manually added to the pungi config (or send a PR for same)
15:58:15 <jsmith> Proposal: Get a status update next week with what we're blocking on, and when
15:58:16 <nirik> the first go/no-go is next thursday. less than a week from now
15:58:28 <nirik> jsmith: -1. too late.
15:58:31 <zbyszek> -1 to waiting the whole week
15:58:33 <sgallagh> nirik: Given the status of the blocker list, that's a dream anyway
15:58:34 <jsmith> nirik: Good point.
15:58:47 <nirik> sgallagh: possibly, but you never know.
15:59:53 <bowlofeggs> is it up to us to set the blocker list, or just to approve it?
15:59:54 <nirik> I guess it would be good to block on bodhi updates for modules for beta...
15:59:55 <sgallagh> fair, but I still think this is worth blocking
16:00:05 <sgallagh> bowlofeggs: Well, this is a special case
16:00:16 <sgallagh> We're declaring Modularity blocking by our overriding power
16:00:17 <nirik> bowlofeggs: we can file a bug and call it a blocker.
16:00:25 <bowlofeggs> yeah
16:00:32 <sgallagh> So we need to decide on what we're using as criteria for success
16:01:15 <jwb> i already put the tracking bug on the blocker proposed list
16:01:18 <jwb> why do we need another one?
16:01:26 <sgallagh> jwb: I think we need criteria though.
16:01:30 <bowlofeggs> why don't we make criteria proposals, vote on them individually, and whatever ones get enough votes become the criteria?
16:01:34 <sgallagh> Which things must work tby Beta?
16:01:44 <jwb> sgallagh, just put them in the tracking bug and say FESCo agreed on them (when we do)?
16:01:52 <nirik> jwb: whats the bug number?
16:01:54 <sgallagh> jwb: Yes, I think we're agreeing here
16:02:03 <bowlofeggs> do we need separate beta and final criteria?
16:02:09 <zbyszek> nirik: I think jwb means https://bugzilla.redhat.com/show_bug.cgi?id=1537253
16:02:38 <zbyszek> the problem is that there's scant info in that bug
16:02:59 <jwb> zbyszek, that sounds like an easy damn problem to solve...
16:03:03 <nirik> weird. I don't see it on blockerbugs app, but ok.
16:03:18 <jwb> nirik, it's there for final
16:03:32 <nirik> ah, ok.
16:03:45 <maxamillion> jwb: true, but we're tight on time and if the info isn't there now to assist in the discussion and/or approval process it makes it difficult
16:03:47 <jwb> nirik, guess i misproposed it or something, but adamw said it was wrong to do that in any case
16:03:56 <jwb> maxamillion, wat?
16:03:58 <sgallagh> OK, so let's rattle off some potential criteria:
16:03:58 <sgallagh> 1) `dnf module list` must display all of the modules and streams from the stable module repository
16:04:05 <jwb> maxamillion, we need FESCo agreement.  that's it.
16:04:07 <maxamillion> jwb: the info not being in the bug
16:04:12 <jwb> no
16:04:14 <jwb> listen
16:04:20 <maxamillion> listening
16:04:37 * zbyszek waits for sgallagh to finish
16:04:40 <jwb> we need to get the criteria listed and agreed on in this meeting, right now.  then we put it in the bug, say what we agreed on, and declare it a blocker
16:04:43 <jwb> this is not hard
16:04:55 <jwb> this is FESCo blocker override in all it's glory
16:05:14 <nirik> - module rpms should only appear in the Modular variant, not any other variants.
16:05:17 <sgallagh> 2) `dnf module enable name:stream` must enable the module stream such that `dnf install <pkgname>` after that is chosen by the solver
16:05:18 <maxamillion> jwb: I misunderstood then, I thought we were expecting the people working on modularity to define the criteria
16:05:36 <sgallagh> maxamillion: One of them is doing that *right this moment* ;-)
16:05:53 <nirik> sgallagh: care to just add it tot he bug? or pastebinit?
16:06:10 <sgallagh> 3) `dnf module install <foo>` must honor specified distribution defaults
16:06:13 <nirik> I don't think we should set the bar too high here... basic operations and bodhi updates work
16:06:23 <bowlofeggs> yeah agree with nirik
16:06:25 <sgallagh> Well, I want to get a few clear cases listed
16:06:30 <nirik> ok.
16:06:32 <bowlofeggs> sure
16:06:34 * nirik shuts up
16:06:37 <bowlofeggs> haha
16:06:38 <sgallagh> So I was describing "basic operations"
16:07:16 <bowlofeggs> sgallagh: so there's both dnf install and dnf module install, but dnf install can also install modules?
16:07:30 <bowlofeggs> or was 2) supposed to have a "module" in th einstall comment?
16:07:33 <sgallagh> bowlofeggs: no, `dnf install` can install RPMs from enabled modules
16:07:45 <sgallagh> And `dnf install @module` is an alias for `dnf module install`
16:08:03 <bowlofeggs> interesting
16:08:04 <bowlofeggs> ok
16:08:11 <zbyszek> sgallagh: do we have a list of some modules that we can test on?
16:08:44 <sgallagh> zbyszek: http://dl.fedoraproject.org/pub/fedora/linux/development/28/Modular/x86_64/os/Packages/ is all I have right now
16:09:02 <sgallagh> It will grow post-beta
16:09:12 <sgallagh> nodejs is the representative example I recommend for now
16:09:20 <sgallagh> It has multiple streams and multiple profiles for each stream
16:09:57 <sgallagh> The django:1.6 stream may also be interesting to some as an example of a module that overrides a branch of the package tree
16:10:39 <sgallagh> ok, and 5) Module updates submitted to bodhi must appear in testing and stable repos as appropriate
16:10:44 <sgallagh> So those are my 5 proposed criteria
16:10:54 <zbyszek> what was 4?
16:11:04 <bowlofeggs> sgallagh: 6) dnf update should use said updates from 5) :)
16:11:12 <sgallagh> "profit"
16:11:21 <sgallagh> zbyszek: I think I missed 4) somehow
16:11:32 * sgallagh tries to remember if I had another criterion
16:11:40 <bowlofeggs> sgallagh: if we can profit wtihout #5 and #6, i say we only do #1-3 :)
16:12:08 <bowlofeggs> i'm +1 to the above, but would like my #6 to be included as well
16:12:11 <nirik> are these all beta? or any different ones for beta/final?
16:12:17 <maxamillion> sgallagh: `dnf install @module` ... how will dnf determine module vs group?
16:12:21 * zbyszek thinks 1-3, 6 are necessary for beta, 5 can for final
16:12:27 <sgallagh> Oh 4) was "it must be possible to build modules with MBS that can be passed to Bodhi and consumed by DNF"
16:12:46 <bowlofeggs> sgallagh: should we h ave a 7) at least one module is available to ship so we have something to test with (we already have it, but just to formalize it)
16:12:54 <nirik> zbyszek: that would mean we don't need bodhi updates handling for beta?
16:12:55 <sgallagh> bowlofeggs: +1
16:13:12 <zbyszek> nirik: yes
16:13:37 <zbyszek> nirik: there's just three modules, so I think we can live without bodhi
16:13:45 <sgallagh> I guess an argument could be made that the Bodhi work can arrive a little late
16:13:52 <bowlofeggs> i think bodhi should block the beta personally
16:14:07 <bowlofeggs> because beta testers should be able to test updates working correctly
16:14:08 <sgallagh> zbyszek: Well, I want Bodhi in part because it will let us open the floodgates and get more modules
16:14:09 <bowlofeggs> imo
16:14:26 <sgallagh> bowlofeggs: Yes, but must they be able to test updates AT RELEASE, or is "the week after" acceptable?
16:14:43 <bowlofeggs> sgallagh: imo, at release, because if we say after that reduces testing time
16:14:44 <sgallagh> I think it needs to be available as soon as possible, but not necessarily ship the release for it
16:14:44 <zbyszek> sgallagh: actually I'd like to vote on a specific list of modules for F28, and not open the floodgates yet
16:14:53 <maxamillion> bowlofeggs: +1
16:15:21 <sgallagh> zbyszek: Middle-ground: require FESCo approval for modules to leave testing and head to stable?
16:15:29 <bowlofeggs> i'm ok with floodgates and just requiring there to be a minimum number of modules to test with (even 1 is fine by me)
16:15:43 <maxamillion> zbyszek: to be fair, you can probably open the floodgates and nobody will come running ... we had similar concerns with the container stuff and after ~18 months of that build system being live, there's like 20 container images
16:15:59 <bowlofeggs> floodgates could be good too
16:16:05 <bowlofeggs> because that means more testers
16:16:19 <bowlofeggs> though i agree with maxamillion
16:16:27 <maxamillion> everyone clamors for it until it's here and then nobody wants to do the work ... >.>
16:16:30 <sgallagh> Also, a reminder: in F28, only Server Edition will ship with the modular repo
16:16:34 <bowlofeggs> i'm for allowing as many modules as people want to do wtihout fesco
16:16:40 <sgallagh> So it's going to have a constrained audience
16:16:44 <zbyszek> I guess maxamillion it right
16:16:55 <zbyszek> bowlofeggs: yes
16:17:13 <nirik> if we are adding modules we really need bodhi updates for them working...
16:17:14 <maxamillion> zbyszek: I wish I wasn't
16:17:25 <bowlofeggs> i'm for all the #'d proposals above, all blocking beta, though it seems some people think the updates bit shouldn't
16:17:46 <sgallagh> I'll go with the majority on 5). I'm on the fence
16:17:56 <bowlofeggs> i will offer this for persuasion: i don't think the bodhi changes will take much longer
16:18:00 <nirik> I'm with bowlofeggs I think. I could see a case for not blocking beta on bodhi/updates, but really we should probibly.
16:18:51 <bowlofeggs> why don't we do a poll to see how people vote on just this bit: proposal: updates should block the beta
16:18:53 <bowlofeggs> +1
16:19:01 <nirik> +1ish
16:19:06 <zbyszek> -1
16:19:06 <jwb> +1
16:19:42 <sgallagh> As I said, I'll go with the majority, so +1
16:19:56 <sgallagh> dgilmore: ?
16:20:01 <sgallagh> maxamillion: ?
16:20:21 <dgilmore> sgallagh: sorry got distracted
16:20:23 <sgallagh> I suppose my vote isn't final until they chime in
16:20:28 <bowlofeggs> haha
16:20:35 <maxamillion> +1
16:20:37 <bowlofeggs> we can do the reverse poll too if we don't get a majority here
16:20:44 <tyll> +1
16:20:47 <bowlofeggs> ok that's +6 and -1
16:20:54 <dgilmore> +1
16:20:54 <sgallagh> dgilmore: Question is whether we block Beta on Bodhi updates for modules
16:20:59 <sgallagh> ok
16:21:01 <nirik> zbyszek: do note that without bodhi updates for modules each new module has to be added manually by releng to a pungi config file.
16:21:10 <dgilmore> I think we can wait until final freeze
16:21:12 <bowlofeggs> that's +7 and -1 now
16:21:28 <bowlofeggs> we can do the reverse poll too if we want to, but i don't think it would beat +7 -1
16:21:28 <sgallagh> dgilmore: Wait, that contradicts your vote
16:21:29 <dgilmore> but if everyone prefers going with Beta I am good with it
16:21:35 <bowlofeggs> because i'd vote -1
16:22:02 <maxamillion> bowlofeggs: you'd assume if we reverse the poll, you'd just get an inverse vote count
16:22:12 <bowlofeggs> ok, so that aside, proposal: all numbered criteria set forth by sgallagh and bowlofeggs above are required for beta and final
16:22:13 <maxamillion> but when humans are involved .... ;)
16:22:19 <maxamillion> bowlofeggs: +1
16:22:20 <dgilmore> sgallagh: I do not feel strong enough on waiting until final freeze that I am opposed to making it done sooner
16:22:28 <bowlofeggs> maxamillion: not necessarily, becaseu some might be +1 to btoh
16:22:37 <sgallagh> bowlofeggs: +1 and I'll take an action to write those to the BZ and inform QA
16:22:44 <nirik> +1
16:22:55 <zbyszek> sgallagh: I just wrote to BZ
16:23:05 <nirik> sgallagh: make sure to set the bug to block the beta blocker bug
16:23:11 <sgallagh> zbyszek: Man, I'm good at delegating, huh? :)
16:23:25 <zbyszek> no, you got the wrong person ;)
16:23:59 <bowlofeggs> i could +3 so far
16:24:00 <zbyszek> Oh, "delegating", nm.
16:24:02 <bowlofeggs> *count
16:24:02 <jwb> +1
16:24:33 <zbyszek> What are we voting on now?
16:24:37 <dgilmore> what is the proposal now?
16:24:45 <nirik> [09:22:12] <bowlofeggs> ok, so that aside, proposal: all numbered criteria set forth by sgallagh and bowlofeggs above are required for beta and final
16:25:02 <tyll> is it for blocking the releases or not shipping modular if the criteria are not met?
16:25:10 <sgallagh> tyll: Blocking the release
16:25:32 <bowlofeggs> tyll: yeah it seems this is an f28 release blocker, so this would block everything, not just modularity
16:25:40 <bowlofeggs> since it's a council objective
16:25:46 <zbyszek> +1 to bowlofeggs
16:26:08 <zbyszek> #info critera are in https://bugzilla.redhat.com/show_bug.cgi?id=1537253#c6
16:26:41 <bowlofeggs> was there a 7?
16:26:43 <tyll> zbyszek++
16:26:44 <zodbot> tyll: Karma for zbyszek changed to 6 (for the f27 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:27:08 <dgilmore> +1 to the listed requirements
16:27:13 <zbyszek> bowlofeggs: I think 7) was profit ;)
16:27:18 <bowlofeggs> 7) at least one module is available to ship so we have something to test with (we already have it, but just to formalize it)
16:27:36 <dgilmore> 4 was missing
16:27:45 <dgilmore> make 4 bowlofeggs 7
16:27:57 <sgallagh> dgilmore: 4 was missed and added later
16:28:01 <bowlofeggs> haha
16:28:03 <bowlofeggs> this is funny
16:28:04 <tyll> do we already know which criteria are likely not met currently? At least 1-3 seems to have been working in the past
16:28:04 * nirik notes rawhide fails that critera, but oh well. ;)
16:28:05 <sgallagh> zbyszek: Has that one right
16:28:13 * bowlofeggs counts votes
16:28:17 <tyll> (from what I remember from Flock)
16:28:30 <sgallagh> nirik: I built a module for Rawhide today that we could ship if needed
16:28:42 <bowlofeggs> i count +7
16:28:50 <bowlofeggs> did someone not vote or did i miss one?
16:28:56 <nirik> sgallagh: might be good at some point to sync up the modules in 28 for rawhide...
16:29:16 <bowlofeggs> ah tyll i don't see a vote from you
16:29:25 <sgallagh> nirik: That will happen at the end of the month
16:29:32 <bowlofeggs> tyll: the updates aren't working yet on bodhi's side
16:29:34 <sgallagh> We need the module stream expansion stuff for that
16:29:38 <bowlofeggs> so #5
16:29:40 <sgallagh> Which is waiting on infra freeze being lifter
16:29:42 <sgallagh> *lifted
16:29:55 * nirik nods.
16:30:07 <tyll> if it is mostly done, I am +1
16:30:12 <bowlofeggs> ok that's +8
16:30:55 <bowlofeggs> #agreed The critieria posted in comments 6 and 7 at https://bugzilla.redhat.com/show_bug.cgi?id=1537253 are required for modularity (+8, 0, -0)
16:31:25 <bowlofeggs> #action sgallagh will inform QA (the proposals are in the BZ already)
16:31:31 <bowlofeggs> ok, let's move on
16:31:41 <bowlofeggs> next is https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
16:31:55 <zbyszek> This is waiting on ppp now
16:32:06 <nirik> I asked this be updated... it really should be marked done
16:32:23 <bowlofeggs> ppp?
16:32:37 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=1537261#c5
16:32:42 <bowlofeggs> nirik: so you believe the work to be done and the maintainer just hasn't updated the ticket?
16:32:55 <nirik> now one of them has.
16:33:05 <bowlofeggs> ah cool
16:33:14 <bowlofeggs> in that case, i think we don't need to do anything right?
16:33:29 <nirik> nope, move on
16:33:32 <bowlofeggs> ack
16:33:39 <bowlofeggs> ok now https://fedoraproject.org/wiki/Changes/Atomic_Cloud_and_Docker_images_for_s390x
16:33:49 <bowlofeggs> also see https://bugzilla.redhat.com/show_bug.cgi?id=1547235
16:34:02 <dgilmore> atomic host is not currently possible
16:34:06 <nirik> There's a pending koji patch to update the timeout for cloud image making... note that this will make our composes longer
16:34:13 <dgilmore> but the container image is done
16:34:38 <bowlofeggs> ime, getting koji patches in can take a long time
16:35:12 <bowlofeggs> well actually koji seems to move more quickly recently, but i've seen it have slow development before
16:35:17 <bowlofeggs> so i'm not sure what to expect
16:35:22 <dgilmore> ostree generation took about 14 hours due to the reading and wriing of /mnt/koji over the slow wan link between the two sites where koji is and the builders are
16:35:48 <nirik> well, we could pull that patch abd build a local koji with it for that builder.
16:35:54 <bowlofeggs> true
16:36:19 <nirik> I can try and do that... and lets just wait on this for now?
16:36:24 <bowlofeggs> would it be interesting to put the container image into f28 but delay the cloud image for f29?
16:36:34 <bowlofeggs> nirik: that's fine wtih me too
16:37:16 <bowlofeggs> proposal: let nirik perform wizardry and revisit in a week
16:37:18 <dgilmore> we could easily get the patch deployed
16:37:36 <dgilmore> we do have the container image
16:37:42 <dgilmore> it is partially done
16:37:56 <dgilmore> we also know that the atomic host portion is not current feasable
16:38:19 <dgilmore> should we ask ksinny to update the change to reflect what is done and do a new one for f29?
16:38:48 <bowlofeggs> i think that could be reasonable too
16:38:57 <dgilmore> bowlofeggs: we could do that in conjection with what I asked
16:38:58 <bowlofeggs> i could +1 either approach
16:39:04 <bowlofeggs> yeah
16:39:15 <maxamillion> same
16:39:19 <dgilmore> if we can get the images for cloud working great, if not we punt it
16:39:39 <bowlofeggs> but we'd wait a week before punting, right?
16:39:47 <maxamillion> ultimately they are related but I think the container image and the atomic host image can stand on their own as disjoint feature changes
16:39:50 <bowlofeggs> to see what wizardry nirik can do?
16:40:01 <bowlofeggs> maxamillion: agreed
16:40:15 <dgilmore> proposal, we let nirik work some koji magic to try get the cloud imegas done, by next week we ask that ksinny has updated the change to reflect reality and punt the rest to f29
16:40:25 <bowlofeggs> dgilmore: +1
16:40:30 <nirik> +1
16:40:31 <zbyszek> dgilmore: +1
16:40:39 <sgallagh> +1
16:40:39 <dgilmore> +1
16:41:12 <bowlofeggs> tyll, maxamillion, jwb: ?
16:41:15 <maxamillion> +1
16:41:19 <tyll> +1
16:41:35 <jwb> +1
16:41:52 <jwb> i have faith in both ksinny and nirik :)
16:41:53 <bowlofeggs> #accepted we let nirik work some koji magic to try get the cloud imegas done, by next week we ask that ksinny has updated the change to reflect reality and punt the rest to f29 (+8, 0, -0)
16:42:18 <bowlofeggs> #action nirik will perform wonders with koji to attempt to get cloud images done
16:42:20 <dgilmore> jwb: me too
16:42:27 <bowlofeggs> ok i think that's the end of this ticket
16:42:36 <nirik> at last
16:42:37 <nirik> :)
16:42:46 <bowlofeggs> #topic #1862 Fedora 28 Beta status, schedule risk
16:42:53 <bowlofeggs> .fesco 1862
16:42:55 <zodbot> bowlofeggs: Issue #1862: Fedora 28 Beta status, schedule risk (meeting item for 2018-03-16) - fesco - Pagure - https://pagure.io/fesco/issue/1862
16:43:56 <bowlofeggs> do we need to take any action on this ticket?
16:44:01 <bowlofeggs> seems like it was for our info
16:44:12 <maxamillion> yeah, I don't really see anything actionable
16:44:13 <pwhalen> for the aarch64 portion, I've been doing basic manual testing for server on aarch64. More testing is being done now in openqa (yay!) - https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&version=28&build=Fedora-28-20180314.n.2&groupid=6
16:44:40 <pwhalen> Some of those failures are due to a broken kernel update, which is already fixed and verified. Many of the soft failures are due to AVC's, and should also be fixed in a proposed FE.
16:44:53 <bowlofeggs> pwhalen: fantastic
16:44:56 <bowlofeggs> proposal: FESCo acknowledges the risk and closes the ticket
16:45:05 <sgallagh> bowlofeggs: +1
16:45:07 <zbyszek> bowlofeggs: +1
16:45:09 <maxamillion> +1
16:45:24 <tyll> +1
16:45:43 <nirik> +1
16:46:02 <bowlofeggs> dgilmore, jwb: ?
16:46:37 <jwb> +1
16:46:48 <jwb> thanks for the update pwhalen  :)
16:47:11 * jwb apologizes for the laggy replys.  now in multi-meeting mode :\
16:47:21 <maxamillion> jwb: that's always the worst :(
16:47:30 <bowlofeggs> haha
16:47:42 <bowlofeggs> well i'm going to say we hard stop in ~12 min just because that's 2 hours
16:47:53 <bowlofeggs> i'm going to count dgilmore as a +0
16:47:55 <jwb> it's the norm.  our efficiency in this meeting could be improved.  2 hours is fairly lengthy
16:47:57 <dgilmore> +1
16:48:11 <dgilmore> thanks pwhalen for the update
16:48:12 <bowlofeggs> #agreed FESCo acknowledges the risk and closes the ticket (+8, 0, -0)
16:48:26 <bowlofeggs> #topic  #1863 F29 Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer
16:48:33 <bowlofeggs> .fesco 1863
16:48:35 <zodbot> bowlofeggs: Issue #1863: F29 Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer - fesco - Pagure - https://pagure.io/fesco/issue/1863
16:48:47 <zbyszek> FTR, jwb voted +1 in the ticket
16:48:50 <dgilmore> +1
16:49:04 <tyll> +1
16:49:06 <nirik> +1
16:49:34 <sgallagh> +1
16:49:34 <zbyszek> +1
16:49:39 <bowlofeggs> i'm internally debating whether this should be self contained
16:49:47 <bowlofeggs> do other things depend on it?
16:50:21 <bowlofeggs> it does say no dependencies i suppose
16:50:27 <bowlofeggs> so i'm +1
16:50:46 <bowlofeggs> so that's +7. maxamillion?
16:50:54 <jsmith> +1
16:51:00 <maxamillion> +1
16:51:00 * jsmith is back
16:51:04 <bowlofeggs> word
16:51:19 <bowlofeggs> #agreed #1863 is approved (+9, 0, -0)
16:51:24 <bowlofeggs> jsmith: want to drive again?
16:51:29 <jsmith> bowlofeggs: Sure :-)
16:51:59 <jsmith> #topic Next week's chair
16:52:13 <jsmith> Anybody want to volunteer for next week?
16:52:57 <jsmith> .... crickets ....
16:53:19 <bowlofeggs> zbyszek, i, and jsmith were the most recent 3
16:53:27 <tyll> I can do it
16:53:28 <nirik> I guess I can do it.
16:53:36 <nirik> or tyll. :)
16:53:41 <jsmith> tyll it is :-)
16:53:48 <tyll> \o/
16:53:48 <jsmith> #agreed tyll to chair next week's meeting
16:53:54 <jsmith> #topic Open Floor
16:53:58 <zbyszek> Review of release blocking deliverables for F28 -- did we miss that?
16:54:00 <jsmith> Any topics for the open floor?
16:54:23 <jsmith> Oops, did I skip that one?
16:54:26 * dgilmore notes that as of next Friday I will no longer be leading release engineering in Fedora
16:54:26 <jsmith> Sorry!
16:54:35 <jsmith> #topic #1859  Review of release blocking deliverables for F28
16:54:35 <jsmith> .fesco 1859
16:54:35 <jsmith> https://pagure.io/fesco/issue/1859
16:54:37 <zodbot> jsmith: Issue #1859: Review of release blocking deliverables for F28 - fesco - Pagure - https://pagure.io/fesco/issue/1859
16:55:12 <bowlofeggs> this was approved last week, right?
16:55:14 <zbyszek> Did we get the action done?
16:55:32 <bowlofeggs> well we did the criteria today
16:55:34 <zbyszek> I guess we discussed that today in meeting.
16:55:36 <bowlofeggs> so i think we have it now
16:55:40 <zbyszek> Right, so this can be closed.
16:55:42 <jsmith> Yeah, I think we're good.
16:55:44 <zbyszek> Sorry for the noise.
16:55:46 <jsmith> I'll close the ticket :-)
16:55:48 <bowlofeggs> no problem :)
16:55:54 <jsmith> zbyszek: It's all good :-)  Thanks for keeping me honest!
16:56:04 <jsmith> #topic Open Floor
16:56:11 <jsmith> Anything else for the open floor?
16:56:14 <tyll> dgilmore: who will be the new releng lead?
16:56:17 <jsmith> dgilmore: Congrats, I think :-)
16:56:19 * zbyszek needs to go now. See you next week.
16:56:24 <jsmith> Thanks zbyszek
16:56:37 <bowlofeggs> tyll: mboddu
16:56:43 <dgilmore> tyll: mboddu will be
16:56:50 <dgilmore> jsmith: thanks and yep :D
16:57:37 <tyll> Is there anyone in FESCo who will not follow DST after next weeking? I would like to propose to adjust the meeting time to DST when everyone is affected by it
16:57:41 <tyll> I see
16:58:05 <maxamillion> sorry, I was planning to take next week as chair but something came up and now I might be on an airplane
16:58:07 <jsmith> tyll: Do you mean going to 16:00 UTC?
16:58:19 <jsmith> maxamillion: We'll catch you another time, it's fine :-)
16:58:32 <sgallagh> dgilmore: Are you planning to stay on FESCo?
16:58:51 <dgilmore> sgallagh: yes, I am staying in FESCo for my term and the council
16:59:01 <tyll> jsmith: actually going to 14:00 UTC so it stays the same in local time
16:59:18 <sgallagh> dgilmore: OK, just wanted to make sure
16:59:18 <jsmith> I'm fine with that -- but I can't speak for everyone else
16:59:20 <dgilmore> sgallagh: my term in FESCo is up with f28 and I had already decided that I would not re run for FESCo
16:59:31 <tyll> jsmith: at least compared to not DST
16:59:32 * sgallagh nods
16:59:48 <bowlofeggs> i'm available for either time slot and generally do not believe in DST (all hail UTC)
16:59:57 <bowlofeggs> actually all hail seconds since 1970
17:00:07 <tyll> bowlofeggs: the problem is that everyone else believes in DST
17:00:08 <bowlofeggs> because UTC still has pesky ridiculous leap seconds
17:00:11 <jsmith> tyll: Maybe the best thing would be to send an email to the group, as I'm not sure we have everyone's attention at the moment...
17:00:16 <bowlofeggs> tyll: yes that is a problem
17:00:18 <tyll> jsmith: ok, will do
17:00:58 <jsmith> tyll: I have a sneaking suspicion that nirik would enjoy having the meeting an hour later, but I don't want to speak for him :-p
17:01:12 <bowlofeggs> yeah it's 07:00 for him if we go back
17:01:29 <bowlofeggs> both times are nice for me in EDTland
17:01:31 * nirik shrugs. I can do either
17:01:47 <nirik> later is nicer for me, but I can get up early too
17:02:11 <tyll> ok, I will send an e-mail to get also everyone else's opinion
17:02:50 <jsmith> Thanks tyll
17:02:57 * jsmith lights the fuse....
17:03:08 <jsmith> I'll end the meeting in one minute if there is nothing else for the open floor
17:03:21 <jsmith> Thanks again to bowlofeggs for covering for me in the second half of the meeting
17:03:23 <jsmith> bowlofeggs++
17:03:59 <bowlofeggs> sure thing :)
17:05:08 <jsmith> #endmeeting