15:58:38 #startmeeting Fedora Packaging Committee 15:58:38 Meeting started Wed Feb 16 15:58:38 2011 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:38 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:58:43 #meetingname fpc 15:58:43 The meeting name has been set to 'fpc' 15:58:56 #topic Roll Call 15:59:56 ping: abadger1999, tibbs|h, Smoother1rOgZ, rdieter_work, geppetto 16:00:31 here 16:00:52 Yep. 16:01:59 * spot assumes racor is also here 16:02:33 * abadger1999 here 16:02:37 here 16:02:53 okay, thats 5, so we have quorum. 16:03:19 #topic Systemd - https://fedorahosted.org/fpc/ticket/31 16:03:44 abadger1999, thanks for your testing, i've sent Lennart a note asking for him to look into those issues 16:04:02 spot: Thanks, I ran a yum update on that vm last night. 16:04:11 I can test some more. 16:04:31 abadger1999: okay, we'll hold on this one until those issues are resolved 16:05:04 #topic List of Services which may autostart from FESCo - https://fedorahosted.org/fpc/ticket/41 16:05:19 https://fedoraproject.org/wiki/User:Kevin/DefaultServices is the list that FESCo generated 16:05:41 they would like our feedback on this list, specifically "tell us if they don't like any parts of it or would like us to handle exceptions moving forward." 16:06:03 So... I don't think we were clear enough with what we wanted somehow. 16:06:07 I assume you have the same objections as before to us deciding on exceptions. 16:06:19 tibbs|h: indeed, i do. 16:06:22 Might be my fault about how I opened the ticket. 16:06:45 but they didn't just give us a list of exceptions back, they also gave us guideline text back. 16:07:07 Which has all the problems that we hashed out in our meeting and we decided wasn't suitable. 16:07:30 abadger1999: yeah. 16:08:04 i thought they had gone through the list of "currently enabled services" and were breaking it down to a permitted list 16:09:42 We also didn't give them anything concrete about what criteria to use to decide whether a service should be enabled. 16:09:43 my inclination is to be more clear and ask them to just generate a list of services, perhaps broken down by category if they feel like they can identify categories that merit enablement by default 16:10:12 Problem is that we're both running out of time and starting to look kind of foolish. 16:10:31 tibbs|h: running out of time for what? 16:10:39 To get this cleaned up. 16:10:42 Maybe we could say something like "Only essential services are allowed to be on by default. FESCo (or FPC) will decide the list of essential services. 16:10:46 I mean, we're getting close to alpha. 16:12:11 abadger1999: yes, with the caveat that i'd drop the "or FPC" from that. 16:12:19 We may already be so close to alpha that changes to some existing packages won't go in until F16... but that doesn't seem like a blocker. 16:13:00 spot: well -- the fesco/fpc thing..... I don't know. I think that fesco is willing to see it as our mandate or not our mandate to deal with it. 16:13:00 Sure, there's always another release. 16:13:19 i can't see any way that defining what is an essential service is a packaging issue. 16:13:43 you and I see the responsibility from different angles.... I suppose we should vote on that here and then tell them. 16:14:06 Personally I can see arguments for and against. 16:14:11 abadger1999: we can vote, but we just barely have quorum today, and since I think you can guess how i would vote... ;) 16:14:11 tibbs|h: Dito 16:14:15 But above all I'd love to get past this. 16:14:26 abadger1999: Do you have a strong opinion on it being our responsibility? 16:14:52 spot: heh ;-) Do we want to go with majority of those present since it's just something we have to get done? 16:15:01 From my (personal, not speaking for the rest of fesco) perspective: If FPC wants to define what's acceptable, then FPC gets to handle exceptions. If FPC wants Fesco to handle exceptions, Fesco gets to define what's acceptable. 16:15:21 I don't think there's any benefit in having one body writing rules and another interpreting them. 16:15:31 Can't disagree with that. 16:15:34 * spot doesn't want to define the acceptability criteria or the exceptions 16:15:38 Not for something as judgement-dependent as this. 16:15:42 spot: We got that :) 16:15:49 mjg59 +1 16:15:52 geppetto: just making it crystal clear. :) 16:16:01 I can agree with that... it would also be part of my reasoning for why FPC needs to handle the exceptions though. 16:16:08 So if FPC just wants to punt responsibility entirely then I'm sure we'll take it, but that's really not the impression I'd been getting from what we were being told via tickets from you 16:16:27 It is telling, though, that in the end whatever is decided will go into the packaging guidelines. 16:16:29 mjg59: i think we are split on this internally. 16:17:00 spot: Ok. So at this point either Fesco unilaterally decides that it's our responsibility, or I think we ignore the issue until FPC comes to some sort of agreement. 16:17:08 ie: I'm not attached to FPC being the arbiter of the exceptions in this instance (it wasn't working in the bundled lib case but maybe this one will be less troublesome); but I very much think that the FPC needs to make all the packaging rules. 16:17:14 (Again, myself, not speaking for anyone else on fesco) 16:18:22 spot: Yes, we are split. I think it's FPC's job to write up the "how to integrate with systemd", but not to specify "which services to allow". 16:18:41 * spot is not interested in waiving the quorum vote rule, but i would let this vote go out to all FPC members via a ticket or email 16:18:44 abadger1999: Right, but I can see spot's point that "this is how you create an rpm for a service which auto starts" and "here are the list of services which can auto start" are not the same thing 16:20:08 Determining what is a service that can auto start seems like a packaging rule, though... it's something that reviewers will check, for instance. 16:20:23 Ugh, my network connection is dropping again. 16:20:31 abadger1999: there is already precedent for non-FPC handled items in the guidelines, specifically, legal and licensing 16:20:57 abadger1999: It's not obvious that can be determined other than "your package is named openssh-server" etc. 16:21:09 abadger1999: We've had policies on this before - I don't see why they should become invalid now and why they need to be refined. 16:21:34 racor: to be fair, the existing service policies were very... ambiguous. 16:21:39 Yes. 16:21:46 Basically, rpmlint complained about it. 16:22:10 spot: yes, and for a reason: because things are not as "clear" as people may want them. 16:22:33 Licensing is about things that can't go into the distro at all. 16:22:47 This is about whether something can autostart. 16:22:58 To me that's a "How to package". 16:23:17 Should I follow the recipe for autostarting? Or the recipe for off by default. 16:23:48 i don't really wish to argue back and forth. 16:24:21 abadger1999: I am wondering, why people are trying to reinvent the wheel. Take what is in f14, clean it up and convert it to systemd? 16:24:23 Let's construct what we'd vote on. 16:24:25 i don't think this is the FPC's responsibility, determining which services can autostart is a FESCo design, IMHO, and i'd like to propose that we vote on that. 16:24:49 abadger1999: I also wonder why this can't be automated/scripted 16:24:57 Given what mjg59 said, are we willing to let fesco make wrong decisions here as well? 16:25:14 ie: We already discussed basically the draft that fesco has given us and determined that it wasn't suitable. 16:25:26 abadger1999: sure. that goes along with "FESCo is responsible for determining which services can autostart" 16:25:30 Are guidelines like that acceptable? 16:26:14 abadger1999: from my perspective, what the guidelines would say is this: 16:26:29 * abadger1999 nots again that mysql and httpd can be on by default with that rule. 16:26:35 *notes 16:26:49 Only essential services are allowed to be on by default. A list of essential services, as explicitly defined by FESCo, can be found here: LINK_OUTSIDE_GUIDELINES. 16:27:33 mjg59: Two questions: If we said that (what spot said), would that be fit your criteria of separation? 16:28:39 mjg59: and second, would you guys be happy to create a list rather than have the generic rules that are in the first couple paragraphs of nirik's draft? 16:29:55 Personally? I'm not comfortable with it being a static list. 16:30:17 k 16:30:34 If you want to define it that way then I (personally) would want attached rationale 16:30:50 I want to know what "essential" is intended to mean here 16:31:15 spot: I would vote against handing it off to FESCo with that perspecive. 16:31:17 Because the only essential service is init 16:32:02 okay. "Only essential services are allowed to be on by default. For a definition of what makes a service essential, along with a list of essential services, as explicitly defined by FESCo, see: LINK_OUTSIDE_GUIDELINES. 16:32:35 Ugh. Not really comfortable with that either. 16:32:45 I think the word "essential" is misleading. 16:32:48 I see that "this is how a package handles a service" is FPC, but "this is why a package gets to autostart" is not. 16:33:16 Essential to what? Implementing the features we advertise? Getting a Unix-like environment? Having the system boot? 16:33:17 here now (sorry, busy @ work) 16:33:20 mjg59: "essential" depends on which types of deployment/use-case scenarios the Fedora distro is aiming at - Defining this would FESCo or may-be FPB's job. 16:33:36 * spot sighs 16:33:41 okay, s/essential/approved 16:33:57 If it were reworded as "Services may not run by default unless they satisfy these guidelines" -> link, sure 16:34:10 spot: yeah, I don't think that really works... we're at a point where we're trying to hand a very specific subset of responsibility back but both parties don't agree that that subset would make for a healthy relationship. 16:34:27 abadger1999: i do not think that we speak with one voice here 16:34:36 i think it would be perfectly healthy 16:34:36 spot: that's true too. 16:34:49 mjg59: single-seat desktop w/ physical access makes a huge difference from activating all services necessary "to be able to upgrade a remote server" 16:35:02 i'm fine with FESCo determining the criteria for which services can be on by default 16:35:19 and i'm fine with them specifying the list of services that meet that criteria and any exceptions. 16:35:45 racor: Right, which is why I quibble with the use of the word "essential", because it implies one set of criteria but doesn't imply what those are 16:36:20 mjg59: please try not to quibble over the implications in wording choices here, i'm just trying to propose something that clearly draws the line of responsibility 16:36:40 (that we don't speak with one voice is true too) 16:36:57 abadger1999: yeah, i guessed that much. ;) 16:37:12 I'll admit to not understanding why this is such a big deal in the first place. 16:37:13 spot: From a demarcation line, no problem. But I (again, personally) wouldn't be willing to accept responsibility for implementing something when the language that's been given to us seems unworkable 16:37:31 mjg59: sure, but if it is only the language, we can clear it up 16:37:56 I mean, it could be as simple as "For details on whether a service is approved to autostart, see: FESCo page" 16:37:57 spot: Right, I'm just mentioning that now so you know before we go through another cycle of bouncing it to each other :) 16:38:01 I don't think it's only language. 16:38:47 we (FPC) clearly have some basic disagreements about what is or isn't our responsibility and whether we're comfortable giving that responsibility up if it is ours. 16:39:30 I guess we should vote on something that is similar to mjg59's wording. 16:39:50 * abadger1999 synthesizes something real quick 16:41:29 Actually... all my atempts come out with spot's phrasing with guidelines substituted for "definition" :-/ 16:42:29 Only essential services are allowed to be on by default. FESCo decides on policy about what makes a service essential, along with a list of the essential services, see: LINK_OUTSIDE_GUIDELINES 16:42:52 abadger1999: s/essential/approved 16:43:34 I wouldn't go for that. 16:43:53 abadger1999: why not? they're approving them, after all, along with any exceptions. 16:43:56 The problem with bundled libraries was that over time the definition of what was an acceptable bundled library changed. 16:44:13 abadger1999: that is just one of the problems with bundled libraries. 16:44:27 abadger1999: "essential" doesn't mean anything 16:44:30 It doesn't match reality 16:44:38 Without giving some guidance about what's being used as the criteria for deciding on whether a service can be on by default, that problem is even worse here. 16:44:58 mjg59: The idea is that FPC is giving fesco the ability to decide what essential is. 16:45:12 FESCo determines which services are allowed to be enabled by default. For more information, see: FOO 16:45:14 abadger1999: ANd I'm saying that the only meaningful definition of "essential" is "init" 16:45:48 mjg59: Sure. 16:45:56 then on $FOO, FESCo can either make a big list, or define criteria, or say "only services that Jack likes may be enabled by default" 16:46:12 So "essential services" means that no packages autostart, and whether or not a package autostarts gets determined by the appropriate SIG 16:46:37 mjg59: you know, if that's what FESCo decides, thats their call. 16:46:39 mjg59: could you explain further? 16:46:53 spot: Oh sure and I think it's internally consistent, but I'd rather that you ask us to do something useful 16:47:11 I don't understand "no package autostarts[...] whether a package autostarts is determined by a SIG" 16:47:34 abadger1999: Nothing in the repo autostarts. SIGs come up with some mechanism to enable package autostarting on their spin. 16:47:50 mjg59: what I would ask you if it was my decision, was to determine either a whitelist of packages that can autostart or define a criteria for when a service can autostart 16:47:57 mjg59: That would totally be okay with me. 16:48:06 FPC debated something along those lines 16:48:20 (With a slightly larger definition of essential :-) 16:48:29 abadger1999: The outcome of this would be that a Fedora install (rather than a desktop install) would give you a getty and nothing else 16:48:37 spot: I'd be fine with that 16:49:06 But then someone decided that FPC didn't have the authority to create a guideline that forced people to come up with those alternate mechanisms. 16:49:12 abadger1999: But in that case there's nothing for fesco to decide. So either don't devolve to fesco, or lose the word essential. 16:49:29 okay. So, let's not devolve to fesco. 16:49:31 mjg59: but that list or criteria would be up to FESCo, not pending FPC approval or even feedback 16:49:33 Because otherwise fesco has to define "essential" as "some set of things that aren't essential" 16:50:06 spot: Sure, if it's clear that fesco defines it then again I don't think that's a problem 16:50:30 mjg59: i suspect we are in agreement, but abadger1999 is not. 16:50:56 essential is a loaded word, and a poor choice on my part. 16:51:11 s/essential/smurfy/ 16:51:27 spot: Well, I can't help you there :) 16:51:37 and fesco is papa smurf 16:52:37 spot: Put some wording into a ticket and we'll vote on it... that way we'll only have to go through our arguments once more (when we add our rationales for our votes to the ticket). 16:52:52 I don't think any of us are going to change other people's minds. 16:52:54 So, perhaps this is more clear: FESCo is responsible for defining an approved list of services which may autostart, and/or defining criteria to determine when and if a service may autostart. 16:53:52 It's not more clear -- it's simply a different idea of what we should be voting on. 16:54:26 It may be closer to what you mean, but it's farther from what I mean :-) 16:55:23 fine. 16:55:26 this is https://fedorahosted.org/fpc/ticket/60 16:56:29 Do we also want to give feedback on Kevin's draft? 16:57:19 abadger1999: well, we can, but honestly, if FESCo is taking responsibility for defining what can be on by default, i'm fine with that definition and criteria. 16:57:25 ie: things like, "we discussed those policies and rejected them because apache and postgres could fall under the exceptions given there" 16:57:27 i was fine with it when i wrote it the first time. 16:57:52 abadger1999: worth noting that parts of GNOME pull in apache httpd these days. 16:58:15 spot: But they don't start up the system service, right? 16:58:25 it's for the per-user file sharing? 16:58:35 abadger1999: not sure, haven't looked tbh 16:58:35 * abadger1999 could be behind the times 16:59:23 i think that apache and postgres both require configuration to be functional and are network enabled 16:59:31 spot: Nope. 16:59:48 spot: The defaults for both can be made functional and limited to the local machine) 16:59:50 the only change i would make is about localhost vs the world 17:00:14 e.g. define network enabled as "connected to an external, non-localhost network" 17:00:51 but again, (and again) 17:00:58 i think FESCo needs to decide that. 17:01:01 not us, not me. 17:01:23 i'm giving feedback in the "they asked for feedback", not in the "i think i should be making this call" 17:01:46 EOF 17:01:56 And that's the whole hour. 17:02:30 Was there anything on the agenda we could actually have gotten through? 17:02:50 tibbs|h: sure, but this was the most "urgent" 17:03:31 * spot will send out an agenda for next wednesday that does not have this item on it 17:03:45 we can vote on #60 via trac 17:04:37 * spot will open the floor briefly for any other "must be addressed today" issues 17:04:40 #topic Open Floor 17:06:11 We should consider to take over the issue lurking inside of the thread starting at http://lists.fedoraproject.org/pipermail/perl-devel/2011-January/031424.html 17:06:47 short summary: mmaslano has changed "perl @INC" and perl installation paths 17:07:15 whether what she did is arguable and questionable. 17:07:25 First question I'd have is whether the Perl guidelines already cover this. 17:08:28 tibbs|h: I don't understand, could you elaborate? 17:08:43 racor: does this action violate the Perl packaging guidelines? 17:09:19 Do the current guidelines already indicate where to install things? 17:09:29 I really thought they did. 17:09:50 Or maybe I'm just not understanding what the base problem is. 17:10:05 worth reading: http://lists.fedoraproject.org/pipermail/perl-devel/2011-February/031449.html 17:10:48 spot: if you mean it lawerish, no it doesn't contradict to the "words of the laws" 17:11:05 so, i would say this is a FESCo issue, not an FPC issue 17:11:10 spot: this doesn't mean it's useful 17:11:24 What I'm missing is what it looked like before. 17:11:35 racor: unless you're proposing a change to the perl guidelines somehow 17:11:59 Also, it does seem somewhat antisocial for someone to just change this without discussing it with at least the rest of the Perl SIG. 17:12:04 tibbs|h: One example: it had been common practice to install _all_ perl-modules to %vendor_dir 17:12:21 now packages go into many different dirs. 17:12:25 But antisocial behavior isn't our bailiwick either. 17:13:01 "FESCo handles the process of accepting new features, the acceptance of new packaging sponsors, Special Interest Groups (SIGs) and SIG Oversight, the packaging process, handling and enforcement of maintainer issues and other technical matters related to the distribution and its construction. " 17:13:10 another example: they redefine %vendor_dir as "place for 3rd parties" to install modules to. 17:13:15 imho, this falls under "handling and enforcement of maintainer issues" 17:13:37 racor: i would encourage you to open a ticket with FESCo 17:13:41 this a) violates the FHS, b) is 100% orthogonal to our current practice 17:13:53 spot: I do not think this is a FESCO matter 17:14:12 I think what mmaslano did was to abuse leaks of the FPG. 17:14:41 racor: then propose a draft change to the perl guidelines, but be aware that we will get feedback from the perl sig 17:14:51 and to try establishing questionable, little-sought out rules on her own. 17:15:24 It would be nice to see a nicely written description of the FHS violation. 17:15:59 FHS says: 3rd party pages need to go to below /opt 17:16:20 => /usr/...perl5 is not the place for 3rd parties to install packages into 17:16:32 Who is a 3rd party? 17:16:37 rpmfusion? 17:16:55 * kanarip responds: yes, but no 17:16:57 this seems to me to be a clear case of a dispute between maintainers. 17:17:05 tibbs|h: Strictly speaking yes, ... 17:17:13 "3rd party" seems to have applied to "non-RPM", if you will? 17:17:26 waaaaaay outside FPC scope, completely irregardless of the validity of the claims 17:17:32 Because, frankly, rpmfusion sticking things in /opt would indeed be insanity. 17:17:35 spot: the dispute actually is about the meaning of %vendor_dir 17:17:56 racor: and %vendor_dir isn't defined in the guidelines, right? 17:18:00 so far %vendor had been "redhat"/"fedora" 17:18:13 Discussion on list seems mostly favorable to the new scheme (besides lib->%_libdir stuff). 17:18:16 spot: I'd have to check, but yes, I think so. 17:18:35 racor: then my suggestion would be for you to propose a change to the guidelines to define %vendor_dir 17:18:46 that is clearly in FPC scope 17:19:04 tibbs|h: what these people miss is that these new directories are completely superflous. 17:19:23 ... in terms of a distro. 17:19:33 if a ticket is opened on this when i get back from lunch, i'll put it in the agenda for next week 17:19:53 otherwise, i'm calling this meeting, so we don't crowd FESCo. :) 17:19:59 thanks everyone. 17:20:02 tibbs|h: it's what we've had in f14 17:20:02 #endmeeting