17:59:49 #startmeeting FESCO (2014-03-05) 17:59:49 Meeting started Wed Mar 5 17:59:49 2014 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:49 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:59:55 #meetingname fesco 17:59:55 The meeting name has been set to 'fesco' 18:00:01 #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb 18:00:01 Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:06 #topic init process 18:00:16 Hello 18:00:22 hi. 18:00:24 morning 18:00:25 * dgilmore is here 18:00:25 hola 18:00:28 .hellomynameis sgallagh 18:00:30 sgallagh: sgallagh 'Stephen Gallagher' 18:00:45 notting will be a few minutes late 18:02:47 * sgallagh waits two more minutes before proceeding 18:03:11 hi! 18:03:54 hi all 18:04:12 #info mitr pjones nirik abadger1999 dgilmore sgallagh mattdm t8m present. notting coming shortly 18:04:23 That's everyone, then 18:04:31 #topic #1178 Fedora 21 scheduling strategy 18:04:39 .fesco 1178 https://fedorahosted.org/fesco/ticket/1178 18:04:39 sgallagh: Error: '1178 https://fedorahosted.org/fesco/ticket/1178' is not a valid integer. 18:04:43 .fesco 1178 18:04:44 sgallagh: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178 18:05:49 So we got a few technical specifications... were there any scheduling requests? 18:06:46 In Server, we discussed that if we want to have Cockpit support, we're probably in a "not before September" situation. 18:07:14 I think Workstation has also noted that October would be preferable to time with GNOME 3.14 18:07:19 We don't have any in particular in Cloud. We will just be less ambitious if it is earlier. 18:08:12 I personally like October 18:08:22 The Cockpit support could be handled through the change process, couldn't it? This would be another step for collecting the knowledge of needed resources (including time) to finish 18:08:28 when is gnome 3.14 scheduled again? 18:08:34 sgallagh, that point was brought up by adamw i think. not sure Workstation actually said anything either way, but i can imagine there wouldn't be a huge objection 18:09:49 drago01: ping? 18:10:01 t8m: Well, Cockpit is shaping up to be the primary way we handle Server Roles in the first pass, so it's pretty tightly integrated 18:10:05 (just picking a desktop folk who happens to be here) 18:10:14 a folk? 18:11:50 Proposal: Fedora 21 will target a release at the end of October 18:11:56 sgallagh, +1 18:12:22 sgallagh: Note about cockpit... there's an unresolved bundling issue with it, we'll have to get that sorted. 18:12:34 abadger1999: but that's still something we can handle through Changes 18:12:36 abadger1999: Not any more. 18:12:38 * abadger1999 puts that ticket onto the FPC meeting agenda 18:12:41 adamw: pong 18:12:47 abadger1999: If it's not affecting the schedule in the order of months, let's not discuss the details here 18:12:49 Or not, apparently ;) 18:12:49 How about targetting _beginning_ of october, to give our traditional room to slip? 18:12:49 abadger1999: They got tired of waiting and fixed that :) 18:12:50 sgallagh: oh, okay -- update me on the status after hte meeting. 18:13:20 drago01: see discussion about gnome 3.14 scheduling - does desktop team have any notes? 18:13:34 drago01: just a few lines before i pinged you 18:13:53 sgallagh: im +1 to your proposal 18:14:07 I'm not too thrilled about extending the release to ~11 months 18:14:09 adamw: ah no "offical" schedule yet but should be around end of sep. like every year 18:14:33 OTOH I can live with it, I suppose. 18:14:35 mitr: on the plus side, it means f20 is a long term release. ;) 18:14:44 nirik: and f19 :) 18:14:53 yeah, but 20 more so even 18:14:59 drago01: and i guess desktop team would like it if f21 release schedule was timed to include 3.14? 18:15:04 have we ever decided to change the release support lifecycle? 18:15:10 dgilmore: nope. 18:15:33 nirik: In an unplanned way that our contributors didn't sign up for :/ 18:15:43 * nirik nods 18:15:43 dgilmore: not yet for fedora.next. 18:15:57 adamw: can't speak for others but that seems to be what most want (go back to an aligned schedule) 18:16:02 dgilmore: Still an open question, but generally accepted to mean "Not for F21" 18:16:42 adamw: oh and 3.14 means better / more complete wayland ;) 18:17:07 mitr, do you think it is a real problem? 18:17:11 * jreznik is a bit late - we have our team meeting 18:17:12 * nirik is not opposed to changing the release cadience, but is very opposed to having different release cycles per product. 18:17:30 If there is a general consensus that the lifecycle "deal" for fedora is "~ 13 months", not necessarily "n + 1 + one month" if n is long, we could look at retiring F19 early 18:17:45 do you want to set the release schedule today or I thought it's going to be more based on Changes proposed (and yeah, I asked people to share the dates in changes) 18:17:50 t8m: I don't think it's a deal-breaker. I do favor shorter release cycles in general ("the sooner the deadline is, the sooner things get done") 18:17:50 mattdm: That should be a separate topic, I think 18:17:51 mattdm, -1 18:17:55 Let's not divert too far here 18:17:56 but yeah, it's october for sure now 18:18:02 mattdm: ugh no 18:18:10 just throwing that out there :) 18:18:15 mattdm: always have been "n + 1 + 1" 18:18:30 jreznik: based on what? So far I've seen third-party suppositions of what Workstation would want; do you have other reasons to say "for sure"? 18:18:36 mitr, I think we should go back to the shorter release cycle after F21, just this single release should be special 18:19:02 we really can't do different cycles per product 18:19:04 t8m: we should go back to the old may/oct model 18:19:13 not without forking the distro 18:19:21 I agree that we should just schedule this release now and leave the larger cycle question for _after_ f21 18:19:34 mattdm: ick 18:19:41 that's how we get stuck doing things we don't like. 18:19:42 drago01: but I'm not sure for how long we would be able to fulfil it 18:20:04 mattdm: I don't think we need to wait that long, but I don't feel this is the right conversation to have it 18:20:09 jreznik: why? we managed to do it more or less for years 18:20:15 pjones okay, then: let's answer the schedule question now, and then deal with the larger cycle as part of a separate agenda item 18:20:17 t8m: Right. I don't really want to be just stop energy here - it just seems to me that we are "drifting" towards extending the release further and further "by default" without any single strong reason, the way we ended up with ~54 "voting" positions without any single strong reason 18:20:33 also longer cycle somehow contradicts with our "First" foundation 18:20:36 drago01: but then we decided we'd like to really plan the release 18:20:50 drago01, frankly, too much emphasis is put on that 18:20:56 jreznik: chicken-egg 18:21:00 ;) 18:21:02 it doesn't matter if you're first if what you're first in doesn't work 18:21:02 +1 to October for F21. 18:21:10 proposal: have jreznik work up a proposed schedule based on a f21 release in later october, review and discuss next week? 18:21:10 (mitr I actually feel like there is a very strong reason. but this is _definitely_ a topic for a different discussion) 18:21:17 jreznik: we cannot be feature and time based on the same time 18:21:23 nirik, why later october? 18:21:26 nirik: I'd say earlier october 18:21:42 sure, ok. I don't care... just october? whatever is actually being proposed? 18:21:47 I am definitely +1 to october but Ialso am in favor of earlier. 18:21:53 nirik: say october and I can prepare more versions 18:21:55 (which is why a thing with dates might be nice to review before +1ing it) 18:21:56 i mean earlier october 18:22:11 earlier october means later october anyway 18:22:17 drago01 exactly 18:22:21 lets look at October 14 as release date 18:22:23 Basically, I see F21 as a "Features" driven release instead of a time driven release. Where the "Features" have to do with changes to how we create Fedora (not the changes to the software inside of Fedora). 18:22:23 and I'd really to see more adjustments based on on Changes proposed 18:22:24 and later october means "thanksgiving" 18:22:26 nirik: Yeah, I was expecting my proposal to be outright shot down got being ambiguous. I just needed to focus the discussion 18:22:33 drago01, later october means november then :D 18:22:38 nirik: ok, +1; this also gives us a week to receive the Change proposals which may actually contain scheduling requests 18:22:39 t8m: indeed ;) 18:22:46 mitr: yep. that too. 18:22:49 we have Oct 7 14 21 or 28 as potential release dates 18:23:10 proposal: have jreznik do a schedule based on a Oct 14 release date 18:23:11 but I want to know what that means for alpha/beta, when we could do mass rebuild/branch, etc. 18:23:19 dgilmore +1 18:23:29 dgilmore: +1 works for me 18:23:30 then we can see if it needs early tweaking 18:23:45 +1 early October... I'm a little worried about slipping into the holidays if we don't start with a target in early October. 18:23:45 why not oct 7 but +1 to Oct 14 anyway 18:23:54 * mattdm echoes t8m 18:24:00 dgilmore: +1 wfm 18:24:04 I'd be happier with the 7th as well 18:24:08 * abadger1999 sane as t8m. 18:24:12 I've worked over too many thanksgiving holidays 18:24:27 Revised then to ask him to provide examples of both? 18:24:27 the scheduling rules say "on a Tuesday as close as possible to October 31st" but I really prefer earlier date and 14th would be ok 18:25:02 sgallagh: I'm ok with it, once I have it in TJ, I can do everything 18:25:07 jreznik, where is the 31st coming from? 18:25:35 TJ? 18:25:44 t8m: we've always aimed for halloween. literally always. 18:25:49 only reason for 14th over 7th is to make sure gnome has time to get final in and tested assuming a sept release 18:25:51 sgallagh: task juggler 18:25:53 ah 18:25:55 t8m: http://fedoraproject.org/wiki/Releases/19/Schedule 18:25:55 pjones, OK :D 18:26:15 t8m: and where 19 you can put any XX 18:26:19 Ok, so I think that's agreed. 18:26:20 t8m: like, since 1994. 18:26:39 (I mean, for every alternate release of course.) 18:26:43 #action jreznik to work up and provide a schedule proposal for Oct 14 target date for next week. 18:26:44 Halloween/Mother's Day. 18:26:52 Shall we move on for today? 18:26:57 yep 18:26:58 t8m: Also: https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Steps_to_Construct_a_New_Schedule 18:27:06 #topic #1221 Product working group activity reports 18:27:07 OK 18:27:14 .fesco 1221 18:27:15 sgallagh: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221 18:27:33 The general consensus here seems to be: "Everyone was working on Tech Specs" 18:27:41 yes 18:27:47 #info The general consensus here seems to be: "Everyone was working on Tech Specs" 18:28:06 yep. 18:28:07 Except for cloud. We did things differently. :) 18:28:20 mattdm: Isn't that kind of your charter? 18:28:24 some good discussions, with some understandable digressions. ;) 18:28:25 sure :) 18:28:45 Ok, anyone have anything specific to call out this week? 18:28:49 mattdm: I liked the document that cloud produced. 18:28:54 abadger1999 thanks 18:28:56 So did I 18:28:58 Does FESCo want to make any kind of a ruling on the FS topic? 18:29:00 Very hekpful for planning 18:29:04 can we link them here with infos? 18:29:10 so for the minutes? 18:29:12 sgallagh, err... what? 18:29:16 sorry about that 18:29:23 such as "Proposal: all Fedora Products will use ext4"? 18:29:26 (Which I am -1 to) 18:29:37 i'd be pretty irate if FESCo did anything like that 18:29:52 sgallagh: why would fesco want to decide that? 18:29:52 #info https://fedoraproject.org/wiki/Workstation/Technical_Specification 18:29:55 sgallagh: I'd be +1 to a proposal that we make no requirements /of that kind/ 18:29:56 here now 18:29:58 #info https://fedoraproject.org/wiki/Cloud_Changelist 18:30:19 #info https://fedoraproject.org/wiki/Server/Technical_Specification 18:30:54 sgallagh: I'd like to push questions like this to Base Design. I'd think answers to the question could be: (Must be implemented as X. By default implemented as X but Products can document they implement a different default. Up to the product to decide.) 18:31:08 abadger1999: Yeah, I'm good with that too 18:31:09 What about all Fedora products will use ext4 or xfs or btrfs? (btrfs at this point in biggest doubt) 18:31:17 mattdm: can i suggest you move cloud things under Cloud/ space like the others have 18:31:40 dgilmore wiki guidelines say everything should be top level. we've ended up with some with and some not. 18:31:53 dgilmore but sure, we can rearrange for consistency 18:31:54 t8m: Let's not vote on things that nobody even suggested shouldn't be done :) 18:32:08 t8m, what about we don't second guess the WGs in their discussions with everyone on what is best for their product and just let them decide? 18:32:08 mattdm: i like consistency :) and things under namespaces is much more common 18:32:26 jwb: +1 18:32:26 no problem 18:32:26 dgilmore *nod* 18:32:43 jwb: I framed the conversation poorly. 18:32:44 I don't see any conflict here we need to decide/mediate... 18:32:55 My intent was to ask whether FESCo has a problem with different FS defaults 18:33:01 i don't have an issue with it 18:33:01 The answer appears to be "no", so let's move on 18:33:03 nirik, jwb +1 18:33:13 sgallagh +1 18:33:15 so many +1s 18:33:20 wait, hang on 18:33:27 i want to explain something 18:33:46 t8m: one of many problems with a statement like that is that there's no scope in it. Are we talking for F21, or until we say otherwise, or forever unless somebody thinks to ask again? 18:34:10 pjones, no problem, it was not meant really seriously 18:34:21 the reason i would be irate is that this FS discussion was almost a perfect example of how broader issues should be dealt with. the WGs came up with what was best, it was discussed in broader context on the devel list, pulling in experts and other WG reps as needed 18:34:37 it was long. there was noise. but it was done, overall, as it should have been 18:34:43 jwb, +1 18:34:44 jwb: Agreed 18:34:54 jwb: yes. 18:34:56 jwb: Yes. 18:35:01 18:35:04 sure. 18:35:12 so to even be discussing some kind of mandate from FESCo or Base is irritating at best 18:35:25 i think my soapbox is broken now. 18:35:27 yeah, that's why I said I'd be against making statements of that kind. 18:35:58 Ok, now that we've all agreed that I shouldn't have asked about this topic in that way, can we move on? 18:36:20 one question... 18:36:42 what are next steps for working groups? continue to work on tech specs/flesh out and convert things into changes that are changes? 18:37:08 convert to changes is what I'd like to see 18:37:10 nirik, i think that's a good summary 18:37:17 nirik, +1 18:37:18 nirik: Yeah, that was my understanding 18:37:28 cool. Just want that to be clear... ;) 18:37:29 Get all of our Changes in by the April 3(?) deadline 18:37:36 I have a question for the workstation workgroup, how do they expect upgrades to work? 18:37:37 Apr 7th 18:37:48 jreznik: Thanks 18:37:58 #info we're all pretty happy with the way the wg discussion about filesystems went, providing a good example of how broader issues should be dealt with in the fedora.nex structure 18:38:09 they don't want an install DVD, the creation of that is what makes the upgrade tree for fedup 18:38:32 nirik: Also, if anyone does have scheduling requirements, they should speak up _now_ 18:38:45 dgilmore: can't we create the tree without having to build and ship a dvd iso? 18:38:54 drago01: no 18:39:00 dgilmore: why? 18:39:12 dgilmore, "they don't want an install DVD" - that means we won't produce it at all or that the install DVD won't be the Workstation product 18:39:13 not without major unplanned work 18:39:42 t8m: well, they state that their install method is livecd only 18:39:47 dgilmore: build the ISO and drop it? 18:39:50 which you cant use for a upgrade 18:39:56 dgilmore: Would you mind putting together an explanation of how that process works on the Wiki? I'd like to see what the dependencies are. 18:40:07 so we won't have install DVD at all? 18:40:08 mitr: we can not build the dvd, but we have to build a install tree 18:40:23 unless they reuse the tree from another product 18:40:37 no, that sounds like the right thing. build an install tree but not isos 18:40:41 So, I think this is the request to plan that work. I think it's perfectly fine to say "Hey workstation team: releng can't do this without some contribution of resources" 18:40:46 I suppose server would want some kind of install DVD 18:40:57 dgilmore: Can you think of a reason they couldn't use the Server tree for this? 18:40:59 sgallagh: its simple. pungi imports lorax which makes the initramfs for both install and upgrade 18:41:00 t8m: for ws, lives only 18:41:04 jwb, dgilmore: Could you bring this back to the Workstation WG? Thanks for highlighting the concern, but I don't think we can solve this here. 18:41:09 Presumably on upgrade they're pointing at the Everything+Updates repos 18:41:14 by 'install tree', it's just stage 2? the repo would be there regardless 18:41:19 sgallagh: thats not installable 18:41:33 dgilmore: I think you missed half of that 18:41:48 I suggested using the Server tree and making sure it was pointed at the Everything+Update repos 18:41:55 install and upgrade aren't synonymous... 18:41:56 That should cover it, or am I mistaken? 18:42:08 so i'm not sure why Everything+Update wouldn't work for upgrades 18:42:17 I don't get it either 18:42:23 jwb: it doesnt have the kernel and initramfs needed 18:42:33 needed? 18:42:33 I suspect there's some aspect of fedup that we're missing. 18:42:38 you still need to build the bits fedup's going to reboot into 18:42:47 but... you shouldn't need an iso for that 18:43:00 you probably could use the servers kernel and initramfs 18:43:15 the upgrade bits in stage2 should be product independent, for now 18:43:19 anyway we cant solve it here. 18:43:22 sgallagh: Would we be essentially deciding-by-code that the packagesets (and comps) must not diverge between Products by this? 18:43:37 dgilmore, would you be so kind as to ask on the desktop list with as much background tech info as possible? be happy to follow up there 18:43:41 I don't think comps matters here 18:43:49 jwb: im not on the desktop list 18:43:53 but I thought the plan was that the packagesets must not diverge 18:43:54 mitr: I'm not sure that makes a big difference for an upgrade 18:44:07 And that places that required divergence would be managed by product-specific subpackages 18:44:12 dgilmore: then sign up? 18:44:30 mitr: no thanks 18:44:34 dgilmore: "nomail" option 18:44:49 I already get more email than i can deal with 18:45:01 dgilmore: if you do a writeup I'd be happy to pass it along to the desktop list and collect responses for you... 18:45:01 that's why he suggested the "nomail" option. 18:45:16 dgilmore Can you delegate this to someone who will work with desktop on it? 18:45:24 anyhow, this is something we need to figure, but not sure in this meeting will work. 18:45:33 nirik, +1 18:45:33 shall we move on? 18:45:34 * EvilBob sees dgilmore running in circles with his fingers in his ears repeating "What I don't know can't hurt me" 18:45:54 ;) 18:46:09 sgallagh: Hmm... do product specific subpackages require Conflicts? Probably should open an FPC ticket to list that in the Conflicts guidelines. 18:46:34 abadger1999: Yeah, I'd been meaning to discuss that with you since DevConf and forgot. 18:46:45 abadger1999 I think they should. 18:46:47 sgallagh: Cool -- talk with me after the meeting. 18:47:02 * nirik would like to see some examples where we actually need them first 18:47:03 abadger1999: I have another meeting in 45 minutes. 18:47:11 sgallagh: ah -- later today then? 18:47:15 Mind sending me a meeting invite for tomorrow? 18:48:12 sgallagh: can do -- but I don't know if we'd get to it (agenda has been pretty full lately.) Maybe best to talk with me and do some initial drafting before it gets to a meeting. 18:48:14 Anyway, shall we move on to the next topic? 18:48:19 +1 18:48:27 ok 18:48:42 +1 18:48:45 yes 18:48:47 #topic #1230 Requesting FESCo address Cherokee logo issue 18:48:47 .fesco 1230 18:48:47 https://fedorahosted.org/fesco/ticket/1230 18:48:50 notting: #1230 (Requesting FESCo address Cherokee logo issue) – FESCo - https://fedorahosted.org/fesco/ticket/1230 18:49:03 So it's past the deadline. I say we orphan it as we originally stated. 18:49:16 s/orphan/retire/ 18:49:29 have we confirmed he hasn't done it yet, or has he just not announced that he's done it? 18:49:35 notting: No build has occurred 18:49:37 I checked Koji 18:49:40 Proposal: Go ahead and orphan it for the reasons we've said before. 18:49:44 yeah, looking at git, it's not done yet 18:49:54 pjones: +1 18:49:56 * pjones +1 18:50:04 pjones: Orphan or retire? 18:50:06 s/orphan/retire/ 18:50:22 Proposal: Retire cherokee from the distribution 18:50:22 Er, I do actually mean retire, don't I. 18:50:24 (for clarity) 18:50:27 sgallagh: +1 18:50:30 Very unhappy +1 18:50:38 sgallagh: you screwed me up when you said orphan the first time. 18:50:39 +1 18:50:43 sgallagh: we said we would, we might as well follow through. +1 18:50:44 pjones: I know 18:50:49 what if somebody decided to un-orphan the package? that would kinda suck 18:50:49 Eh 18:50:52 +1 to retiring I'm afraid. 18:50:54 yeah, what notting said. 18:50:56 How about give it a week. 18:51:02 +1, but sad since maintainer said they would. Do we want to give them a tiny bit more time? 18:51:04 I'll try to put a placeholder image in this week. 18:51:14 masta: Nothing prohibits that, but we would still want the logos gone. 18:51:17 If I or the maintainer don't get to it orphan next week. 18:51:24 abadger1999: +1 18:51:26 yeah, what nirik said. I'd like to at least wait for a chance to respond to the reminder. 18:51:48 I can be +1 to abadger1999 as well 18:51:52 abadger1999: If you are willing to do that, +1. 18:51:53 And assume that the maintainer is at this point acting in good faith. 18:51:56 proposal: retire Monday if not fixed in the mean time 18:52:06 dgilmore +1 18:52:09 dgilmore: +1 18:52:13 actually, that is probably better 18:52:15 dgilmore: +1 18:52:21 dgilmore: wfm: +1 18:52:24 dgilmore: +1 (fior clarity, assuming that abadger1999 fixing this counts) 18:52:40 mitr: anyones fixing counts 18:53:38 * dgilmore will gladlly do the retirement on monday 18:53:39 sure. 18:53:59 dgilmore, +1 18:54:24 Question: how do we handle released Fedoras here? 18:54:33 does retire mean rawhide or released ones as well? 18:54:40 what sgallagh said 18:54:40 Assuming we retire it for being unacceptable, I mean. 18:54:42 #agreed FESCo decision reiterated. Package will be retired Monday if not fixed. (+:7,-:0,0:0) 18:55:04 Presumably that means we shouldn't be continuing to ship it anywhere. 18:55:13 Do we drop it from the stable repos? 18:55:19 Fake out an Obsoletes: to remove it? 18:55:30 I mean having a webserver suddenly retired mid release is .... 18:55:30 sgallagh: I would strongly oppose making a "remove-cherokee" update, and we can't drop it from releases isos 18:55:32 mitr, +1 18:55:45 * mattdm hopes the update just happens 18:55:48 mitr: Sure, but I'm just noting that this is an exceptional case. 18:55:50 let's not change past 18:56:14 yeah, i wouldn't do that yet. ideally, we get someone to fix it. 18:56:18 And it wouldn't hurt to have a plan for this if we ever had to deal with a legal issue forcing a removal, but that's hypothetical. 18:56:30 Ok, defer that question to next week 18:56:47 sgallagh: RHL did edit the isos once, about 10 years in the past IIRC; let's not plan for that pain just yet 18:57:00 mitr: ugh, don't remind me 18:57:22 woohoo, new business. 18:57:23 #topic #1219 Contributor nationality 18:57:24 .fesco 1219 18:57:24 https://fedorahosted.org/fesco/ticket/1219 18:57:25 notting: #1219 (Contributor nationality) – FESCo - https://fedorahosted.org/fesco/ticket/1219 18:57:48 so, brought this up on the agenda just to clarify the note from legal: 18:58:04 #info Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence. If a potential contributor independently (and explicitly) reveals their nationality, country of origin, or area of residence, and that nationality, country of origin, or area of residence is in one of the export restricted countries (currently: Cuba, Iran, North Korea, Sudan & Syria), th 18:58:05 en they are required to bring that information to the attention of Fedora Legal. 18:58:12 #undo 18:58:12 Removing item from minutes: INFO by notting at 18:58:04 : Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence. If a potential contributor independently (and explicitly) reveals their nationality, country of origin, or area of residence, and that nationality, country of origin, or area of residence is in one of the export restricted countries (currently: Cuba, Iran, North Korea, Sudan & Syria), th 18:58:43 so what happens if a country gets added to that list? hunt down contributor accounts and kick them out? 18:58:44 #info Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence. If a potential contributor independently (and explicitly) reveals their nationality, country of origin, or area of residence, and that nationality, country of origin, or area of residence is in one of the export restricted countries (currently: Cuba, Iran, North Korea, Sudan & Syria), th 18:58:44 en they are required to bring that information to the attention of Fedora Legal. 18:58:45 so dont ask dont tell 18:58:57 notting, split it at sentences 18:59:30 #undo 18:59:30 Removing item from minutes: INFO by notting at 18:58:44 : Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence. If a potential contributor independently (and explicitly) reveals their nationality, country of origin, or area of residence, and that nationality, country of origin, or area of residence is in one of the export restricted countries (currently: Cuba, Iran, North Korea, Sudan & Syria), th 18:59:31 just take the list off 18:59:36 t8m: yeah 18:59:37 #info current countries that are export restricted are: cuba, iran, north korea, sudan, and syria. 18:59:51 # Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence. 18:59:55 DAMMIT 19:00:00 #info Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence. 19:00:25 #info If a potential contributor independently (and explicitly) reveals their nationality, country of origin, or area of residence, and that nationality, country of origin, or area of residence is in one of the export restricted countries, then they are required to bring that information to the attention of Fedora Legal 19:00:26 dgilmore: Yeah, that seems to be the summary. 19:00:50 #info In the specific case that prompted this ticket, Fedora Legal has deemed the contributor is OK. 19:02:27 moving on 19:02:34 #topic #1240 taking ownership of packages fityk and sundials 19:02:34 .fesco 1240 19:02:34 https://fedorahosted.org/fesco/ticket/1240 19:02:35 notting: #1240 (taking ownership of packages fityk and sundials) – FESCo - https://fedorahosted.org/fesco/ticket/1240 19:02:52 * nirik meant to comment on this one. 19:03:20 While I doubt malicious intent, I don't think we want to set a precedent on bypassing non-responsive process here. 19:03:22 we could either just do it, or request a direct ack from the fomer maintainer in ticket or whatever 19:03:37 sgallagh: +1 19:03:54 nirik: i'm ok with requesting a direct ack 19:03:59 I'm happy to help people reassign packages, as long as we are sure the identity of the person wanting to do it. 19:04:03 Yeah, a direct ack would be preferable 19:04:05 nirik: well if his fas account is inactive he can't comment in the ticket right 19:04:15