15:00:30 <bookwar> #startmeeting fesco
15:00:30 <zodbot> Meeting started Mon Apr 27 15:00:30 2020 UTC.
15:00:30 <zodbot> This meeting is logged and archived in a public location.
15:00:30 <zodbot> The chair is bookwar. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:30 <zodbot> The meeting name has been set to 'fesco'
15:00:42 <bookwar> #chair nirik, ignatenkobrain, decathorpe, zbyszek, bookwar, sgallagh, contyk, mhroncok, dcantrell
15:00:42 <zodbot> Current chairs: bookwar contyk dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
15:00:52 <nirik> morning
15:00:54 <bookwar> #topic init process
15:00:55 <contyk> .hello psabata
15:00:56 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:59 <bookwar> .hello2
15:01:00 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:01:01 <mhroncok> hello
15:01:02 <decathorpe> .hello2
15:01:03 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
15:01:06 <dcantrell> .hello2
15:01:09 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
15:01:14 <bookwar> first time chairing, so expect something to go wrong )
15:01:29 <bcotton> .hello2
15:01:30 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:56 <sgallagh> .hello2
15:01:57 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:59 <zbyszek> .hello2
15:02:00 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:02:15 <bookwar> ok, looks like we gave enough people
15:02:26 <bookwar> let's start with the agenda
15:02:34 <bookwar> #topic #2372 F33 Self-contained Change: Network Time Security
15:02:41 <bookwar> .fesco 2372
15:02:42 <zodbot> bookwar: Issue #2372: F33 Self-contained Change: Network Time Security - fesco - Pagure.io - https://pagure.io/fesco/issue/2372
15:03:25 <sgallagh> I honestly do not understand what they're asking for
15:03:34 <zbyszek> The proposal has various TBD items and it is unclear what the scope is.
15:04:00 <zbyszek> The description says "support ... in ... chrony and ... anaconda".
15:04:15 <bookwar> mkolman: ping
15:04:15 <zodbot> bookwar: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
15:04:49 <zbyszek> That first part is clear (compilation settings), but the second one less so, because it is not clear what servers will be used.
15:04:50 * nirik thinks we need more input from change owners, yeah.
15:05:19 <sgallagh> I'm -1 without more information.
15:05:23 <zbyszek> IIUC, the proposal is to make this opt-in (at least for now), but that should be clarified too.
15:05:39 <sgallagh> zbyszek: "This change also makes the default configuration of the NTP client secure."
15:05:50 <bookwar> proposal: postpone discussion until TBD items are resolved
15:05:58 <nirik> +1
15:06:00 <sgallagh> +1
15:06:01 <dcantrell> +1
15:06:05 <mhroncok> bookwar: +1
15:06:06 <zbyszek> +1
15:06:09 <contyk> +1
15:06:21 <zbyszek> sgallagh: it's TBD ;)
15:06:30 <zbyszek> *marked as
15:06:40 <decathorpe> +1
15:06:52 <bookwar> #agreed postpone discussion until TBD items are resolved (+8, 0, 0)
15:07:02 <bookwar> did i do it right?
15:07:16 <sgallagh> Yes
15:07:28 <bookwar> ok, moving on
15:07:39 <bookwar> #topic #2382 systemd default service exception for rpmdb-rebuild service
15:07:47 <bookwar> .fesco 2382
15:07:48 <zodbot> bookwar: Issue #2382: systemd default service exception for rpmdb-rebuild service - fesco - Pagure.io - https://pagure.io/fesco/issue/2382
15:08:31 <sgallagh> zbyszek: I didn't get a chance to reply to your latest comment on the ticket
15:08:38 <sgallagh> But the problem with RPM is upgrades.
15:08:49 <zbyszek> sgallagh: yeah, I just made it, sorry for being so late with that.
15:08:52 <sgallagh> RPM is guaranteed to be present on all systems.
15:09:08 <sgallagh> So it will *never* enable this service on an upgrade
15:09:22 <sgallagh> Without doing that, we can't convert the databases to the new version
15:09:42 <sgallagh> Hence why I proposed unconditionally setting the preset at the end of the transaction.
15:09:49 <zbyszek> I wrote "and a custom scriptlet to be added to do preset also on package upgrades (e.g. a %triggerun on the old rpm version as mentioned on the mailing list)."
15:09:57 <sgallagh> But maybe I don't understand the %triggerun behavior?
15:10:12 <zbyszek> A sec
15:10:41 <bookwar> sgallagh: is it going to be temporary ? for two releases, and then we drop it?
15:10:42 * nirik wonders if we should table this one for testing and actually vote on approving the tested version next week?
15:11:29 <mhroncok> happy to vote on tsted solution
15:11:31 <zbyszek> So.. let's say we had rpm-4.15-21.fc32 as the last "old" version, and starting with -22.fc32 as the first "new" version. Add a '%triggerun rpm < 4.15-22.fc32' that does the preset.
15:11:32 <mhroncok> *tested
15:11:40 <dcantrell> I'm ok with this exception given that it's rpm and this is a special case, but I would be more comfortable if there has been some testing done.  Like upgrading an F31 system to rawhide with this version of rpm
15:11:53 <sgallagh> zbyszek: My understanding of triggerun is that it wouldn't happen until the *next* update after
15:12:18 <zbyszek> A, OK. You might be right.
15:12:36 <sgallagh> But I think I misread that
15:12:53 <sgallagh> OK, I think you're right; that should work after all.
15:13:15 <zbyszek> But this probably isn't the best place to discuss this.
15:13:47 <sgallagh> Yeah, I'll take it back to the ticket.
15:13:49 <bookwar> proposal: get the results of the test and vote next week
15:13:58 <sgallagh> I think we've got it sorted out now, though.
15:14:11 <bookwar> or vote in the ticket?
15:14:21 <nirik> either way
15:14:25 <zbyszek> But one more thing, before we switch subject:
15:14:59 <zbyszek> sgallagh do you agree that this shouldn't be unconditional, i.e. that the preset should happen just once?
15:15:30 <sgallagh> Yes, I do. Until just now, I had been unable to come up with a way to make that happen.
15:15:38 <sgallagh> Thanks for the tip
15:15:38 <zbyszek> OK, thanks.
15:15:55 <bookwar> cool, we made a progress )
15:17:01 <sgallagh> #action sgallagh to update the ticket with the new proposed approach and try to help test it
15:17:13 <bookwar> sgallagh: thanks
15:17:33 <bookwar> so we vote as usual there then
15:17:37 <bookwar> moving on?
15:17:41 <zbyszek> yep
15:17:52 <bookwar> #topic #2371 F33 System-Wide Change: Removal of the glibc-headers package
15:17:57 <bookwar> .fesco 2371
15:17:58 <zodbot> bookwar: Issue #2371: F33 System-Wide Change: Removal of the glibc-headers package - fesco - Pagure.io - https://pagure.io/fesco/issue/2371
15:18:36 <nirik> +1 here
15:18:53 <contyk> I thought I voted +1 but can't see it. So +1.
15:18:58 <nirik> same here
15:19:01 <zbyszek> I was +1 in the ticket.
15:19:04 <bookwar> we got +1 from zbyszek and two zeroes in the ticket
15:19:29 <bookwar> +1 from me
15:19:54 <bookwar> more votes?
15:20:39 <decathorpe> if we need more votes you can have my +1
15:20:58 <bookwar> sgallagh: ?
15:21:08 <sgallagh> I was +1 in the ticket
15:21:35 <bookwar> i understand this is a complex change, but if we don't have clean reasons not to, i'd rather approve maintainer's work
15:21:42 <bookwar> ah, ok, sorry
15:21:49 <sgallagh> np
15:22:50 <bookwar> counting )
15:23:01 <bookwar> #agreed APPROVED (+6, 0, 0)
15:23:10 <zbyszek> miscount
15:23:16 <mhroncok> I was 0
15:23:18 <zbyszek> we need (+6, 2, 0)
15:23:29 <mhroncok> indeed
15:23:34 <sgallagh> #undo
15:23:34 <zodbot> Removing item from minutes: AGREED by bookwar at 15:23:01 : APPROVED (+6, 0, 0)
15:23:48 <bookwar> #agreed APPROVED (+6, 2, 0)
15:23:52 <bookwar> thanks
15:24:08 <bookwar> #topic Next week's chair
15:24:15 <zbyszek> bookwar, nirik, contyk, decathorpe, zbyszek, one more?
15:24:26 <bookwar> sgallagh
15:24:37 <contyk> I won't be around next week.
15:24:52 <decathorpe> I haven't chaired for a while, it can be me
15:24:55 <zbyszek> Ah, thanks. Not that it matters, but for correctness' sake.
15:25:07 <bookwar> zbyszek: sure
15:25:29 <bookwar> #action decathorpe to chair next one
15:25:43 <bookwar> #topic Open floor
15:25:56 * nirik has a short status/update on the datacenter move if folks would like.
15:26:02 <dcantrell> yes, please
15:26:05 <bookwar> yes!
15:26:09 <sgallagh> Yes, please
15:26:44 <nirik> so, due to some delays we need to push back the switchover to the new datacenter and final shipping of things from the old one.
15:27:06 <nirik> we were planning on moving services last week of may and shipping the rest first week of june
15:27:19 <nirik> now it will be the second week of june to move and the 3rd week to ship.
15:27:31 <nirik> Hopefully nothing else needs to change after it...
15:27:50 <nirik> and this is assuming we get network access to the new datacenter this week.
15:28:15 <nirik> On the rdu front, communishift is all racked up and smooge is out there today cabling it up.
15:28:38 <nirik> so hopefully back up later this week or so, but of course we will have to see
15:28:47 <bookwar> so communishift migration is independent from that delay for the move?
15:29:03 <nirik> yeah, it went to our RDU2 datacenter in raleigh.
15:29:10 <bookwar> that's actually good news, thanks
15:29:24 <nirik> the new datacenter in virgina (IAD2) is the one we are having some delays with.
15:30:00 <bookwar> but we haven't switched off anything for IAD2 yet, so it is a shift in the schedule, not the additional outage
15:30:01 <nirik> happy to answer any other questions here, in email or anytime on irc... we will also be making a more detailed schedule when we have networking.
15:30:12 <nirik> yep. exactly so.
15:30:20 <bookwar> cool, thank you
15:30:32 <nirik> we have a bunch of new hardware + some things we shipped early there, but we can't get to them yet to install them. ;(
15:30:43 <bookwar> any other questions to nirik? i have one more about lenovo initiative
15:31:33 <bookwar> i'll go with my then, do we have support for lenovo models somehow tied in our release criteria?
15:31:40 <bookwar> maybe adamw knows?
15:31:50 <zbyszek> nirik: sounds good and thanks for keeping everyone updated.
15:32:21 <zbyszek> bookwar: I don't think there's any reason to make special reqs for Lenovo.
15:32:25 <nirik> happy to. sorry for the delay
15:32:25 <bcotton> we do not
15:32:45 <bookwar> zbyszek: we had this conversation last week, that a bug in certain component has impact on thinkpads and can be a blocker for the release
15:32:47 <zbyszek> Their drivers are supposed to be all upstream, and we should treat any bug affecting Levono as any bug affecting hardware.
15:32:50 <bcotton> although one of the rejected blockers was a bug opened by lenovo
15:33:27 <decathorpe> the nvidia reboot bug?
15:33:29 <bookwar> with this promise from lenovo to ship vanilla fedora images on their laptops i wonder if we should consider adding that as a test check at least
15:34:03 <bookwar> but probably we dont have enough quorum for this conversation here now, let's find some other place for it
15:34:21 <bookwar> any other  topics?
15:34:53 <adamw> ahoy
15:35:06 <adamw> i was pulled into the lenovo stuff a few weeks ago
15:35:23 <bookwar> adamw: hi, do we test those lenovo laptops as a part of rawhide images testing or release verification?
15:35:31 <adamw> sort of
15:35:51 <adamw> we (the RH people who work on Fedora QA) got pulled into this lenovo stuff a few weeks ago
15:35:55 <adamw> and lenovo has mailed us some test laptops
15:36:11 <adamw> but we did tell them that until it went public we can't be blocking on lenovo problems just because they're lenovo problems or anything
15:36:22 <adamw> lenovo themselves are also actively testing, and filing bugs
15:36:37 <adamw> if you look at the late proposed blockers for F32 you'll see there were several lenovo ones, most we took as FEs, i believe
15:36:50 <adamw> for F33 and later we may look at doing something more formal, now it's not a sekrit project any more
15:37:23 <bcotton> yeah, the embargoed nature of it made it hard to do anything for F32. i'd be open to establishing a "if you're a hardware partner, you get more stringent blocker criteria than general hardware does"
15:37:24 <bookwar> i was wondering if we can invite them to rawhide gating actually, they can be a third party ci system, which runs tests on their internal infra, but provide feedback for example on all kernel upgrades
15:38:21 <zbyszek> We *could* invite them, but I don't think this makes much difference, except a good impression.
15:38:57 <zbyszek> After all, they can test things, and whether people take their reports seriously depends more on consistent and reliable results than anything else.
15:39:27 <adamw> bookwar: that'd be technically quite easy (they'd just have to file results to resultsdb) but i have reservations about that sort of setup (it's been proposed before for RH testing of fedora)
15:39:29 <sgallagh> Starting with F33, I think we probably do need to establish a hardware certification program
15:39:48 <adamw> i don't like the image of a situation where bits of Fedora are gated on a test result that some people can't see
15:40:25 <zbyszek> sgallagh: I think that'd be very hard, with the resources that we have.
15:40:27 <adamw> it's like when you file a pull request on anaconda and it goes and runs some tests inside RH's network and if you don't work for RH you can't see the results. it's not great
15:40:30 <bookwar> adamw: i think we can come up with requirements for test results, one of them would be that test results and logs are open
15:40:38 <adamw> right, if we did that it'd be great
15:40:50 <sgallagh> zbyszek: I don't mean a full certification like RH does.
15:41:00 <bookwar> the infra which runs the tests can be internal, but the output then should be published
15:41:22 <bookwar> i think this is what kernel CI does for upstream kernel now, so we can look into similar setup
15:41:59 <bookwar> adamw: anyway, thanks for clarification, let's see how it develops in f33 cycle
15:42:10 <zbyszek> For example, all the laptops that RH distributes to employees, I suspect most of them would not pass.
15:42:20 <nirik> sgallagh: those things seem doomed to failure after a while... either out of date or incomplete or...
15:42:26 <zbyszek> E.g. on mine, the fingerprint reader never worked.
15:42:43 <nirik> and yeah, what does 'certified' mean?
15:43:36 * nirik would probibly approach it with some ansible playbook... 'run this and put the output in the compat db on the net', but not sure it could test everything.
15:44:10 <zbyszek> I'm not trying to be negative here. If there is strong support from RH, and actual resources are devoted to this, incl. people to the legal/marketing magement and set rules, maybe this could be pulled off. But as a side project, I don't see that happening.
15:44:26 <bookwar> zbyszek: but we should not try to aggressively certify everything, we have a basic setup and three laptop models, and the first step i think is not to certify more, it is to prevent regressions in what we have achieved already
15:45:57 <zbyszek> I'm not sure if we can make any promises. If the drivers for a given laptop are broken in upstream kernel, we are not going to stop kernel updates in Fedora, and neither do we have any resources to fix the issue.
15:46:37 <zbyszek> The best we can do is to try to resolve any issues as they are reported.
15:47:05 <bookwar> but it would be better if they are reported by lenovo for rawhide rather then the enduser
15:47:14 <bookwar> on released system
15:47:16 <zbyszek> Definitely.
15:48:00 <bookwar> do you want to discuss this topic further? or we call it a day?
15:48:35 <zbyszek> I have one thing too, if we are done with this one.
15:48:48 <bookwar> zbyszek: yes, go on
15:49:09 <zbyszek> I think FESCo should get involved in the dist-git change process.
15:49:46 <zbyszek> I opened a long ticket
15:49:52 <zbyszek> .fesco 2383
15:49:53 <zodbot> zbyszek: Issue #2383: fesco statement on the dist-git change process - fesco - Pagure.io - https://pagure.io/fesco/issue/2383
15:50:51 <zbyszek> It seems that the process is being changed in the direction that takes Fedora needs into account more clearly, but it's not possible to say anything more than "seems".
15:51:03 <zbyszek> Anyway, please take a look.
15:52:11 <bcotton> so my question here is "what happens if FESCo is not satisfied with the outcome?" is this intended to be a position statement or more actionable?
15:52:54 <zbyszek> I think we should make a statement on the process.
15:52:59 <bookwar> i agree that we need more info, but i am not sure it can be properly analyzed on the level of requirements and user stories. I'd rather get FESCo involved when there is the proposed architecture, the design, which we can evaluate
15:53:44 <zbyszek> Yes, and the ticket is about the need to make it *possible*, i.e. that the proposal is described and discussed *before* a decision is made.
15:54:16 <bookwar> for now saying "GitLab" means nothing, and i want to give people who are proposing it opportunity to come up with the design, not drowning in the discussions on each of 300 requirements on a hand-wavy level
15:54:38 <zbyszek> The last round went directly from the "let's start gathering requirements" to "the decision has been made".
15:54:45 <bookwar> zbyszek: ok, i need to go through the full text first  :)
15:55:03 <zbyszek> Yeah, let's discuss in the ticket.
15:55:13 <bookwar> any more questions?
15:56:11 <bookwar> if not, closing in a minute
15:57:02 <bookwar> #info Issue #2383: fesco statement on the dist-git change process
15:57:43 <bookwar> #endmeeting