16:00:31 #startmeeting fpc 16:00:31 Meeting started Thu Apr 12 16:00:31 2018 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:31 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:31 The meeting name has been set to 'fpc' 16:00:31 #meetingname fpc 16:00:31 The meeting name has been set to 'fpc' 16:00:31 #topic Roll Call 16:00:44 Howdy. 16:00:47 hi there 16:00:52 hello 16:01:02 #chair tibbs 16:01:02 Current chairs: geppetto tibbs 16:01:06 #chair mhroncok 16:01:06 Current chairs: geppetto mhroncok tibbs 16:01:11 #chair redi 16:01:11 Current chairs: geppetto mhroncok redi tibbs 16:01:39 hey 16:03:05 hi everybody (newbie here) 16:03:15 #chair decathorpe 16:03:15 Current chairs: decathorpe geppetto mhroncok redi tibbs 16:03:40 Hey, no problem … kind of easy and the new people outnumber the old atm :) 16:04:00 * racor is here, too 16:04:22 racor: Hey, we've switched over to the new members … but you are free to hang out. 16:04:55 Well, you don't want to know what I think of this. 16:05:46 #topic Schedule 16:05:49 https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/GCXK7RGE7UW2JCAABX3LKNP37DB7VC6L/ 16:06:01 #topic #761 Modernize R guidelines 16:06:04 .fpc 761 16:06:06 geppetto: Issue #761: Modernize R guidelines - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/761 16:06:28 I've gone trough the changes and I think they are straightforward and good 16:06:42 the old guidelines seems to be prehistoric 16:07:23 yeh, probably … I'm not sure anybody knew much about R … other than it existed. 16:07:24 hi 16:07:29 Yeah, I think it's all "just do it" stuff in any case; there are no real functional changes besides dropping an unnecessary explicit dependency. 16:07:46 Rathann: Hey, we've moved over to the new members today … but feel free to hang out. 16:07:53 oh, that's great 16:08:37 congratulations to new members 16:09:04 I didn't go through the whole page to see if anything else was missed, but all the changes in the diff look good to me 16:09:12 Yeh, I'm happy to +1 this change. Seems simple enough. 16:09:58 +1 if it needs a formal vote 16:10:07 according to the summary it mostly just cleans up some ancient stuff - looks sane to me (+1) 16:10:20 Yeh, I'm kind of assuming everyone who said they are happy it +1 … but a formal thing is good too :) 16:10:25 +1 16:10:50 +1 16:10:52 #action Modernize R guidelines (+1:5, 0:0, -1:0) 16:11:00 Ok, cool. That was easy :) 16:11:03 Now old tickets 16:11:45 #topic #726 Review for SELinux Independent Policy packaging Draft 16:11:49 .fpc 726 16:11:51 geppetto: Issue #726: Review for SELinux Independent Policy packaging Draft - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/726 16:12:13 So this one hasn't moved forward … but maybe redi can help out a bit on the changes needed? 16:12:15 I think this is still stalled out on me, but if someone else wants to take a crack it at. 16:12:44 Basically what they have submitted isn't anything like what should be packaging guidelines. 16:13:28 We don't need to tell people how to set up github repositories or anything like that. 16:13:56 So it needs to be distilled down to "here's what you put in your spec to include some selinux policy in your package". 16:13:59 I didn't review this one before the meeting. Can take a look if you want, but it won't be before next week 16:14:17 * mhroncok haven't yet find time to read this one but it definitvely looks non-guidelinish 16:14:30 Anyone is always welcome to take a look at those things. 16:14:35 redi: No problem 16:15:36 We just have a big disconnect between what they submitted and what we actually want to put in packaging guidelines. 16:15:54 * geppetto nods 16:16:13 tibbs: the thing that bothered me was teh absence of a tutorial, or pointer to an acutal worked example, showing how to move from them doing SElinux adds, to moving it down to the .spec files 16:16:54 I tried to work through their outline, and immediately found a bug -- that indicted to me that it was an untested outline 16:17:02 indicated* 16:17:10 Even then, a tutorial isn't something we would want in a packaging guideline either. 16:17:22 tutorial can be posted somewhere else on wiki 16:17:35 we can then mention it in the guidelines 16:17:37 And I think it would be better for us to avoid talking too much about what "acceptable selinux policy" looks like. 16:17:41 orc_fedo: I suspect it was tested, but then it changed and not retested. 16:17:56 geppetto: dunno -- i tested within a day of its initiall mention 16:18:00 Maybe some general statements, but the emphasis should be on how you package the stuff. 16:18:14 * geppetto nods 16:18:27 tibbs: I am find w the standard not including worked examples, r tutorials, but they need to exist as well 16:18:42 That's out of scope for what we do here. 16:18:43 pretty sure we said last time that we didn't want "what is good selinux policy" in the guidelines. 16:18:55 looking at the draft, more than 50% is not about packaging itself ... 16:19:33 do we have guidelines for guidelines we can ask people to follow? 16:19:51 or would that be too meta? 16:20:21 mhroncok: those are us :) 16:21:19 ok 16:21:57 I think general suggestions for the "structure" of Guidelines (what to include, what to put into a separate tutorial) could be helpful 16:22:59 I have no problem with someone doing some simple meta guidelines if they want, just need to make sure not to word it like "if you follow these we'll just approve them" 16:23:03 It's a pretty rare thing. 16:23:23 true 16:23:51 So, sure, if someone has time, but we have a backlog of stuff so I personally wouldn't prioritize it. 16:24:05 * geppetto nods 16:24:08 right 16:24:26 But I mean, a couple of paragraphs in the document that tells people how to submit stuff to us isn't a bad idea. 16:24:55 #action redi will look at helping tibbs, but not before next week 16:24:59 #topic #723 Guidelines for handling deprecated dependencies during review 16:25:05 .fpc 723 16:25:08 geppetto: Issue #723: Guidelines for handling deprecated dependencies during review - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/723 16:26:18 So, again … this is one of those "something here seemed good, but we don't have a draft so we are kind of stuck" 16:26:45 as far as I read it, this boils to: 16:26:56 create a guideline that says that deprectaed packages have a specific provide 16:27:13 say packages MUST not depend on deprecated 16:27:26 say package can only be marked as deprecated once nothing depends on it 16:27:31 I think the amount of effort we've spent talking about this far exceeds anything that could be saved by the tiny chance that this would make much difference. 16:27:43 Though it does have more relevance with the python2 thing. 16:27:54 tibbs: I think with modularity approaching it might be more useful than you think 16:27:55 right 16:28:16 But, yeh, I think mhroncok got the basic summary 16:28:35 I'm not following that proposal. what's the benefit of a package adding "provides: deprecated(%{name})"? other packages can just keep depending on the real thing? 16:28:48 question is, whether anyone can juts mark their packages deprecated, or if it requires some kind of approval 16:28:54 I think with modularity it gets more complicated than anyone thinks. 16:29:05 everyhtng gets complicated with modularity :D 16:29:17 *everything 16:29:33 exactly. that's now what I think every time I see the word "modularity" ;) 16:29:39 decathorpe: Because that gives you a way to see that something is actually deprecated. 16:29:52 Otherwise what can you do? Consult some wiki page? 16:29:58 decathorpe: The two ideas were: 1) Other packagers could see the provide and avoid the dep. 2) Automated tools could see the provide and flag any deps. 16:30:12 This way you can technically run a repoquery line and see if anything in your depchain is deprecated. 16:30:33 ah, that makes sense. 16:30:54 that can be added to FedoraReview or whatever 16:31:23 the thing that remains unclear to me is who decides what's deprecated 16:31:33 It's certainly not us. 16:31:37 agreed 16:31:50 it can be either the package maintainers or fesco 16:31:51 Everything is up to the packager in the end. 16:31:57 AFAIK it's the packager who owns the package being deprecated … if only by default. 16:32:13 If FESCo wants to step in then that would be up to them. 16:32:17 yeh 16:32:32 ok, I can prep a draft 16:32:51 #action mhroncok Will prep. a draft 16:33:36 #topic #719 Simplify packaging of forge-hosted projects 16:33:37 technical: i want to assign the issue to me, but appaerntly, I still cannot 16:33:40 .fpc 719 16:33:42 geppetto: Issue #719: Simplify packaging of forge-hosted projects - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/719 16:34:00 So AIUI here tibbs already did the technical parts of this, and the macros are already live 16:34:16 Yes. I now forget what this ticket is waiting on. 16:34:18 We, again, "just" need a draft telling people to use them. 16:34:30 Though of course I didn't do anything other than merge the PR. 16:34:41 are the new macros reasonably "bug free" now? 16:35:07 I haven't heard any complaining, nor have any updates been sent in a while. 16:35:20 are there enough packages that use them to tell? 16:35:42 should there be packages using it before the changes were approved by FPC? ;) 16:35:42 A whole raft of Go stuff, I guess. 16:36:03 decathorpe: that's debatable. It was not forbidden 16:36:04 decathorpe: Good luck with that. How long have we had Go packaging without Go packaging guidelines? 16:36:30 Plus you can't have guidelines for everything, and at some point people have to be able to test things before actually writing guidelines. 16:36:40 so somebody "just" needs to write up how to use these macros, and add it to the guidelines? 16:36:45 Yes. 16:36:59 sign me up, I guess 16:37:02 Generally the people who understand them are the ones who would do that. 16:37:12 that's not me, but I'd like to learn how they work :) 16:37:19 I can take a first stab at it anyway 16:37:22 And then we turn what they give us into guidelines. 16:37:40 that seems sensible. have they been asked? 16:37:50 I think that's part of the point of the ticket. 16:38:18 nim gave us sort of an outline. 16:38:42 a very brief one. I can start from that though 16:38:43 But I don't know how in-sync the ticket is with reality, so that needs to be worked out and then we beat on it for a while and vote. 16:38:59 #action redi Volunteers to understand macros and write up a draft for using them. 16:39:08 https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation isn't really brief, though. 16:39:10 ok. I'll experiment with them next week, converting some spec files to use them 16:39:29 ah I didn't see that page 16:39:31 There's enough in that wiki page to make a reasonable guideline, I think. 16:39:47 But no changes since January so I don't know if that means it's outdated or just stable. 16:40:09 I have packages on gitlab and github that I can experiment with 16:40:42 #topic #715 Separately building package documentation 16:40:45 .fpc 715 16:40:47 geppetto: Issue #715: Separately building package documentation - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/715 16:40:58 Ok, so big surprise … this needs a draft. 16:41:27 I think we also got lost in the weeds about bootstrapping last time, when it wasn't really relevant. 16:41:57 I'm not opposed to separate source packages. after all, some packages already get built separately exactly that way for other reasons (python3 + python3-docs) 16:42:05 Oh, hmm, I thought this was dead. 16:42:21 But basically … if building your docs. takes a bunch of time and/or deps. … people want to move from sub-packages to different fedora git entries 16:42:46 decathorpe: Yeh, this is basically generalizing the python/python-docs thing. 16:42:54 I didn't realize python3 built the docs separately; that's certainly a nice example. 16:43:06 So people don't need two reviews, and they'll tend to make the packages work in similar ways etc. 16:43:34 be careful not to recommend this as the best ay to do it 16:43:46 Is there a better way? 16:43:50 keeping python3-docs in sync is painful 16:44:04 I like the sentence in the ticket... 16:44:15 If building documentation requires many additional dependencies then you MAY elect to not build it in the main package and instead create a separate *-doc source package which builds only the documentation. This separately packaged documentation MUST correspond to the version of the packaged software. 16:44:31 * geppetto nods 16:44:37 sounds reasonably optional to me 16:44:48 And a lot hinges on "correspond" there. 16:45:02 this has the advantage that the -docs package can (almost always ?) be noarch 16:45:03 Because docs don't always change when the software changes. 16:45:06 it also doesn't give a framewrok to somebody crazy to go and push provenpackager changes to remove the docs form your packages 16:45:22 The docs package can generally be noarch now. 16:45:27 tibbs: I would guess that means … sources entries must be the same 16:45:34 yes, but it has to be built only once if it's the main package 16:45:43 geppetto: I wouldn't want it to mean that. 16:45:59 tibbs: what then? 16:46:24 If you bump a package from 14.7.2.0 to 14.7.2.1 then it might be reasonable to not touch the docs package in that case. 16:46:38 hmm, I would have expected if the source changes (which presumably means the %version changes) then the -doc pkg gets updated too, even if it's strictly the same content 16:46:56 I don't think that this is a MUST 16:47:06 tibbs: I'd say if the upstream tarball changes then you should probably rebuild the docs anyway, even if you are pretty sure the upstream didn't change the docs. 16:47:08 redi: I think part of the idea is to avoid doing that when it's unnecessary. 16:47:08 MUST is to correspond, as said by tibbs 16:47:20 Which is why I used "correspond" there. Not "match the version exactly". 16:47:27 just so there's no concern that (as a user) you're looking at old docs because you have foo-14.7.2.1 and foo-doc-14.7.2.0 16:47:35 I think most reasonable people can tell when the docs don't correspond to the software. 16:47:40 but I can see both sides of the argument, and don't mind either way 16:47:51 yeah 16:47:51 tibbs: I'm happy to not rebuild for every patch … but not rebuilding when the source changes seems a bit risky. 16:47:51 "These docs are three years out of date; could you please fix it?" 16:48:01 :) 16:48:06 I don't see what the risk is, though. 16:48:21 it's not like it breaks anything 16:48:23 yeah 16:48:29 worst case somebody files a bugzilla 16:48:41 I mean, the huge doc suite that is rarely installed because most people just use a web browser might not mention a flag or something. 16:48:52 We're not talking about breaking the distro. 16:49:00 Fair enough … I'd just prefer a concrete definition of correspond … and upstream source makes that easy. 16:49:24 Meanwhile, not splitting docs means that texlive is most of the more critical components of the entire thing. 16:49:40 it seems OK to leave it up to the maintainer to be responsible for keeping the docs current if they choose to split the specs 16:50:07 Ok 16:50:15 agreed. this looks like a nice trade-off 16:50:36 So … anyone want to volunteer to draft this? 16:50:45 This separately packaged documentation MUST be accurate for the version of the packaged software. 16:50:48 should the guidelines say that the main pkg spec file MUST have a comment saying there's a -doc pkg that should be considered when updating it? 16:50:55 is different wording that basically means the same 16:51:16 redi: That would probably be a good idea. 16:51:27 mhroncok: seems fine to me. 16:51:35 redi: I'd go with SHOULD here, but I'm ok with MUST 16:51:50 yeah, mentioning the -doc package in the main one seems like a good idea 16:51:53 I was hesitating as typing it :) 16:52:00 SHOULD is ok too 16:52:27 well, adding one line of comment to a .spec file that is being completely rewritten for split out -doc isn't too much to ask 16:52:43 :) 16:53:08 that's bikeshedding, I'm ok with both 16:53:54 it would be nice if the comment was there for provenpackagers, but SHOULD and MUST are both fine with me 16:54:18 "This separately packaged documentation MUST correspond to the version of the packaged software. In other words, if a new release of the software includes changes to the documentation, then the documentation package MUST also be updated. But if the new version of the software does not include documentation changes, then you MAY choose not to update the documentation package." 16:54:37 (Sorry, was typing that.) 16:54:55 tibbs: +1 16:54:57 +1, sounds reasonable 16:55:16 +1 16:55:33 should the docs package require the main or not? I'd say not, but just makeing sure 16:55:51 +1 16:56:24 I guess if the docs "work" without the main package, I wouldn't add requires artificially ... 16:56:26 mhroncok: if you can read the docs without the main one, I'd say not. 16:56:27 In general documentation packages don't require the main package. 16:56:28 yeah 16:56:43 agreed, just wanting to know if we are on the same page 16:56:53 I think that's already in the guidelines anyway. 16:56:55 ok, so we now need to glue the texts together 16:57:51 The proposal was to add that bit to https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation 16:58:07 I generally do the "glue" as part of writing things up. 16:58:18 ok. +1 on that 16:58:42 ok, are we all good on which bits of text you'll be gluing together though? 16:58:49 https://pagure.io/packaging-committee/issue/715#comment-505572 16:59:02 thta misses the comment part 16:59:24 also misses the "doesn't have to require the main package if it's not needed for reading the docs" 16:59:35 decathorpe: That's kind of a separate proposal. 16:59:42 * decathorpe shrugs 16:59:46 If someone wants to propose a sentence, I can add that as well. 17:00:06 give me a minute 17:00:36 Just tacking on "The -doc subpackage SHOULD NOT have a dependency on the main or -devel packages." would do it, assuming that's actually correct. 17:01:42 Of course, now we get into questions about whether you need to include the license file separately in the -doc package. 17:01:50 you do 17:01:52 If building documentation requires many additional dependencies then you MAY elect to not build it in the main package and instead create a separate *-doc source package which builds only the documentation. This separately packaged documentation MUST correspond to the version of the packaged software. In other words, if a new release of the software includes changes to the documentation, then the documentation package MUST also 17:01:52 be updated. But if the new version of the software does not include documentation changes, then you MAY choose not to update the documentation package. A comment SHOULD be added next to the Version tag of the software package to remind others to bump the doc package as well if needed. 17:02:23 tibbs: If you don't require the main package then legal says yes AIUI 17:02:38 You need the license for the documentation. 17:02:44 +1 17:02:52 Sometimes that's different than the license for the software. Because this is fun. 17:03:09 of course, licenses are always fun 17:03:12 I try to leave as much of that unsaid as possible. 17:03:15 tibbs: yeh, but if it's the same you still need it if you don't require the main package … again, AIUI 17:03:24 tibbs: good plan 17:03:34 you need it be other guidelines, we don't need to add an explicit reminder herwe 17:03:49 In general you'll see that I try to do that as often as possible, like with "correspond". Because otherwise things will grow without bound. 17:04:07 yeh, everything should work the same as sub-packages … just without the building together. 17:04:26 And yeah, we have to avoid repeating ourselves even though people will say that the one section they looked at should tell them everything they needed to know. 17:05:23 Ok, we are almost 5 mins. over time … do we need to vote on anything here? 17:05:48 mhroncok proposed more words, which seems fine. 17:06:00 mhroncok: Please make sure that gets in the ticket. 17:06:18 Otherwise it might get missed when doing writeups. 17:06:42 Fortunately my entire 1PM onwards cancelled today, so I should actually have time to do some writeups. 17:06:51 #action tibbs to paste bits of test agreed on together in the writeup. 17:07:24 #action Agreed on some wording changes for building docs packages separately (+1:5, 0:0, -1:0) 17:07:44 #topic Open floor 17:08:07 Well I have another meeting in 8 minutes … but I should get around to the summaries and email etc. later 17:08:29 I think I updated all the wiki packages for the new people … are you all on the mailing list? 17:08:34 geppetto: how can i help with that? 17:08:50 I'm on the packaging ml if you mean that one 17:08:57 Yeh, that one. 17:09:02 yeah, me too 17:09:03 I don't think I am, I'll sub 17:09:09 I cannot edit fpc tickets metadata 17:09:17 it probably doesn't matter much, but the contributors list on https://pagure.io/packaging-committee hasn't been updated yet 17:09:22 Ahh, yes … you all need to be added to the group 17:09:29 tibbs: You remember how to do that? 17:10:08 I'll update pagure 17:10:19 #action geppetto update https://pagure.io/packaging-committee for new members 17:10:38 is there even a fas group? 17:11:27 yeh 17:11:34 There is? 17:11:37 .fasinfo tibbs 17:11:38 tibbs: User: tibbs, Name: Jason ティビツ, email: tibbs@math.uh.edu, Creation: 2005-05-19, IRC Nick: tibbs, Timezone: UTC, Locale: en, GPG key ID: 0BBED13E, Status: active 17:11:41 tibbs: Approved Groups: wikiadmin +wikiedit @packaging-committee sysadmin-build cla_done @fedorabugs cvsfedora sysadmin sysadmin-cvs cla_fedora provenpackager sysadmin-web gitfas sysadmin-devel cla_fpca @cvsadmin sysadmin-dba sysadmin-noc @packager @gitkquotanotifier 17:11:46 Yep, there is. 17:12:04 https://admin.fedoraproject.org/accounts/group/members/packaging-committee/* 17:12:16 there is this one but the meber aare... not right 17:12:45 or at least I only see 2 17:12:49 I do not know how the permissions flow into the wiki, either. We will need to make sure that happens. 17:13:17 I don't know what, if anything, that fas group is actually used for. 17:13:30 The committee certainly predates the group by a very long time. 17:13:44 I can ask the admin folks and get that sorted if it needs to be sorted. 17:13:51 maybe it was created to be filled in and used somewhere, yet it wasnt 17:13:54 Yeh, but something allows us to edit the wiki pages and the tickets 17:14:04 the tickets, that's pagure 17:14:07 seems like manually added 17:14:27 the wiki i don't know. but I've mostly seen tibbs doing it an he is in that fas group 17:14:32 pagure just has a list of people, which is easy to change. 17:14:39 Yeh, I've done it 17:14:49 mbooth has done it, too, and he's not in the group. 17:15:03 I believe the wiki simply has a list of people. I will find it and get it fixed up. 17:15:07 ok, so it's not the group 17:15:20 #action tibbs to allow new members to alter wiki 17:15:22 yet we might want to fill in the group and strat using it? 17:15:38 we could get badges based on the group :D 17:15:51 yeah, why not use it if the group has already been set up? 17:15:52 :) 👍 17:15:52 I'll get it all taken care of regardless. I don't even know why the group was added. But sure, I can add everyone to the group in any case. 17:17:17 tibbs: thnaks 17:17:27 tibbs: Maybe for trac? 17:17:39 but I think that had it's own list, so probably not 17:17:39 Trac predated that by many years. 17:17:48 ¯\_(ツ)_/¯ 17:17:50 And yeah, I would manually maintain the trac list. 17:18:21 I'm not entirely sure how adding a group in pagure controls how mail is delivered. 17:18:38 Ok, going to close the meeting only 18 minutes late … not bad for a first meeting for new people with a giant backlog :) 17:18:39 As in, if you're just accessing pagure because you're in a group, I'm not sure if you get notifications. 17:19:02 #endmeeting