16:00:36 <geppetto> #startmeeting fpc
16:00:36 <zodbot> Meeting started Thu Sep 14 16:00:36 2023 UTC.
16:00:36 <zodbot> This meeting is logged and archived in a public location.
16:00:36 <zodbot> The chair is geppetto. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:36 <zodbot> The meeting name has been set to 'fpc'
16:00:36 <geppetto> #meetingname fpc
16:00:36 <zodbot> The meeting name has been set to 'fpc'
16:00:36 <geppetto> #topic Roll Call
16:00:45 <tibbs> Hey.
16:00:49 <geppetto> #chair tibbs
16:00:49 <zodbot> Current chairs: geppetto tibbs
16:00:51 <geppetto> Hey
16:01:15 <geppetto> The new school year rush slowing down, yet?
16:01:33 <tibbs> A little, but today I have someone at my house installing kitchen cabinets.
16:01:57 <geppetto> ahh, always nice and quiet when working from home ;)
16:03:06 <tibbs> This closing in on seven months without a kitchen now because we chose the wrong company.
16:03:40 <michel-slm> .hello salimma
16:03:41 <zodbot> michel-slm: salimma 'Michel Lind' <michel@michel-slm.name>
16:04:12 <carlwgeorge> .hi
16:04:13 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
16:04:28 <geppetto> #chair carlwgeorge
16:04:28 <zodbot> Current chairs: carlwgeorge geppetto tibbs
16:10:02 <deca> hello o/ sorry for being late, lost track of time rewriting Rust Packaging Guidelines
16:12:52 <geppetto> #chair decathorpe
16:12:52 <zodbot> Current chairs: carlwgeorge decathorpe geppetto tibbs
16:12:54 <geppetto> #topic Open Floor
16:13:08 <geppetto> Anyone want to talk about anything … like Rust guidelines?
16:13:58 <decathorpe> well ... the current ones are a but dusty and don't apply to many of the situations that people are encountering lately, so I'm trying to refresh them
16:14:41 <decathorpe> the downside is that it's basically going to be a 100% new document :(
16:15:08 <tibbs> I didn't realize so much had changed.
16:15:25 <decathorpe> well, the things that are currently in the guidelines are still valid
16:15:47 <decathorpe> but they don't mention some things *at all* which are now happening more frequently
16:15:57 <decathorpe> like, "native" Python packages that aren't written in C but in Rust
16:16:03 <tibbs> Makes sense.
16:16:33 <decathorpe> I'm trying to make Guidelines that are useful for *all* (or at least, most) circumstances in which people need to build Rust code in Fedora
16:16:38 <michel-slm> the intersection is interesting. for these Python packages - do we require rust-sig be in the ACL like other Rust packages?
16:17:08 <decathorpe> michel-slm: no, rust-sig won't get added automatically there. but some maintainers still opt-in-to that
16:20:53 <michel-slm> I guess we can always create compat crates for those
16:21:36 <decathorpe> can you elaborate how this connects to your question?
16:22:45 <michel-slm> sure - right now if we're upgrading a crate, and the dependents all look safe to rebuild, the person driving the upgrade can just rebuild everything by themselves
16:22:50 <michel-slm> (person == SIG member)
16:23:17 <decathorpe> ah, right. for crates that have "external" dependents, I usually create compat packages.
16:23:27 <michel-slm> if there are other packages that depend on that crate that the SIG does not have direct access to, it would mean either waiting for PRs to be merged, create compat crates to bypass, or use provenpackager
16:23:39 <decathorpe> this also solves the problem that other ecosystems (like Python) also have a different update cycle, i.e. don't push all updates to stable branches
16:24:03 <michel-slm> good point
16:27:51 <geppetto> Well good luck :) … I guess we can vote on it in the next week or two?
16:28:26 <geppetto> Anything else to talk about, or should I just close the meeting and give everyone 30 minutes back?
16:32:04 <decathorpe> I'll ask for some early feedback from Rust SIG first, and then I'll need to convert from markdown to asciidoc ...
16:32:14 <decathorpe> but yes I hope to have this ready within the next 1-2 weeks
16:32:19 <geppetto> Sounds good
16:32:43 <decathorpe> yolo pandoc -i Rust.md -o Rust.asciidoc
16:33:35 <michel-slm> speaking of supporting multiple releases, pandoc is that one thing that's really hard to get into EPEL so many of their packages can't ship docs :)
16:33:50 <decathorpe> :<
16:34:10 <decathorpe> well we don't ship docs for Rust at all so ... :shrug:
16:34:42 <michel-slm> real devs compile the code in their head to deduce behavior ;)
16:34:47 <carlwgeorge> hot take, building/shipping docs in packages isn't worth the effort
16:35:05 * michel-slm nods - that sounds like a good FPC discussion topic
16:35:09 <decathorpe> carlwgeorge: yeah that's mostly the reason why I haven't looked into enabling docs subpackages for Rust crates
16:35:22 <decathorpe> dealing with bundled JS and fonts is PAINFUL
16:35:31 <carlwgeorge> maybe a lukewarm take then :)
16:35:38 <michel-slm> it makes sense in the 'server does not have internet access' case but you can look up the docs on a separate machine anyway
16:35:50 <michel-slm> and for container use cases the focus is on stripping things
16:35:56 <decathorpe> but at least with rustdoc there'd be only *one* theme (i.e. only one set of fonts / JS used by *everything*)
16:36:06 <michel-slm> also: getting false alarm on security issues because the JS has a CVE
16:36:14 <decathorpe> 😦
16:36:43 * michel-slm dealing with an actual CVE now that somehow does not get detected ... so, false negative :)
16:38:19 <geppetto> Yeh, I know we did a bunch of work to make python-docs etc. … and I always just used the internet.
16:38:51 <decathorpe> python docs is actually one of the only docs packages that I have locally installed
16:39:03 <geppetto> Also nobody reads the docs anyway … and I know becaue I don't read the docs ;)
16:39:14 <geppetto> decathorpe: You ever use them?
16:39:14 * decathorpe frowns
16:39:25 <decathorpe> aren't we basically in charge of writing docs? ...
16:39:48 <geppetto> decathorpe: That's a really old quote from a kernel developer
16:39:50 <decathorpe> geppetto: I used to much more frequently, but I'm doing much less Python programming, so now I mostly use google
16:39:59 <michel-slm> geppetto: ha, I just had to build python-docs for EPEL because it's a dependency of a package and I don't want to maintain a fork of that package
16:40:20 <carlwgeorge> do we currently have a should/may/must type guideline on shipping docs in packages?
16:40:24 <michel-slm> geppetto: which kernel dev?
16:40:39 <decathorpe> carlwgeorge: I don't think so? ... let me check
16:40:49 <geppetto> I thought we left it up to each maintainer
16:41:02 <michel-slm> carlwgeorge: that seems to tie in nicely with the discussion a few weeks ago (that I sadly miss) about recommending how to skip tests and docs consistently?
16:41:04 <Son_Goku> .hello ngompa
16:41:05 <zodbot> Son_Goku: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:41:07 <Son_Goku> hey
16:41:24 <michel-slm> if we do so we can probably also provide guidelines on how critical shipping docs is
16:41:57 <decathorpe> it's not really mentioned right now I think
16:42:10 <Son_Goku> hot take: docs subpackages are important, especially when behavior gets patched
16:42:22 <decathorpe> just "if building docs pulls in many dependencies, docs can be built from a separate source package"
16:42:32 <decathorpe> Son_Goku: that's true
16:42:44 <Son_Goku> I've been burned in the past over stuff like this, and it really sucks having no reference
16:42:54 <carlwgeorge> README.fedora for divergent behavior only, done
16:43:02 <Son_Goku> nobody reads those
16:43:11 <Son_Goku> they don't even know they exist, and the package manager doesn't tell you about them
16:43:26 <Son_Goku> we don't have a feature like urpmi that throws those to the user when they are detected in a transaction
16:43:31 <carlwgeorge> more people read those than docs that may or may not be patched for behavior differences
16:44:04 <carlwgeorge> honestly having docs that don't indicate if they're different from upstream is a problem itself
16:44:04 <geppetto> #chair Son_Goku
16:44:04 <zodbot> Current chairs: Son_Goku carlwgeorge decathorpe geppetto tibbs
16:44:47 <geppetto> Son_Goku: Way more likely to read a README.fedora etc. than diff the docs vs. upstream, or read them all again to see if anything is different.
16:45:00 <carlwgeorge> exactly
16:45:27 <Son_Goku> the problem is when things like man pages get cut because "building docs is hard"
16:46:15 <carlwgeorge> man pages are a different thing, and I believe are covered by the guidelines already with a should
16:46:40 <carlwgeorge> i.e. SHOULD ship man pages for commands
16:46:47 <decathorpe> yeah, man pages are often genuinely useful and not that hard to build (usually one CLI call), and they don't bundle fonts or JavaScript :D
16:47:05 <Son_Goku> I care less about web docs unless they're graphical applications
16:47:13 <Son_Goku> because graphical applications often load those as their help system
16:48:34 <carlwgeorge> I'd be happy with SHOULD for man pages, MAY for anything else
16:49:23 <carlwgeorge> I had a review held up recently because I didn't include a useless README.md file as a %doc
16:49:54 <Son_Goku> well that's dumb obviously
16:50:03 <decathorpe> 🤡
16:50:11 <Son_Goku> but manual and manual equivalents for applications should be expected to be build
16:50:14 <Son_Goku> *built even
16:50:27 <michel-slm> except on EPEL if the manpage is generated with pandoc :P
16:50:52 * michel-slm wonders if we should actually just try and get pandoc in EPEL9
16:51:34 <Son_Goku> yes
16:51:52 <Son_Goku> I think Jens was working on it
16:52:03 <michel-slm> nice
16:52:06 <carlwgeorge> I'm fine with pre-generating the man pages on fedora and then bundling them for epel
16:52:26 <michel-slm> that's .. not going to be fun to maintain
16:53:06 <carlwgeorge> it's not bad if the EPEL packages are maintained at a RHEL-like pace like they should be
16:53:17 <geppetto> haha
16:53:43 <Son_Goku> yeeeeaaaah
16:53:47 <Son_Goku> no
16:53:50 <Son_Goku> :)
16:54:16 * michel-slm cries in ELN ;)
16:54:43 <carlwgeorge> that feels like a segue to a bundled provides conversation I don't have the energy for right now
16:54:46 <geppetto> ELN would build them normally, I'd assume
16:55:17 <michel-slm> geppetto: right, but using ELN to prep for stream / epel would be less useful if they diverge on building docs
16:55:25 <geppetto> Seems good … I'm going to close and we can all contemplate what we've said ;)
16:55:50 <decathorpe> sounds good to me
16:55:58 <geppetto> #endmeeting