fpc
MINUTES
16:08:56 <geppetto> #startmeeting fpc
16:08:56 <zodbot> Meeting started Thu May 21 16:08:56 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:08:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:08:57 <geppetto> #meetingname fpc
16:08:57 <geppetto> #topic Roll Call
16:08:57 <zodbot> The meeting name has been set to 'fpc'
16:09:01 <geppetto> #chair tibbs
16:09:01 <zodbot> Current chairs: geppetto tibbs
16:09:06 <geppetto> #chair tomspur
16:09:06 <zodbot> Current chairs: geppetto tibbs tomspur
16:09:10 <geppetto> #chair orionp
16:09:10 <zodbot> Current chairs: geppetto orionp tibbs tomspur
16:09:13 <geppetto> #chair SmootherFrOgZ
16:09:13 <zodbot> Current chairs: SmootherFrOgZ geppetto orionp tibbs tomspur
16:09:17 <geppetto> #chair racor
16:09:17 <zodbot> Current chairs: SmootherFrOgZ geppetto orionp racor tibbs tomspur
16:09:24 <Rathann> hi
16:09:32 <geppetto> #chair Rathann
16:09:32 <zodbot> Current chairs: Rathann SmootherFrOgZ geppetto orionp racor tibbs tomspur
16:09:59 <geppetto> mbooth not here?
16:10:46 <geppetto> #topic Schedule
16:10:48 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-May/010658.html
16:11:10 <geppetto> jzeleny-home: ffesti: You ready?
16:11:15 <geppetto> #topic #531 	Discuss guidelines for use of weak dependencies
16:11:16 <geppetto> .fpc 531
16:11:16 <geppetto> https://fedorahosted.org/fpc/ticket/531
16:11:19 <zodbot> geppetto: #531 (Establish guidelines for use of weak dependencies in package specifications for F23.) – fpc - https://fedorahosted.org/fpc/ticket/531
16:11:28 <ffesti> yup
16:12:02 <tibbs> This is indeed a bit more fleshed out than the previous proposal.
16:12:07 <jzeleny-home> here
16:12:23 <tibbs> I wonder if the people who submitted this are even aware of the previous proposal.
16:12:41 <ffesti> damit I read ticket 492 for preparation...
16:12:43 <geppetto> tibbs: The reverse deps one? Yeh, they reference it, right?
16:13:04 <geppetto> tibbs: yeh, 492 is the first line :)
16:13:20 <tibbs> Ah, that's the one.
16:13:32 <tibbs> I was searching the wrong way, trying to find the old proposal first.
16:13:41 * geppetto nods
16:14:10 <tibbs> Anyway, my opinion is pretty much the same: documenting it is good; if it works in a defined way with the tools we have then I've no problem.
16:14:39 <Rathann> documenting when and why would be even better
16:14:44 <Rathann> with examples, of course
16:14:45 <tibbs> Although I do hope as well that they don't screw me over in practice.
16:15:29 <geppetto> yeh, the biggest worry I have is that if we aren't that strict about it they'll be a lot of cases where packagers randomly choose soft-requires/requires … or soft-requires/nothing.
16:15:30 <racor> tibbs: My expectations are the worst.
16:16:04 <tibbs> geppetto: Indeed, which is why I'm kind of troubled by people just going ahead and stuffing this stuff into their packages already.
16:16:15 <tibbs> At least if it gets documented something can happen.
16:17:42 <tibbs> Anyway, have I been dumb again and missed the proposed draft?
16:17:59 <geppetto> There isn't a proposed draft
16:18:13 <tibbs> OK, good, so I'm not that dumb.
16:18:13 <geppetto> That's why I changed the ticket to discuss guidlines
16:18:34 <Rathann> ^ what geppetto said
16:18:37 <Rathann> ;)
16:18:45 <jzeleny-home> at this point I suspect we need to have some agreement on the level of detail of the guidelines
16:19:01 <geppetto> Hopefully the main thing we can get today is some kind of "this is a high level of what the draft should say"
16:19:16 <jzeleny-home> sounds good
16:19:31 <tibbs> Half of the ticket is about whether we actually need to say "don't use this stuff now".
16:20:17 <ffesti> well, I started https://fedoraproject.org/wiki/PackagingDrafts/WeakDependencies a while ago
16:20:18 <geppetto> So the 3 possibilities I see are: 1) "Go use them to do whatever, and try not to be too crazy, this is what they do" … and look at what happened in a few months
16:20:33 <tibbs> But at a "high level", I'd prefer to say that this kind of thing should be used sparingly.
16:20:37 <orionp> I'm tempted to try to ban them to force the creating of some good guidelines
16:20:47 <ffesti> If I had known about this meeting more than 2 hours in advance I might have polished it up a bit
16:20:49 <geppetto> 2) A list of problems people think they can solve with them, and have recipe type things of "Do XYZ to solve ABC problm"
16:21:02 <geppetto> or something way more complicated, that I doubt anyone wants to write ;)
16:22:15 <tibbs> I actually kind of like #2.
16:22:58 <jzeleny-home> agreed
16:23:00 <orionp> #2 seems good, ffesti's doc seems like a template in that direction
16:23:02 <jsilhan> me too
16:23:03 <Rathann> ffesti: I think Recommends/Suggests get installed by default unless user explicitly configures dnf not to
16:23:10 <ffesti> as long as we do not have boolean deps yet the cases are actuallynot that complicated
16:23:23 <geppetto> ffesti: you have package preference on your page … do you think that's a good use of soft-requires, and won't need rich-deps?
16:23:30 <tibbs> To me the real issue is with the default behavior of the tools, what ends up just being ignored and what ends up the same as Requires:?
16:23:32 <Rathann> I'm in favour of #2 as well
16:23:43 <geppetto> jsilhan: hey, a dnf dev too :)
16:23:47 <tomspur> Rathann: Souldn't that be Recommends/Supplements (instead Suggests)?
16:23:57 <Rathann> tomspur: correct, my mistake
16:24:29 <jzeleny-home> geppetto: to be honest, the preference stuff is just a side effect in my opinion and the preference should be actually handled by a completely different mechanism
16:24:49 <Rathann> tibbs: Recommends is like Requires when installing, but you can uninstall whatever was recommended afterwards and there will be no broken deps, so it's different
16:24:56 <geppetto> jzeleny-home: Yeh, I would agree … but that seems to be the first usecase everyone else looks to solve, so :-o
16:25:04 <ffesti> The main use case for now is replacing Requires by Recomment where the package is not strictly required but wanted by the requiering package
16:25:06 <orionp> people may want to compare their packages to those in debian as well
16:25:11 <jzeleny-home> geppetto: yes, unfortunately
16:25:18 <tibbs> Rathann: Right, but to most people that's going to look just like Requires:.
16:25:32 <ffesti> Main reason is allowing smaller installations with a reduced feature set
16:25:40 <ffesti> like for containers or VMs
16:26:02 <tibbs> So treat it pretty much like Requires:.  And Suggests:, well, it is just a hint and hopefully doesn't actually do anything by default, so packagers can throw it in without much issues.
16:26:22 <orionp> speak of the devil - error: line 44: Unknown tag: Recommends:     python-theano   - epel7
16:26:22 <geppetto> ffesti: ok … that sounds simpler than it is. How do we define doesn't work? … and doing that conflicts heavily with people adding soft-requires to bring in more stuff
16:26:28 <ffesti> In general Forward deps should be used
16:26:42 <ffesti> unless the main package really should not care
16:27:00 <Rathann> I'd say: Use Recommends: for any packages that your package should have installed as dependencies by default, but doesn't crash without
16:27:19 <jzeleny-home> tibbs: pretty much. The idea there is to have the possibility to query the package and see if there is something related that can be also installed. Sort of an "FYI" if you will
16:27:19 <ffesti> Rathann, exactly
16:27:24 <tibbs> Rathann: Hey, I like that.
16:27:45 <geppetto> Rathann: so if not having something as requires means the program will only really do --version and --help … that's fine?
16:27:59 <Rathann> geppetto: "by default"
16:28:19 <tibbs> geppetto: Actually in a lot of cases, that might actually be fine.
16:28:25 <geppetto> Rathann: Ok, so the program should do it's "default" operation, without any recommends being installed?
16:28:33 <ffesti> geppetto, yes, If the package does not crash
16:28:42 <tibbs> It's going to be a judgment call anyway.
16:28:53 <ffesti> for things like containers people might want to have more controll over what modules they actually install
16:28:57 <Rathann> we should find an example :)
16:29:06 <Rathann> it's easier to explain with a good one
16:29:08 <geppetto> tibbs: well there's a pretty big difference between "doesn't crash" and "does something useful"
16:29:43 <Rathann> geppetto: I'd say Requires and Recommends should cover default user experience for a package
16:30:20 <ffesti> geppetto, but if a package can do multiple things (like en(decoding multiple formats) it is ok to not require any of the modules
16:30:25 <jzeleny-home> Rathann: sounds good
16:30:34 <ffesti> it will do something useful by default
16:30:42 <jzeleny-home> Rathann: and Requires only should cover some minimal set
16:30:47 <Rathann> exactly
16:30:47 <jzeleny-home> I actually have one specific example
16:30:49 <ffesti> only people wanting more controll can restrict the packages that get installed
16:30:51 <jzeleny-home> systemd in containers
16:31:12 <jzeleny-home> the default systemd is a pretty big steam machine
16:31:12 <Rathann> oh, gstreamer stack could be a good example
16:31:24 <jzeleny-home> but most of its functionality is not required in containers
16:31:31 <Rathann> also, libreoffice
16:31:46 <Rathann> and texlive
16:31:59 <ffesti> basically all documentation and examples
16:31:59 <tibbs> BTW, who is the DNF maintainer now?  I have had trouble keeping track.
16:32:06 <geppetto> jzeleny-home: But if you install that minimal set on a real install … nothing works, right?
16:32:15 <tomspur> I see the example for texlive, but now for the other two...
16:32:15 <geppetto> tibbs: meet jsilhan
16:32:35 <jsilhan> yeah, thats me
16:32:43 <tibbs> OK, cool.
16:32:50 <jzeleny-home> geppetto: pretty much ... the expectation is that user uninstalling Recommended packages knows what is he doing
16:33:07 <tibbs> I just wanted to make sure that someone who understood all of the details of the DNF implementation was onboard.
16:33:10 <ffesti> geppetto, that's what all those container guys want if I understod them correctly
16:33:36 <geppetto> jzeleny-home: That seems like a pretty big bar to get over … uninstalling packages that are happy to go (because they are only recommended), and then your system is unbootable … that doesn't seem like a good idea to me
16:34:06 <jsilhan> tibbs, well it's about depsolver implementation - not exactly dnf thing
16:34:20 <jsilhan> this is libsolv job but we can tweak it a bit
16:34:21 <tomspur> This sounds similar like gvim Recommending X, which seems odd to allow installing gvim without any X
16:34:27 <tibbs> But it's exactly a dnf thing.
16:34:30 <geppetto> ffesti: Yeh, but people want crazy things … they already have a fakesystemd, right? And that seems like a much better solution.
16:34:33 <Rathann> so gstreamer could have Recommends: gstreamer-plugins-good and Suggests: gstreamer-plugins-bad-free
16:34:36 <tibbs> Because that's the user interface people are going to see.
16:35:01 <tibbs> Exactly what all of the relevant tools will do is entirely the point of this exercise.
16:35:02 <Rathann> hm I wonder why pidgin, gnomebaker and farstream have explicit requires on gstreamer-plugins-good
16:36:16 <tibbs> geppetto: BTW, wasn't it only some yum protection plugin that kept yum uninstall from making your system unbootable?
16:36:41 <ffesti> geppetto, well, it depends on the package. For systemd and other things and can make the system no longer boot it might be worth comming up with a special handling
16:36:54 <ffesti> geppetto, but for things like documentation...
16:36:59 <geppetto> tibbs: Kind of, before the protection stuff the tools would let you confirm removing your entire system
16:37:23 <geppetto> tibbs: But at least you got the hint that removing bash (or whatever) was going to take 666 other packages with it
16:37:35 <racor> tibbs: No, IIRC "plain yum" had some protection, as well as rpm itself also has(d) some protection
16:37:45 <jzeleny-home> geppetto: you have a point ... I guess it's up to the maintainer and his judgement; we also have mechanisms to protect components which can make your system unbootable if uninstalled
16:37:49 <geppetto> tibbs: The problem is that with recommends, you could try removing XYZ and only XYZ would go … even though systemd now can't boot your system
16:38:01 <ffesti> rpm does not a protection against removing packages
16:38:06 <tibbs> We're kind of down into per-product configuration land here, where package dependencies alone aren't sufficient to express what's actually needed.
16:38:31 <ffesti> it is just not practical to remove the complete system with rpm as you need to add all packages at the command line
16:38:42 <geppetto> tibbs: right, which is why the systemd vs. fakesystemd solves this better … one product can install fakesystemd and it won't have the requires.
16:38:45 <racor> ffesti: rpm had a list of unremovable packages.
16:38:46 <geppetto> IMO
16:40:01 <Rathann> geppetto: I disagree, systemd should be able to trim down its strict dependency set and boot-critical stuff should be added to protectbase or something like that for Workstation product or nonproduct configuration
16:40:24 <Rathann> if the minimal dep set still allows stuff to work in container scenario
16:40:30 <jsilhan> weak deps isn;t cure for anything. You can split systemd into many provides and require only the needed features
16:40:31 <Rathann> then I'm all for it
16:41:02 <jsilhan> * anything -> everything
16:41:12 <geppetto> Rathann: So kickstart + minimal + no recommends == no boot … you think that's good?
16:41:38 <geppetto> tibbs: I know you wanted to do something like that … you happy with having to manually add systemd stuff in?
16:41:40 <ffesti> geppetto, you need to add those packages to minimal
16:41:56 <ffesti> for bootable system
16:41:59 <Rathann> obviously when you run kickstart you should know what you're doing, but the minimal set should result in a working container
16:42:10 <geppetto> ffesti: Dont' containers use minimal though?
16:42:33 <ffesti> hmm, may be you need to add it to something else
16:43:02 <ffesti> if we use minimal for containers then yes the result should be a unbootable system
16:43:06 <tibbs> geppetto: Oh, you mean a minimal server install?
16:43:21 <ffesti> but we need another group we use for bare metal installation
16:43:33 <Rathann> exactly
16:43:40 <tibbs> Yeah, I don't particularly have a problem with trying to make sure that /sbin/init is there.
16:43:48 <geppetto> tibbs: yeh, you'd mentioned wanting to just turn soft-requires off in your kickstarts
16:44:14 <tibbs> Yes.
16:44:58 <tibbs> I think if you want a system with the absolutely minimal dependency set, you kind of get to figure out how to actually drive that.
16:45:12 <ffesti> my guess is that people will need finer controll than just switching weak deps on and off globally for the whole system
16:45:39 <ffesti> so they will run some part of the installation with them switched on and some with them switched off
16:45:48 <geppetto> Ok, so given that I think we want the "by default" to be a much looser "in some condition" type thing. So that we can say moving a bunch of requires to recommends is fine if stuff works in the container, even though it doesn't anywhere else.
16:46:09 <geppetto> ffesti: How would that be possible, it's one transaction?
16:46:12 <tibbs> I wouldn't propose multiple levels of "Recommends:" for fear of feeling pain via IRC.
16:46:35 <tibbs> But if you need finer control, you just specify the deps you actually want.
16:47:02 <racor> ffesti: I think people will need a "per installation/transaction" --with/no-recommends
16:47:15 <ffesti> well, you run a few dnf commands
16:47:18 <geppetto> racor: in theory that's possible already with --setopt
16:47:50 <geppetto> More than that and I think you want a better UI than just yes/no.
16:48:07 <geppetto> Eg. dselect vs. apt-get
16:48:31 <jzeleny-home> geppetto: ... vs. aptitude
16:49:23 <ffesti> I would suggest to actually have some weak deps first and worry abut a UI later
16:49:41 <geppetto> yeh, maybe I have the names wrong … there's the default one that just installs all of them or not (pretty sure that's apt-get), then the one which shows a tree and lets you check/uncheck individual recommends
16:50:19 <jzeleny-home> ffesti: agreed
16:50:46 <racor> ffesti: We already have some.
16:51:03 <ffesti> The thing is that there are two opposing trends: #1 do not bother the user with all those details 2# More control over what gets installed
16:51:22 <racor> ffesti: Some folks went ahead and "just did it".
16:51:32 <ffesti> yup
16:51:48 <geppetto> ffesti: Right, and we have two options … and it looks like people want to go further in each direction with each option
16:51:50 <tibbs> I don't think it's acceptable to worry about a UI later.
16:52:11 <jsilhan> yep, repoquery filters and weak deps switch should come first
16:52:18 <tibbs> At least the general concepts of how that UI would work need to be considered before just going ahead and doing things.
16:52:32 <ffesti> well, there will of course be a basic UI for kickstart and dnf
16:52:40 <tibbs> But I don't think we need a fully functioning UI in every one of the tools before we approve guidelines.
16:52:40 <geppetto> So we'd have: 1) soft-requires turned off … you have lots of control, but have to be very careful or stuff won't work. 2) soft-requires on … you have little control and nethack gets installed when you installl bash ;)
16:53:11 <tibbs> geppetto: How are you defining soft-requires?
16:53:11 <geppetto> Which I'm mostly fine with, if someone wants to write the policy.
16:53:27 <geppetto> tibbs: the dnf option
16:53:29 <tibbs> Recommends: or Suggests:?
16:53:57 <geppetto> tibbs: the first one
16:54:32 <tibbs> Soft dependencies and really floppy squishy dependencies.
16:56:00 <tibbs> So where are we at?
16:56:23 <geppetto> I _think_ we are mostly agreed on what I said … although I didn't see any agreements :-o
16:56:32 <geppetto> So someone just needs to write that up in a policy
16:57:41 <ffesti> Is there a meeting next week?
16:57:49 <geppetto> yeh, there should be
16:58:21 <ffesti> Ok, I am PTO half of the comming weak but I should be able to polish https://fedoraproject.org/wiki/PackagingDrafts/WeakDependencies up til next Thursday
16:58:32 <tibbs> In any draft, I'd like to see reasonable examples, a provision for discussing how tooling deals with the various softnesses of dependencies in general terms, and some kind of admonition that at least Recommends: should be used sparingly where needed to trim the dependency list.
16:58:57 <Rathann> agreed
16:59:42 <racor> geppetto: OT, but while we're at it, I won't be able to attend the next two Thursdays (being on vacation).
16:59:51 <geppetto> racor: ok
17:00:06 <ffesti> tibbs, should the tooling stuff really go into the packaging policy?
17:00:25 <tibbs> The general concepts, yes.
17:00:33 <ffesti> ok
17:00:44 <tibbs> Specific information, not really; we don't want the guidelines turning into documentation for DNF.
17:00:48 <geppetto> ffesti: At least the option name should be easily accessible, so that people can find it.
17:01:02 <ffesti> ok, will put them in
17:01:30 <geppetto> #action ffesti Work on https://fedoraproject.org/wiki/PackagingDrafts/WeakDependencies for next meeting
17:01:43 <tibbs> The guidelines have always kind of straddled the line between being abstract, and documenting oddities in our tooling to explain why we have to do some bizarre things.
17:02:16 <geppetto> Ok, is there anything else anyone wants to bring up this week?
17:02:27 <racor> FWI: A quick count (still counting) tells, in F22  there already are > 25 Recommends and > 7 Suggests.
17:02:27 <tibbs> Can we just do the R thing?
17:02:42 <geppetto> tibbs: I meant for this ticket :)
17:02:52 <tibbs> Ah.
17:03:37 * tomspur likes to favor enhances over supplements
17:04:05 <tibbs> Yeah, the reverse dependencies thing probably needs some discussion too.
17:04:09 <geppetto> tomspur: that's the reverse recommends, over info-reocmmends?
17:04:32 <tomspur> geppetto: yes Supplements is the reverse Recommends
17:04:39 <tibbs> I like them because I can add a package A that enhances some other package B without having to mess with B at all.
17:05:19 <tibbs> But I'd really hate it if I were the maintainer of B and someone basically forced their package into my dependency list.
17:05:33 <tomspur> Maybe with a specific example I see the use case better. For now it just feels dangerous with random Supplements: bash
17:05:33 <ffesti> well, I have heard the very opposite opinion
17:05:37 <tibbs> So Enhances: good, Supplements: bad.
17:05:52 <geppetto> tibbs: that always felt wrong to me … I can see why it's a great hack for an add-on package you create and obviously can't change your vendor package
17:06:09 <geppetto> tibbs: But for the vendor itself, just change B … or not.
17:06:54 <ffesti> I might be able to come up with two variants of the policy one more reverse deps friendly and one more conservative
17:07:08 <tibbs> But I'm happy to leave all of that out of the draft, or to ban them altogether in Fedora.
17:07:27 <tibbs> I mean, in Fedora we don't have an upstream vendor who might not want to change anything.
17:07:35 <tibbs> EPEL can make their own rule if they want to do so.
17:07:57 <racor> ffesti: Why doesn't rpm have -q --whatrecommends etc. ?
17:08:00 <geppetto> Yeh, feel free to just concentrate on just "recommends" … when people can apply it, or change requires to it, and how users turn it off/on and what that means.
17:08:07 <tibbs> And of course you get into the question of whether someone can Enhances: a pacakge in rpmfusion or something.
17:08:14 <geppetto> We can then add more policy around reverse-deps later.
17:08:47 <tibbs> Well, if we're going to do anything with soft deps but leave off the reverse cases, we really should explicitly ban them.
17:09:14 <geppetto> jsilhan: Quick question … if you have recommends turned on … does it treat them as requires when doing clean_requirements_on_remove?
17:09:25 <tibbs> Because the whole "just throw random crap into your packages without guidelines" think is a recipe for disaster.
17:09:34 <tibbs> s/think/thing/.
17:09:44 <jsilhan> geppetto, TBH I don't know -> will try
17:09:57 <racor> FYI: Counting just finished: 27 Recommends, 7 Suggests in fc22
17:10:13 <geppetto> racor: So no reverse deps?
17:10:14 <tibbs> racor: Any Enhances: or Supplements:
17:10:21 <tibbs> ?
17:12:00 <ffesti> racor, looks like that slipped through somehow. Will add it.
17:12:05 <racor> geppetto, tibbs: Not checked yet, I just started it.
17:12:23 <racor> ffesti: OK, glad to hear this.
17:12:50 <geppetto> Ok, let's move on then.
17:12:56 <geppetto> #topic #532 	Guidelines Draft: Systemd Preset Policy
17:13:00 <geppetto> .fpc 532
17:13:01 <zodbot> geppetto: #532 (Guidelines Draft: Systemd Preset Policy) – fpc - https://fedorahosted.org/fpc/ticket/532
17:13:07 <geppetto> https://fedorahosted.org/fpc/ticket/532
17:14:49 <tibbs> I hadn't even seen this one yet.
17:15:15 <geppetto> yeh, it came in the last day or so
17:15:35 <geppetto> It seems fine, from what I can see
17:15:37 <geppetto> +1
17:15:42 <tibbs> The scriptlet snippet page is obvious to me.
17:15:48 <SmootherFrOgZ> +1 from me
17:15:57 <orionp> Looks good +1
17:16:03 <tibbs> The starting services by default policy should move into the guidelines.
17:16:33 <tibbs> I think.  Since it isn't there currently, I guess we don't care about changes made to it.
17:16:37 <tibbs> But +1 anyway.
17:17:09 <Rathann> +1 from me
17:17:49 <geppetto> racor: vote?
17:17:58 <geppetto> tomspur: vote?
17:18:12 <Rathann> and I agree with tibbs on the moving the policy into FPG
17:18:32 <tomspur> Do I see it right, that a service must meet all critera and not just one?
17:19:38 <Rathann> tomspur: no
17:19:42 <geppetto> I read the first one as being "here are the exceptions, everything else is banned"
17:19:52 <geppetto> Where each exception is self-contained
17:19:59 <Rathann> it's either local, non-persistent or is on the approved exceptions list
17:20:09 <tomspur> yeah... my mistake...
17:20:24 <racor> sorry, was reading +1
17:20:46 <tomspur> fstrim seems to be bad but would count as non-persistent service isn't it?
17:20:57 <geppetto> tomspur: yeh
17:21:17 <geppetto> what do you mean by bad?
17:21:38 <racor> geppetto, tibbs: FYI: There don't seem to be any Suggests and Enhances in fc22
17:21:48 <tomspur> I remember something about that on the fesco ticket discussion
17:21:49 <geppetto> racor: cool, thanks
17:22:27 <racor> Sorry folks, my time is up for today, I need to quit now.
17:22:33 <geppetto> racor: ok
17:22:46 <tomspur> geppetto: https://fedorahosted.org/fesco/ticket/1441#comment:4
17:23:51 <geppetto> tomspur: Well the policy does say "may be enabled by default (but is not required to do so)."
17:24:12 <geppetto> hopefully the fstrim packager wouldn't enable it, if it's dangerous
17:24:29 <tomspur> ok
17:24:31 <tomspur> +1
17:24:41 <geppetto> #action Updated systemd Preset Policy #532 (+1:7, 0:0, -1:0)
17:25:06 <geppetto> #topic #535 	Adjust the place of DESCRIPTION in R packaging guidelines
17:25:09 <geppetto> .fpc 535
17:25:12 <zodbot> geppetto: #535 (Adjust the place of DESCRIPTION in R packaging guidelines) – fpc - https://fedorahosted.org/fpc/ticket/535
17:25:14 <geppetto> https://fedorahosted.org/fpc/ticket/535
17:25:57 <geppetto> seems like a trivial +1
17:26:08 <Rathann> yes, +1
17:26:27 <tomspur> +1
17:26:53 <orionp> +1
17:26:57 <tibbs> +1
17:27:16 <orionp> we should also note why
17:28:06 <geppetto> not sure we really need to say "because DECRIPTION files aren't really docs"
17:28:33 <SmootherFrOgZ> +1
17:28:41 <tibbs> I can say why in the announcement, but I agree that it really doesn't need to be in the guidelines.
17:29:00 * geppetto nods
17:29:12 <geppetto> #action Adjust the place of DESCRIPTION in R packaging guidelines (+1:6, 0:0, -1:0)
17:29:50 <geppetto> #topic Open Floor
17:30:18 <geppetto> None of the older tickets seem to have changed in the last week … but does anyone want to talk about them?
17:31:08 <tomspur> I have problems with testing the macros in #281. Does someone see what is wrong in that macro? (see last comment over there)
17:31:35 <geppetto> ffesti: you still around?
17:31:56 <tibbs> I've been terrible about doing announcements but I'm on vacation today so I'm going to finish all of the pending writeups and announcements today.
17:32:36 <tibbs> I also wanted to point out https://github.com/fedora-python/packaging-guidelines/
17:32:55 <geppetto> tomspur: Did you mean to define py_rt_build twice?
17:33:07 <tibbs> rkuska was trying to get together a collaborative guideline effort, but I'm not entirely sure that github is a good way to do wiki pages.
17:34:09 <tomspur> geppetto: hmm, I don't think so. Shouldn't the last one be used anyway
17:34:21 <geppetto> tomspur: I've no idea
17:34:37 <tomspur> I will delete the first py_rt_build and try again
17:35:26 <Rathann> my time is up as well
17:35:29 <Rathann> thanks everyone
17:35:32 <tibbs> In general terms, I think the python guidelines are the worst we have going currently, and I'm going to propose a crap-ectomy soon.
17:36:00 <tibbs> But that's just removing a bunch of admons and useless stuff so we can get down to actually simplifying the meat.
17:36:09 <geppetto> Rathann: see ya
17:36:12 <tomspur> tibbs: There are many python changes coming up. I don't know if those can be done easier step wise or with one big change of everything
17:36:21 <tibbs> I think one by one is far easier.
17:36:23 <geppetto> tibbs: I mean, that's all to do with py2 + py3, right?
17:36:38 <geppetto> tibbs: once we get rid of that disaster, it should be fine again … right?
17:36:48 <tomspur> tibbs: Each change would touch a lot of current packages in a row
17:37:06 <tomspur> I don't know  if we have the manpower to do so
17:38:18 <tibbs> Well, changes to the guidelines don't really have to result in changes to packages.
17:38:28 <tibbs> I mean, our guidelines aren't retroactive anyway.
17:39:59 <tomspur> I don't think the py2->py3 transition can be done without that
17:40:54 <tibbs> I don't really see why not, but I think what matters is what changes are actually proposed.
17:41:44 <tibbs> If someone proposes a "tweak this bit" change like I did with my proposal last week then I guess we'd consider that.
17:42:04 <tibbs> I just don't see anyone actually making a concrete proposal for a rewrite.
17:43:48 <tomspur> I try to work on it with rkuska until the next meeting
17:44:45 <geppetto> ok
17:45:02 <geppetto> anything else?
17:46:12 <geppetto> Ok, see you all next week
17:46:20 <geppetto> #endmeeting