16:00:31 <geppetto> #startmeeting fpc
16:00:31 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:31 <zodbot> The meeting name has been set to 'fpc'
16:00:31 <geppetto> #meetingname fpc
16:00:31 <zodbot> The meeting name has been set to 'fpc'
16:00:31 <geppetto> #topic Roll Call
16:00:44 <tibbs> Howdy.
16:00:47 <mhroncok> hi there
16:00:52 <redi> hello
16:01:02 <geppetto> #chair tibbs
16:01:02 <zodbot> Current chairs: geppetto tibbs
16:01:06 <geppetto> #chair mhroncok
16:01:06 <zodbot> Current chairs: geppetto mhroncok tibbs
16:01:11 <geppetto> #chair redi
16:01:11 <zodbot> Current chairs: geppetto mhroncok redi tibbs
16:01:39 <geppetto> hey
16:03:05 <decathorpe> hi everybody (newbie here)
16:03:15 <geppetto> #chair decathorpe
16:03:15 <zodbot> Current chairs: decathorpe geppetto mhroncok redi tibbs
16:03:40 <geppetto> Hey, no problem … kind of easy and the new people outnumber the old atm :)
16:04:00 * racor is here, too
16:04:22 <geppetto> racor: Hey, we've switched over to the new members … but you are free to hang out.
16:04:55 <racor> Well, you don't want to know what I think of this.
16:05:46 <geppetto> #topic Schedule
16:05:49 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/GCXK7RGE7UW2JCAABX3LKNP37DB7VC6L/
16:06:01 <geppetto> #topic #761 Modernize R guidelines
16:06:04 <geppetto> .fpc 761
16:06:06 <zodbot> geppetto: Issue #761: Modernize R guidelines - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/761
16:06:28 <mhroncok> I've gone trough the changes and I think they are straightforward and good
16:06:42 <mhroncok> the old guidelines seems to be prehistoric
16:07:23 <geppetto> yeh, probably … I'm not sure anybody knew much about R … other than it existed.
16:07:24 <Rathann> hi
16:07:29 <tibbs> 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 <geppetto> Rathann: Hey, we've moved over to the new members today … but feel free to hang out.
16:07:53 <Rathann> oh, that's great
16:08:37 <Rathann> congratulations to new members
16:09:04 <redi> 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 <geppetto> Yeh, I'm happy to +1 this change. Seems simple enough.
16:09:58 <mhroncok> +1 if it needs a formal vote
16:10:07 <decathorpe> according to the summary it mostly just cleans up some ancient stuff - looks sane to me (+1)
16:10:20 <geppetto> Yeh, I'm kind of assuming everyone who said they are happy it +1 … but a formal thing is good too :)
16:10:25 <redi> +1
16:10:50 <tibbs> +1
16:10:52 <geppetto> #action Modernize R guidelines (+1:5, 0:0, -1:0)
16:11:00 <geppetto> Ok, cool. That was easy :)
16:11:03 <geppetto> Now old tickets
16:11:45 <geppetto> #topic #726 Review for SELinux Independent Policy packaging Draft
16:11:49 <geppetto> .fpc 726
16:11:51 <zodbot> geppetto: Issue #726: Review for SELinux Independent Policy packaging Draft - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/726
16:12:13 <geppetto> So this one hasn't moved forward … but maybe redi can help out a bit on the changes needed?
16:12:15 <tibbs> I think this is still stalled out on me, but if someone else wants to take a crack it at.
16:12:44 <tibbs> Basically what they have submitted isn't anything like what should be packaging guidelines.
16:13:28 <tibbs> We don't need to tell people how to set up github repositories or anything like that.
16:13:56 <tibbs> 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 <redi> 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 <tibbs> Anyone is always welcome to take a look at those things.
16:14:35 <geppetto> redi: No problem
16:15:36 <tibbs> 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 <orc_fedo> 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 <orc_fedo> 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 <orc_fedo> indicated*
16:17:10 <tibbs> Even then, a tutorial isn't something we would want in a packaging guideline either.
16:17:22 <mhroncok> tutorial can be posted somewhere else on wiki
16:17:35 <mhroncok> we can then mention it in the guidelines
16:17:37 <tibbs> And I think it would be better for us to avoid talking too much about what "acceptable selinux policy" looks like.
16:17:41 <geppetto> orc_fedo: I suspect it was tested, but then it changed and not retested.
16:17:56 <orc_fedo> geppetto: dunno -- i tested within a day of its initiall mention
16:18:00 <tibbs> Maybe some general statements, but the emphasis should be on how you package the stuff.
16:18:14 * geppetto nods
16:18:27 <orc_fedo> tibbs: I am find w the standard not including worked examples, r tutorials, but they need to exist as well
16:18:42 <tibbs> That's out of scope for what we do here.
16:18:43 <geppetto> pretty sure we said last time that we didn't want "what is good selinux policy" in the guidelines.
16:18:55 <decathorpe> looking at the draft, more than 50% is not about packaging itself ...
16:19:33 <mhroncok> do we have guidelines for guidelines we can ask people to follow?
16:19:51 <mhroncok> or would that be too meta?
16:20:21 <geppetto> mhroncok: those are us :)
16:21:19 <mhroncok> ok
16:21:57 <decathorpe> 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 <geppetto> 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 <tibbs> It's a pretty rare thing.
16:23:23 <decathorpe> true
16:23:51 <tibbs> 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 <mhroncok> right
16:24:26 <tibbs> 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 <geppetto> #action redi will look at helping tibbs, but not before next week
16:24:59 <geppetto> #topic #723 Guidelines for handling deprecated dependencies during review
16:25:05 <geppetto> .fpc 723
16:25:08 <zodbot> geppetto: Issue #723: Guidelines for handling deprecated dependencies during review - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/723
16:26:18 <geppetto> 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 <mhroncok> as far as I read it, this boils to:
16:26:56 <mhroncok> create a guideline that says that deprectaed packages have a specific provide
16:27:13 <mhroncok> say packages MUST not depend on deprecated
16:27:26 <mhroncok> say package can only be marked as deprecated once nothing depends on it
16:27:31 <tibbs> 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 <tibbs> Though it does have more relevance with the python2 thing.
16:27:54 <geppetto> tibbs: I think with modularity approaching it might be more useful than you think
16:27:55 <mhroncok> right
16:28:16 <geppetto> But, yeh, I think mhroncok got the basic summary
16:28:35 <decathorpe> 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 <mhroncok> question is, whether anyone can juts mark their packages deprecated, or if it requires some kind of approval
16:28:54 <tibbs> I think with modularity it gets more complicated than anyone thinks.
16:29:05 <mhroncok> everyhtng gets complicated with modularity :D
16:29:17 <mhroncok> *everything
16:29:33 <decathorpe> exactly. that's now what I think every time I see the word "modularity" ;)
16:29:39 <tibbs> decathorpe: Because that gives you a way to see that something is actually deprecated.
16:29:52 <tibbs> Otherwise what can you do? Consult some wiki page?
16:29:58 <geppetto> 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 <tibbs> This way you can technically run a repoquery line and see if anything in your depchain is deprecated.
16:30:33 <decathorpe> ah, that makes sense.
16:30:54 <mhroncok> that can be added to FedoraReview or whatever
16:31:23 <mhroncok> the thing that remains unclear to me is who decides what's deprecated
16:31:33 <tibbs> It's certainly not us.
16:31:37 <mhroncok> agreed
16:31:50 <mhroncok> it can be either the package maintainers or fesco
16:31:51 <tibbs> Everything is up to the packager in the end.
16:31:57 <geppetto> AFAIK it's the packager who owns the package being deprecated … if only by default.
16:32:13 <tibbs> If FESCo wants to step in then that would be up to them.
16:32:17 <geppetto> yeh
16:32:32 <mhroncok> ok, I can prep a draft
16:32:51 <geppetto> #action mhroncok Will prep. a draft
16:33:36 <geppetto> #topic #719 Simplify packaging of forge-hosted projects
16:33:37 <mhroncok> technical: i want to assign the issue to me, but appaerntly, I still cannot
16:33:40 <geppetto> .fpc 719
16:33:42 <zodbot> geppetto: Issue #719: Simplify packaging of forge-hosted projects - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/719
16:34:00 <geppetto> So AIUI here tibbs already did the technical parts of this, and the macros are already live
16:34:16 <tibbs> Yes.  I now forget what this ticket is waiting on.
16:34:18 <geppetto> We, again, "just" need a draft telling people to use them.
16:34:30 <tibbs> Though of course I didn't do anything other than merge the PR.
16:34:41 <decathorpe> are the new macros reasonably "bug free" now?
16:35:07 <tibbs> I haven't heard any complaining, nor have any updates been sent in a while.
16:35:20 <mhroncok> are there enough packages that use them to tell?
16:35:42 <decathorpe> should there be packages using it before the changes were approved by FPC? ;)
16:35:42 <tibbs> A whole raft of Go stuff, I guess.
16:36:03 <mhroncok> decathorpe: that's debatable. It was not forbidden
16:36:04 <tibbs> decathorpe: Good luck with that.  How long have we had Go packaging without Go packaging guidelines?
16:36:30 <tibbs> 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 <redi> so somebody "just" needs to write up how to use these macros, and add it to the guidelines?
16:36:45 <tibbs> Yes.
16:36:59 <redi> sign me up, I guess
16:37:02 <tibbs> Generally the people who understand them are the ones who would do that.
16:37:12 <redi> that's not me, but I'd like to learn how they work :)
16:37:19 <redi> I can take a first stab at it anyway
16:37:22 <tibbs> And then we turn what they give us into guidelines.
16:37:40 <redi> that seems sensible. have they been asked?
16:37:50 <tibbs> I think that's part of the point of the ticket.
16:38:18 <tibbs> nim gave us sort of an outline.
16:38:42 <redi> a very brief one. I can start from that though
16:38:43 <tibbs> 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 <geppetto> #action redi Volunteers to understand macros and write up a draft for using them.
16:39:08 <tibbs> https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation isn't really brief, though.
16:39:10 <redi> ok. I'll experiment with them next week, converting some spec files to use them
16:39:29 <redi> ah I didn't see that page
16:39:31 <tibbs> There's enough in that wiki page to make a reasonable guideline, I think.
16:39:47 <tibbs> But no changes since January so I don't know if that means it's outdated or just stable.
16:40:09 <redi> I have packages on gitlab and github that I can experiment with
16:40:42 <geppetto> #topic #715 Separately building package documentation
16:40:45 <geppetto> .fpc 715
16:40:47 <zodbot> geppetto: Issue #715: Separately building package documentation - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/715
16:40:58 <geppetto> Ok, so big surprise … this needs a draft.
16:41:27 <geppetto> I think we also got lost in the weeds about bootstrapping last time, when it wasn't really relevant.
16:41:57 <decathorpe> 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 <tibbs> Oh, hmm, I thought this was dead.
16:42:21 <geppetto> 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 <geppetto> decathorpe: Yeh, this is basically generalizing the python/python-docs thing.
16:42:54 <tibbs> I didn't realize python3 built the docs separately; that's certainly a nice example.
16:43:06 <geppetto> So people don't need two reviews, and they'll tend to make the packages work in similar ways etc.
16:43:34 <mhroncok> be careful not to recommend this as the best ay to do it
16:43:46 <geppetto> Is there a better way?
16:43:50 <mhroncok> keeping python3-docs in sync is painful
16:44:04 <mhroncok> I like the sentence in the ticket...
16:44:15 <mhroncok> 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 <mhroncok> sounds reasonably optional to me
16:44:48 <tibbs> And a lot hinges on "correspond" there.
16:45:02 <decathorpe> this has the advantage that the -docs package can (almost always ?) be noarch
16:45:03 <tibbs> Because docs don't always change when the software changes.
16:45:06 <mhroncok> 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 <tibbs> The docs package can generally be noarch now.
16:45:27 <geppetto> tibbs: I would guess that means … sources entries must be the same
16:45:34 <decathorpe> yes, but it has to be built only once if it's the main package
16:45:43 <tibbs> geppetto: I wouldn't want it to mean that.
16:45:59 <geppetto> tibbs: what then?
16:46:24 <tibbs> 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 <redi> 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 <mhroncok> I don't think that this is a MUST
16:47:06 <geppetto> 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 <tibbs> redi: I think part of the idea is to avoid doing that when it's unnecessary.
16:47:08 <mhroncok> MUST is to correspond, as said by tibbs
16:47:20 <tibbs> Which is why I used "correspond" there.  Not "match the version exactly".
16:47:27 <redi> 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 <tibbs> I think most reasonable people can tell when the docs don't correspond to the software.
16:47:40 <redi> but I can see both sides of the argument, and don't mind either way
16:47:51 <redi> yeah
16:47:51 <geppetto> tibbs: I'm happy to not rebuild for every patch … but not rebuilding when the source changes seems a bit risky.
16:47:51 <tibbs> "These docs are three years out of date; could you please fix it?"
16:48:01 <geppetto> :)
16:48:06 <tibbs> I don't see what the risk is, though.
16:48:21 <mhroncok> it's not like it breaks anything
16:48:23 <redi> yeah
16:48:29 <mhroncok> worst case somebody files a bugzilla
16:48:41 <tibbs> 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 <tibbs> We're not talking about breaking the distro.
16:49:00 <geppetto> Fair enough … I'd just prefer a concrete definition of correspond … and upstream source makes that easy.
16:49:24 <tibbs> Meanwhile, not splitting docs means that texlive is most of the more critical components of the entire thing.
16:49:40 <redi> 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 <geppetto> Ok
16:50:15 <decathorpe> agreed. this looks like a nice trade-off
16:50:36 <geppetto> So … anyone want to volunteer to draft this?
16:50:45 <mhroncok> This separately packaged documentation MUST be accurate for the version of the packaged software.
16:50:48 <redi> 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 <mhroncok> is different wording that basically means the same
16:51:16 <geppetto> redi: That would probably be a good idea.
16:51:27 <geppetto> mhroncok: seems fine to me.
16:51:35 <mhroncok> redi: I'd go with SHOULD here, but I'm ok with MUST
16:51:50 <decathorpe> yeah, mentioning the -doc package in the main one seems like a good idea
16:51:53 <redi> I was hesitating as typing it :)
16:52:00 <redi> SHOULD is ok too
16:52:27 <decathorpe> 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 <mhroncok> :)
16:53:08 <mhroncok> that's bikeshedding, I'm ok with both
16:53:54 <decathorpe> it would be nice if the comment was there for provenpackagers, but SHOULD and MUST are both fine with me
16:54:18 <tibbs> "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 <tibbs> (Sorry, was typing that.)
16:54:55 <mhroncok> tibbs: +1
16:54:57 <decathorpe> +1, sounds reasonable
16:55:16 <geppetto> +1
16:55:33 <mhroncok> should the docs package require the main or not? I'd say not, but just makeing sure
16:55:51 <redi> +1
16:56:24 <decathorpe> I guess if the docs "work" without the main package, I wouldn't add requires artificially ...
16:56:26 <redi> mhroncok: if you can read the docs without the main one, I'd say not.
16:56:27 <tibbs> In general documentation packages don't require the main package.
16:56:28 <redi> yeah
16:56:43 <mhroncok> agreed, just wanting to know if we are on the same page
16:56:53 <tibbs> I think that's already in the guidelines anyway.
16:56:55 <mhroncok> ok, so we now need to glue the texts together
16:57:51 <tibbs> The proposal was to add that bit to https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation
16:58:07 <tibbs> I generally do the "glue" as part of writing things up.
16:58:18 <mhroncok> ok. +1 on that
16:58:42 <geppetto> ok, are we all good on which bits of text you'll be gluing together though?
16:58:49 <mhroncok> https://pagure.io/packaging-committee/issue/715#comment-505572
16:59:02 <mhroncok> thta misses the comment part
16:59:24 <decathorpe> also misses the "doesn't have to require the main package if it's not needed for reading the docs"
16:59:35 <tibbs> decathorpe: That's kind of a separate proposal.
16:59:42 * decathorpe shrugs
16:59:46 <tibbs> If someone wants to propose a sentence, I can add that as well.
17:00:06 <mhroncok> give me a minute
17:00:36 <tibbs> 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 <tibbs> Of course, now we get into questions about whether you need to include the license file separately in the -doc package.
17:01:50 <mhroncok> you do
17:01:52 <mhroncok> 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 <mhroncok> 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 <geppetto> tibbs: If you don't require the main package then legal says yes AIUI
17:02:38 <tibbs> You need the license for the documentation.
17:02:44 <decathorpe> +1
17:02:52 <tibbs> Sometimes that's different than the license for the software.  Because this is fun.
17:03:09 <mhroncok> of course, licenses are always fun
17:03:12 <tibbs> I try to leave as much of that unsaid as possible.
17:03:15 <geppetto> 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 <geppetto> tibbs: good plan
17:03:34 <mhroncok> you need it be other guidelines, we don't need to add an explicit reminder herwe
17:03:49 <tibbs> 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 <geppetto> yeh, everything should work the same as sub-packages … just without the building together.
17:04:26 <tibbs> 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 <geppetto> Ok, we are almost 5 mins. over time … do we need to vote on anything here?
17:05:48 <geppetto> mhroncok proposed more words, which seems fine.
17:06:00 <tibbs> mhroncok: Please make sure that gets in the ticket.
17:06:18 <tibbs> Otherwise it might get missed when doing writeups.
17:06:42 <tibbs> Fortunately my entire 1PM onwards cancelled today, so I should actually have time to do some writeups.
17:06:51 <geppetto> #action tibbs to paste bits of test agreed on together in the writeup.
17:07:24 <geppetto> #action Agreed on some wording changes for building docs packages separately (+1:5, 0:0, -1:0)
17:07:44 <geppetto> #topic Open floor
17:08:07 <geppetto> Well I have another meeting in 8 minutes … but I should get around to the summaries and email etc. later
17:08:29 <geppetto> I think I updated all the wiki packages for the new people … are you all on the mailing list?
17:08:34 <mhroncok> geppetto: how can i help with that?
17:08:50 <mhroncok> I'm on the packaging ml if you mean that one
17:08:57 <geppetto> Yeh, that one.
17:09:02 <decathorpe> yeah, me too
17:09:03 <redi> I don't think I am, I'll sub
17:09:09 <mhroncok> I cannot edit fpc tickets metadata
17:09:17 <decathorpe> it probably doesn't matter much, but the contributors list on https://pagure.io/packaging-committee hasn't been updated yet
17:09:22 <geppetto> Ahh, yes … you all need to be added to the group
17:09:29 <geppetto> tibbs: You remember how to do that?
17:10:08 <geppetto> I'll update pagure
17:10:19 <geppetto> #action geppetto update https://pagure.io/packaging-committee for new members
17:10:38 <mhroncok> is there even a fas group?
17:11:27 <geppetto> yeh
17:11:34 <tibbs> There is?
17:11:37 <tibbs> .fasinfo tibbs
17:11:38 <zodbot> 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 <zodbot> 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 <tibbs> Yep, there is.
17:12:04 <mhroncok> https://admin.fedoraproject.org/accounts/group/members/packaging-committee/*
17:12:16 <mhroncok> there is this one but the meber aare... not right
17:12:45 <mhroncok> or at least I only see 2
17:12:49 <tibbs> I do not know how the permissions flow into the wiki, either.  We will need to make sure that happens.
17:13:17 <tibbs> I don't know what, if anything, that fas group is actually used for.
17:13:30 <tibbs> The committee certainly predates the group by a very long time.
17:13:44 <tibbs> I can ask the admin folks and get that sorted if it needs to be sorted.
17:13:51 <mhroncok> maybe it was created to be filled in and used somewhere, yet it wasnt
17:13:54 <geppetto> Yeh, but something allows us to edit the wiki pages and the tickets
17:14:04 <mhroncok> the tickets, that's pagure
17:14:07 <mhroncok> seems like manually added
17:14:27 <mhroncok> the wiki i don't know. but I've mostly seen tibbs doing it an he is in that fas group
17:14:32 <tibbs> pagure just has a list of people, which is easy to change.
17:14:39 <geppetto> Yeh, I've done it
17:14:49 <tibbs> mbooth has done it, too, and he's not in the group.
17:15:03 <tibbs> I believe the wiki simply has a list of people.  I will find it and get it fixed up.
17:15:07 <mhroncok> ok, so it's not the group
17:15:20 <geppetto> #action tibbs to allow new members to alter wiki
17:15:22 <mhroncok> yet we might want to fill in the group and strat using it?
17:15:38 <mhroncok> we could get badges based on the group :D
17:15:51 <decathorpe> yeah, why not use it if the group has already been set up?
17:15:52 <geppetto> :) 👍
17:15:52 <tibbs> 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 <mhroncok> tibbs: thnaks
17:17:27 <geppetto> tibbs: Maybe for trac?
17:17:39 <geppetto> but I think that had it's own list, so probably not
17:17:39 <tibbs> Trac predated that by many years.
17:17:48 <geppetto> ¯\_(ツ)_/¯
17:17:50 <tibbs> And yeah, I would manually maintain the trac list.
17:18:21 <tibbs> I'm not entirely sure how adding a group in pagure controls how mail is delivered.
17:18:38 <geppetto> 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 <tibbs> 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 <geppetto> #endmeeting