17:00:16 #startmeeting fpc 17:00:17 Meeting started Thu Jan 28 17:00:16 2016 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:17 The meeting name has been set to 'fpc' 17:00:17 #meetingname fpc 17:00:17 #topic Roll Call 17:00:17 The meeting name has been set to 'fpc' 17:00:27 Howdy. 17:00:41 Hey 17:00:43 #chair tibbs 17:00:43 Current chairs: geppetto tibbs 17:00:44 It has been a horrible week for me. 17:00:50 .hello smdeep 17:00:51 smdeep: smdeep 'Sudeep Mukherjee' 17:01:11 smdeep: Welcome. 17:01:12 smdeep: Hey Sudeep 17:01:17 Hey all 17:03:20 barely here - major firewall work going on... 17:03:32 Ok, you want me to chair you or not? 17:03:46 #chair orionp 17:03:46 Current chairs: geppetto orionp tibbs 17:03:54 Well, count you as a chair for quorum 17:04:29 Yeah, I'm still straightening out my RHEL7.2 NFS problems. 17:04:35 So I'm in and out too. 17:04:44 Ok, well we can just cancel this week 17:04:56 Just a reminder that I won't be here next week 17:05:20 * racor is here 17:05:24 #chair racor 17:05:24 Current chairs: geppetto orionp racor tibbs 17:05:42 I don't see anything super important on the schedule 17:05:56 I'm around enough if we have something to discuss. 17:06:00 I'm assuming the openshift thing doesn't need to happen Right Now(tm) 17:06:17 I'm not entirely sure I'll be able to chair next week. 17:06:32 And definitely not on the 11th (as the 10th is my birthday and I'll be out of town). 17:06:54 Ok 17:07:18 I'd hate to cancel all three meetings so if we can do anything today.... 17:07:39 * geppetto nods … well we don't even have technical quorum yet 17:07:43 * tomspur is here, sorry got distracted 17:07:47 #chair tomspur 17:07:47 Current chairs: geppetto orionp racor tibbs tomspur 17:07:52 Ok, we have technical quorum now 17:08:00 We'll see how it goes. 17:08:11 #topic Schedule 17:08:13 https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/AJ43MQ6THTTICHXIFTYQXYUDAU2UNXX5/ 17:08:19 #topic #591 Description of filtering macros in Perl is outdated 17:08:24 .fpc 591 17:08:26 geppetto: #591 (Description of filtering macros in Packaging:AutoProvidesAndRequiresFiltering#Perl is outdated) – fpc - https://fedorahosted.org/fpc/ticket/591 17:08:53 We spoke about this last week … but wanted to wait a week for more votes 17:08:56 Nothing happened as far as I can see. 17:09:36 Yeh, last edit was by you last week 17:09:55 #topic #593 use RPM tags for langpacks description 17:09:57 I have been investigating, but haven't come with a conclusion, yet 17:10:03 .fpc 593 17:10:04 geppetto: #593 (use RPM tags for langpacks description) – fpc - https://fedorahosted.org/fpc/ticket/593 17:12:15 Sorry, on 591, is there anything we actually _need_ to change now? 17:12:40 Hi, I am here to answer any queries about langpacks guidelines. This guideline is to ask langpack providing packages to add Supplements: tag in their langpack subpackages. That 17:12:40 way when basic language meta-package like langpacks-ja is installed, any base package installation will pull ja langpacks if they are available. 17:12:41 I mean … I don't think there was anything that was wrong 17:12:48 I mean, if something is terribly wrong and people are copying it or arguing that they're right because they're the guidelines.... 17:12:52 But it might not be what people were actually doing 17:13:16 But if so that's been true for a while now, and won't matter a couple more weeks 17:13:38 True. So no big deal. 17:13:47 Anyway, sorry for distracting. 593.... 17:14:18 I think the main part of 593 is this wanting to go somewhere: https://fedoraproject.org/wiki/PackagingDrafts/Langpack 17:14:31 Note that this would be the first use of "rich deps" in Fedora. 17:15:05 Yeah, something got horribly screwed up with overlapping wiki edits. 17:15:32 There are a bunch of things I didn't change that ended up being shown under my change. 17:15:37 We requested manual mutexes online, when we had a similar problem in #fedora-python 17:16:08 I really should try to sort it out but I just haven't had the time. 17:16:27 I would prefer "%package langpack-bs" over "%package bs" 17:16:47 So it is easier to search for a langpack 17:16:54 tomspur: That's the current draft 17:16:54 hi 17:16:55 tomspur: I tried to add that, but I think it got reverted or something. 17:16:57 it will be good to identify packages by using langpack 17:16:59 #chair Rathann 17:16:59 Current chairs: Rathann geppetto orionp racor tibbs tomspur 17:17:25 Also, the current draft has macroized things. 17:17:29 Which I like. 17:17:38 geppetto: in comment #5 the question arises again anyway, so maybe it is worth discussing about this first? 17:17:49 I can add that to redhat-rpm-macros once we approve something. 17:18:02 Assuming that's necessary. 17:18:07 Well, add me as a +1 on prefering the langpack-bs variant 17:18:22 Yes, +1. 17:18:45 Yeh, so at that point it's pretty much decided :) 17:19:05 I am for langpack-, too. 17:19:11 * geppetto nods 17:19:20 We don't want to do a mass renaming, though. 17:19:32 We don't? 17:19:42 Original draft said we didn't. 17:19:43 These should all be subpackages 17:19:49 I don't think existing package maintainers will do renaming 17:19:54 +1 to langpack- as well 17:20:00 so we just thought let's apply this for any future langpack pacages 17:20:02 They will if they convert their packages to use nice macros. 17:20:08 geppetto, actually hugspell package is SRMP for each package 17:20:27 Yeah, hunspell is split up finely. 17:20:36 There are a few other packages which are that way. 17:20:46 so does hyphen-* and mythes-* 17:20:48 Fair enough, but I assume that's an outlier and most others are subpackages? 17:21:00 tibbs|w: How many existing packages are we talking about? 17:22:10 Probably close to 100, though I haven't looked. 17:22:39 yes they are many 17:23:04 dnf list aspell-\* autocorr-\* drascula-\* hunspell-\* hyphen-\*| 17:23:16 Says 274, but includes some other stuff (-devel). 17:24:01 Sorry, that also has "installed" stuff in it as well. Still, it's over 200. 17:24:06 we have these packages marked langpacks in comps -> https://fedoraproject.org/wiki/I18N/Langpacks/BasePackages 17:24:20 tibbs: My rough estimate is ~50 ;) 17:24:54 (that's why naming "langpack-" would be better for langpack management) 17:25:13 dnf list aspell-\* autocorr-\* drascula-\* hunspell-\* hyphen-\*|grep fedora|grep -Ev 'devel|music'| 17:25:26 219 packages. All of those really are langpacks. 17:25:49 Anyway, we know there are many. 17:26:30 I might suggest augmenting the macro or adding a new one which automatically does provides/obsoletes. 17:26:51 I could work on that as I'm sadly rather familiar with doing RPM macro magic these days. 17:27:04 ok 17:27:05 But that's not essential for a first pass anyway. 17:27:16 yeh 17:27:24 So: we all like foo-langpack-XX. 17:27:58 And a renaming would be up to the packagers, unless we break with our usual policy of not doing retroactive changes. 17:28:03 * jflory7 is here idling -- would like to mention something at your open floor when the time comes 17:28:14 tibbs|w: You counted binary package - The number of src.rpm is much smaller. 17:28:22 That's true. 17:28:38 In the order of 10-20, I'd guess ;) 17:28:38 It's still a whole lot of obsoletes/provides someone has to add. 17:28:46 Yes, not many srpms. 17:28:57 But a whole lot of packages which have to change names. 17:29:09 racor, all hunspell-\*, hyphe-\*, mythes-\* , aspell-\* are individual src packages 17:29:28 they are not coming from single srpm 17:29:29 Anyway, besides those two things I listed, what is up for discussion? 17:29:55 paragan: OK, I wasn't aware about this. 17:30:10 we need Supplements tag as recommendation in langpacks packages as per given in https://fedoraproject.org/wiki/PackagingDrafts/Langpack 17:30:21 paragan: Did you get your changes from comment 5 back into the draft? 17:30:39 yes see above link 17:30:54 Just making sure that's in the current draft. 17:30:55 langpack-%{1} 17:31:02 I think supplements is fine. 17:31:04 okay 17:31:14 You also had comments about the definition of "langpacks". 17:31:30 paragan: Well, that's a aspect, I am not comfortable with. 17:31:37 tibbs|w, yes they are not just language translation packages 17:31:45 Well, make sure that's reflected in the draft. 17:32:00 I just want to make sure we're looking at the actual draft we're supposed to consider. 17:32:20 tibbs|w, yes included as "The idea behind "langpacks" is to separate translations or language specific content into subpackages" 17:32:20 racor: I think the choice is between Supplements: in one package and Suggests: in another. 17:32:35 Where does your discomfort lie? 17:32:54 no need of Suggests: tag 17:33:26 paragan: Well, you have to have either a forward weak dependency, or a reverse weak dependency. 17:33:34 right 17:33:43 Hence, Supplements: in the langpack packages, or Suggests: in the "main" package. 17:34:13 I'm trying to figure out if racor preferred one over the other, or if he had a problem with weak deps in general, or something else. 17:35:32 tibbs, the forward and reverse deps are not the same. The reverse one perfectly suits there 17:36:00 the weak deps of already installed packages are not considered 17:36:03 I agree, but racor said he was uncomfortable and I'm trying to understand why. 17:36:24 I mean, we have to use some kind of weak dep here. 17:36:51 A simultaneous renamer (Obsoletes/Provides/...) with using a little test feature in the light of dnf's immaturity doesn't seem wise, IMO. 17:37:23 racor, we are not asking to rename existing packages 17:37:52 its just recommendation for any future coming langpack packages in Fedora. 17:37:59 tibbs|w: Let me put it verbosely: renamers alone are error-prone, ... and my trust in dnf is NULL 17:38:01 As I said earlier, FPC doesn't do that in general. 17:38:10 I don't know how many more times I can say that. 17:38:37 But someone may want to rename; it's up to them. 17:38:59 right if existing package owners like to rename, they can 17:38:59 I only suggested we consider that case. And someone has to test dnf at some point anyway. 17:39:00 we request only to add suggests tag into existing langpacks 17:39:09 * supplements 17:39:31 Otherwise any bugs just won't be found. You can't just say "we'll never touch these features because they might be broken". 17:39:48 tibbs|w: I consider the renamer (*langpack*) to be progrees. 17:39:53 Names of weak deps. still confusing all the devs. N years later :( 17:40:36 But, yeh, while the rich deps. usage is new … and supplements, I guess … we can't easily do it in the packages without that. 17:41:07 considering the number of langpacks for a particular package can increase or (sometimes) decrease over time, revdeps are much better here 17:42:15 Rathann, I am not familiar with revdeps approach but isn't that mean we need to Suggests: every langpacks in base pack, that will look horrible. 17:42:26 Kind of … I'm not sure how DNF works, but I'm guessing it's the same as yum and only considers the weak deps. on installs. 17:42:35 Supplements: is a reverse dependency. 17:42:39 I think we're all aggreeing. 17:42:46 geppetto, yes 17:42:47 So adding langpacks as rev weak deps. isn't that ideal, from that POV 17:43:06 But, yes, we really need to know how dnf handles these things. 17:43:09 But I'm still fine with it. 17:43:34 If only so that we don't stick something out there, then find out it doesn't work after people start using it. 17:43:35 paragan: why horrible? 17:43:42 Is any of this implemented in any package. 17:43:58 the alternative is to have Suggests for every langpack in each package that has langpacks 17:44:03 Rathann: I think using forward dependencies for this means that the main package will have a huuge list of Suggests:. 17:44:07 I thought we need to write Suggests: langpacks-as or langpacks-bs or langpacks-ja or ....... 17:44:19 in the same line 17:44:27 paragan: ? 17:44:30 exactly, it's better to have Supplements IMHO 17:44:33 tibbs|w, it's in copr repo, you can try it for test set of packages 17:44:43 tibbs|w, https://bugzilla.redhat.com/show_bug.cgi?id=1114422#c22 17:44:43 right Supplements is better 17:44:49 But how does DNF handle it? And renaming? 17:45:02 at least it's one per langpack and you don't have to modify the main package if there's a new langpack 17:45:15 Someone who's working on this could hopefully try out a few cases and paste the results so we can see. 17:45:34 Rathann: paragan: If you do normal weak deps. instead of reverse … it's the same thing just change s/supplements/suggests/ and put it in the main package. 17:45:38 I have tested the Supplements: and its working fine 17:45:47 I think that's all anyone is asking for here. Does dnf handle the issue as we'd expect? If so, the discomfort should mostly go away. 17:46:22 Rathann: Advantage is you get newer langpacks as they are released … disadvantage is that the main package needs to know about all langpacks 17:47:03 Also, a minor thing is that deps. on main package will now be "big". 17:47:04 I like Supplements: usage, its easier 17:47:31 paragan: I agree. 17:48:07 I suggest linking to some specs in the ticket. Maybe some specs that show how it would look either way if people want to see that. 17:48:28 No need to do the later, unless anybody wants to argue hard for non-reverse deps. 17:48:41 And then doing some dnf tests, including how you would do a rename, and showing how all of that works. 17:49:04 This would be the first major use of weak reverse deps that I know of, so it would be good to be extra-certain here. 17:49:08 sorry but I don't understand we are not asking to rename the packages 17:49:39 Because someone might want to do so, even if it's not mandatory. 17:49:48 And if it doesn't work then we need to tell them not to do so. 17:49:49 tibbs|w: In a real world project, I now would insist on a public demo to stress-test supplements/suggests. 17:50:05 racor: Which is kind of exactly what I'm asking for. 17:50:12 We already have suggests usage 17:50:19 And, also, there is the copr which is about as public of a demo as you can get. 17:50:30 geppetto: Yeah, I just don't think it's as widespread as this might be. 17:50:42 The main things here are supplements, if that's different … and "rich deps." which is the boolean operations. 17:51:18 I'm just suggesting that someone show us how it works in practise, with dnf output, so that we can see without everyone on the committee having to spin up a test vm. 17:51:20 jsilhan: Do you have any external test repos. for DNF you can post for either of those? 17:51:26 tibbs|w: OK, so we are heading the same road. 17:51:50 I don't think that's too much to ask, and someone familiar should be able to do all of this in half an hour. 17:51:57 geppetto, dnf copr enable jsilhan/langpacks 17:52:04 see https://bugzilla.redhat.com/show_bug.cgi?id=1114422#c22 17:52:09 how packages are called 17:52:26 #info Test repo. is available at: copr enable jsilhan/langpacks 17:53:21 the only difference is that the main langpacks are called "tl-langpacks-cz" instead of "langpacks-cz" 17:53:35 I didn;t want to introduced any conflict 17:53:59 If you named them as they would be named, we could see how updates work. 17:55:58 jsilhan: Would it be possible for you to set up a page with detailed instructions on how to use this? 17:56:23 racor, ok, no problem 17:56:52 how to use demo or how to use rich deps? 17:57:06 the demo is actually described in that bug comment step by step 17:57:18 jsilhan: background: I've never used copr before ;) 17:57:26 dnf copr enable jsilhan/langpacks 17:57:29 that's it 17:57:47 then you have that repo file locally 17:58:07 and "dnf install tl-langpacks-cz" will install package from that repo 17:59:25 if you follow exact sequence of commands from: https://bugzilla.redhat.com/show_bug.cgi?id=1114422#c22 you will see how it works 17:59:35 then you can play around by yourself 17:59:50 installing / removing another config langpacks 18:01:50 should I explain steps better? or is everybody playing with it? 18:02:36 the example looks good, though I wish it were placed somewhere more accessible than a bugzilla comment 18:03:28 jsilhan: I assume the last part only works with cleanup_leaf=true? 18:03:28 Rathann, would you like it to be included in the draft? 18:03:50 geppetto, yes 18:03:51 No, although maybe post it in the ticket? 18:04:02 it's referenced 18:04:05 there 18:04:12 It should be in the notes from this meeting anyway, so it'll be a bit more findable after today 18:04:17 * geppetto nods 18:06:00 Ok, is there anymore that people want to say about this feature at this meeting? 18:06:49 I'm pretty much +1 at this point, provided that it actually works properly with dnf, which I'm sure jsilhan will ensure anyway. 18:07:04 Sure, me too 18:07:06 But I would like to address the rename issue one way or the other. 18:07:16 We aren't asking anyone to rename. 18:07:28 But at some point we'll need to accommodate them if they decide they want to do so. 18:07:31 But I think a few others want to play with it more before voting, or am I wrong? 18:07:40 Or tell them they shouldn't rename at this point. 18:08:01 I don't think we should do that, if anything we should encourage them. 18:08:18 And then we should tell them how to do so. 18:08:23 * geppetto nods 18:08:29 And make sure that actually works. 18:08:36 It doesn't have to be in a first pass, though. 18:08:48 +1 18:08:53 Which is why I'm fine with this as is (though I need to go through it all again). 18:09:01 racor: Rathann: orionp: mbooth: You want to vote? 18:09:30 No, don't want to vote. 18:09:41 I'm afraid i haven't been able to follow 18:09:43 I'l toss in a +1 just for the record. 18:09:54 +1 ftr 18:09:59 But we won't get to +5 anyway. 18:10:13 But, yeh, loooks like it'll be another week or 2 for people to look at it and vote then. 18:10:25 This is a really good example of why folks submitting things should give as much information as possible up front. 18:11:26 Can people vote in the ticket and see if this can get approved by next week if there is no meeting next week? 18:11:29 #info Use RPM tags for langpacks (+1:3, 0:0, -1:0) … more time needed for people to see what happens/why/etc. 18:11:52 okay 18:12:05 hm dnf remove langpacks-foo will only remove all langpacks for language foo if the option clean_requirements_on_remove is set to 1 (which is the default) 18:12:11 but if it's 0, then it won't 18:12:17 Rathann: Yeh 18:12:31 I have it set to 0 because dnf was overzealous in removing stuff IMHO 18:12:43 Me, too. 18:12:48 Yeh, me too 18:12:49 For what's it worth: dnf install tl-libreoffice-core-langpacks-es doesn't install tl-libreoffice-core 18:12:59 In theory a requires on the base package could be added in each langpack 18:13:11 So, perhaps some hard deps are needed somewhere. 18:13:14 Ninja'd. 18:13:17 And that would also "fix" racro's observation. 18:13:22 yeah there shoudl be require 18:13:31 racor, that is not it supposed to work 18:13:59 ok, I'm +1 as well at this point 18:14:08 #undo 18:14:26 jsilhan: You want to update the draft to add the requires? 18:14:38 paragan: but that's what needs to be exercised: The new rpm tags interaction with traditional requires/provides. 18:14:39 We are at +4 now … if anybody else wants to vote today 18:14:54 the expectation is, I guess, that who unsets that option will know what they're doing and deal with the fallout 18:15:08 geppetto, in the draft it's actually there 18:15:09 paragan: Might be worth knowing why it's not supposed to work. 18:15:19 jsilhan's copr apparently doesn't test this. 18:15:59 Yeah, in the draft, the base package is hard-required. 18:16:03 racor, those are just test packages and I think there is missing Requires: on tl-libreoffice-core 18:16:05 jsilhan: Ahh, you're right the example does have it … maybe add something with the supplements text at the top? 18:16:08 It's down in the macro definition. 18:16:18 I've made that CORP minimal example and forgot about requires 18:16:25 yup the example does have it 18:16:25 * geppetto nods 18:16:43 Are you all referring to the macro in the draft as the example? 18:16:47 I mean Requires: on the main package it supplements 18:16:47 yeh 18:16:48 yes 18:17:05 Personally I would like for the definition of macro to _not_ be in the draft 18:17:20 We don't want people pasting it in. It should be defined for them. 18:17:39 In redhat-rpm-config if there's no other base dependency these packages will have. 18:17:57 tibbs|w: but the macro in example isn't generic, is it? 18:18:10 tibbs|w, as I wrote. I have not found any general macro. Some packages may add additional tags or files 18:18:22 I mean the file path may vary from package to package 18:18:33 True, but you could pass some of that. 18:18:41 langpacks are not just for translations 18:18:48 I would have to see how it works out with a couple of packages. Someone's done glibc. 18:19:05 and so it can carry any file within any directory with any extension 18:19:12 It's just that if you want people to do this, that much macroization is beyond a lot of people. 18:19:17 I agree it would be nice to have a generic macro in rpm-config 18:20:04 Anyway, I can look at something. How many sets of converted packages are available? 18:20:16 for translations langpacks we can think of rpm macro but not for all kind of langpack packages 18:20:17 Also, it doesn't have to be a macro which covers _everything_. 18:20:27 #info Use RPM tags for langpacks (+1:4, 0:0, -1:0) … more time needed for people to see what happens/why/etc. 18:20:51 Only one more vote needed in the ticket, if people want to vote there before the next meeting. 18:21:27 Anyway … unless anyone really wants to talk about this more I'm going to move to 594 18:21:29 When this will get approved I need to ask base package maintainers to add Supplements: tag in their langpack subpackages 18:22:11 geppetto, tibbs Rathann tomspur racor thanks all for this discussion 18:22:21 no problem 18:22:29 #topic #594 uid/gid allocation requested for openshift origin 18:22:33 .fpc 594 18:22:34 geppetto: #594 (uid/gid allocation requested for openshift origin) – fpc - https://fedorahosted.org/fpc/ticket/594 18:23:02 BTW, a billion lines ago someone had something to ask in open floor. 18:23:12 If they did I missed it :-o 18:23:35 Just making sure that person is still around, since it's been a while. 18:23:48 * tomspur needs to go in 7 mins 18:23:52 * geppetto nods 18:24:01 I think this ticket is fairly simple 18:24:20 It's somewhat annoying that everything cloud related wants it's own uid/gid 18:24:30 But it is what it is. 18:25:03 I'm starting to wonder why we're caring so much. 18:25:17 If we fill up the range, well, it won't be our problem. 18:25:17 * geppetto shrugs … I'm +1 18:25:54 BTW, why do they ask for a soft allocated UID? 18:26:01 Hmm... 18:26:08 Have I forgotten the definitions? 18:26:32 soft allocated is just what everyone does when they add a user. Doesn't need to go through us. 18:26:51 tibbs: I thought soft allocated meant they got to pick a number too 18:27:01 So package install ordering wouldn't affect the uid they got 18:27:06 Then what would hard allocated mean? 18:27:34 What else can be harder than fixing the name to the particular number? 18:27:36 If I remember correctly hard == always allocated on an install, soft == only allocated on a machine if package is installed. 18:28:27 So, in theory, it's possible to install "foo" and it request number XYZ but get XXX instead. 18:28:56 Whereas root or news or whatever is just assumed to be there, and there is no failure case. 18:29:00 OK, thy mean "soft static". 18:29:06 https://fedoraproject.org/wiki/Packaging:UsersAndGroups 18:29:25 Ok :) 18:29:52 So, assuming they really mean "soft static" then +1. 18:29:54 I'm still +1 with correct wording ;) 18:30:12 tomspur: orionp: Rathann: racor: mbooth: vote? 18:30:25 We should add a section on "Hard allocation" to that, for the case where the UID/GID does in %setup. 18:30:26 one moment 18:30:55 The ticket isn't the clearest thing. By "volume" I'm assuming they mean some remote shared filesystem. 18:31:20 Yeh, I assume so. 18:31:24 I wish I had time to revisit my "fixing UIDs at kickstart" thing. 18:31:30 It's completely possible now. 18:31:31 +1 18:31:59 Ok, that's +3, anymore? 18:32:03 +1 18:32:06 +1 18:32:18 And +5 … 18:32:26 BTW, it was jflory7 who wanted to ask something. 18:32:31 racor: mbooth: Want to vote for the record? 18:32:36 tibbs|w: Yes :) 18:32:36 Since I think we're getting close. 18:32:39 * tomspur needs to go. Sorry 18:33:00 Then see you in 2-3 weeks or so...? 18:33:11 tibbs|w: Okay to go ahead? 18:33:11 #action uid/gid allocation requested for openshift origin (+1:5, 0:0, -1:0) 18:33:18 #topic Open Floor 18:33:24 jflory7: Ok, go ahead now 18:34:22 The Fedora CommOps team is helping sub-projects and groups in Fedora put together a 2015 "Year in Review" article sharing a few highlights of the past year and few goals for 2016. With an important group like the FPC, it would be awesome to have a Year in Review shared on the Community Blog. :) 18:34:24 https://communityblog.fedoraproject.org/share-your-year-in-review-with-fedora/ 18:34:37 That's the original announcement with a few templates to make the writing part easy. 18:34:49 Here's a few other live examples that have already been published: https://communityblog.fedoraproject.org/tag/year-in-review-2015/ 18:35:36 And that can go out at any time? 18:36:04 Heh, our "year in review" seems to have ended up with a big backlog of writeups and announcements for me. 18:36:12 I should have time today, though. 18:36:18 "should". 18:36:36 Nah, I think one point of our year in review would be the huge reduction in the backlog, and new members. 18:36:44 * Rathann still has a truckload of bugs and package reviews to go through 18:36:54 geppetto: Ideally, we'd like to have it before too late in February -- maybe middle of the month at the latest would be a good deadline? 18:37:17 I can help edit/review the article though 18:37:17 We're hoping to write up a bigger "Fedora Year in Review" later with the contributions of others too. :) 18:37:24 jflory7: Right, I meant more was there anything it should wait on … or should someone just do it and publish asap. 18:37:34 geppetto: Oh, no, the sooner the better :) 18:37:51 I'm going to come right out and say that I probably won't have time to do this. 18:38:10 Well, that probably leaves me as volunteer then 18:38:20 Though the announcements I've sent over the year should be a reasonable base for some of it. 18:38:27 Yeh 18:38:43 I think this was the year we got much better organized and cleaned out our ticket backlog, though. Wasn't it? 18:38:44 Dito. 50ish meeting minutes :) 18:38:52 I can't remember that far back. 18:38:57 tibbs: Yeh, see above :) 18:39:00 Well not this meeting. 18:39:41 I'll try and have a look at it, the big problem is that I've got tomorrow and then I'm busy until around the 11-12th of Feb. 18:40:14 geppetto: Can you throw something on the wiki and then if I have time I can add to it? 18:40:35 geppetto++ That would be awesome if you could get a start on it! 18:40:35 jflory7: Karma for james changed to 1 (for the f23 release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:41:26 Well … that's me volunteered then ;) 18:42:02 I'm not sure we have any goals for 2016 … but I can probably do an initial draft of top 3 highlights from 2015 and some links. 18:42:21 Also, for the record, feel free to ping me any time to help with this too -- especially once it's finished, so I can help get it scheduled :) 18:42:27 * geppetto nods 18:42:28 Not do worse than we did in 2015? 18:42:39 Address SCLs again? 18:42:48 hey, we did pretty well in 2015 … that's a pretty high bar. 18:43:00 tibbs: Don't you know the new new thing is containers 18:43:03 We strive for excellence..... 18:43:41 2017 will be the year for containers using remote btrfs snapshots, for sure. 18:43:52 I'm hoping the container thing will blow over before I have to get too involved with it. 18:43:53 or 2016, whichever year we are in now :-o 18:44:13 You said btrfs. Should probably change that to 2027. 18:44:55 I was just repeating the amazing systemd devs. who all had a good think and decided on btrfs snapshots 18:45:32 * geppetto should probably close soon, before I throw down any gauntlets. 18:46:06 #action geppetto Try to get a draft for FPC year in review. 18:46:11 Anything else? 18:46:19 That's all I wanted to add :) 18:46:20 Thanks! 18:46:23 no problem 18:47:51 I guess I'll wander off. I still have to sort out the bad interaction between SCLs and epel-rpm-macros-6. 18:47:59 Oh, here's a random question: 18:48:08 ban useless uses of %defattr? 18:48:16 why? 18:48:28 Because useless.... 18:48:41 It's just cargo culted crap. 18:48:57 I'm going to script them out of every Fedora spec after F24 branches anyway. 18:49:42 Probably not worth a guideline, but we have all of this junk that persists in packages for no good reason. 18:49:58 I'm not against it if you want to go gungho prooven packager on it. 18:50:11 I posted a huge list on devel@ the other day. 18:50:16 4500 packages.... 18:50:38 We suggest that new packagers look at existing packages, but so many of them are just terrible. 18:50:50 Are you up with what's in epel-rpm-macros currently? 18:51:09 * geppetto nods … I bet all mine have unneeded defattrs in them :-o 18:51:17 I'm not 18:51:19 Several of mine did too. 18:51:50 In EPEL5, I made things so that you no longer need BuildRoot:, %clean, Group: or the buildroot cleaning in %install. 18:52:13 interesting 18:52:17 I rebuilt all of epel and have no breakages due to it. 18:52:21 alright, I have to drop off now 18:52:27 cool 18:52:33 thanks guys 18:52:36 Rathann: Ok, thanks for coming 18:52:37 see you later 18:58:14 Crap, dgilmore has asked me to bring something up. 18:58:20 oh? 18:58:24 I should have filed a ticket. 18:58:47 Might be best way, file ticket and deal with it at a future meeting 18:58:52 He wanted FPC's opinion on whether koji should install soft deps when making the buildroot. 18:59:23 I'd guess not 18:59:31 My suggestion was no, you should actually specify the dependencies you need rather than relying on how soft deps manage to work. 18:59:46 But right now koji does, or doesn't, depending on which arch is building. 18:59:47 Yeh 18:59:52 :-o 19:00:03 That is the least useful way to do it 19:00:46 Anyway, I will try to remember to file a ticket. 19:01:13 * geppetto nods … after thinking a couple of minutes I'm pretty firmly in the no weak deps. … just add stuff to build deps. 19:01:27 But a ticket is good, maybe someone can come up with a reason for it. 19:01:35 Ok, really going to close now :) 19:01:41 #endmeeting