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