17:00:19 #startmeeting FESCO (2016-02-12) 17:00:19 Meeting started Fri Feb 12 17:00:19 2016 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:19 The meeting name has been set to 'fesco_(2016-02-12)' 17:00:19 #meetingname fesco 17:00:20 The meeting name has been set to 'fesco' 17:00:20 #chair maxamillion dgilmore number80 jwb nirik paragan jsmith kalev sgallagh 17:00:20 #topic init process 17:00:20 Current chairs: dgilmore jsmith jwb kalev maxamillion nirik number80 paragan sgallagh 17:00:27 .hello kevin 17:00:28 nirik: kevin 'Kevin Fenzi' 17:00:34 .hello sgallagh 17:00:35 sgallagh: sgallagh 'Stephen Gallagher' 17:00:39 .hello pnemade 17:00:40 paragan: pnemade 'Parag Nemade' 17:01:00 hi 17:01:46 .hello maxamillion 17:01:47 maxamillion: maxamillion 'Adam Miller' 17:02:57 That's quorum, but I'll wait a couple more minutes before diving in 17:04:16 hello 17:04:22 .hello hguemar 17:04:24 number80: hguemar 'Haïkel Guémar' 17:05:13 OK, let's get started 17:05:40 Do we want to do the rubber-stamping of Changes first or the more involved tickets? 17:05:58 Changes first 17:06:24 Works for me 17:06:32 #topic #1478 F24 Self Contained Changes 17:06:32 .fesco 1478 17:06:37 sgallagh: #1478 (F24 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1478 17:07:10 all seem fine to me 17:07:26 I'm +1, but would love it if gnome-software and dnf could cooperate on history. It's becoming an anoying issue. ;) 17:07:36 I think the graphical system upgrade one is actually a System-Wide change 17:07:55 Since it's likely to impact systemd's offline updates mode 17:08:06 I'm +1 for both, of course 17:08:33 +1 17:08:42 +1 to both 17:08:44 +1 to all 3 (includes Atomic Developer mode change) 17:09:21 Oh right. I forgot the Developer one was from last week 17:09:43 ah yes 17:10:03 Proposal: Graphical System Upgrades, Shenandoah and Atomic Developer Mode are approved. 17:10:07 (Just for the record) 17:10:19 I'm +1 on Atomic Developer Mode also with the previous concerns having been addressed in the Change Wiki page by the Change Owner 17:10:20 I was already for the ADB change 17:10:42 so still +1 for all of them 17:10:51 +1 to all 3 17:10:56 +1 to proposal 17:11:12 +1 to sgallagh's proposal 17:11:46 +1 to sgallagh's prosal 17:12:13 #agreed Graphical System Upgrades, Shenandoah and Atomic Developer Mode are approved. (+6, 0, -0) 17:12:24 #topic #1540 F24 System Wide Change: Langpacks Installation With RPM Weak Dependencies 17:12:25 .fesco 1540 17:12:28 sgallagh: #1540 (F24 System Wide Change: Langpacks Installation With RPM Weak Dependencies) – FESCo - https://fedorahosted.org/fesco/ticket/1540 17:12:40 +1 17:12:49 +1 17:12:50 +1 17:12:59 +1 17:13:08 +1 17:13:19 +1 17:13:37 #agreed "Langpacks Installation With RPM Weak Dependencies" is approved (+6, 0, -0) 17:13:47 #topic #1541 F24 System Wide Change: LiveUserCreator as Primary Downloadable 17:13:47 .fesco 1541 17:13:48 sgallagh: #1541 (F24 System Wide Change: LiveUserCreator as Primary Downloadable) – FESCo - https://fedorahosted.org/fesco/ticket/1541 17:14:14 This ticket is named wrong; that should be LiveUSBCreator. 17:14:22 yup 17:14:34 Fixed on Trac 17:14:51 I'm fine with it but the missing warning is for me a release blocker 17:15:14 OK, two proposals then: 17:15:47 What all is going to be required of RelEng and the Websites team for this? and have those requests been placed and accepted? (or is that out of the scope of FESCo?) 17:15:47 Proposal 1) LiveUSBCreator will become the primary download for Fedora Editions 17:16:19 maxamillion: the change page lists some of that... nothing has been filed yet since it's not accepted yet I would imagine. ;) 17:16:21 maxamillion: I *think* it should be just the Websites team. The LUC will pull the normal ISOs and consume them 17:16:48 nirik: Right, but rel-eng doesn't like Changes that require them to do work going to FESCo before they have been notified and weighed in 17:16:49 Fedora Editions? 17:16:50 sgallagh: do we need LUC signed in any way? 17:17:02 nirik: Feel free to counter-propose. 17:17:23 maxamillion: Good question. 17:17:24 I meant, what do you mean by that? is there some definition I am not aware of? 17:17:38 maxamillion: " Live USB Creator for Windows (pretty much ready, we just need to get a signing key) " 17:17:47 seems like it does 17:17:51 nirik: Fedora Cloud, Fedora Server, Fedora Workstation are the Fedora Editions 17:18:13 I was explicitly trying not to make a judgment about spins at this juncture 17:18:21 I can't see how this makes sense for cloud... and might not for some server cases 17:18:37 in fact I don't think it does any non live media does it? 17:18:54 nirik: It works just fine on any ISO format 17:19:04 I've used it with Server DVD on numerous occasions 17:19:14 it still doesn't make sense on cloud 17:19:27 jwb: Well, it might for Atomic-on-bare-metal 17:19:29 because cloud requires the data cloud-init wants. i don't think LUC is going to shove that in there 17:20:17 I'm fine with Editions and let people use common sense, current Cloud edition is not a target for LUC 17:20:26 Atomic as sgallagh said might be in the future 17:20:34 currently the download list is anoying... 17:21:25 Let's back up a moment and address the root cause of this effort. 17:21:47 how about primary download for Spins, Workstation and Server? 17:21:52 * Users are trending away from burning to actual plastic spinning disks 17:22:14 * There are multiple ways of creating a USB install medium, each of which we have to test and approve 17:22:54 The goal of this is to limit our testing and approval to a single, blessed mechanism (ideally one that can be collaborated on with other distros, but branded for ours) 17:23:13 We can probably approve this much without dictating any change to Website prominence 17:23:43 Though we'll still want to make sure Websites updates and instructions on how to install Fedora using the blessed method 17:23:52 s/and/any/ 17:24:54 the change actually doesn't talk about any of that. ;) 17:25:10 yeah, I'm mostly on board ... just worried about "implementation details" 17:25:14 ie, getting rid of other methods in favor of this one, etc. 17:25:14 yeah 17:25:39 I'm fine with the change, just don't think it should apply to cloud. 17:25:49 nirik: OK, so should we make a request to get them to clarify those points and revisit it later? 17:26:19 sgallagh: +1 17:26:48 we could I guess. The dropping other methods might just be a different change? I suppose it's pretty related tho 17:27:15 would be good to know more about signing for windows/osx and any releng needs there too. 17:28:13 nirik: it doesn't 17:28:24 Yeah, I think we need those questions answered before I vote here. 17:28:29 number80: hum? 17:28:32 btw, I remembered why I didn;t file a ticket for the warning 17:28:42 oh, cloud, right. 17:29:04 development is not hosted on fedorahosted and there's no place where to file tickets ... 17:29:16 note that this change talks about the new redesigned one... which isn't actually available yet anywhere that I know of. So details about UI and dialog are likely not too accurate based on the current one. 17:29:35 Well, both Windows and OSX will put up a warning that the binary is unsigned, but I don't know if that's a blocker. 17:29:43 oh, there's a copr... 17:29:49 https://github.com/MartinBriza/liveusb-creator 17:29:52 ha, with 0 builds 17:30:09 I did try copr builds last week :/ 17:30:24 https://copr.fedorainfracloud.org/coprs/mbriza/liveusb-creator/ 17:30:27 no, there' s a few 17:30:51 proposal: defer to next week 17:30:54 anyhow, +1 to defer, ask more info. 17:30:56 I'm +0.5 with this, but it needs to have a canonical place first 17:31:01 +1 to jwb proposal 17:31:18 +1 to jwb proposal 17:31:24 Does someone want to volunteer to go ask the right questions? 17:31:32 +1 defer to next week 17:31:38 /me is going to be on vacation next week, so I won't be able to 17:31:51 sgallagh: I CC'ed Jiri and Martin on the tickets, I can try 17:31:58 number80: it has a canonical place. github. 17:32:21 jwb: it's not reflected in the spec file and has issue tracker disabled 17:32:35 * jwb shrugs 17:32:59 the new ui is much much nicer. 17:33:03 #action number80 to contact the LUC Change Owners and get clarification on points discussed here 17:33:11 *nods* 17:33:45 jwb: +1 17:33:45 #agreed Defer one week to gather information (+5, 0, -0) 17:33:59 #topic #1543 F24 System Wide Change: Mono 4.2 17:33:59 .fesco 1543 17:34:00 sgallagh: #1543 (F24 System Wide Change: Mono 4.2) – FESCo - https://fedorahosted.org/fesco/ticket/1543 17:34:26 +1 17:34:36 +1 17:34:40 +1 (most of the work is already done) 17:34:50 +1 17:34:58 This should be a Self-Contained Change 17:35:02 But +1 17:35:10 +1 17:35:28 #agreed Mono 4.2 is approved (+6, 0, -0) 17:35:32 #topic #1545 F24 System Wide Change: The GNU C Library version 2.23 17:35:32 .fesco 1545 17:35:37 sgallagh: #1545 (F24 System Wide Change: The GNU C Library version 2.23) – FESCo - https://fedorahosted.org/fesco/ticket/1545 17:35:51 +1 17:36:00 It's also pretty much already there 17:36:00 +1 17:36:01 +1 17:36:02 +1 17:36:07 +1 17:37:50 #agreed glibc 2.23 is approved (+5, 0, -0) 17:37:55 #topic #1546 F24 System Wide Change: Removal of librtkaio from glibc 17:37:55 .fesco 1546 17:37:59 sgallagh: #1546 (F24 System Wide Change: Removal of librtkaio from glibc) – FESCo - https://fedorahosted.org/fesco/ticket/1546 17:38:06 +1 17:38:10 +1 17:38:10 one nitpick, it should be documented in the release notes too 17:38:13 This one is slightly more controversial 17:38:28 uh 17:38:29 controversial? 17:38:31 not just glibc upstream doc 17:38:52 so i'm +1 for glibc 2.23. don't bother revising the count 17:39:02 i'm also +1 for removing librtkaio 17:39:31 +1 from me 17:39:48 +1 (and kindly request maintainer to add an item in release notes) 17:40:12 damnit, it's already there 17:40:22 was not looking in the right place 17:40:28 +1 17:41:03 #agreed Remove librtkaio from Fedora's glibc (+6, 0, -0) 17:41:10 #topic #1547 F24 System Wide Change: GNOME 3.20 17:41:10 .fesco 1547 17:41:12 sgallagh: #1547 (F24 System Wide Change: GNOME 3.20) – FESCo - https://fedorahosted.org/fesco/ticket/1547 17:41:21 +1 17:41:24 +1 17:41:29 +1 17:41:30 +1 17:41:36 +1 17:41:50 -1000000 17:41:51 /me has been running GNOME 3.19 under Wayland for months now and it's shaping up very nicely 17:42:00 no, just kidding. +1 17:42:04 jwb: :) 17:42:20 jwb: :) (I almost made that same joke, with fewer zeroes, but restrained myself) 17:42:29 Another interesting discussion would be delegating responsibility of this kind of change to workstation WG? 17:42:38 if it wasn't for focus issues gnome/wayland would be fine here. ;) Well, and middle click is anoying 17:42:49 number80: +1 17:42:59 nirik: The middle-click thing I hear is nearly ready upstream, so should make it to F24. 17:43:03 yeah. 17:43:05 if people are ok, i can add it to the agenda then :) 17:43:26 #agreed GNOME 3.20 is approved (+6, 0, -0) 17:43:42 #topic #1535 quassel maintainer (tuxbrewr) not responding 17:43:42 .fesco 1539 17:43:43 sgallagh: #1539 (Are 32-bit upgrades to Fedora 24 release blocking? Supported?) – FESCo - https://fedorahosted.org/fesco/ticket/1539 17:43:49 We CCed him and gave him a week 17:44:00 no answer, so I keep my +1 17:44:03 Whoops 17:44:09 .fesco 1535 17:44:10 sgallagh: #1535 (quassel maintainer (tuxbrewr) not responding) – FESCo - https://fedorahosted.org/fesco/ticket/1535 17:44:16 (bad copy-paste in my meeting script) 17:44:50 lupinix has a good case, so we should just allow the take over 17:45:19 number80: we already gave them quassel. 17:45:26 Proposal: Orphan all of tuxbrewr's packages 17:45:41 nirik: excellent, I haven't checked pkgdb since last week 17:45:42 sadly +1, hope they are ok 17:45:47 +1 17:45:50 +1 17:45:50 +1 to orphan 17:45:53 +1 17:46:00 +1 17:46:25 #agreed Orphan all of tuxbrewr's packages (+6, 0, -0) 17:46:42 And now the fun question... 17:46:44 #topic #1539 Are 32-bit upgrades to Fedora 24 release blocking? Supported? 17:46:44 .fesco 1539 17:46:46 sgallagh: #1539 (Are 32-bit upgrades to Fedora 24 release blocking? Supported?) – FESCo - https://fedorahosted.org/fesco/ticket/1539 17:47:58 Proposal: Upgrade issues unique to ix86 do not block the release, but upgrades are supported. 17:48:05 (Throwing that out there; discuss) 17:48:13 what does the latter part mean 17:48:26 jwb: Meaning that we aren't terminating support for i686 completely. 17:48:27 as much as anything is supported. ;) 17:48:39 We expect upgrades to work, but won't block the release if they don't 17:48:41 we can tolerate a few weeks delay 17:48:50 then i'd rather just leave that part off and say they don't block the release. 17:48:50 number80: Delay in whay? 17:49:00 *in what way 17:49:02 sgallagh: for 32 bits deliverables 17:49:04 jwb: +1 17:49:16 OK, modified proposal: 17:49:21 if thee are any 17:49:23 Proposal: Upgrade issues unique to ix86 do not block the release 17:49:30 +1 17:49:34 +1 17:49:55 +1 17:49:56 +1 17:50:12 +1 17:50:14 +1 17:50:32 Now, in an ideal world, we'd be able to have fedup disallow attempts at those upgrades if we know that they are present. 17:50:43 err, the new non-fedup thing 17:51:10 dnf system-upgrade plugin 17:52:32 Do we want to attempt to address that risk in advance? 17:52:59 I don't think so. 17:53:00 i.e. ask the system-upgrade maintainers to add the ability to disallow upgrades on certain arches if they're known to be broken? 17:53:21 no 17:53:21 sounds like asking for work where there might not be any, and also for something we don't actually care is release blocking. ;) 17:53:28 no, people who still uses 32 bits are mostly power users, so they should know what they do 17:53:34 ie, we don't support this, but we are going to put in work to not support it. ;) 17:54:32 Works for me. 17:54:41 I just figured the question should be asked 17:55:16 #agreed Upgrade issues unique to ix86 do not block the release (+6, 0, -0) 17:55:24 #topic Next week's chair 17:55:35 I've been keeping this chair warm for two weeks... someone else's turn :) 17:55:45 I've not done it in a while... I can 17:55:46 i'll do it 17:55:51 or jwb can. ;) I don't care 17:55:53 IT'S MINE 17:55:57 MY PRECIOUS 17:55:59 /me gets out the steel cage 17:56:09 :) 17:56:15 :) 17:56:17 you got it. 17:56:26 #action jwb to chair next week's FESCo meeting 17:56:27 at some point I'd like to ... just a little scared of my first go at it ... please be nice when I inevitably screw it up :P 17:56:39 maxamillion: it's not so hard, and we have a wiki page with the process. 17:56:47 nirik: oh? awesome, didn't know that 17:56:49 mostly just tedious. :) 17:56:55 maxamillion: https://fedoraproject.org/wiki/FESCo_meeting_process 17:56:55 * maxamillion <3's docs 17:56:58 sgallagh: thanks 17:57:25 the docs are even mostly correct! 17:57:43 Because they get updated and re-checked every time a new member is seated :) 17:57:57 #topic Open Floor 17:57:59 I have one item to bring up. Well, one item, but concerns several tickets. 17:58:03 number80: Did you have something here too? 17:58:20 sgallagh: yes, about delegating some of our decisional power to WG 17:58:31 but let nirik first :) 17:58:33 I'll quickly note that I've still not heard from Mozilla, though I pinged them again today 17:58:55 thanks for the update 17:59:04 If I don't get anything from them over the next week or so, let's re-add that to the agenda on the 26th 17:59:08 ack, thanks for dealing with "that" 17:59:25 nirik: go ahead 17:59:30 so, we have a process for provenpackager that says if there isn't enough votes or there is -1's it goes to fesco. However, we don't have any note about becoming sponsor requests that hit that same thing. 17:59:49 we currently have 3 becoming sponsor requests that are over a week and have either not enough votes or -1's 18:00:03 should we just close these and ask reapply? or should they go to fesco? 18:00:13 nirik: I lean toward 1. 18:00:13 and how to do that since they are in a different trac 18:00:20 nirik: In the case of sponsors, I'd err on the side of assuming they don't have enough support 18:00:37 https://fedorahosted.org/packager-sponsors/ticket/232 18:00:45 https://fedorahosted.org/packager-sponsors/ticket/251 18:00:48 https://fedorahosted.org/packager-sponsors/ticket/254 18:01:11 ok, the process currently doesn't say at all. 18:01:28 "Votes will be collected in the ticket for a week. At the end of that time, if the differential between positive and negative votes stands at +3 or greater, your request will be approved and you'll be promoted to sponsor status immediately. After waiting an hour or so for the new permissions to propagate through the system, you will be able to sponsor new packagers." 18:01:59 process seems very clear. they need to be at +3 after a week. if they aren't, they are not approved 18:02:11 Sponsor is a higher level of trust even than provenpackager. If you abuse pp, we take it away and that's that. If you abuse sponsorship, there could be many new people who shouldn't have commit privileges around. 18:02:20 So I'd tend towards being more picky about sponsors. 18:02:21 if they get no votes, or few votes, that isn't enough to reach +3 18:02:24 Then it should say that... ;) since the provenpackager one says it will go to fesco 18:02:35 sponsors are here to mentor new packagers, if we can't acertain that, that's a problem 18:02:54 nirik: i'm fine with adding the line explicitly, but i don't want it coming to fesco 18:03:06 +1 to jwb proposal 18:03:14 so, I can add ", if not, your request will be closed, you can reapply anytime you feel you have more support" ? 18:03:23 yes 18:03:24 yes 18:03:25 yes 18:03:30 works for me 18:03:45 alright. I will close those and amend the page to be more clear, thanks. 18:03:49 (Though if someone keeps re-applying every week, that could get tedious) 18:04:07 true, but not been an issue so far... 18:04:10 sgallagh: i have a feeling they'll quickly get into -1 territory if that's the case 18:04:15 True enough 18:04:21 I hope that people use common sense and not require us to add more rules ... 18:04:49 Do we need a formal vote on that? 18:05:15 if nirik needs one, yes, but i trust him to do the appropriate change :) 18:05:15 Probably 18:05:24 Well, it's a policy change, so we should record it 18:05:27 +1 18:05:57 https://fedoraproject.org/w/index.php?title=How_to_sponsor_a_new_contributor&diff=434010&oldid=430417 18:06:09 Proposal: Sponsorship requests will be closed after one week. If the total differential between positive and negative votes is not at least +3, the sponsor will not be approved and may reapply later. 18:06:23 formal +1 18:06:27 +1 18:06:36 +1 18:06:49 +1 18:06:55 formal +1 18:07:05 #agreed Sponsorship requests will be closed after one week. If the total differential between positive and negative votes is not at least +3, the sponsor will not be approved and may reapply later. (+6, 0, -0) 18:07:21 number80: OK, your question about Changes? 18:07:44 sgallagh: it's about delegation but I think we should start poll the devel list before coming with proposal 18:08:00 number80: I'm unclear what you want to change? 18:08:15 sgallagh: some changes could be decided at WG level like desktop changes 18:08:17 The purpose of this process is mostly to get top-level sign-off 18:08:35 And to have them recorded in a single place 18:08:59 we could have WG use our trac instance for such things 18:09:11 So yeah, much of the time we're just going to trust the WGs' judgment, but I think it still makes sense to have our decisions recorded by FESCo 18:09:40 then, if we could also record WG judgement in the trac ticket, I'm fine then 18:10:12 Well, these things don't come to us except as output from the WG 18:10:18 So I think WG judgement is implied :) 18:10:27 ok 18:10:40 that isn't true 18:10:47 No? 18:10:49 no 18:10:55 Could you elaborate? 18:10:57 Changes can be submitted by anyone 18:11:09 there's nothing that says a WG has even reviewed it 18:11:27 Strictly speaking, I said "don't", not "can't", but ok yes. 18:11:29 Let's refine the discussion on the list, then 18:11:46 that's not something we can decide on a napkin 18:13:36 let's close on if there's no other topic 18:14:03 Anything else to discuss this week? 18:15:04 Thanks for coming, folks! Have a nice weekend. 18:15:08 #endmeeting