16:01:59 <spot> #startmeeting Fedora Packaging Committee
16:01:59 <zodbot> Meeting started Wed Jan 19 16:01:59 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:04 <spot> #meetingname fpc
16:02:04 <zodbot> The meeting name has been set to 'fpc'
16:02:09 <spot> #topic Roll Call
16:02:20 <spot> i saw abadger1999's comment about being out for 10 minutes
16:02:21 <geppetto> here
16:02:29 <racor> here
16:02:35 <limburgher> here
16:02:55 * spot is here
16:02:59 <tibbs|h> howdy
16:03:38 <spot> so, thats five + a late abadger1999
16:04:19 <spot> #topic Services which may autostart - https://fedorahosted.org/fpc/ticket/41
16:04:34 <spot> This is somewhat important to do in order to get the systemd work done
16:05:25 <spot> i've been talking with lennart this morning, and he proposed that we permit all on-network services which do not require any configuration to be enabled by default, and also allow specific exceptions such as: * dbus * openssh * iptables * auditd * udev * readahead * syslogd * NetworkManager * abrtd
16:06:03 <spot> should be "non-network" not "on-network"
16:06:18 <geppetto> What kind of non-network daemons is he thinking about?
16:06:24 <limburgher> spot: Whew.
16:06:44 <racor> The latter 2 from his list require configuration
16:06:49 <limburgher> And, Permit, not Require, correct?
16:06:57 <geppetto> Also … I'd be open to a more generic exception for things like "iptables" and "readahead" … ie. stuff that just runs something once on boot
16:07:20 <spot> racor: yes, which is why they're exceptions.
16:07:47 <spot> limburgher: yes, permit not require
16:08:28 <racor> spot:  exceptions from what? These are networked services, requiring explicit configuration - Abrt even per-user configuration
16:08:43 <spot> racor: notably because NetworkManager is often configured by anaconda at install and because abrtd's defaults are generally good enough.
16:09:01 <racor> abrt doesn't work at all
16:09:03 <geppetto> racor: Exceptions from the rule that network stuff should be off by default
16:09:29 <racor> networkmanager doesn't work in certain situations
16:10:00 <spot> racor: i don't think those points are necessarily relevant, we're not judging the quality of these applications.
16:10:11 <spot> racor: we're just saying they have permission to be started by default
16:10:39 <racor> counter question: Why are we discussing this here? IMO, this is not our job
16:10:50 <spot> racor: FESCo said it was our job.
16:11:48 <racor> spot: Neither do I judge the quality: I am reporting facts: ABRT doesn't work without manual configuation, NM is dysfunctional in certain situations.
16:12:12 * spot is rather confident that he has never manually configured abrtd
16:12:30 <geppetto> dito.
16:12:37 <limburgher> Without nm or network, will sshd start?  I forget. I mean, if it does, you can't reach it, but. . .
16:12:39 <spot> and given that anaconda configures NM in many common installation scenarios, we need to permit it to run by default
16:13:01 <limburgher> spot: I think you do once you try to submit a bug, but it runs before that.
16:13:06 <racor> spot: you never entered you BZ account?  you never installed a system where ABRT is supposed not to molest users, who don't have any use for ABRT?
16:13:18 <spot> racor: thats the applet, not the abrtd
16:13:20 <geppetto> limburgher: Right, but that's nothing to do with the daemon, AIUI
16:13:33 <Rathann> sorry for being late folks
16:13:38 <geppetto> no problem
16:13:41 <limburgher> racor: I do that too, but it runs ok by default, whether you like that state or not. :)
16:13:48 <spot> Rathann: we are discussing https://fedorahosted.org/fpc/ticket/41#comment:3
16:13:50 <geppetto> Just arguing about: https://fedorahosted.org/fpc/ticket/41
16:13:50 <limburgher> gepetto: right.
16:13:56 <limburgher> geppetto: right.
16:14:11 * abadger1999 here now
16:14:34 <spot> geppetto: i dont know that a generic exception for "runs once and goes away" is okay, but i might be thinking too harshly here
16:14:55 <geppetto> spot: Well I think of that as the "most simple" non-network case
16:15:22 <geppetto> spot: I'm much more worried about random packages starting "local only" daemons, eating RAM/CPU/etc.
16:15:39 <spot> can anyone think of a service that meets the "runs once and goes away" that we would not want on by default?
16:16:30 <geppetto> And we allow people to install cron jobs, which is the same thing … no?
16:16:38 * spot cannot think of one
16:17:34 <geppetto> Me either
16:17:55 <geppetto> So I'd be happy to +1, the list of exceptions … and any "run once" jobs
16:18:03 <Rathann> abrtd is useful, but not all the time - I wouldn't start it by default, the abrt applet could detect if any crashes have occured (I think it does that already) and ask to enable abrtd if necessary
16:18:36 <geppetto> Rathann: Are you sure that works?
16:18:48 <Rathann> and I seem to remember someone in the devel list saying it's not necessary to run abrtd
16:19:12 <Rathann> geppetto: not sure
16:19:34 <abadger1999> If we're allowing NetworkManager what about other network configuring scripts?
16:19:59 <tibbs|h> Surely we'd only want zero or one of those.
16:20:07 * abadger1999 supposes network might fall under teh "run once" jobs
16:20:13 <tibbs|h> (sorry, my network is still in and out)
16:20:19 <geppetto> abadger1999: Yeh, that's what I'd classify it as
16:20:47 <spot> Okay, so i am typing up a little draft.
16:20:53 <racor> Rathann: ABRT is useful in certain use-cases (Single-User, developer machines), in most others it's not useful (multi-user, non-IT user base), in some it causes malfunctions (tight memory setups)
16:21:29 <tibbs|h> My problem with the run-once stuff is things like alternate firewall implementations.
16:21:34 <Rathann> racor: agreed
16:21:58 <tibbs|h> But I guess they require configuration, and so wouldn't fall under that rule.
16:22:29 <limburgher> tibbs|h: Right.  That's the case for one of my boxes.
16:22:32 <tibbs|h> I just don't want to see the argument of "it provides a useful default configuration at installation time, so should start at boot"
16:23:48 <spot> https://fedoraproject.org/wiki/User:Spot/DefaultServices
16:25:10 <abadger1999> Well... alternative network stacks would also require configuration.
16:25:34 <spot> abadger1999: yes, but at the moment, NM is the only network stack being configured by anaconda
16:25:38 <abadger1999> Which might be another argument for keeping those off.
16:26:02 <abadger1999> Yeah -- I'm saying NM can have an exception but /etc/init.d/network and similar would not.
16:26:18 <spot> abadger1999: we could add the "and does not require configuration" to the runs once and goes away criteria
16:26:18 <Rathann> spot: except abrtd, it looks good to me
16:26:41 <abadger1999> yes please,
16:26:41 <spot> Rathann: abrtd does not require configuration and is not network enabled.
16:26:54 <spot> Rathann: so, technically, it doesn't even need an exception, it has permission.
16:26:54 <abadger1999> (moving the require configuration to cover run-once)
16:27:12 <geppetto> spot: isn't readahead a run once thing?
16:27:33 <Rathann> but it eats up memory and is not that useful for less clueful users
16:27:45 <abadger1999> What about services which can use the network but by default are configured not to (I say, they fall under the exception)
16:27:53 <spot> Rathann: look, this isn't the appropriate place for that particular holy war.
16:27:54 <geppetto> spot: Also … do we really want to non-network daemons generic exception?
16:28:16 <spot> geppetto: yes, i think there are few enough of those that we can permit it
16:28:21 <abadger1999> What about services that can listen on 127.0.0.1 but nothing else by default (I say they also fall under the exception)
16:28:34 <tibbs|h> I'd say no.
16:28:36 <Rathann> well, I'm against giving all daemons a blanket approval for getting started by default
16:28:47 <Rathann> I'd say we need a whitelist, not a blacklist
16:28:57 <spot> Rathann: i don't think that scales well at all.
16:29:27 <tibbs|h> Well, it scales if you want the default state to be only absolutely essential things on.
16:29:42 <tibbs|h> Because the set of absolutely essential things is small and changes only rarely.
16:29:52 <abadger1999> Hmmm... if the first rule was in place, things like postgresql and httpd (properly default configured) could be on by default.
16:29:55 <spot> tibbs|h: the problem i think we'll run into is that it turns us into the group that decides what starts on boot
16:29:56 <Rathann> tibbs|h: depends on the definition of absolutely essential :) but yes
16:30:05 <abadger1999> tibbs|h: +1 to essential being a better criteria
16:30:05 <tibbs|h> I suppose my ideal situation of "nothing on at all, the installer can turn it on if it wants" won't fly.
16:30:22 <spot> as opposed to defining criteria for what is acceptable for being enabled by default
16:30:29 <racor> tibbs|h: Agreed, this would disqualify ABRT, because it's definitely not essential.
16:30:31 <abadger1999> Truth be told, I really like that idea :-)
16:30:38 <spot> abadger1999: i do not.
16:30:40 <abadger1999> (installer can enable)
16:30:42 <geppetto> I assume the other problem with "local only" is that if we disallow it, then someone has to decide what to do with every dbus service, etc.
16:30:56 <spot> abadger1999: sorry, wrong point, i don't have a problem with anaconda turning things on
16:31:05 <spot> geppetto: yep.
16:31:11 <tibbs|h> Are dbus-activated things involved in this at all?
16:31:48 <spot> tibbs|h: i'd rather let them continue to do their own thing, as long as we permit dbus to be on by default
16:31:53 <geppetto> tibbs|h: AIUI there is less difference between a dbus service and a systemd service, so it doesn't make sense to treat them differently
16:32:11 <abadger1999> We probably want to -- I was just going to mention that we should mention that we are including inetd services in this.
16:32:16 <Rathann> tibbs|h: +1 to the nothing at all + installer-enabled idea, maybe with a small list of exceptions like the ones spot listed
16:32:23 <geppetto> I guess I'm +1 on the draft … I'd prefer to get rid of the local-only exception, but meh
16:32:55 <geppetto> Rathann: One problem there might be that stuff "works differently" if you install it via. anaconda or on it's own
16:33:06 <spot> i do not think we are the appropriate body to tell anaconda that they have to enable services.
16:33:11 <geppetto> So I can see how moving that to the packages will make things easier
16:33:42 <spot> i do however concede that we are the appropriate body to tell packagers when they can enable included services by default.
16:34:14 <tibbs|h> spot: I don't disagree, but we can start with "what would the installer enable if it could do that?" and work from there.
16:34:29 <tibbs|h> Which I guess is what the current exception list does, perhaps not including abrt.
16:34:57 <spot> tibbs|h: i do not want to be casting judgement on any service
16:35:08 <spot> the fact that people dislike abrtd is irrelevant.
16:35:12 <tibbs|h> Isn't that what we're doing anyway?
16:35:25 <spot> this is _not_ the appropriate forum to say "i hate it, it is buggy, we should disable it by default"
16:35:36 <spot> take that to FESCo
16:35:46 <spot> it is part of the current default image
16:35:51 <tibbs|h> It is the intended forum to say "it's not an essential system service; don't enable it by default".
16:36:03 <Rathann> tibbs|h: +1
16:36:07 <abadger1999> tibbs|h: +1
16:36:12 <tibbs|h> Or, if it's not, then why are we discussing exceptions and lists anyway?
16:36:24 <spot> it is currently enabled by default.
16:36:41 <spot> i am extremely uncomfortable with changing that
16:36:44 <abadger1999> spot: Doesn't mean it's right...
16:36:50 <tibbs|h> It never should have been enabled by default in the first place.
16:37:03 <spot> especially given that it would be permitted to be enabled by default without any exception in this draft
16:37:09 <spot> (it is non-network and requires no configuration)
16:37:12 <limburgher> I think the argument was that if it wasn't on by default, it would never be used.
16:37:27 <abadger1999> spot: abrt is network enabled.
16:37:32 <spot> abadger1999: the applet is
16:37:49 <Rathann> well, the truth probably is - if it hadn't been enabled, most of its bugs wouldn't have been fixed
16:37:51 <abadger1999> Ah... okay.
16:37:53 <spot> abadger1999: abrtd just detects and traps the crashes
16:37:59 <tibbs|h> Honestly I don't care specifically about abrt.
16:38:13 <abadger1999> I still don't think it would satisfy "essential" however.
16:38:22 <spot> tibbs|h: my problem with a whitelist is that we end up acting like FESCo and making judgement calls on apps
16:38:22 <tibbs|h> Since I don't ever install it, I can't talk about it specifically.
16:38:31 <spot> and that is NOT our responsibility, that belongs to FESCo
16:38:56 <tibbs|h> I thought FESCo asked us to decide this?
16:39:00 <abadger1999> smolt is just as useful, for instance.
16:39:00 <limburgher> Could it be enabled by default but not in the default install?
16:39:28 <spot> tibbs|h: FESCo asked us to define criteria for what can be enabled by default
16:39:55 <spot> limburgher: sure.
16:40:02 <spot> we're not responsible for what is in comps
16:40:07 <abadger1999> spot: I disagree about the responsibility... we aren't saying an app cannot be in the distribution -- we're saying that it cannot turn itself on if the package is installed.
16:40:48 <racor> spot: I think this whole topic should be responsibility of those who build the distro (rel-eng, QA, testing?), and not ours.
16:41:35 <spot> abadger1999: yes, but if we were to explicitly exclude abrtd, which we know is in the default comps image right now, we're doing that.
16:41:43 <spot> so let me back us up a bit.
16:42:12 <spot> i've removed abrtd from the exceptions list and added the "does not require configuration" to the "runs once" criteria
16:42:22 <abadger1999> spot: How so?  1) The installer/firstboot could turn it on. 2) It can still be installed, it just requires someone to turn it on.
16:43:18 * abadger1999 still likes tibbs's criteria of essential better than the broad exceptions that are in the draft.
16:43:35 <racor> spot: abrt is not my point - I talking about "which services to enable by default", rel-eng topic - If they want "ABRT by default". so be it, independently of whether I consider it to mature enough or not.
16:44:16 <geppetto> abadger1999: I think "essential" is too subjective, so I do prefer spot's more objective filters
16:44:20 <spot> racor: you seem to think rel-eng decides what goes into a release, i think that is FESCo
16:44:25 * abadger1999 also notes -- if the current draft passes, then he has no problem with abrtd being on by default -- it's consistent with the draft.
16:44:44 <spot> on my draft, it may be worthwhile to give iptables an exception
16:44:44 <geppetto> abadger1999: Also, I think we'd want to good reason to approve something that doesn't fit with that happens atm.
16:44:50 <geppetto> why?
16:44:58 <spot> because it is likely to be configured by anaconda by default
16:45:11 <spot> even if that configuration is to disable it.
16:45:15 <limburgher> in fact I think that's unavoidable, even if it's all open.
16:45:18 <geppetto> So … it can still run without configuration … it just doesn't do anything
16:45:18 <limburgher> jinx
16:45:28 <racor> spot: OK - FESCO - if you say so. would be news to me they are working on anaconda and writing comps.
16:45:57 <spot> is anyone opposed to adding iptables as an exception?
16:46:11 <abadger1999> +1 to iptables and ip6tables
16:46:21 <racor> both require configuration
16:46:33 <tibbs|h> The default without iptables is "all ports open", right?
16:46:33 <geppetto> no, but I don't see why it needs to be one … it seems bad to have a bunch of exceptions which aren't exceptional to the rules
16:46:38 <spot> racor: yes, but both will almost always be configured by anaconda.
16:47:07 <spot> geppetto: hmm, are you positing that iptables does not require configuration?
16:47:09 <Rathann> I thought iptables were configured by firstboot
16:47:11 <geppetto> spot: If by "requires no configuration" you mean "does something useful/significant without any configuration" … then you probably want to change that wording
16:47:41 <geppetto> spot: I'm saying that there are a bunch of "run once" things that just do nothing, without configuration … and I'd be happy for them to all run (and do nothing)
16:47:47 <spot> geppetto: perhaps "does not require configuration to be functional" is more appropriate...
16:48:02 <geppetto> yeh, that's mostly what I assumed it to mean
16:48:25 <spot> with that wording, iptables would not need an exception.
16:48:32 * geppetto nods
16:48:39 <spot> okay, i made that change
16:49:00 <geppetto> ok … and why does readahead need an exception?
16:49:07 <geppetto> After that … +1 to the draft
16:49:10 <spot> it may not
16:49:15 <spot> i am not overly familiar with that
16:49:24 <geppetto> AIUI it's a run once thing
16:49:53 * spot looks
16:50:07 <tibbs|h> That was my understanding as well.
16:50:13 <spot> okay
16:50:16 <spot> i'll drop it too
16:50:28 <geppetto> ok … so +1
16:50:34 <spot> +1 from me
16:51:27 <abadger1999> -1
16:51:51 <limburgher> +1
16:52:02 <abadger1999> I can suggest improvements to the current draft but I think I'd still vote -1...
16:52:32 <abadger1999> We should specify that this covers activated services like inetd and dbus/systemd activation as well.
16:52:59 * spot has no issue with that.
16:53:08 <racor> How about cron, atd?
16:53:22 <abadger1999> And we should also clarify whether the local-only exception covers things that are configured to be local-only but can be non-local.
16:53:50 <tibbs|h> I'm in the middle.  As a realist, I understand that there's little chance of getting to where I think this should be.
16:53:55 * spot sighs
16:53:55 <abadger1999> Good question.  Is there any reason to allow something to install something that uses atd at all?
16:54:01 <abadger1999> cron.... not sure.
16:54:39 <racor> gpm ... people installing it will assume it to run  ...
16:54:57 <spot> abadger1999: if the default configuration included with a package is explicitly local-only, then i think it is covered by the exception.
16:55:13 <tibbs|h> The "I installed it, why didn't it run by default" problem is general.
16:55:20 <abadger1999> spot: We're okay, then, with postgresql and httpd being on by default?
16:55:42 <spot> abadger1999: no, because postgresql does not come with a default configuration, last time i looked
16:55:49 <spot> neither did httpd
16:56:08 <abadger1999> spot: But either can come with a default configuration.
16:56:14 <Rathann> httpd just shows the default page if I remember correctly
16:56:34 <tibbs|h> I'd also argue that listening to 127.0.0.1 is indeed listening to the network, unless we've started discounting attacks from unprivileged local users.
16:56:35 <abadger1999> I think httpd just needs to be tweaked to only listen on localhost to satisfy this criteria.
16:57:10 * spot is about to bang his head on his desk
16:57:40 <tibbs|h> Why?  You somehow thought this was a simple issue that everyone would agree on?
16:58:01 <spot> no. i just get annoyed at the level of nitpicking sometimes, even when it is necessary.
16:58:23 <spot> it is not in my nature to be a "rules lawyer"
16:58:26 <abadger1999> hehe.. I just don't want the nitpicking to occur in bugzilla if I can help it :-)
16:58:44 <geppetto> tibbs|h: I think it's less useful to argue about stuff that is already happening
16:58:50 <tibbs|h> Far better that we nitpick amongst ourselves.
16:58:51 <spot> i would prefer to give packagers the benefit of the doubt and restrict later when and if it is an issue.
16:59:00 <racor> spot: Has it come to your mind that this approach might not be the right one?
16:59:14 <spot> racor: absolutely, but no one else has bothered to draft anything.
16:59:17 <tibbs|h> geppetto: If you extend that line, why have guidelines at all, since folks can just ignore them and then we don't get to talk about it.
16:59:43 <tibbs|h> Certainly we can at least try to turn the failboat around.
16:59:47 <spot> if anyone else thinks that they can draft a better set of guidelines as to when a package is permitted to enable a service by default, by all means, speak. :)
17:00:09 <geppetto> tibbs|h: what I mean is … people have already decided that N things should start by default, just in an ad hoc way … so doing a draft which changes what those N things are seems … pointless
17:00:23 <spot> alternately, if anyone thinks that we should simply ask FESCo to provide a list of what must be enabled by default (whitelist), propose it.
17:00:25 <tibbs|h> Well, my suggestion was unworkable.
17:00:54 <abadger1999> tibbs|h: Is it really?
17:01:07 <tibbs|h> Well, we can't force anaconda folks to do anything.
17:01:09 <racor> spot: Isn't possible to map what we had so far (w/ sysvinit) 1:1 to systemd?
17:01:14 <tibbs|h> It's the same as forcing rpm to do something.
17:01:24 <tibbs|h> Do we actually have a list of what's enabled now?
17:01:40 <tibbs|h> Keeping it as is certainly doesn't make anything worse.
17:01:45 <abadger1999> we don't -- it's not in package metadata.
17:02:12 <spot> in theory, we could do an everything install and generate a list.
17:02:34 <spot> but that, to an extent, grandfathers possible bad behavior.
17:02:42 <spot> and it does not provide guidance for new packages.
17:02:42 <Rathann> or just the packages that own files in /etc/init.d/ and /etc/rc.d/init.d/
17:02:57 <abadger1999> Rathann: that won't work in rawhide :-)
17:03:19 <Rathann> ... right
17:03:21 <tibbs|h> Well, guidance for new packages is easy: not on by default.
17:03:44 <tibbs|h> That's what we have now, isn't it?
17:03:57 <spot> tibbs|h: roughly, yes.
17:04:22 <spot> So, we could say, not on by default except for what is already on by default.
17:04:29 <tibbs|h> It feels like a bunch of this discussion has been about crafting general guidelines and a small whitelist in order to basically capture the current set of "on by default" services.
17:04:57 <spot> but as soon as we add abrtd to the list and people get on their soapboxes about it, we've gone outside of the scope of the FPC
17:05:16 * abadger1999 notes that we are expanding the scope though if we include "activated" services.
17:05:53 <tibbs|h> Should we stop talking about services and start talking in terms of systemd units?
17:06:07 <tibbs|h> Because I'm starting to lose the plot of what is actually a service now.
17:06:14 <Rathann> I think this guideline should be handled like the bundling exceptions: off by default, on for exceptions that provide good reasons (i.e. essential for system operation)
17:06:43 <Rathann> just like FESCo asked
17:06:58 <spot> Rathann: and i am saying that i do not feel we are chartered to determine what is essential.
17:07:12 <limburgher> tibbs|h: And I think it would be acceptable to say that and move the abrrt discussion to another time?
17:07:20 <spot> e.g. FESCo has repeatedly approved abrt as a feature
17:07:29 <abadger1999> And try to create more general guidelines as we get new requests?  That would be fine with me... preseed with the ones that we already think need an exception.
17:07:40 <tibbs|h> Well, abrt breaks the current rules.  It could break the new ones as well.
17:07:50 <abadger1999> spot: abrt as a feature has nothing to do with whether the package enables it or not, though.
17:07:51 <limburgher> exactly
17:08:10 <abadger1999> and yes, I agree with what tibbs said as well.
17:08:21 <spot> abadger1999: i'm not sure i would agree with that, and I suspect strongly that the abrt developers would not agree either
17:08:30 <Rathann> even better: abrtd could be enabled by default on rawhide and disabled on released branches
17:08:30 <tibbs|h> I don't feel we get anywhere by worrying about abrt breaking the rules as part of this discussion.
17:08:46 <Rathann> (just an idea)
17:08:53 <tibbs|h> Or worrying about abrt at all as part of this discussion.
17:09:00 <Rathann> like kernel debugging options
17:09:12 <abadger1999> <nod>
17:09:26 <spot> Are there any other drafts on the table on this topic?
17:09:40 <spot> Or people volunteering to draft something for a later date?
17:10:00 <Rathann> sorry, no time :(
17:10:25 <tibbs|h> Mine wasn't a draft, I guess.
17:10:42 <tibbs|h> So, what are we left with?
17:10:58 <abadger1999> All services (started by systemd, xinet.d, bus activated, etc) should not be turned on by the package unless they are granted an exception.  The exceptions are listed on this page along with reasons that the exception was granted which may lead to more general rules in the future:
17:11:40 <tibbs|h> I love punting the difficult general rules to the future while still getting something done.
17:11:41 <abadger1999> Essential System Services: dbus openssh syslogd  NetworkManager
17:12:19 <spot> abadger1999: please eof when you're done.
17:12:24 <tibbs|h> (no sarcasm in that)
17:12:25 <geppetto> abadger1999: So one problem with that is, AIUI, that you can't disable a dbus service … if it's installed it's enabled
17:12:29 <tibbs|h> Personally I have to acknowledge that dbus-activated things are beyond my ken at this point, though.
17:12:51 <abadger1999> auditd
17:13:29 <abadger1999> Services which are only run during boot and provide a better system: readahead iptables ip6tables
17:13:36 <abadger1999> eof
17:13:54 <spot> Okay, abadger1999's draft is on the table.
17:14:04 <spot> -1
17:14:10 <abadger1999> We can continue to expand o nthat, but that's the framework that Rathann proposed.
17:14:15 <geppetto> spot: why?
17:14:24 <spot> geppetto: multiple reasons
17:14:36 <spot> geppetto: 1) we will end up being the "services police"
17:14:41 <spot> 2) it does not include abrtd
17:14:42 <abadger1999> geppetto: I think mainly: [09:06:57] <spot> Rathann: and i am saying that i do not feel we are chartered to determine what is essential.
17:14:51 <tibbs|h> We already are the services police.
17:14:54 <spot> 3) we are not chartered to determine what is essential
17:15:04 <tibbs|h> People just haven't asked us for exceptions.
17:15:26 <geppetto> So why not just add some text saying FESCO/rel-end/whoever-else makes the determination of what is an exception?
17:15:41 <spot> 4) A draft of this nature should come from FESCo
17:16:17 <limburgher> geppetto: So wouldn't FESCO have to sign off on the list?
17:16:26 <tibbs|h> So, wait, the draft you proposed is OK to come from us, but Toshio's draft isn't appropriate?
17:16:40 <tibbs|h> Because I'm having trouble grasping the nuance.
17:16:51 <limburgher> We could say that the policy is our bailiwick, saying all but list XYZ, but XYZ is under FESCO control.
17:16:52 <abadger1999> I disagree with 3 and 4 ... but then I agree with tibbs that we already are the "service police" .... essentially that it is within our charter.
17:17:50 <tibbs|h> I dislike that we've been at this for so long without progress.
17:17:57 <abadger1999> limburgher: We could... however, that didn't work out well with bundled libraries.  OTOH, we may not be interesting in "fixing" these in the same way as bundled libraries.
17:18:01 <tibbs|h> Is there any commonality that we can agree on?
17:18:19 <spot> my draft has guidelines. abadger1999's does not.
17:18:27 <spot> aside from "no"
17:18:28 <limburgher> abadger1999: true, it's an ongoing fight.
17:19:04 <geppetto> How does everyone else feel about abadger1999's proposal?
17:19:16 <spot> i do not think that we can assign technical reasoning to exceptions without political grandstanding
17:19:34 <tibbs|h> Well, everything's political.
17:19:36 <spot> and for better or worse, political grandstanding is FESCo
17:20:01 <geppetto> bah, the md5 bundling thing is our problem … and that's at least 50% political
17:20:12 <limburgher> I like the idea of the proposal, separate from the list.  The list should come from FESCO.
17:20:24 <spot> geppetto: fwiw, i've never been quite sure that we should be the ones deciding on bundling.
17:20:33 <tibbs|h> Unless fesco turns around and says the list should come from us.
17:20:43 <spot> geppetto: but at least in that situation, fesco said "you're responsible"
17:20:44 <tibbs|h> We could save a week by proposing one. Just saying.
17:21:14 <geppetto> tibbs|h: limburgher: It's my understanding that the exception list is just "what happens now" … ergo. it does come from FESCO already
17:21:18 <spot> i would vote +1 if there were guidelines for new packages to consider and reasoning was removed from exceptions.
17:21:33 <spot> (oh, and if abrtd was added to the exception list if it did not meet the guidelines)
17:21:43 <spot> but i suspect that is my draft
17:22:01 <geppetto> :)
17:22:04 <tibbs|h> Is the fundamental disagreement here one of whether "no" is an acceptable guideline?
17:22:16 <limburgher> geppetto: does it, or is it legacy?
17:22:46 <geppetto> limburgher: Same thing … if it's that way now, and FESCO ultimately make decisions … then the current list is from FESCO
17:23:15 <geppetto> tibbs|h: I don't think so … apart from the fact I'm not going to +1 anything that doesn't match current reality
17:23:20 <limburgher> geppetto: Eeeeehhhhhhh. . .sorta.  Ok, I can see your point, but it's not the same as it being explicitly blessed.
17:23:29 <Rathann> geppetto: +1 to abadger1999's
17:23:48 <spot> i would not be opposed to +1'ing a "no packages may start services by default, with the exception of items explicitly defined by FESCo"
17:24:11 <tibbs|h> geppetto: So matching current reality for you includes excepting packages which have been breaking existing rules?
17:24:13 <geppetto> spot: That's mostly my impression of what abadger1999 was trying for … and yeh, I'll +1 that
17:24:23 <tibbs|h> Not trying to argue, just trying to understand where you're comingg from.
17:24:29 <abadger1999> Could be -- I think that no is an acceptable guideline... I'd vote yes on a proposal that said "Services must be off except for those services needed for someone to turn configure other services via ssh, a local console, firstboot, [add other methods here if you've got them]"
17:24:32 <Rathann> and an initial guideline for starting by default: the system is unusable or doesn't do anything useful if service X is not enabled by default
17:24:58 <abadger1999> That was to tibb's's Is the fundamental disagreement here one of whether "no" is an acceptable guideline?)
17:25:07 <geppetto> tibbs|h: Yes … we can have a different discussion (at FESCO or whereever) about changing current reality, but yeh … abortd is on by default now, so the policy we approve should allow abrtd
17:25:17 <geppetto> IMO
17:25:18 <limburgher> Rathann: Cool, define a universally-applicable "useful".
17:25:22 <tibbs|h> I'm going to have to stop typing soon; my wrist arthritis is getting bad.
17:25:31 <spot> i much prefer my draft to the "no + FESCo's list", but i wouldn't oppose it.
17:25:33 <Rathann> also, as I said earlier, in rawhide it might be acceptable to turn on services which affect performance (abrtd?) but are useful for development
17:25:37 <geppetto> tibbs|h: But I'm happy with a blanket "no" for everything not currently allowed
17:25:44 * nirik notes fesco meeting scheduled in about 5
17:25:47 <abadger1999> geppetto: Eh.... I'm not opposed to abrtd specifically but I am opposed to a grandfather for these guidelines.
17:26:25 <abadger1999> If somethings on that doesn't make sense, it should get turned off... not make up rules that don't make sense to accomodate it.
17:26:52 <geppetto> abadger1999: Again, it's just going to cause pain to issue guidlines that don't match reality … if you want abrtd gone, that's fine … just get it removed in version 1.1 after FESCO/whoever says it's fine to go
17:27:19 <abadger1999> geppetto: A good percentage of hte rules we make cause pain.
17:27:28 <spot> we have a hard stop in two minutes
17:27:30 <abadger1999> Since they require changes to the way things are currently packaged.
17:27:40 <geppetto> abadger1999: Well your policy isn't rules so much as "no, but with these exceptions" … which is fine, but the exceptions should be the ones that are currently exceptional
17:28:08 <spot> so unless people want to vote on "no, but with these exceptions as defined by FESCo", i think we'll have to pick it up in a week
17:28:09 <geppetto> Anyway … I'm -1 on abadger1999, if it doesn't match reality … +1 if it does
17:28:11 <racor> I'd go for a "everything which was on by default in f14 is OK, new daemons should be off, unless approved by FESCO" guideline.
17:28:18 <abadger1999> geppetto: Sure.... but "exceptional" rather than "is currently on"
17:28:36 <geppetto> racor: Right, that's basically my vote too
17:28:41 <abadger1999> +1 for next week... but let's do the other guidelines first next week :-)
17:28:54 <spot> abadger1999: we cannot do systemd until this is decided
17:29:08 <abadger1999> spot: Why not?
17:29:17 <spot> abadger1999: it mentions what is enabled by default
17:29:24 <tibbs|h> I have to say I'd be quite disappointed to give the message that if you just ignore the guidelines for long enough we'll give you an exception without asking.
17:29:42 <geppetto> tibbs|h: post policy it's different
17:29:56 <tibbs|h> Oh, just this once, then?
17:29:58 <spot> tibbs|h: +1. i'm much more comfortable telling FESCo that they need to review the existing enabled list and send us back approved exceptions.
17:30:02 <geppetto> tibbs|h: right
17:30:11 <limburgher> spot: +1
17:30:20 <spot> with the understanding that they may simply rubber stamp the list
17:30:33 <spot> anyways, we are really out of time.
17:30:39 <gholms> :(
17:30:40 <limburgher> Or have an abrt flamewar. :)
17:30:40 <spot> we'll pick this fight up again next week
17:30:46 <Rathann> ok
17:30:47 <geppetto> that's fine too, it's basically "the current list" but immediately asking FESCO to review it, IMO
17:30:50 <tibbs|h> It sounds as if we have significant agreement.
17:30:50 <geppetto> so +1
17:31:07 <limburgher> I think we do.
17:31:10 <tibbs|h> +1 in the interest of moving forward.
17:31:18 <abadger1999> -1, I still think the review is our resposibility, not fesco's
17:31:18 <spot> tibbs|h: we can try to do a fast vote on "no, with exceptions as defined by FESCo"
17:31:37 <geppetto> spot: Right, that's what my +1 was for :)
17:31:40 <spot> i am reluctantly +1 on that
17:31:43 <limburgher> +1
17:31:58 <racor> +1
17:32:12 <tibbs|h> abadger1999: Our responsibility is dictated by Fesco.
17:32:16 <geppetto> abadger1999: We can certainly ask them if they want us to do it (like the bundling exceptions), when they review the list
17:32:35 <geppetto> But that's 5 +1, yeh?
17:32:36 <Rathann> +1 with asking who decides exceptions
17:32:56 <spot> okay, thats +5 and we will give FESCo the option of tasking us with making that call
17:32:59 <abadger1999> (If we're only missing one +1, we can revisit next week and I might change my mind about it).
17:33:01 <spot> (although, i really dislike that)
17:33:31 * nirik can try and bring that up in the open floor section today... I thought we did ask FPC to make the call, but I might be misremembering. ;)
17:33:39 <limburgher> Yeah, I'd rather they do the list.
17:33:50 <abadger1999> 5 +1, 1 -1, and rathann, want yours recorded as +1 or -1 since your question wasn't addressed?
17:34:03 <limburgher> nirik: That was for Bundled Library exceptions, IIRC.
17:34:24 <spot> #action No, but FESCo provides exceptions (and has the option of tasking FPC to determine exceptions). (+1:5, 0:0, -1:1)
17:34:39 <spot> nirik: for the record, lemme say that i am also opposed to FPC determining these exceptions.
17:34:45 <abadger1999> limburgher: FESCo did ask fpc to make the call -- but spot and I gave opposite input on whether that was within fpc's responsibility.
17:34:48 <notting> sorry about that, here now.
17:35:03 <spot> we really need to clear the room, thanks FPC members
17:35:03 <abadger1999> just carried over to fpc it seems.
17:35:05 <spot> #endmeeting