18:01:15 #startmeeting FESCO (2015-03-04) 18:01:15 Meeting started Wed Mar 4 18:01:15 2015 UTC. The chair is ajax. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:15 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:15 #meetingname fesco 18:01:16 #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh 18:01:16 The meeting name has been set to 'fesco' 18:01:16 Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza 18:01:18 #topic init process 18:01:23 * rishi waves 18:01:31 .hello sgallagh 18:01:32 sgallagh: sgallagh 'Stephen Gallagher' 18:01:33 hi 18:01:35 Hello 18:01:36 morning 18:01:37 hola 18:01:39 hello all 18:01:53 I'm concurrently working on a blocker issue for Alpha, so apologies if I'm slow to respond 18:02:32 paragan said he can't make it so that's everyone i think 18:02:54 egy for services that do not have systemd native unit files 18:02:54 .fesco 615 18:02:55 https://fedorahosted.org/fesco/ticket/615 18:02:57 ajax: #615 (Strategy for services that do not have systemd native unit files) – FESCo - https://fedorahosted.org/fesco/ticket/615 18:03:09 #topic #615 Strategy for services that do not have systemd native unit files 18:03:13 bad paste 18:04:16 so basically https://fedorahosted.org/fesco/ticket/615#comment:43 was the last concrete proposal in there? 18:04:48 yes 18:04:52 at issue is, what do we do with remaining sysvinit subpackages 18:05:05 1) do we care or do we work to eliminate them 18:05:06 I'm ok with point 1 in that proposal. 18:05:28 2) if we work to eliminate them, do we leave any support at all, or a demo script, or... 18:06:09 ajax: support yes, demo script maybe 18:06:19 and then i guess do we care about doing this in f22 18:06:30 We definitely leave support for init.d scripts in the system. And the exceptions in Zbysek’s point 2 will be enough to ensure some users stay, so we don’t need an extra demo script. 18:07:07 I'm not sure I agree with point 2 in the proposal... 18:07:34 I wouldn’t mind F22, I don’t think it is essential. (Also somebody has to actually _do_ the work to drop *-sysvinit) 18:07:36 nirik: agreed 18:08:01 i guess i can't agree with point 2 without the work of point one being done first 18:08:29 True, actually dropping packages for F22 after Alpha would be rather late 18:08:51 ajax: Are they directly connected somehow? 18:08:55 Are the fesco members intending on signing themselves on doing the migration legwork themselves? 18:09:10 so, to be clear, I am in favor of cleaning up those packages that have both (there's no point in also shipping sysvinit), but I am not in favor of dropping packages because they haven't converted. 18:09:14 I'm opposed to dropping any such packages for F22. 18:09:17 F23, sure. 18:09:43 I am in favour of (1) if we can do that in time for F22 Alpha. Otherwise, F23. 18:09:43 I also don't see any problems with point 1 (even in F22) 18:09:57 okay, let's make this concrete: 18:10:01 I'm actually not in favor down the road either. ;) 18:10:25 rishi: We are already frozen for Alpha, that is not happening. 18:10:26 nirik: I am in the same boat as you 18:10:32 #proposal drop sysv init script packages if a systemd unit file exists, for f22 18:10:39 it is too late for f22 18:10:40 +1 18:10:46 is that the #verb? 18:10:48 -1 18:10:56 ajax: There's no verb for proposals 18:11:08 Just for agreed, info, action, etc. 18:11:16 there is no harm in dropping the legacy sysv initscript package if there already exist an unit file for it 18:11:31 that stuff does not work anyway 18:11:37 ajax: Who will actually do it? 18:11:37 ajax: +1 18:11:58 Viking-Ice: I broke F21 release three times doing something that "couldn't possibly cause harm". I am necessarily wary. 18:11:59 mitr: whoever wants to give me a list, i'll whack the packages 18:12:06 it's not like it's brain surgery 18:12:10 there's 17 of them? I could also do it. 18:12:22 ajax: they are in the comment in the ticket with the proposal 18:12:41 hey, even easier 18:12:42 mitr: Then in that case F23. Dropping packages after the alpha freeze doesn't sound good. 18:12:44 Hm, amavisd-new Requires: clamav-server-sysvinit; ip-sentinel Requires: ip-sentinel-sysvinit (through init(ip-sentinel)) 18:13:24 rishi: this is not dropping packages, it's removing the old unused sysvinit subpackage on packages that already have a systemd unit 18:13:27 Yeah, I'm fine with doing this in Rawhide, but I'm opposed to making changes like this in F22 at this point 18:13:39 sgallagh, the legacy sysv initscript never worked in conjunction with the unit files since a) the unit file was shipped with the main component by default hence it could not be removed and b) the unit file takes precedence over the legacy sysv initscript ( sub package or not ) 18:13:45 dgilmore: +1 even though you said it's too late for f22? 18:14:11 I'm fine with just rawhide too... is there some kind of urgency ? 18:14:19 ajax: well, dropping just the subpackages can be done 18:14:30 nirik: i don't think there's any particular urgency, no 18:14:35 No urgency from my perspective, but without a deadline, nothing ever gets finished. 18:14:36 ajax: its too late to do more invasive changes 18:14:42 k then, master only 18:14:54 Hence why I originally proposed a hard-nosed approach 18:15:01 Viking-Ice: They don’t actually always have the same name (sadly) 18:15:25 nirik: Yes, I meant the subpackages. I am saying that dropping them for F22 after the alpha freeze is too late. 18:15:33 ajax: +1 to master only; undecided on F22 18:15:34 rishi: ok 18:15:50 mitr, these are just 30 components or something that continued to ship legacy sysv initscript after the migration 18:15:50 ajax: +1 for rawhide 18:16:08 I'm +1 for master/F23, -1 for F22 only because of the schedule timing. 18:16:25 mitr, which component(s) of those ca 30 did not retain their name? 18:16:32 i'm +1 for f23 as well 18:16:47 Viking-Ice: both clamav-server and ip-sentinel (the only 2 I have looked at now) 18:16:58 which makes +6, which i do believe is a majority (nirik, dgilmore, mitr, thozza, sgallagh) 18:17:05 * nirik nods. 18:17:32 #agree drop sysvinit subpackages if a systemd unit file exists, in f23 18:17:33 Yes, +1 for rawhide, -1 for f22. 18:17:54 #agrede drop sysvinit subpackages if a systemd unit file exists, in f23 18:18:00 #agreed drop sysvinit subpackages if a systemd unit file exists, in f23 18:18:00 Heh 18:18:06 one of these must work 18:18:40 it's agreed, but it doesn't say anything I don't think... just adds to minutes. ;) 18:18:48 i remember a bot response? 18:18:56 anyway 18:18:57 ajax: no bot response on that comand 18:19:26 What if the duplicate script is contained in the main package, not in the subpackage? Can you clarify that it should be dropped too? 18:19:38 zbyszek: yes it should be 18:19:38 zbyszek: certainly 18:19:46 yes. 18:20:05 #note also remove sysvinit scripts not in subpackages where there is a working systemd unit 18:20:09 zbyszek, it's in the violation of the FPG if it does 18:20:47 Viking-Ice: I know, but there are cases where this happens. 18:20:48 so: how do we feel about actively pruning packages retaining sysv scripts after this round? 18:21:23 I feel -1 on it. I think we should let them exist and fix them as maintainers and packagers and upstreams permit. 18:21:34 i'm +0, think i'd like to form an opinion after i see what all is left 18:21:35 I mean, we still ship gtk+ :) 18:22:03 #action ajax to prune sysvinit subpackages in f23 18:22:07 Historically our enforcement of packaging standards, and generally getting things fully done, has been really poor; if this were the starting point for a change, it would be just as well. 18:22:22 indeed 18:22:27 there are around up to 150 components left to be migrate 18:22:29 So +0.5 18:22:32 Does systemctl show SYSV scripts? 18:22:45 sgallagh: yes 18:22:56 ok 18:23:30 anything more on this one? we're at like 20 minutes, and can revisit next week 18:24:09 right then 18:24:10 #topic #1412 anaconda password change is causing consternation among the user community please review this policy decision 18:24:19 .fesco 1412 18:24:21 ajax: #1412 (anaconda password change is causing consternation among the user community please review this policy decision) – FESCo - https://fedorahosted.org/fesco/ticket/1412 18:24:38 I proposed a compromise of sorts, but it didn't get much answer. 18:24:39 right, so: anyone looked into this? anyone heard stories? 18:24:42 So, we asked the Workstation and Anaconda teams to try to come to an accommodation 18:24:52 They have been unable to do so 18:25:02 (I don’t quite see the point of the "file bugs and we'll see" resolution; we have seen bugs closed) 18:25:15 sgallagh: I don't understand why this change was done in the first place. It seems that none of WGs asked for it. 18:25:17 ajax: Yes, I've been following it and listening to complaints from both sides. 18:25:34 * nirik has also read all the complaint emails and irc meetings and such 18:25:54 Meanwhile, security@ is discussing policies, math and the like, but is no closer to having someone actually implement ssh rate limiting 18:26:22 right. So, I asked if we could set anaconda to require pwquality > 0... 18:26:27 Initially it was being said that the Server needs because sshd is enabled. But sgallagh says that they didn't ask for it either. 18:26:32 rishi: It’s not like every communication needs to go through WGs 18:26:32 we could also ask them to add back the double done thing 18:26:43 mitr: Why not? 18:26:51 nirik: The responses I have been hearing have been mostly "We've always been able to ignore it if we wanted to, why are you taking away that option?" 18:26:56 mitr: Particularly this one because it is quite a user-visible change. 18:26:59 rishi: Because this is not IBM (and neither is RH internally for that matter) 18:27:07 talking to people directly is common and expected 18:27:09 mitr: Sorry, but that is nonsense. 18:27:10 /me notes its interesting to hear this argument coming _from_ GNOME folks ;-) 18:27:25 sgallagh: The WGs define the products. 18:27:47 getting off track 18:27:51 i wonder how large is the patch to put the double done back 18:27:53 If that is the case, then having such user-visible changes forced down the throats is a bit weird. 18:28:02 nirik: Yeah; as long as anyone ever considers “well just change it after installation to what you want” a valid workaround we should not be enforcing this at all. 18:28:17 sgallagh: well, and 'its too hard to come up with a password it likes' and 'we don't need that level of security because we have sshd off and only local users' and 'there's no feedback on what part of a rejected password is rejected and what for' 18:28:22 rishi: As far as products go, this is honestly a minor UI change. Noticeable, but definitely minor. 18:28:30 and 'there's no guidence to users what to use for a good password' 18:28:35 Just to move things along: 18:28:36 Proposal: Ask Anaconda to restore the "double-done" solution. 18:28:51 and if they say no? 18:28:52 mitr: Minor enough that a good percentage of users won't even install Fedora. :) 18:28:52 mitr: if we are pissing users off in the installer, we loose them before the os is laid down on disk 18:29:02 sgallagh: +1 (Not _happy_ about the F21 status quo but not able to significantly improve in it what I think is the right way) 18:29:06 because dcantrell asked us to look at having a consistent password policy 18:29:37 rishi: Sure, this one is noticeable. But not the kind of think you would want WGs to keep approving all the time. 18:29:45 proposal: ask them to restore double done for f22, work on a policy and better UI and such around password settings 18:29:48 I'm also +1, I think it was landed before it was thought well-enough through. 18:30:12 nirik: Sure, I was basically going to assume the second half. 18:30:27 +1 18:30:31 nirik: +1 18:30:38 jwb: Policy is not at all a solution here; Given the current software we can either give up or have a stringent policy. We actually need to write code to get a policy Workstation / testers would like (and I think that kind of policy is quite achievable) 18:30:42 but we should start/continue that now... ;) not wait 6 months and be surprised. 18:30:52 nirik: Sure, +1 18:30:52 -1. i don't think we're actually going to work on a policy 18:31:01 mitr: jwb: A consistent password policy is good to have, but hard enforcing local password checks across all products is a bit extreme. 18:31:08 Feel free to warn the user as much as you want. 18:31:10 and if we aren't, then i think we should just tell them we aren't instead of saying we'll look into it 18:31:15 jwb: As far as "what if they say no", would you prefer we rephrase that as "Instruct anaconda to"? 18:31:17 But don't take away the option of overriding it. 18:31:24 jwb: See https://lists.fedoraproject.org/pipermail/security/2015-February/002074.html . It’s not FESCo but some conversation is happening. 18:31:48 sgallagh, no... why do we believe we can tell an upstream what to do? 18:31:51 Otherwise you end up like my dad who writes his passwords on a piece of paper. 18:32:04 jwb: Well we actually can. 18:32:12 jwb: We can tell the maintainers of a downstream package. 18:32:17 jwb: so we should close this with: please go talk to anaconda, bye? 18:32:20 That they happen to also be upstream maintainers is a perk. 18:32:23 rishi: (Writing passwords on a piece of paper is frequently the right thing to do.) 18:32:42 Also, Anaconda is only dubiously an "upstream". There are few upstreams that could claim to be more "Fedora" than Anaconda. 18:32:53 rishi: https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00030.html is why it was changed 18:34:34 sgallagh, the anaconda developers i've spoken to have pretty clearly stated that they want to get out of that model because it's terrible 18:35:15 so if they don't want to change it upstream, i don't think we're in a position to tell them to. if we want to carry a patch in the fedora package of it, then fine 18:35:18 the thing is, this is just one part of a story... 'root password' 'ssh settings' 'user iterface to help users choosing passwords' 'level of security process desired' etc 18:35:58 dgilmore: Right. That is the mail I remember reading. I would have understood if the Server WG explicitly asked for this. 18:36:06 But that doesn't seem to be the case. 18:36:07 nirik: Yes. And we do need $someone to take a deep look and write patches; I don’t know where to find such $someone ATM 18:36:13 And the Workstation doesn't turn on sshd by default. 18:36:23 So ... not sure why this was suddenly done. 18:36:43 I don't even think we need someone to write patches (although they would be welcome), we just need someone to come up with a bigger picture story here... 18:36:53 rishi: it was anaconda in resposne to the sshd change to disable root logins saying we should make the defaults in anaconda better and doing it 18:37:23 it was an anaconda change done within anaconda. done in isolation 18:37:38 dgilmore: We rejected the NoRootLogins change, as I recall. 18:37:45 sgallagh: we did 18:38:06 Mostly because that would have been painfully difficult for Server 18:38:13 nirik, i think that is what dcantrell was getting at with the policy request 18:38:17 sgallagh: but they did go and talk to anaconda guys who reacted by changing password polices enforced in anaconda 18:38:23 jwb: yeah. 18:38:27 We seem to be at +5 already, plus or minus minor wording differences (sgallagh, nirik, thozza, ajax, mitr)? 18:39:06 sure. 18:39:07 (I don’t want to kill the discussion, just to make sure this was noted) 18:39:08 i am +1 to nirik's proposal 18:39:08 Maybe we should ask this question: 18:39:08 Would anyone have a problem with asking Anaconda to revert the behavior? 18:39:30 well, I was just saying they should re-add double done... thats not complely reverting 18:39:33 Because if we're hemming and hawing over whether they will revert the change, the easiest way is to ask. 18:39:33 sgallagh: I am okay with the length change to 8 characters 18:39:42 Sorry, bad choice of words 18:39:46 they changed leng and pwquality score 18:39:51 renablling the double done I think would satisfy everyone 18:40:29 for now. 18:40:40 sure, for now is fine 18:40:59 it's clear we're asking for accomodation in the absence of a more elaborate response, right? 18:41:08 fine, ask 18:41:08 ajax: right 18:41:14 ajax: Let's rephrase it that way, but yes 18:41:23 Umm... what are we voting for. 18:41:25 * rishi reads 18:41:26 I do think we need bigger picture plan/design here... but I don't want to commit myself to do it as I am overcommited on other stuff already. ;) 18:41:40 rishi: asking anaconda to restore double confirm for weak passwords 18:41:44 Ok, +1 to nirik 's proposal 18:41:46 ajax: I think to do anything else would require FESCo to sit down and write a policy for the default password settings for the distro 18:41:54 which, yes, noble 18:41:57 then having pam, anaconda, etc all match 18:42:07 let's find the people who oughta do that and do that 18:42:12 dgilmore: the matching part is ~easy; all use libpwquality already 18:42:25 Rephrased: FESCo would like anaconda to turn back on the "double-done" option for Fedora 22. Better solutions should be investigated for F23. 18:42:29 it's not just pwquality 18:42:37 sgallagh: +1 18:42:39 sgallagh: +1 18:42:45 +1 18:42:47 sgallagh: +1 18:42:51 sgallagh: +1 18:42:53 mitr: length etc also 18:43:05 +1 i guess 18:43:05 in the end endusers can configure whatever policy they want 18:43:06 that's +6 assuming sgallagh approves his own proposal 18:43:07 dgilmore: can and should be done only in libpwquality 18:43:10 ajax: +1 18:43:33 #agreed FESCo would like anaconda to turn back on the "double-done" option for Fedora 22. Better solutions should be investigated for F23. 18:43:43 so that was _also_ twenty minutes 18:43:52 mitr: implementation detail, something that would be sorted out with hypothetical distro password policy 18:44:04 dgilmore: sure 18:44:13 and we have still yet to wrangle with that whole actually defining that policy thing 18:44:15 well, it also fits with ssh rate limiting, feedback on bad passwords, generating example ones for people, etc 18:44:27 but hey, i bet we can find some security experts 18:44:42 ajax: we have a security list 18:45:09 ajax: I have been asking around but really nobody has time. 18:45:28 We have a few people interested discussing it but nobody itching to write code, at least not right now 18:45:57 shocking. 18:46:24 how about we keep trying to find a group/people to work on this, leave it open and move on 18:46:31 yes, let's. 18:46:33 (since I doubt we are going to make a policy here today in the meeting) 18:46:34 +1 move on 18:46:34 please 18:46:45 new business! 18:46:53 #topic #1418 FESCo Decision: Revert Tomcat to version 7 for Fedora 22 18:46:54 .fesco 1418 18:46:55 ajax: #1418 (FESCo Decision: Revert Tomcat to version 7 for Fedora 22) – FESCo - https://fedorahosted.org/fesco/ticket/1418 18:47:02 pretty sure this is a fait accompli? 18:47:04 this is already done 18:47:04 we pretty much already decided this in ticket right? 18:47:08 This achieved sufficient votes in the ticket and I finished it last night 18:47:13 A+ 18:47:16 thanks sgallagh 18:47:18 excellent work, team 18:47:20 great 18:47:22 :) 18:47:54 so, not actually in the agenda, but mentioned on the list: 18:48:05 #topic F22 self contained changes 18:48:06 ajax: what about the self-contained changes? 18:48:11 ah, ok :) 18:48:12 .fesco 1374 18:48:13 ajax: #1374 (F22 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1374 18:48:23 +1 to both 18:48:29 two of these i think, lxqt and xfce 4.12 18:48:29 +1 for both, too 18:48:35 -1 to both. 18:48:48 sgallagh: why? 18:49:01 We're already in Alpha Freeze and I don't want us opening it up at this point to two new DEs 18:49:18 sgallagh: lxqt is done, it's more marketing change 18:49:20 sgallagh: they do not have to get in for Alpha 18:49:28 they could land post Alpha 18:49:30 sgallagh: at least the LXqt is pretty self-contained 18:49:32 i am +1 to both 18:49:33 jreznik: OK, that's different, I guess. 18:49:37 Xfce is also very self contained 18:49:55 OK, let me revise my statement. 18:49:56 I'd personally like to get it in alpha to get wider testing. 18:50:02 and we always said we will be pretty open to self contained later after deadline... as these are mostly marketing changes than real big thing that affects alpha release 18:50:03 +1 to both 18:50:03 but if not, it will land after that 18:50:09 If LXqt and XFCE are okay with not being in Alpha, +1 to both 18:50:16 nirik: wider testing will happen with it being in updates-testing 18:50:19 But I don't want them in the freeze exception process 18:50:22 jreznik: I didn’t think we were considering freeze exceptions in that discussion. 18:50:34 sgallagh: It is not that we have stable GNOME 3.16 in Fedora at this point. 18:50:41 sgallagh: I think it's a bit heavy handed to by pass that process isnt it? 18:50:42 sgallagh: that is a bit silly 18:50:49 mitr: for LxQt you even don't need freeze exception, it's just in repo 18:50:53 if you don't think they are worthy of being FE's you can vote no there? 18:51:03 xfce is a bit different case, true 18:51:11 mitr: we are not, its sgallagh beinga bit silly 18:51:14 OK, let's take LXqt off the table 18:51:23 I'm +1 to that, if it's already there 18:51:29 rishi: Which is, strictly speaking, more GNOME not following the intent of the rules (though it has "always been that way” rather than an established precedent to follow. 18:51:53 +1 to lxqt (mitr dgilmore thozza rishi sgallagh) plus me makes six, agreed 18:52:03 yeah, I am +1 to both to be clear 18:52:05 I am +1 to both. 18:52:16 i'm +1 to both 18:52:27 I don't have anything against XFCE, I'm just wary of landing a big feature during Alpha Freeze 18:52:45 sgallagh: well, for freeze, there's freeze exception process 18:52:51 +1 to xfce (mitr dgilmore thozza rishi jwb) plus me makes six, agreed 18:52:51 sgallagh: that is outside the scope of what we do here 18:52:54 Yeah, so let's let it go there 18:53:01 I understand your caution, but I am hard pressed to see how it could affect anything but the xfce spin... 18:53:04 but who knows I guess. 18:53:06 +1 to the Change, I guess. 18:53:27 #agreed lxqt and xfce self-contained changes accepted 18:53:28 nirik: As I noted earlier, I broke F21 several times with things that "can't affect anything..." 18:53:41 let's see what the daage is by beta, i bet we'll be pleased 18:53:42 sgallagh: sure, I just can't think of anything here... 18:53:44 damage, even 18:54:06 My +1 is in place. I'll take my concerns to blocker review instead. 18:54:17 right! 18:54:20 sgallagh: if it is an accepted FreezeException and breaks anything, it breaks the Xfce spin and nothing else 18:54:23 #topic Next week's chair 18:54:25 they get the pieces 18:54:31 for freeze exception - it would be too late today but seems like no way to say go tomorrow, so there's still space to get it as FE 18:54:40 it still has to go through the freeze exception process 18:54:49 who's up? 18:55:16 I guess I can do it 18:55:29 awesome! 18:55:29 yay 18:55:37 #note thozza to chair next week 18:55:56 #topic Open Floor 18:55:58 So I have something for Open Floor from the Workstation WG meeting today. 18:55:58 did we ever get any further on new meeting time? or just gave up and keeping this one? ;) 18:56:23 nirik: we got no further. we may be at a local extremum. 18:56:35 alright. 18:56:43 * nirik hands the mic to sgallagh 18:57:09 So, there's a request for clarification on the third-party repo policy that FESCo wrote. 18:57:22 #link https://fedoraproject.org/wiki/Third_Party_Repository_Policy 18:57:45 anything in particular? 18:58:26 Specifically, they would like to know whether it is permissible to include *disabled* repo files for COPRs in RPMs distributed by Fedora repositories. 18:58:27 * mclasen_ envisions sgallagh typing furiously 18:59:03 This is specifically in relation to the new GNOME Software feature that allows searching metadata in certain disabled repos, but not allowing packages to be installed without user intervention. 18:59:09 sgallagh: from the thread on the Desktop list they wanted to have things like a repo file for chrome 18:59:12 Which I believe is in keeping with the spirit of the original decision. 18:59:19 IMHO, it would be nice to draft up a nice clear ticket and we can think about it and address next time? 18:59:23 dgilmore, that isn't what is being proposed or asked here 18:59:26 dgilmore: We're not discussing closed-source or non-libre stuff at the moment. 18:59:29 sgallagh: things in copr i think are okay, but that is not what was discussed 18:59:33 So "chromium" might be a better example 18:59:46 sgallagh: that I think is fine 18:59:50 sgallagh: Is that different from “ RPMS with .repo files pointing to COPR repos cannot be included in the main Fedora repository per FESCo decree. ” on that page? 19:00:05 Which contradicts other parts of that section. 19:00:25 My recollection was that this was transcribed poorly and is missing a clarification of "enabled" vs "disabled" 19:00:38 Sigh, I read "can" instead of "cannot"; ignore me 19:01:02 Given that I was not part of the group who wrote the original policy ... 19:01:20 sgallagh: Just reading the #c20 in that ticket seems like a rationale for _not_ enabling COPR 19:01:27 * mitr goes to read the original logs 19:01:30 I don't know if can 'clarify'. :) 19:01:51 mitr: Can you #link the ticket? I can't find it handily 19:01:51 at the time that the policy was written, installing disabled repo files wasn't an interesting thing to consider 19:01:58 https://fedorahosted.org/fesco/ticket/1201#comment:20 19:02:15 Right. But now it becomes possible to view the metadata while still disallowing installation without user intervention. 19:02:21 Which makes it an interesting case. 19:03:03 sounds pretty reasonable. 19:03:10 mitr, that comment seems to specifically talk about technical challenges, not the principle 19:03:40 cschalle: The Board was there to decide on the principle; FESCo is here for the technical challenges 19:04:17 So, whatever the original intent, with new information: 19:04:17 Proposal: It is acceptable to ship COPR repo files in the standard Fedora repositories, but they must ship as enabled=0. They may ship as enable_metadata=1. 19:04:23 the discussion with releng and infra that the ticket said was needed was never started 19:04:37 sgallagh: nak 19:04:49 * mitr points at http://meetbot.fedoraproject.org/fedora-meeting/2013-12-04/fesco.2013-12-04-17.59.log.html 19:05:07 sgallagh: enable_metadata=1 can be extremely problematic for people on capped internet connections 19:05:22 ship how? 19:05:37 nirik: .repo files in some package 19:05:49 fedora-repos-copr or something like it 19:06:00 ok, and thats a curated subset of all coprs? 19:06:07 presumably the same logic in networkmanager that knows you're on mobile data could also be used to search less aggressively 19:06:08 I assume so 19:06:13 yes, that would be the idea 19:06:20 nirik: Yes, it would be a limited selection of COPRs 19:06:23 +1 19:06:34 I'm +1, for the count 19:06:43 ajax: thats not really useful, since you could be on dsl but only able to download 10 or 20G a month 19:06:43 would it be possible to actually have a ticket and discuss this next week? 19:06:46 is there a hurrry? 19:06:53 it's been a long day and this is coming from no where... 19:07:06 dgilmore: That's a bug that can be addressed. 19:07:13 yeah, i'd prefer a ticket tbh 19:07:28 sgallagh: not really 19:07:33 perhaps with a proposed diff of the existing policy? 19:07:36 a ticket is fair 19:07:38 not easily anyway 19:07:42 AFAICT originally this was refused primarily because there was no signing of coprs, and they aren't mirrorred. Has both changed? 19:07:45 a ticket is very fair 19:07:52 mitr: they are now signed 19:07:55 dgilmore: Allowing a user to select how often to check for metadata is reasonable. 19:07:59 mitr: they are not mirrored 19:08:02 they are not mirrored that I know of. 19:08:03 GNOME Software does it weekly, as I understand it. 19:08:11 dgilmore, well the bandwith issue seems to be one that is outside the domain to FeSCo to be fair 19:08:43 yeah. if we were worried about bandwidth at a fesco level, we'd be doing something about the ocean of updates we ship with every release 19:08:47 cschalle: we have no control over it, but do need to consider it when making decisions 19:09:12 dgilmore: I think we are talking about enabling only a few COPRs. 19:09:14 in the same manner that we support delta rpms 19:09:15 cschalle: There needs to be _some_ domain for this objection to be raised by infra. 19:09:29 dgilmore: Would that increase the bandwidth hit that much> 19:09:33 dgilmore, well I would say that that specific question falls under the jurisdiction of the working group and the users they are targetting. It is not a technical or principal item belonging to Fesco 19:09:48 cschalle: I disagree 19:09:51 sgallagh: could i entreat you to write this up in a ticket for next week's meeting? 19:09:52 I'm not against this idea in principal... but I'd like details. ;) who decides, does it cause problems if copr is down, etc, etc. 19:09:55 dgilmore: Unless you are talking about the infra' side of it. (COPRs are not mirrored, are they?) 19:10:00 rishi: It could 19:10:05 ajax: Yeah, I'll write something up. 19:10:06 sgallagh: at any rate, the bit about clarifying the policy 19:10:14 rishi: I am talking about the users not infra side 19:10:16 sgallagh: thanks 19:10:36 though there is things to be considered on the infra side 19:10:41 #action sgallagh to coordinate with Workstation WG on FESCo ticket around COPR metadata enablement. 19:10:55 anything else for open floor? 19:11:01 that's... not how i would have phrased it sgallagh 19:11:03 but whatever 19:11:14 please end this meeting 19:11:28 sixtyish seconds 19:12:17 #endmeeting