16:00:48 #startmeeting FESCO (2017-08-18) 16:00:48 Meeting started Fri Aug 18 16:00:48 2017 UTC. The chair is kalev. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:48 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:48 The meeting name has been set to 'fesco_(2017-08-18)' 16:00:51 #meetingname fesco 16:00:51 The meeting name has been set to 'fesco' 16:00:53 #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann 16:00:53 Current chairs: Rathann dgilmore jforbes jsmith jwb kalev maxamillion nirik sgallagh 16:00:56 #topic init process 16:01:05 morning 16:01:09 morning everyone 16:01:48 hello .jforbes 16:01:49 apologizes in advance if I suddenly drop off irc: I'm in a moving car :) 16:02:03 not attending today. my term should have been up last week and i don't feel right voting on issues because there was an election mistake. 16:02:05 .hello jsmith 16:02:06 jsmith: jsmith 'Jared Smith' 16:03:48 .hello maxamillion 16:03:48 jwb: I think you should attend, but I can't obviously force you if you feel you don't want to 16:03:48 maxamillion: maxamillion 'Adam Miller' 16:04:01 kalev: nope. i'm done. 16:04:10 ok, fair enough. thanks jwb! 16:04:14 jwb: we are poorer for your absense. :) Thanks for all your service in the past... 16:04:18 hola 16:04:32 nirik: thanks. happy belated birthday to you and maxamillion btw 16:04:43 :D 16:04:44 jwb: thanks for all your work 16:04:44 thanks 16:04:48 jwb: thank you 16:04:58 thanks jwb 16:05:15 ok, let's get started then 16:05:23 first we have two followups 16:05:24 #topic #1737 Proposal: i686 SIG needs to be functional by F27 release date or we drop i686 kernel from F28 16:05:27 .fesco 1737 16:05:28 kalev: Issue #1737: Proposal: i686 SIG needs to be functional by F27 release date or we drop i686 kernel from F28 - fesco - Pagure - https://pagure.io/fesco/issue/1737 16:05:29 https://pagure.io/fesco/issue/1737 16:05:51 I have seen no propsed definition of functional from them 16:06:00 sooooo, two weeks have passed, but I am not sure we can really do anything right now 16:06:15 did anyone actually talk to the i686 sig and say that they need to come up with the proposal? 16:06:32 I didn't see anything on list... 16:06:33 it feels a bit like we are deciding things here in a vacuum and not including people :) 16:06:40 * nirik nods 16:07:08 * jsmith sighs 16:07:18 proposal: extend the deadline for two more weeks. I'll send out a note to the devel mailing list that the i686 sig needs to be functional and try to cc relevant people as well 16:07:42 there might be some more interest kicked up at flock... 16:08:04 kalev: +1, I guess... 16:08:07 ahh, right! forgot about flock. we should probably extend the deadline to be after flock then 16:08:15 yeah, 3 weeks? 16:08:19 when is flock again? I'm not going htis year so not entirely sure 16:08:40 kalev: +1 16:08:49 kalev: in 2 weeks 16:08:58 errr ... 2.5 weeks? 16:09:05 ok, let's make the deadline 3 weeks then? 16:09:06 nope, 2 16:11:03 #info extend the deadline for three more weeks, so that we can start a i686 SIG discussion on devel list and hopefully get a SIG formed at Flock 16:11:16 ok, let's move on then 16:11:26 #topic #1760 F27 approved Changes not in MODIFIED status (considered as not testable) 16:11:29 .fesco 1760 16:11:30 kalev: Issue #1760: F27 approved Changes not in MODIFIED status (considered as not testable) - fesco - Pagure - https://pagure.io/fesco/issue/1760 16:11:31 https://pagure.io/fesco/issue/1760 16:12:08 jkurik listed 3 changes, but as far as I recall, the first two are postponed to until before Beta 16:12:12 so we don't need to do anything about that 16:12:33 I'd like to talk about https://bugzilla.redhat.com/show_bug.cgi?id=1474861 here as well 16:12:38 sure 16:12:42 * kalev clicks on the link 16:12:47 right. Also, pjones was planning to come in today to discuss the 32bit UEFI stuff, but was in transit, so perhaps later when he arrives 16:12:58 jforbes: he appears to have arrived :) 16:13:06 (just barely...) 16:13:11 I see that 16:13:29 tldr: I still want to land this in f27 16:13:46 And I can do it fairly safely, such that if we have a problem we can revert to the current version and it'll work 16:13:47 What's the current status? 16:13:57 pjones: how risky is the change? it is unlikely to cause a f27 slip, right? 16:14:29 kalev: if it gets close to causing a slip, we rebuild shim-signed with the previous version and yank shim-unsigned-x64 until after we ship. 16:14:47 ok, sounds like we should include it in f27 then as it's ready to go 16:15:16 how big are the changes in lorax/anaconda/etc ? 16:15:24 would any of that need backing out? 16:15:29 they're fairly small and they're pretty well tested 16:15:38 and I can make the deps suich that they won't need to be backed out. 16:15:40 such 16:15:51 (they're nearly 100% identical to the rhel-7.4 code and packaging.) 16:16:01 ahh, is it already tested in rhel 7.4? 16:16:10 it's not /quite/ the same, but it's very close. 16:16:26 then I feel we should include it in Fedora as well 16:16:29 proposal: #agreed Include 32bit UEFI Support in F27 16:16:31 +1 16:16:38 +1 16:17:00 woohoo 16:17:24 +1 16:17:31 +1 16:18:30 any more votes / opinions or have we lost quorum here? 16:18:33 +1 16:19:16 #agreed Include 32bit UEFI Support in F27 (+1:5, 0:0, -1:0) 16:19:22 thanks all. 16:19:32 thanks pjones! nice to see that this is ready to land 16:19:45 ok, let's do Java 9 next 16:20:06 no jvanek here, but I think I saw builds in koji already 16:20:16 https://bugzilla.redhat.com/show_bug.cgi?id=1447237 16:21:00 sounds like it's actually already done in F27 and it's just the advertising part here left 16:21:14 and since this is a preview it should be safe to land 16:21:19 * kalev nods. 16:21:40 proposal: #agreed Allow Java 9 as a late exception for F27, as it's already ready to land 16:21:43 +1 16:21:44 +1 16:22:15 +1 16:22:21 +1 16:23:14 +1 16:23:59 #agreed Allow Java 9 as a late exception for F27, as it's already ready to land (+1:5, 0:0, -1:0) 16:24:51 does anyone remember the status of "Bodhi Non-RPM Artifacts", "Graphical Applications as Flatpaks", and "Modular Server" ? 16:25:16 the first two need review 3 days before beta if I recall correctly and not now 16:25:28 what's the Modular Server status, do we need to decide anything here? 16:25:28 * langdon lurks 16:26:56 I thought last week's decision was to revisit in a couple weeks.. But my memory stinks and I'm on mobile 16:27:07 Bodhi non-RPM Artifacts is expected to be ready by bodhi enablement, so we give it a pass today. 16:27:26 extend the deadline for Flatpak to three days before Beta Freeze 16:28:33 Modular Server has no agreement in minutes, I can check the full log 16:28:38 thanks jforbes 16:28:41 I would be shocked if flatpak is ready, however waiting is fine 16:28:50 * nirik thought we likewise agreed to check modular server down the road some. 16:29:16 I remeber reading that it would be checked later in the minutes 16:29:18 dgilmore: last I heard the code is all written and pushed upstream, awaiting code review (however, one of the reviews is for docker-distribution upstream and that's not been fast moving) 16:29:34 jforbes: thanks 16:29:40 maxamillion: it all relies on a bunch of infrastructure updates 16:29:50 that we do not have 16:30:14 Supposedly there was a change to be committed and there should be an image this week, but the official decision was to defer until this week 16:30:33 langdon: update on status there? 16:31:12 I don't think us deciding anything here really changes anything wrt the actual status. sounds like it needs more work and we should do the same as with Flatpak and Bodhi non-RPM Artifacts and just let the work continue 16:31:14 We are still going.. Running in to fun problems but it is still yellow.. Vs red 16:31:20 dgilmore: ah 16:32:02 proposal: #info Modular Server work continues and we'll do another review on the status before the Beta freeze 16:32:09 Current headache is the installer and it's reliance on everything including, at last check, a kitchen sink 16:32:53 Requires: kitchen-sink > 1 tap 16:32:59 kalev: +1 16:33:02 kalev: +1 16:33:04 +1 from me too 16:33:32 #info Modular Server work continues and we'll do another review on the status before the Beta freeze 16:33:47 #info same with Flatpak and Bodhi non-RPM Artifacts as well. 16:33:49 ok, let's move on 16:33:59 #topic #1756 provenpackager request for junghans 16:34:00 .fesco 1756 16:34:00 https://pagure.io/fesco/issue/1756 16:34:01 kalev: Issue #1756: provenpackager request for junghans - fesco - Pagure - https://pagure.io/fesco/issue/1756 16:34:27 we rarely process provenpackager tickets anymore because they are mostly automatic 16:34:34 but when we get a -1 then they need discussion 16:34:43 and there was a -1 vote in the ticket. 16:34:51 yeah, I did see that 16:35:37 nirik: this is mostly about EPEL packaging and you're doing a lot of EPEL work. can you suggest what we should do here? 16:35:59 do we know if there a pattern of these types of things where the packager ignores policy or was it just that one time? 16:36:45 well, I agree it's good to get commits on packages you want to work on... then you see bugs, etc. 16:36:50 I invited junghans and mschwendt join to clarify their positions but I don't think either of them are here 16:37:02 but sometimes there are already active maintainers and you just want to update a stack of things, etc. 16:37:58 nirik: can you suggest a proposal to vote on, please? I don't have a strong opinion either way 16:38:13 the example they mention in ticket seems to have been handed just fine without PP, but I don't know if they have more examples 16:38:23 I agree with mschwendt here 16:38:30 Yeah, it's hard to tell. 16:38:46 I think becomeing a comaintainer is best given the types of changes he is proposing 16:38:56 kalev: I'm not sure I do either. Perhaps if they had more examples where PP would help them? 16:40:05 I guess I'm going back and forth between "comaintainer instead" and "provenpackager with warning about communications before making drive-by changes" 16:40:32 Perhaps defer another week for more input on other situations where PP would help them? 16:40:42 sure 16:40:46 More input would be good 16:41:01 as it stands, I am inclined to deny 16:41:05 I guess I'm in the same boat, along with us saying we wouldn't set all that high a bar for provenpackager when we first created it 16:41:56 sure, let's defer then 16:42:08 * nirik is +1 to asking them in ticket if pp has more needs for them or if they can just be comaintainer 16:42:13 and waiting 16:42:16 nirik: +1 16:42:43 +1 16:43:28 nirik: +1 16:43:46 +1 16:43:52 #info FESCo defers the decision for a week. We'd like to know if it would be enough for the requester to be co-maintainer for the packages they want to work on or if they have other needs to become a PP. 16:44:21 ok, moving on 16:44:21 #topic #1759 Approval for packaging 'xpra.socket' file 16:44:21 .fesco 1759 16:44:21 https://pagure.io/fesco/issue/1759 16:44:25 kalev: Issue #1759: Approval for packaging 'xpra.socket' file - fesco - Pagure - https://pagure.io/fesco/issue/1759 16:45:20 sgallagh suggests in the ticket to disable xpra.socket in the default preset 16:45:41 yeah, I agree with sgallagh 16:46:06 same 16:46:25 I am going to have to agree, not by default 16:46:31 * kalev nods. 16:46:45 Agreed 16:46:56 same here 16:47:31 proposal: #agreed FESCo votes on "no" to enabling xpra.socket by default. The convenience of the user not having to type systemctl enable xpra.socket in any way outweighs the potential risks of adding a new network-listening service to autostart. 16:47:43 * kalev stole sgallaghs wording :) 16:48:00 :-) 16:48:20 +1 16:48:29 +1 16:48:31 +1 16:49:37 #agreed FESCo votes on "no" to enabling xpra.socket by default. The convenience of the user not having to type systemctl enable xpra.socket in any way outweighs the potential risks of adding a new network-listening service to autostart. (+1:6, 0:0, -1:0) 16:49:38 +1 16:49:48 * kalev counted all the "agreed" abovce and sgallagh's vote in the ticket as well. 16:50:02 #topic #1763 Fedora Modules Guidelines and Process 16:50:02 .fesco 1763 16:50:02 https://pagure.io/fesco/issue/1763 16:50:03 kalev: Issue #1763: Fedora Modules Guidelines and Process - fesco - Pagure - https://pagure.io/fesco/issue/1763 16:51:25 have we had a discussion on the -devel list about this? I feel like this might need a bit more time for people to read through 16:52:09 langdon: are you in a hurry with getting this approved or can this wait a bit while we have a discussion on the devel list? 16:52:12 I haven't seen one 16:52:19 I'm mostly worried about the process part.. Which is basically a clone of the container one.. The guidelines will evolve over time 16:52:49 Right now, we can't let anyone else make modules.. Which is a bit tough.. 16:53:06 note, the container one still has a lot of room for improvement 16:53:34 we probably should figure out something to let people start on modules 16:53:52 having tools to verify module validity on commit would be awesome 16:54:29 running checks on specs when commiting to ensure compliance with~ packaging guidelines would rock as well 16:55:11 We have the beginnings of those.. But they need work 16:55:29 We want to make the review process almost completely automated 16:55:38 langdon: +1 16:55:44 that would be fantastic 16:55:55 automated would be awesome 16:56:12 Basically only involve a human on failures/exceptions 16:57:05 langdon: could you kick off a devel list discussion and we can then discuss this again next week? 16:58:03 Sure.. But I am not sure what the discussion is about.. Maybe I'm dumb? 16:58:41 Like reviewing guidelines? Process? Something else? 16:59:06 just a quick email that you've written up the guidelines and process and ask if anyone has any comments 16:59:37 Ahh gotcha.. /me feels like he did that a while back.. 16:59:52 But.. Should do it again now that it is more real 17:00:32 Thanks. I think that would be a good idea to do it again now, yep. 17:00:40 And definitely didn't do the process as I made it up last week.. By cribbing from Adam :) 17:01:11 langdon: I made it up as I went .... it'll be fine ;) 17:01:22 Ha 17:01:55 proposal #info We'll discuss this again next week. langdon will ask -devel list for feedback and FESCo members will read through the guidelines as well in the mean time. 17:02:09 +1 17:02:16 I read through them, other than having no idea if the guidelines are good or bad (I'm assuming y'all know what you're recommending for the thing you invented), it all looked good to me 17:02:23 +1 17:02:38 +1 17:02:58 #info We'll discuss this again next week. langdon will ask -devel list for feedback and FESCo members will read through the guidelines as well in the mean time. 17:03:01 ok, let's move on then 17:03:04 #topic #1764 new orphan packages: gnome-shell-extension-sustmi* 17:03:06 .fesco 1764 17:03:06 https://pagure.io/fesco/issue/1764 17:03:07 kalev: Issue #1764: new orphan packages: gnome-shell-extension-sustmi* - fesco - Pagure - https://pagure.io/fesco/issue/1764 17:04:24 I feel like we often get nonresponsive maintainer tickets where people do some parts of the process, but not the whole thing 17:04:31 kalev: yeah 17:04:53 * langdon goes back to his lunch 17:05:02 thanks langdon 17:05:19 Yeah.. Just mention if you want/need me back 17:05:43 yeah, although to be fair, the process is anoying and error prone 17:06:04 * kalev nods. I wonder if we should maybe improve the documentation with how to exactly do that. 17:06:14 anyway, in this case it looks like the packager has been gone for several years already 17:06:20 agreed 17:06:36 I'm a +1 to orphan given the circumstances 17:06:44 * kalev nods. 17:06:47 yeah, +1 to orphan their packages (they also have another extension) 17:06:49 +1 as well 17:07:00 +1 17:07:14 and sugar-calendario 17:08:24 proposal: #agreed Orphan all yaderv's packages 17:08:31 +1 17:08:34 +1 17:10:18 #agreed Orphan all yaderv's packages (+1:5, 0:0, -1:0) 17:10:27 ok, moving on 17:10:35 #topic #1765 Proposed Fedora 28 schedule 17:10:36 .fesco 1765 17:10:36 https://pagure.io/fesco/issue/1765 17:10:39 kalev: Issue #1765: Proposed Fedora 28 schedule - fesco - Pagure - https://pagure.io/fesco/issue/1765 17:11:15 mattdm: around? you ok with the proposed schedule? 17:12:12 is this the one that had all the discussion on devel a while back? 17:12:22 my only concern here is that we have a major deadline a week after christmas shutdown 17:12:22 mboddu: ping - anything from the proposed schedule jump out at you from a releng standpoint? https://pagure.io/fesco/issue/1765 17:12:35 dgilmore: yeah, good point 17:12:35 many people will not look at filing changes until the new year 17:12:54 I think mass rebuild is also too early for gcc glibc 17:13:13 not sure, I haven't followed the devel list very much recently 17:13:26 I also wonder if we should not remove the software string freeze, it has been years since we have really done that right 17:14:17 probibly it should get another round of discussion and input from tools folks, etc. 17:14:20 dgilmore: do you want to put your questions in the ticket and cc gcc/glibc people? 17:14:34 and I'd like a clear +1 from mattdm as well 17:15:04 kalev: +1 17:15:22 kalev: done 17:15:27 thanks dgilmore 17:15:54 #info This needs more discussion. We'll revisit again next week. 17:16:07 ok, that concludes today's topics 17:16:10 #topic Next week's chair 17:16:24 who wants to chair next week? 17:16:29 I can take next week, I haven't done one in a few 17:16:39 #info maxamillion to chair next week 17:16:47 #topic Open Floor 17:16:55 anyone got anything to discuss? 17:17:13 not I 17:17:52 * nirik is looking forward to flock, hopefully many of you will be there. 17:18:02 Yup, looking forward to it 17:18:03 * dgilmore will be at flock 17:18:11 when is the new election over? 17:18:18 * maxamillion will be at flock 17:18:19 Tuesday I think 17:18:32 08-21 17:18:49 ah, then we should have new fesco next time 17:19:44 I suggest we have the first fesco meeting with new members at the usual time next week and then see if it needs moving to accomodate all the new people 17:20:03 maxamillion: I think dgilmore already mentioned the concerns from releng perspective. gcc glibc are my concerns as well. 17:20:30 mboddu: yeah, he did 17:20:36 thanks mboddu for checking 17:20:41 mboddu: thank you 17:20:56 kalev: +1 17:21:19 alright, thanks for coming everybody! 17:21:19 #endmeeting