15:01:00 #startmeeting FESCO (2019-08-19) 15:01:00 Meeting started Mon Aug 19 15:01:00 2019 UTC. 15:01:00 This meeting is logged and archived in a public location. 15:01:00 The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:00 The meeting name has been set to 'fesco_(2019-08-19)' 15:01:01 #meetingname fesco 15:01:01 The meeting name has been set to 'fesco' 15:01:01 #chair nirik, ignatenkobrain, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor 15:01:01 Current chairs: bookwar contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek 15:01:03 #topic init process 15:01:04 .hello2 15:01:04 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 15:01:09 .hello2 15:01:10 jforbes: jforbes 'Justin M. Forbes' 15:01:12 .hello2 15:01:13 .hello2 15:01:13 sgallagh: sgallagh 'Stephen Gallagher' 15:01:16 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:01:17 .hello2 15:01:19 bcotton: bcotton 'Ben Cotton' 15:01:26 .hello psabata 15:01:28 contyk: psabata 'Petr Šabata' 15:01:33 We have quorum. 15:01:50 Anyone else? 15:02:15 morning 15:02:39 OK, let's start. 15:02:44 #topic #2180 F31 System-Wide Change proposal (late): No i686 Repositories 15:02:48 .fesco 2180 15:02:49 zbyszek: Issue #2180: F31 System-Wide Change proposal (late): No i686 Repositories - fesco - Pagure.io - https://pagure.io/fesco/issue/2180 15:03:49 okay, so 15:03:53 did we get all the info we wanted here? 15:03:58 We did not. 15:04:10 there is a way to build i686 modules without i686 repos; it's not user friendly but it's possible 15:04:25 we determined that it was sufficient; that was during the modularity session 15:04:38 Considering how infrequently this is going to have to be done, I okay with this 15:04:50 most likely never, yes 15:05:02 but it needs to be documented by someone who understands MBS :) 15:05:06 yeah, very low numbers I suspect 15:05:30 I couldn't be in the modularity session because of scheduling conflicts, sadly. 15:05:51 * nirik also. :( 15:06:14 If you all think that the work-around is sufficient, I'll defer to your opinion on this. 15:06:30 MBS lets you build against a different base repo (and maps it to the platform module) and lets you set the arch in its config under /etc; there isn't a cli option for that 15:06:34 but it's achievable 15:06:42 contyk: can you document the work-around somewhere? 15:06:59 I'm +1 as long as we have somewhere documentation which describes how to build that. Also pretty sure not many people will do that. 15:07:13 it needs to be documented, yes; but I'd defer to the MBS devs for that 15:07:18 +1 what ignatenkobrain said 15:08:11 Hmm, I wouldn't want to approve the change, and then see the docs deferred indefinitely. 15:08:39 Who would be responsible for the docs? 15:09:14 I see asamalik is here 15:09:48 asamalik: do you think it would make sense to describe these things on the upstream modularity docs website? or should it go elsewhere? 15:09:49 if he could do docs on this that would be great. 15:10:41 proposal: Change is approved. Change owner has to make sure somebody updates the docs somewhere. 15:10:56 +1 15:11:15 I can ask/make sure. 15:11:27 nirik: sorry to dump this on you, but there are no volunteers, and you are the owner ;) 15:11:31 +1 15:11:41 Also the default person to go to when things break ;) 15:11:56 +1 ;) 15:12:03 sure, it's fair. 15:12:32 sgallagh? 15:12:39 * sgallagh was +1 above 15:13:01 * nirik adds a task to the list 15:13:10 #agreed Approved. Change owner has to make sure somebody updates the docs somewhere. (+6, 0, 0) 15:13:20 #topic #2172 F31 Self-Contained Change: Limit Scriptlet Usage of core packages 15:13:23 .fesco 2172 15:13:24 zbyszek: Issue #2172: F31 Self-Contained Change: Limit Scriptlet Usage of core packages - fesco - Pagure.io - https://pagure.io/fesco/issue/2172 15:13:49 I put this on the agenda because I'd like to see something happen in this area, but the change is still very vague. 15:14:14 well, it's a lot more focused than before.... 15:14:21 minimal container image packages 15:14:43 I've asked James to join us here 15:15:16 thanks 15:15:19 hey 15:15:20 geppetto: Welcome 15:15:33 geppetto: we're discussing 15:15:36 so, geppetto is the change owner :) 15:15:37 .fesco 2172 15:15:38 zbyszek: Issue #2172: F31 Self-Contained Change: Limit Scriptlet Usage of core packages - fesco - Pagure.io - https://pagure.io/fesco/issue/2172 15:15:42 * geppetto nods 15:17:28 Are there questions? 15:17:55 is it known what packages will be affected? 15:18:31 How do you want to replace the scriptlets? 15:18:33 Yes, there's a link to a wiki page... 15:18:40 nirik: https://fedoraproject.org/wiki/JamesAntill/ScriptletUsage 15:18:54 ah ha. 15:19:18 Are you saying that all those scriptlets are unecessary, or do you have specific replacement mechanism ready? 15:19:25 nirik: https://fedoraproject.org/wiki/JamesAntill/ScriptletUsage 15:20:35 zbyszek: I thought there were dropin replacements, for users/tmp-files … but later found out we need to create the rpm file trigger programs, which hasn't been done yet 15:21:03 zbyszek: It's likely that page won't be empty by F31 … but will hopefully be smaller. 15:21:32 geppetto: it's worse than that. There are specific concerns how to make those things work smoothly. 15:21:58 In https://bugzilla.redhat.com/show_bug.cgi?id=1740545 mock tried to switch to sysusers, and in the end reverted back to useradd, because that's simply easier to use. 15:22:24 There is the idea to adopt the opensuse (or was it mandriva?) approach of using a separate subpackage. 15:22:37 But somebody would need to figure this out, create some macros, write docs, etc. 15:23:06 * geppetto nods 15:23:37 sounds like a lot of work for f31 15:23:51 but good to do. 15:23:56 For alternatives, there's an idea to convert to declarative files in /usr/lib, systemd-style, but again, somebody needs to write the code. 15:24:20 I am under the impression that this will not be done by F31, but I don't see any harm in starting the process now, and making this a multi-release spanning change 15:24:33 jforbes: +1 15:24:36 zbyszek: Didn't we hear at DevConf this year that Debian already has a mechanism for that? 15:24:41 Can we adopt it? 15:24:41 zbyszek: yeh, alternatives wasn't ever assumed we could do for F31 15:25:04 sgallagh: I missed that. If they have, and we could use it, that'd be great. 15:25:05 jforbes: This is actually sounding more like an Objective than a Change 15:25:15 sgallagh: yes 15:25:31 I mean, I'm happy to approve the change, but not as a blanket ticket. If all the individual changes are approved by maintainers of specific packages, then that'd be enough for me. 15:25:34 sgallagh: That's fair … I didn't know about an objective though … so I went with a change. 15:26:48 feels a bit too narrow and specific to be an objective, though :) 15:26:53 * contyk shrugs 15:27:03 yeah... 15:27:12 contyk: Or our Objectives have been too broad and hard-to-define-success-for :) 15:27:20 anyhow, any more info needed, or shall we vote ot ? 15:27:27 yeah, I think a change is fine. 15:27:36 OK, I'm fine with it as-is 15:27:39 +1 15:27:45 +1 here 15:28:06 contyk: yes, I was connected, but not really here :) 15:28:06 One thing: 15:28:17 > After this change it'd be good to have some kind of temporary exception to be granted before those packages could add a scriptlet back (post F31 work). 15:28:27 +1 here 15:28:50 I assume that we are NOT approving that, i.e. no exception process would be required? 15:28:55 myself I would be more happy if this would be F32 thing. So I'll abstain for F31. 15:29:48 Hmm, the description says: 15:29:50 > Remove direct scriptlet calls from "core packages" (those that are used to build minimal container image). The packages can still affect changes during installation by placing files in the correct locations to trigger registered external programs. 15:29:52 contyk: to your original question: I think it would make sense to have it in the docs, but someone who actually knows the steps would need to send a PR 15:29:54 do we review scriptlet adding now? I would expect it would be the same as normal? 15:30:08 No, we don't. 15:30:20 And I don't think we should start, that's too much micromanagment. 15:30:23 asamalik: yeah, I was thinking probably jkaluza :) 15:31:07 What the description says, is not really true. sysusers does not work sufficiently well, and the same is true for other potential replacements of scriptlets. 15:31:11 re:the change, I'm also abstaining; the prep work can definitely start now but I wouldn't be comfortable pushing all those changes into 31 15:31:25 If we approve this change, people will be misled by this. 15:31:28 Both users and packagers. 15:32:08 As the person on systemd side who wrote some of those macros, I don't want to "advertise" this, when it's not really ready yet. 15:32:39 zbyszek: Do you not think it can be fixed? 15:32:46 contyk: +1 15:33:38 hey, sorry, I had my notifications on quiet :( 15:33:43 geppetto: I'm pretty sure it can be fixed, but that's not what the Change page says :) 15:33:48 mhroncok: welcome back 15:34:06 zbyszek: I meant the systemd side 15:35:30 Well, the code should be ready *now*, and 100% complete deadline is 29/08. 15:36:05 I cannot commit to working on this during the next two weeks. 15:36:43 Ahh, yes, that's fine … I thought you meant you thought it couldn't be fixed for F32 or later. 15:37:19 I'm also +1 to contyk 15:37:51 well, so perhaps we should ask to rescope this to f31 and another followon for f32? 15:38:01 wfm 15:38:07 or do you think it should just all be in f32 now? 15:39:35 I'd make it an f32 change, approving it now 15:39:44 contyk: +1 15:39:46 whatever prep work is needed can begin right away 15:39:56 geppetto: can you rescope it into parts that can be done for F31, and the rest for F32? 15:40:59 zbyszek: It's probably easier to just do what contyk said … we can still do things, even if it's a F32 change 15:41:13 OK. 15:41:39 So we have +4 for contyk 15:41:58 nirik, sgallagh? 15:42:09 +1 15:42:14 jforbes? 15:42:15 I can +1 that 15:42:20 +1 15:42:31 ignatenkobrain: I counted you already 15:42:37 +1 15:42:39 zbyszek: just to make it clear :) 15:43:12 Then we end up with 111% votes in favour, that doesn't look good. 15:43:49 #agree Change is approved for F32 (+7, 0, 0) 15:44:01 #topic #2149 Proposal to change non-responsive maintainer policy 15:44:04 .fesco 2149 15:44:05 zbyszek: Issue #2149: Proposal to change non-responsive maintainer policy - fesco - Pagure.io - https://pagure.io/fesco/issue/2149 15:44:14 I meant to merge the PRs before this meeting, but didn't make it. 15:44:25 But I think it's all good in general. 15:44:49 Bugzilla templates have been created. 15:45:03 we should also announce to devel-announce? 15:45:20 nirik: we should. I'll do that. 15:45:38 #action zbyszek to send an announcement to devel-announce 15:45:54 I think we should move on, unless there's more comments. 15:46:12 #topic #2211 Fedora 32 schedule 15:46:16 .fesco 2211 15:46:17 zbyszek: Issue #2211: Fedora 32 schedule - fesco - Pagure.io - https://pagure.io/fesco/issue/2211 15:46:30 There was a good question in the ticket: why late April, not early May? 15:46:35 bcotton^ 15:46:40 for symmetry mostly 15:47:23 i looked back at the schedules for previous may-ish releases, and we end up anywhere between april and july in the last few years 15:47:58 Is everyone OK with adding the gpg keys item to the schedule? 15:48:06 I am 15:48:30 my first pass at it had it a week later (4th week of april, with a "target #1" of first week of may), but i figured "3rd tuesday of $month" was easier 15:48:31 I am 15:48:35 I am 15:48:36 plus, there's a marketing aspect to it 15:48:52 OK, I'm +1 (with the addendum) 15:48:58 zbyszek: gpg keys +1 15:49:07 people don't seem to understand that april and may are adjacent months, so a late april date that slips to early may gets blown out of proportion :-) 15:49:23 the gpg keys item is a releng task, right? 15:49:44 yes 15:50:14 okay, i'll add that 15:50:50 nirik, jforbes, ignatenkobrain, contyk, your +1's ? 15:51:06 +1 15:51:14 +1 15:51:15 +1 15:51:41 +1 15:52:00 I was +1 in the ticket, but I'll add it here anyway 15:52:20 sgallagh: ack 15:52:24 #agreed Approved (with the gpg keys addendum) (+7, 0, 0) 15:52:24 #action bcotton to add the gpg keys item to the schedule 15:52:35 #topic #2207 Questions about the 7 day waiting period in Bodhi 15:52:35 .fesco 2207 15:52:38 zbyszek: Issue #2207: Questions about the 7 day waiting period in Bodhi - fesco - Pagure.io - https://pagure.io/fesco/issue/2207 15:52:41 zbyszek: one sec 15:52:47 #undo 15:52:47 Removing item from minutes: 15:53:13 zbyszek: for clarity, does the approval apply to both the f32 schedule and the "let's assume we're going to follow the same schedule every time unless we say otherwise" part of the proposal? 15:53:22 Oh, right. 15:53:37 This wasn't clear. +1 to both. 15:53:46 I was +1 to both 15:53:47 so am I 15:53:49 if we slip a release by let's say a month, what usually happens with the next one? 15:54:00 mhroncok: we try to recover 15:54:03 * nirik was also... if we need to adjust we can 15:54:20 #undo 15:54:20 Removing item from minutes: ACTION by zbyszek at 15:52:24 : bcotton to add the gpg keys item to the schedule 15:54:22 mhroncok: we don't slip by a month anymore ;-) i'd say for a month or less, we'd just move on. if it's more than a month, then we open a discussion about shifting the next release 15:54:24 #undo 15:54:24 Removing item from minutes: AGREED by zbyszek at 15:52:24 : Approved (with the gpg keys addendum) (+7, 0, 0) 15:54:44 ok, in that case, consider me +1 for the permanent change as well 15:54:59 similarly, if the "let's skip a release to work on tooling" proposal comes around again, that would require explicit fesco approval 15:55:07 Right. 15:55:15 ditto for re-adding an alpha release or deciding to drop beta and only do GA or... :-) 15:55:21 OK, I'll assume that we all agree. 15:55:24 #agreed Approved (with the gpg keys addendum). Schedule is assumed to apply forever until changed. (+7, 0, 0) 15:55:27 #action bcotton to add the gpg keys item to the schedule 15:55:36 #topic #2207 Questions about the 7 day waiting period in Bodhi 15:55:36 .fesco 2207 15:55:37 zbyszek: Issue #2207: Questions about the 7 day waiting period in Bodhi - fesco - Pagure.io - https://pagure.io/fesco/issue/2207 15:55:59 thanks zbyszek :) 15:56:10 thanks bcotton ;) 15:56:18 thanks everyone! :-D 15:56:31 There's a number of good points in the discussion. 15:56:38 as I noted in the ticket I am strongly against changing this/voting on anything that hasn't had a full discussion on devel first. We spend ages getting to this current setup, I don't think we want to change it without well thought out and widely accepted consensus. 15:57:31 mhroncok: do you think you could do a write-up of the salient points and send it out to fedora-devel? 15:57:57 there's also some misconceptions there... like that updates with no karma aren't tested. 15:58:05 I also would like to see full devel discussion first. While I hate the 7 day timeline, kernel updates more frequently than that, and the oldest release doesn't get karma, kernel is not a typical package 15:58:27 zbyszek: I could but I'd rather somebody what wants this do it 15:58:31 +1 to start discussion at devel@ first and +1 for finding ways how to shorten the period of testing :_ 15:58:35 *who wants this 15:58:57 Oh, sorry, I thought you opened the ticket, but that was bex. 15:59:35 bexelbie, around? 16:00:30 i haven't seen him around much in the past week or so 16:00:58 I can take this with bex offline 16:01:08 ignatenkobrain: cool. 16:01:26 If he can't do it, I guess I could write the mail to fedora-devel too. 16:01:37 I don't lack opinions on the subject ;] 16:02:00 :) 16:02:00 #action ignatenkobrain to talk with bexelbie about starting a discussion on fedora-devel. 16:02:20 Should we move on? 16:02:24 yes 16:02:31 #topic Next week's chair 16:02:38 Volunteers? 16:02:42 I can do it 16:02:51 #action jforbes is "it". 16:03:01 #topic Open Floor 16:03:15 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NKFYAWL4GWYR37C6XA63JMNBZYEM6BI3/ 16:03:55 I'm trying to collect feedback fro the FTBFS policy, as clearly, it currently makes people scared 16:04:18 mhroncok: I love the work you are doing. You have at least one fan. 16:04:26 I think right now is kinda a bad time due to a lot of things hitting at once. 16:04:37 I've started on devel instead of opening a fesco ticket, but I intent to open one later. would be good if fesco participated in the thread 16:04:46 ftbfs for the first time in a while, python2 retiring, fails to install, etc. 16:05:18 mhroncok: I also really appreciate you doing the work. :) I hope we can come up with some better way to make people more happy 16:05:34 there is an "idea proposal" at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KXKSG3JQ4HRJDRIEEQ5IXZFDZNJRGQNV/ 16:06:26 zbyszek, nirik: thanks 16:06:54 I'm wondering if we couldn't do something better outside bugzilla... but I guess it would be email based too... 16:07:36 I don't think 1.5 years to fix FTBFS makes sense. 16:07:39 IMHO there's not hope for maintainers that put bugzilla to /dev/null 16:07:55 For the package itself, that might be OK, but it creates a burden for everyone else. 16:08:35 Dependent packages, reverse dependencies that need a rebuild, security fixes, mass rebuilds, etc. 16:09:36 zbyszek: I agree. OTOH the maintainer should be able to say: "not this time, sorry. if it actually blocks you, let me know" 16:09:53 (not for ever of course) 16:10:23 majority of the pacakges were retired when the bugizlla was NEW anyway 16:11:21 So packages with FTBFS/NEW would be retired as previously, but if the matainers resets to ASSIGNED every 6 months, then we'd wait? 16:12:18 * nirik doesn't think we are going to solve it today. 16:12:24 nirik: agreed 16:12:39 zbyszek: if you want to chat about this, we can continue later 16:13:01 mhroncok: I'll reply on fedora-devel. I meant to, but then ... other things. 16:13:30 zbyszek: ack 16:13:41 I have something... 16:13:53 A comment on the process: when we didn't have the meeting last week, 16:13:53 I sent out a short mail to fedora-devel mentioning that the meeting is 16:13:53 cancelled. But I think we should also send out announcements for 16:13:53 approved changes, even if the meeting doesn't take place. This way 16:13:53 people don't have to wait to changes to go through the process as 16:13:55 long. 16:14:09 I think that is fair 16:14:31 Would everyone be OK with doing that the next time this happens (Christmas or Thanksgiving prolly)? 16:14:42 zbyszek: do we only consider the changes really approved once announced? 16:14:45 Though realistically, I expect people with those changes don't wait until announcement, they know when it is approved in the ticket 16:14:51 that 16:15:14 yes 16:15:26 for Change proposals, i start processing them once the approval threshold is reached in the ticket, so i'm indifferent. for policy changes and the like, i think it would be good to send the announcement anyway for the reason given 16:15:31 I'm not strongly against announcing even when the meeting is not happening. I just don't consider it important. 16:15:41 OK. 16:16:35 Anyway, I guess it'll be up to the person who is the chair the next time when such a situation occurs. 16:16:42 Anything else? 16:16:51 If not, I'll close in 1 minute. 16:17:41 #endmeeting