17:00:15 <geppetto> #startmeeting fpc
17:00:15 <zodbot> Meeting started Thu Mar  7 17:00:15 2019 UTC.
17:00:15 <zodbot> This meeting is logged and archived in a public location.
17:00:15 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:15 <zodbot> The meeting name has been set to 'fpc'
17:00:15 <geppetto> #meetingname fpc
17:00:15 <geppetto> #topic Roll Call
17:00:15 <zodbot> The meeting name has been set to 'fpc'
17:00:36 <redi> i
17:00:39 <redi> hi
17:00:41 <decathorpe> ahoy
17:00:42 <geppetto> #chair redi
17:00:42 <zodbot> Current chairs: geppetto redi
17:00:46 <ignatenkobrain> .hello2
17:00:47 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
17:00:48 <geppetto> #chair decathorpe
17:00:48 <zodbot> Current chairs: decathorpe geppetto redi
17:00:53 <geppetto> #chair ignatenkobrain
17:00:53 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain redi
17:02:32 <tibbs> Hey, folks.
17:02:38 <geppetto> #chair tibbs
17:02:38 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain redi tibbs
17:02:45 <geppetto> hey, tibbs!
17:02:52 <tibbs> Was stuck at the optometrist ordering glasses.  Just ran over.
17:02:52 <geppetto> That makes 5 … woo :)
17:04:24 <mhroncok> hey. I'm connected but I'm in the BRno RH office and people want to talk IRL
17:04:32 <geppetto> ok
17:04:33 <mhroncok> so don't count on me, sorry
17:04:37 <geppetto> #chair mhroncok
17:04:37 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain mhroncok redi tibbs
17:04:46 <geppetto> You get to be a chair anyway ;)
17:05:18 <geppetto> #topic Schedule
17:05:22 <geppetto> #link https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
17:05:35 <geppetto> Nothing has changed since last week
17:06:21 <geppetto> #topic Open Floor
17:06:30 <ignatenkobrain> If we don't have anything to talk about, I have 2 things which came up :)
17:06:46 <geppetto> Cool, go ahead
17:07:43 <ignatenkobrain> 1. One guy from docs team was asking if he can get commit access to our docs so that he can fix formatting and/or restructure things... My answer was that we would prefer if he would just send PRs and we would merge them ourselves. Are we in agreement on this?
17:09:24 <redi> yeah sending PRs doesn't seem too difficult. Although personally I don't mind giving someone access if they're just going to make editorial fixes
17:09:28 <decathorpe> well, it wouldn't hurt to give him commit-level access, would it?
17:09:33 <geppetto> I mean we can always revert, so I'm not too bothered and assume it's fine to just let him do minor fixes
17:09:52 <ignatenkobrain> I'm fine either way :)
17:09:55 <decathorpe> as long as that doesn't come with any extra powers, I think it would be fine
17:10:18 <tibbs> To be fair, I'd prefer that the docs team fix some of the underlying issues with the system before worrying about tweaking our pages.
17:10:22 <ignatenkobrain> .fasinfo pbokoc
17:10:23 <zodbot> ignatenkobrain: User: pbokoc, Name: None, email: pbokoc@redhat.com, Creation: 2013-06-21, IRC Nick: None, Timezone: None, Locale: None, GPG key ID: None, Status: active
17:10:26 <zodbot> ignatenkobrain: Approved Groups: +docs cla_fpca cla_done fedorabugs
17:10:34 <tibbs> But I don't see what harm it would do to have someone else fixing typos if they want.
17:11:00 <tibbs> You mentioned restructuring, though.... that's probably something that should involve discussion.
17:11:24 <decathorpe> right
17:12:24 <ignatenkobrain> PROPOSAL: Add pbokoc as committer to our repository and instruct the way that bigger changes need PR, but typos and small tweaks can be handled without notifications.
17:12:36 <geppetto> +1
17:12:55 <decathorpe> +1
17:13:04 <redi> +1
17:13:15 <tibbs> +1 (we'll get notifications anyway)
17:13:36 <ignatenkobrain> (I'm +1 too, FTR)
17:13:40 <redi> rather than "typos" I would say "editorial fixes", i.e. ones that don't change meaning but improve the presentation
17:13:54 <ignatenkobrain> redi: agree
17:14:02 <tibbs> To me "editorial" has a much broader meaning than that.
17:14:02 <redi> making something bold to improve readability is not a typo :)
17:14:38 <tibbs> But note that we should have consistency, and if we're going to have some kind of standards document for these pages, we as a committee should talk about that.
17:15:17 <redi> my intention was something similar to the first bullet at https://github.com/cplusplus/draft/wiki/How-to-tell-if-an-issue-is-editorial
17:15:29 <redi> which is what we use for the C++ standard
17:15:48 <redi> but I think we're generally in agreement that simple improvements to the presentation are ok
17:16:25 <geppetto> Sure, at least I am
17:18:20 <ignatenkobrain> I think we are pretty much in agreement… geppetto can you make it an #action?
17:18:27 <geppetto> Sure
17:19:08 <geppetto> #action  Add pbokoc as committer to our repository for typos and small tweaks (+1:5, 0:0, -1:0)
17:19:15 <ignatenkobrain> 2. I was thinking whether it would make sense to get some modularity guidelines in our repository..
17:19:22 <geppetto> ha
17:19:37 <ignatenkobrain> https://docs.fedoraproject.org/en-US/modularity/making-modules/packaging-guidelines/
17:19:52 <ignatenkobrain> there are some kind of that there, but it is not under FPC control and is not verbose enough :)
17:21:13 * geppetto nods … a bunch have been written … they have been much more dynamic than most of our stuff though
17:21:47 <geppetto> I figured by F30 or maybe even F31 they'd be stable enough to come into FPC land.
17:22:23 <ignatenkobrain> They are more or less stable nowadays
17:22:29 <ignatenkobrain> format doesn't change and is not planned to
17:22:42 <ignatenkobrain> small things might change, but generally it will stay same
17:23:10 <geppetto> yeh, but the tools are still a bit … eg. how you can do local builds will only be well defined in the next couple of months
17:23:26 <tibbs> I was actually wondering about this as well.
17:23:29 <geppetto> I'm fine on including anything anyone wants to though
17:23:56 <tibbs> I assume that anything in a module would still have to follow all of the regular guidelines.
17:24:20 <ignatenkobrain> yes
17:24:40 <ignatenkobrain> probably with some exceptions
17:24:41 <tibbs> And then... how does someone audit these things?
17:25:00 <tibbs> Right now we can get a tarball of rawhide specfiles.  But modularity stuff is somewhere else.
17:25:11 <ignatenkobrain> RPMs in a module do not have to increment evr
17:25:15 <mhroncok> I've asked for this months ago
17:25:24 <tibbs> ignatenkobrain: Uh, what?
17:25:25 <mhroncok> (for spcfiles)
17:25:40 <tibbs> Surely they must do that at some point.
17:25:51 <tibbs> Otherwise how would anything ever be seen as an update?
17:26:01 <mhroncok> by magic
17:26:08 <geppetto> tibbs: MBS has automatic data as part of the release of an rpm
17:26:29 <tibbs> If I can't download the RPMs to a directory and run rpm on them then... that's broken.
17:26:30 <ignatenkobrain> tibbs: in modular metadata
17:27:05 <tibbs> Please tell me they haven't broken the underlying assumptions about what constitutes an update according to RPM.
17:27:16 <ignatenkobrain> tibbs: you can... with multiple caveats
17:28:08 <ignatenkobrain> tibbs: right now rawhide-modular has libgit2-0.26, libgit2-0.27 and libgit2-0.28.. without knowing module stream you would be updated to 0.28... while with modular metadata you would stay with 0.26 or 0.27 or 0.28 as you chose yourself
17:28:10 <tibbs> There shouldn't be any caveats.  If rpm -U doesn't think it's an update then it's not an update.
17:29:55 <ignatenkobrain> what I meant is that technology doesn't prohibit this... but as part of FPG we probably want to prohibit this
17:30:02 <tibbs> I guess this isn't the place to shake our heads in wonder at how modularity has been implemented.
17:30:27 <ignatenkobrain> that's why I was asking whether it is something we want to take over or leave it to modularity guys..
17:30:44 <tibbs> Well I think they should submit guidelines as normal.
17:30:50 <redi> I'm trying to ignore modularity for as long as possible
17:32:59 <tibbs> Really, if I have a system with modularity disabled, enable the repo, run dnf upgrade and see packages being upgraded, this thing really must be treated no differently than the main repository.
17:33:22 <tibbs> (and that's 100% the case in F29)
17:35:03 <mhroncok> going offline
17:35:08 <tibbs> Take care.
17:35:33 <mhroncok> tibbs: thanks :)
17:36:15 <decathorpe> tibbs: let me shake my head with you ;)
17:36:23 <ignatenkobrain> I'll need to go in 5 minutes too. So I think basically we want 1) have modular guidelines at some point controlled by FPC 2) have as less differences between RPM packages in traditional way compared to modular ones (if any)
17:36:37 <geppetto> Sure
17:36:48 <tibbs> Anyway, I imagine that such a guideline would impose additional restructions on modularity content, just like, say, Perl or Python guidelines.
17:36:52 <ignatenkobrain> 3) probably we don't want to have it now, but in some near future
17:37:34 <tibbs> If there's some specific set of rules from which they would be excepted then I guess I'd have to see what those would be.
17:38:02 <ignatenkobrain> sure
17:38:24 <tibbs> My fear of course is that the thing has come all the way to be enabled by default and packages dropping out of the traditional repository, but nobody's submitted any packaging guidelines to us at all.
17:40:21 <ignatenkobrain> I need to go, folks. Have a nice rest of the day!
17:40:58 <geppetto> Eh, I'm not that worried … the rpms are basically the same … the new modular content is al in the wrapping metadata, and that's changed a lot and unsimilar to rpms
17:41:05 <geppetto> ignatenkobrain: see you next week.
17:41:36 <tibbs> geppetto: I admire your optimism.
17:41:57 <geppetto> Ok, with two less people I'm going to close unless someone speaks up.
17:41:59 <geppetto> tibbs: ha
17:42:18 <tibbs> I have no idea when my crazy work schedule will normalize.
17:42:30 <tibbs> I guess it has normalized to "crazy".
17:42:36 <geppetto> :(
17:44:05 <geppetto> #endmeeting