15:01:01 <acozine> #startmeeting Documentation Working Group aka DaWGs
15:01:01 <zodbot> Meeting started Tue Jun 22 15:01:01 2021 UTC.
15:01:01 <zodbot> This meeting is logged and archived in a public location.
15:01:01 <zodbot> The chair is acozine. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:01 <zodbot> The meeting name has been set to 'documentation_working_group_aka_dawgs'
15:01:07 <acozine> #topic opening chatter
15:01:09 <acozine> who's around?
15:01:13 <lmodemal> o/ Hey everyone!
15:01:36 <tadeboro> o/
15:01:39 <samccann> o/
15:01:40 <acozine> hey lmodemal!
15:01:47 <acozine> #chair lmodemal tadeboro samccann
15:01:47 <zodbot> Current chairs: acozine lmodemal samccann tadeboro
15:02:32 <acozine> abadger1999: bcoca dmsimard gundalow aminvakil baptistemm briantist cyberpear felixfontein jillr Xaroth zbr you folks talking docs today?
15:02:42 <briantist> sure
15:02:45 <acozine> agenda begins with https://github.com/ansible/community/issues/579#issuecomment-861720413
15:02:48 <acozine> #chair briantist
15:02:48 <zodbot> Current chairs: acozine briantist lmodemal samccann tadeboro
15:03:30 <abadger1999> Good morning
15:03:38 <acozine> bom dia abadger1999
15:03:41 <acozine> #chair abadger1999
15:03:41 <zodbot> Current chairs: abadger1999 acozine briantist lmodemal samccann tadeboro
15:05:34 <acozine> did anyone mark the Summer Solstice this year?
15:05:52 <acozine> it always makes me a little sad, knowing that the days are starting to get shorter
15:06:04 <samccann> ssshhhh!!!
15:06:07 <acozine> heh
15:06:14 <lmodemal> :(
15:06:56 <acozine> I was in Finland on the solstice one year, several years back
15:07:15 <acozine> and people were driving around with tree branches on the front of their cars
15:07:36 <acozine> I wonder where they put the branches, back before cars
15:07:43 <felixfontein> hi!
15:07:49 <acozine> hi felixfontein
15:07:52 <acozine> #chair felixfontein
15:07:52 <zodbot> Current chairs: abadger1999 acozine briantist felixfontein lmodemal samccann tadeboro
15:08:43 <abadger1999> Coming from a hot climate, I'm somewhat relieved when the solstice comes around (although i know the hottest days are still in front of me ;-)
15:09:05 <acozine> abadger1999: yeah, I could see that
15:09:32 <abadger1999> felixfontein: is the antsibull pr in the agenda  for semantic markup correct?  It seems to mainly be about documenting roles
15:09:56 <samccann> heh figures. I tried to grab the right ones but must have missed that
15:10:14 <felixfontein> abadger1999: it is, see "(For now contains #272 so I have less chaos locally :) )" :)
15:10:52 <felixfontein> abadger1999: it's basically the last commit which is specific to that PR
15:10:59 <acozine> heh, that's a good goal
15:11:04 <acozine> #topic semantic markup
15:11:11 <abadger1999> Okay, so just the last commit is what i should be looking at?
15:11:17 <abadger1999> Xool
15:11:35 <abadger1999> (Sorry, latency in my reading and typoing this morning :-)
15:12:05 <felixfontein> abadger1999: if you're interested in semantic markup, then yes :)
15:12:19 <acozine> #info summary issue: https://github.com/ansible/ansible/issues/75054
15:12:58 <felixfontein> I was assuming/hoping that the roles PR would have been merged before we really start discussing the semantic markup PR :)
15:13:01 <acozine> the summary issue contains links to the current PRs and to the original conversation back in December/January
15:13:33 <samccann> cool thanks for that
15:13:59 <samccann> felixfontein - should we take a look at the roles PR after this?
15:14:26 <felixfontein> samccann: sure, sounds good :)
15:15:17 <acozine> I think we have two decisions to make before we merge any code
15:15:19 <samccann> meanwhile today -are we trying to agree on the output format?
15:15:25 <felixfontein> (there's also the devel docs PR; the other PRs are not strictly docs-related, resp probably don't need discussing here)
15:16:39 <acozine> the first decision is: What are the macros called and what do they format? For example, do we have `O(option_name)` or `P(parameter)` and/or `V(value)`?
15:17:21 <felixfontein> that's basically acozine's ansible/ansible PR, I think
15:17:22 <acozine> felixfontein: what macros does your current PR implement?
15:17:34 <felixfontein> https://github.com/ansible/ansible/pull/73137
15:17:39 <felixfontein> acozine: I'm implementing the macros from your PR
15:18:23 <acozine> cool
15:18:40 <felixfontein> that is, O(k) for option names, O(k=v) for option key/values, V(v) for option values, E(env) for env variables, and P(community.general.foo#lookup) for plugin references
15:19:01 <felixfontein> though P() isn't in your PR, that's something we discussed a couple of weeks ago
15:19:08 <acozine> awesome
15:19:31 <samccann> #info the proposed semantic markup is O(k) for option names, O(k=v) for option key/values, V(v) for option values, E(env) for env variables, and P(community.general.foo#lookup) for plugin references
15:20:17 <acozine> so those obviously made sense to me, since I wrote the proposal . . . are there others we should add? does anybody see problems with the suggested ones, or have alternative ideas?
15:21:07 <acozine> I like the `P(FQCN)` syntax
15:21:49 <samccann> And we are removing C()?
15:21:52 <felixfontein> I think we already discussed them back then before you wrote the proposal (that is, all except P(), since we only talked about this a couple of weeks ago); we didn't vote though IIRC, we wanted to wait for the proposal
15:21:58 <felixfontein> samccann: C() etc. will stay
15:22:08 <abadger1999> I'm good with the proposed formats. Gave we let Galaxy and core (and maybe navigator) know that we're discussing these?
15:22:11 <felixfontein> samccann: C() is for other code/teletype usage
15:22:20 <acozine> those are python ones, aren;t they>
15:22:24 <acozine> ?
15:22:40 <abadger1999> (core should see the pr but it's nice to ping them directly)
15:22:54 <abadger1999> *have we let
15:23:18 <acozine> good idea abadger1999, I have not asked for feedback directly from core or galaxy folks
15:23:22 <felixfontein> acozine: it's ansible, not python :)
15:23:59 <felixfontein> bcoca definitely did saw the propsal PR since he commented on it. though that was in february, so no idea how much he remembers :)
15:24:13 <acozine> even the `I(italic_text)` and `B(bold_text)` ones?
15:24:29 <tadeboro> I already said that semantic markup is something I really like.
15:24:30 <felixfontein> acozine: it's all ansible specific
15:24:34 <samccann> #action acozine to followup with core, navigator? and galaxy on the proposed new markup options
15:24:37 <acozine> huh, TIL
15:25:26 <acozine> well, I see no harm in leaving them, especially since some docs already use them
15:25:56 <acozine> it will take a while to update everything to this new system, and if we can avoid breaking things in the meantime, that would be good
15:26:31 <tadeboro> I would also say we keep the non-semantic formatting becasue sometimes you just want to emphasize something without that things having any special meaning.
15:26:47 <felixfontein> yep, exactly
15:26:59 <felixfontein> also it will take a long time until all collections have converted their docs
15:27:03 <acozine> tadeboro: like **SERIOUSLY DON'T DO THIS**?
15:27:09 <felixfontein> yes :)
15:27:24 <felixfontein> B(THIS WILL DELETE ALL YOUR DATA!)
15:27:30 <acozine> heh
15:28:01 <acozine> heh, `P(clean_slate_or_possibly_bankruptcy_you_decide)`
15:28:32 <samccann> so should we vote on the proposed markup options to make it 'official'?
15:28:33 <felixfontein> that won't work ;)
15:28:44 <acozine> nope, not an FQCN
15:28:47 <acozine> samccann: sure!
15:28:54 <felixfontein> and no #<plugin_type> part :)
15:28:58 <felixfontein> sounds good to me
15:30:05 <acozine> VOTE: semantic markup macros: O(k) for option names, O(k=v) for option key/values, V(v) for option values, E(env) for env variables, and P(FQCN) for plugin references; existing markup macros will remain
15:30:07 <acozine> #chair
15:30:08 <zodbot> Current chairs: abadger1999 acozine briantist felixfontein lmodemal samccann tadeboro
15:30:15 <acozine> +1
15:30:25 <felixfontein> +1
15:30:27 <tadeboro> +1
15:30:28 <samccann> +1
15:30:31 <briantist> +1
15:30:37 <felixfontein> wait, it's not P(FQCN), but P(FQCN#plugintype)
15:30:49 <acozine> ahhh
15:30:57 <lmodemal> +
15:31:10 <lmodemal> +1
15:31:31 <acozine> #info correction to the vote above: semantic markup macros: O(k) for option names, O(k=v) for option key/values, V(v) for option values, E(env) for env variables, and P(FQCN#plugintype) for plugin references; existing markup macros will remain
15:31:38 <tadeboro> I was just about to ask why are we using P() for names ;)
15:31:42 <abadger1999> +1 provided that galaxy and core also sign off on them too.
15:32:31 <acozine> yeah, once we're agreed here, we can take this ansible-wide; if we get any requests for changes, we can address those over the next few weeks
15:32:45 <acozine> it's easier to give feedback on a specific implementation
15:33:07 <briantist> +1 (still,  not sure if we were meant to repeat our vote after correction)
15:33:25 <acozine> sorry, no need to vote again unless you've changed your mind
15:33:43 * acozine realizes this is probably not Robert's Rules of Order, but . . .
15:33:57 <samccann> heh
15:34:14 <acozine> the motion passes!
15:34:18 <samccann> #agreed semantic markup macros: O(k) for option names, O(k=v) for option key/values, V(v) for option values, E(env) for env variables, and P(FQCN#plugintype) for plugin references; existing markup macros will remain
15:34:56 <acozine> okay, the next decision is: what is the desired formatting/output for each macro? (should options be displayed in italics, in bold, in code, and so on)
15:35:17 <acozine> bear in mind that the whole point of semantic markup is that we can change the formatting/output in future without updating hte docs
15:35:24 <acozine> so whatever we decide today can be changed
15:35:38 <samccann> the rendering options are all as follows:
15:36:31 <briantist> disregarding any kind of transition period where semantic might match existing conventions, I'll just say I dislike italics for option rendering. If `I(option[=value])` weren't the existing convention, I'd use `C()` for them, personally :-/
15:36:32 <samccann> 1. I(option=value) https://dmsimard.com/files/docsite/1/collections/ansible/builtin/lineinfile_module.html
15:36:32 <samccann> 2. C(option=value) https://dmsimard.com/files/docsite/2/collections/ansible/builtin/lineinfile_module.html
15:36:32 <samccann> 3. I(option)=C(value) https://dmsimard.com/files/docsite/3/collections/ansible/builtin/lineinfile_module.html
15:36:32 <samccann> 4. I(option=)C(value) https://dmsimard.com/files/docsite/4/collections/ansible/builtin/lineinfile_module.html
15:36:32 <samccann> 5. B(option)=C(value) https://dmsimard.com/files/docsite/5/collections/ansible/builtin/lineinfile_module.html
15:37:05 <tadeboro> IIRC, we said that we will (at least initially) use the same format Red Hat already uses in other docs?
15:37:11 <samccann> (ignore I/C/B as this was done before we decided on O() P() etc)
15:37:41 <felixfontein> the I/C/B here is important because it's not semantic, and thus we already know what it means ;)
15:37:46 <briantist> I only mentioned it to relate the visual result of whatever the semantic option will produce
15:37:46 <samccann> #IBM Style Guide (what RH uses) suggests #2 in the preferred approach (monospace for it all)
15:38:08 <briantist> nice, I like #2 best out of all those options
15:38:10 <acozine> briantist: I agree, I like `code` for the whole phrase
15:38:23 <abadger1999> FWIW, I like 2 as well
15:39:15 <samccann> +1 for #2
15:39:16 <acozine> the only downside is that it's so easy to copy/paste, and most of our examples are still `option=value`, but we encourage `option: value` now
15:39:36 <samccann> can you elaborate?
15:39:48 <felixfontein> somewhat related: how do we want to format O(k) an V(v)? I guess V(v) will be C(v), but will O(k) be C(k) (would be a change) or I(k) (would be what we have now)?
15:40:12 <samccann> let's vote on the `option=value` first
15:40:38 <samccann> then we can decide the others and have a complete set to go out for wider review
15:40:49 * acozine needs to investigate distant crashing noise, BRB
15:40:50 <briantist> right, not what we're voting on now, but a future change might be to use code formatting for (most of) the text on the semantic options, with different background colors (or other differentiators, if there's an accessibility WG they should be consulted)
15:40:50 <felixfontein> for me, the vote for O(k=v) depends on what O(k) will be :)
15:41:08 <samccann> heh
15:41:17 <tadeboro> I would say we render the whole thing in monospace and advise people to replace `=` with `: `.
15:41:37 <abadger1999> I agree with felixfontein's linking of the two.... I'd vote to use C(k) in the future.
15:42:04 <briantist> I tend to prefer monospace/"code" for almost if not all of these, O(k), O(k=v), E(), etc.
15:42:05 <felixfontein> tadeboro: with O(k=v), we can automatically render the `=` as `: `
15:42:22 <tadeboro> For O(k), I would say it maps to B(k), and V(v) maps to C(v).
15:42:30 <abadger1999> for `=` vs `:` we could render it as C(k: v)  rather than C(k=v).... I'm not sure if that's as legible, though.
15:42:45 <samccann> trying to quickly check IBM style guide here for reference.  Parameter names are highlighted as 'bold monospace'
15:42:45 <tadeboro> I think this is what we had to do with ManageIQ docs.
15:43:10 <felixfontein> so BC(k), which currently does not exist :)
15:43:18 <tadeboro> \o/ ;)
15:43:31 <briantist> bold monospace sounds nice.. and differentiates the `k` from the `v` (whether `=` or `:`)
15:43:35 <felixfontein> does that actually work with RST? or does one need to use more fancy RST features to achieve this?
15:44:02 <abadger1999> felixfontein: Heh.  It's a new feature to encourage people to use the semantic macros ;-)
15:44:07 <tadeboro> Maybe this is why ManageIQ uses asciidoc ...
15:44:11 <samccann> #info IBM style guide says parameter names are 'bold monospace' and values are 'monospace' but key-value pairs are monospace only.
15:44:17 <felixfontein> (doing *k*=`v` was already pretty much fun ;) )
15:44:22 * abadger1999 checks whether there is a way to do that with rst...
15:44:57 <felixfontein> abadger1999: I'm sure there is, the main question is how complicated it will be
15:44:58 <acozine> yeah, it's easier to understand the overall meaning of "Only effective when `immediate=yes`" than "Only effective when `immediate: yes`", but if you copy/paste that into a playbook it won't work
15:46:52 <acozine> my instinct is to do everything in `code` and force uppercase for `ENV_VARS`
15:47:21 <briantist> maybe I should sit this out as I don't know of any user/community feedback, but I feel like copy/pasting out of the text descriptions where this is relevant is an unlikely use case (as opposed to examples), and so I kind of feel like people could use whichever format (= or :) best fits the specific situation
15:47:38 <acozine> that's a good point briantist
15:47:39 <felixfontein> abadger1999: with roles it should be easy to do (https://doughellmann.com/posts/defining-custom-roles-in-sphinx/), and since we already have an antsibull sphinx extension... :)
15:48:03 <briantist> in short: I'd prioritize readability over copy-ability
15:48:12 <felixfontein> i.e. O(k=v) and O(k: v) should both work?
15:48:16 <abadger1999> felixfontein: <nod> Yeah
15:48:19 <briantist> yeah, imo
15:48:20 <samccann> cyb-clock-clone wakes up and realizes we are 48 minutes into the meeting and into this topic
15:48:27 <acozine> heh
15:48:50 <samccann> what decision(s) can we make in the next 10 min?
15:48:57 <acozine> is there enough of a consensus to vote on?
15:49:20 <felixfontein> how about: 1) allow O(k:v) next to O(k=v)
15:49:42 <felixfontein> and 2) render O(k), O(k=v), O(k:v), V(v), E(v) all as teletype (i.e. like C())
15:49:44 <acozine> +1, just let whatever the documentation itself does come through in the output
15:50:16 <tadeboro> I would say that we follow the IBM style guide if at all possible. That is battle-tested stuff.
15:50:21 <acozine> heh, true
15:50:26 <felixfontein> or 2b) render O(k), O(k=v), O(k:v), V(v), E(v) all as teletype, and additionally render k bold
15:50:27 <samccann> fwiw, because I have the beast open here - IBM sez `key=value`
15:50:28 <lmodemal> I agree with tadeboro
15:51:10 <abadger1999> felixfontein: Will O(k:v) render as C(k=v) ?
15:51:20 <felixfontein> abadger1999: that's also to be defined :)
15:51:23 <acozine> samccann: so when does IBM Style Guide suggestion bold teletype?
15:51:26 <abadger1999> Heh :-)
15:51:31 <acozine> s/suggestion/suggest
15:51:41 <samccann> sorry I should say it has key value pairs as key=value, not with a colon
15:51:45 <felixfontein> abadger1999: options are: O(k=v), O(k:v) (1) both render as `k: v`, (2) both render as `k=v`, (3) render as specified
15:51:46 <briantist> I've always felt `k=v` was a bit strange in Ansible docs, given it's rarely used that way in Ansible (but I agree it reads better in English sometimes)
15:51:51 <tadeboro> acozine: IIRC, only for O(k).
15:51:57 <briantist> but I'm not that opinionated on it
15:52:01 <samccann> otherwise yes, key=value should be bold monospace
15:53:01 <acozine> hm, but we only have three macros, right?
15:53:03 <felixfontein> samccann: should only the `key` part be bold monospace, or the whole `key=value` expression?
15:53:20 <samccann> felixfontein the whole thing is bold monospace
15:53:27 <samccann> sorry
15:53:33 <samccann> the whole thing is MONOSPACE
15:53:40 <felixfontein> ah :)
15:53:48 <felixfontein> and only `key` is also bold? or nothing?
15:53:50 <samccann> bold monospace is for parameters (aka options)
15:54:04 <samccann> no bold in `key=value` just monospace
15:54:12 <felixfontein> hmm, but `key` is an option :)
15:54:22 <samccann> but for readability, you keep it the same
15:54:25 <acozine> We have `O` for both `option` and `option=value`, so unless we add another macro, those have to have the same formatting
15:54:27 <felixfontein> then `key` would be rendered differently, depending on whether it appears standalone or as part of `key=value`?
15:54:36 <samccann> key by iteslfe is an option yes and will render as bold monospace
15:54:36 <felixfontein> acozine: they don't have to
15:54:52 <tadeboro> So: O(k) -> B(k), O(k=v) -> C(k=v), V(v) -> C(v), right?
15:54:53 <samccann> acozine I disagree
15:54:57 <felixfontein> acozine: there's code which processes the contents and decides how to render them
15:55:11 <acozine> okay
15:55:16 <felixfontein> tadeboro: with B(k), do you mean bold mono, or just bold?
15:55:18 <acozine> I'm not opposed
15:55:37 <tadeboro> B is bold mono as per IBM style guide.
15:55:43 <acozine> but a 1:1 of macro:format makes more sense to me
15:55:45 <felixfontein> tadeboro: B() is bold as per ansible :)
15:56:15 <samccann> cyb-clock-clone sez we have 4 minutes left
15:56:16 <tadeboro> I know, I forgot to add M there: so O(k) -> BM(k)
15:57:22 <samccann> fwiw IBM style guide for V() suggests it is also bold monospace (for environment variable names)
15:57:38 <felixfontein> samccann: E() is env variables, V() is option values
15:57:44 <samccann> woopsie
15:58:04 <samccann> E() is bold monospace according to IBM style guide
15:58:40 <samccann> with two minutes left, what do we do? do we need another week to digest the rendering for all these markup types?
15:58:47 <acozine> so, current proposal is `O(option)` formats as BOLD MONO when it contains the `key` only, and as MONO when it contains `key=value` or `key: value`; `V(.) formats as mono, `E(.)` formats as BOLD MONO; and `P(.)` formats as mono
15:58:53 <felixfontein> is the IBM style guide available online for free somewhere, or do one needs to buy it to be able to look into it?
15:59:13 <samccann> Do we need to know of RST supports a bold-mono? Because if the stuff in module docs (with all your fancy code) doesn't match the stuff in  the rst files, it's ... messy
15:59:17 <felixfontein> P() should not format as mono
15:59:30 <felixfontein> P() should be similar to M() and format as RST references format
15:59:37 <samccann> IBM style costs $$ yes
15:59:38 <acozine> aren't they currently mono?
15:59:47 <tadeboro> I have a hard-stop in two minutes. And I would go with "what IBM does". And P should end up as link in HTML, right?
15:59:56 <acozine> yes
15:59:58 <felixfontein> acozine: they're not
16:00:20 <acozine> shows how often I've looked at those docs recently :-(
16:00:26 <acozine> okay
16:00:42 <acozine> can we vote on `Follow IBM Style Guide as closely as rst allows"?
16:00:55 <lmodemal> +1
16:00:58 <felixfontein> see second paragraph of https://docs.ansible.com/ansible/latest/collections/community/general/etcd3_lookup.html#synopsis, it uses M()
16:01:18 <acozine> excellent, thanks felixfontein
16:01:31 <samccann> +1 for follow IBM where we can
16:01:49 <acozine> +1 for IBM where we can
16:01:56 <samccann> felixfontein so M() is replaced by P() going forward?
16:01:57 <felixfontein> I don't really like all decisions of the IBM style guide apparently, but still +1 to follow it to avoid endless bikeshedding ;)
16:02:04 <acozine> heh
16:02:18 <tadeboro> +1 for IBM if at all possible
16:02:18 <felixfontein> samccann: M() will stay, P() is a superset which allows to also reference other plugin types
16:02:41 <tadeboro> Thanks all. Read you some other time!
16:02:46 <acozine> okay
16:02:48 <felixfontein> bye tadeboro!
16:02:50 <tadeboro> #unchair tadeboro
16:02:50 <zodbot> Current chairs: abadger1999 acozine briantist felixfontein lmodemal samccann
16:02:52 <abadger1999> No opnion from me which I suppose is similar to felixfontein's +1.
16:02:54 <samccann> felixfontein I guess I'm asking - do we recommend NEW docs use P() instead of M() or doesn't matter?
16:03:02 <acozine> thanks and bye tadeboro
16:03:11 <lmodemal> bye tadeboro!
16:03:29 <felixfontein> samccann: for modules, I think using M() is fine, after all it's less typing. but that's my own opinion :)
16:03:56 <acozine> yeah, either one seems fine
16:04:06 <acozine> we're never going to replace all the M() references
16:04:15 <samccann> ok cool thanks
16:04:15 <felixfontein> yes, that too :)
16:04:47 <acozine> okay, that's two down, and we can move forward with getting input from galaxy and core on the proposal
16:04:50 <samccann> #agreed follow IBM style guide as much as we can with RST for these semantic markup options
16:05:10 <acozine> \o/
16:05:17 <acozine> #topic open floor
16:05:29 <acozine> all questions, comments, ideas, complaints, suggestions welcome
16:06:36 <felixfontein> #info rendering bold mono might require a custom RST role, which can be achieved by a Sphinx extension (which the antsibull sphinx extension happens to be)
16:06:45 <felixfontein> (just so I don't forget about it ;) )
16:06:58 <acozine> heh
16:07:15 <felixfontein> speaking on sphinx... is there a reason that using the sphinx ansible theme hasn't been backported to stable-2.11 yet?
16:07:18 <samccann> so we'd need another extension to cover the regular rst files?
16:07:22 <acozine> that's an awesome added bonus
16:07:41 <acozine> felixfontein: I think there's a PR but it got opened just as the stable branches went into lockdown
16:07:49 <acozine> I think I can merge it today
16:07:56 <samccann> felixfontein I feel like I have a PR review request in my inbox for that, but I think stable-2.11 is locked this week
16:07:59 <felixfontein> acozine: I created a backport https://github.com/ansible/ansible/pull/75058 since I couldn't find any other
16:08:17 <felixfontein> there just was a set of releases, so I guess it's no longer locked
16:08:27 <felixfontein> though I have no idea when exactly it is locked :)
16:08:36 <samccann> #action review and merge backport of ansible sphinx theme to 2.11 https://github.com/ansible/ansible/pull/75058
16:08:38 <acozine> I think it was locked all last week
16:08:59 <acozine> if anyone wants to chime in on https://github.com/ansible/ansible/pull/74956, please do
16:09:01 <samccann> 2.9 went out just this am. Not sure about 2.10/2.11
16:09:46 <samccann> acozine we should stage that PR since the ansible theme version got bumped up
16:09:58 <samccann> I can kickstart that now
16:10:11 <acozine> I think using `pip-tools` is more overhead than we need
16:10:14 <abadger1999> I was going to review felixfontein's PR for devel docs yesterday but had something unplanned come up.  I'll do it today.  From my preliminary look, I think it's fine to merge but I want to check some code organization.... probably I'll end up merging and then making any reorganizations in a followon PR.
16:10:51 <felixfontein> acozine: samccann: I would stick to the old version and bump the theme version in a separate PR. most importantly, I would **not** use `>=` for the theme version
16:11:16 <acozine> yikes, agreed
16:11:28 <acozine> "upgrade any time" is exactly the behavior we're trying to avoid
16:11:50 <samccann> I thought that was the point of the new requirements file tho - to not be fixed
16:12:02 <acozine> sigh, true
16:12:03 <samccann> we have the 'known good' file for fixing versions
16:12:23 <felixfontein> also the next versoin of the theme will probably break the docsite if https://github.com/ansible/ansible/pull/73170 hasn't been merged
16:13:12 <felixfontein> abadger1999: sounds good! can you maybe take a look at the smaller newer PRs first, because they should be very easy to merge? :)
16:13:49 <abadger1999> felixfontein: Sure, if you want to feed me the order to look at PRs, I'll review whatever you want today :-)
16:13:58 <acozine> wow, that PR is from January
16:14:17 <acozine> we're getting behind
16:14:43 <samccann> yaeh I feel like we need a hackmd or something with the list of all prs we need to merge and in what order
16:14:55 <felixfontein> abadger1999: 284, 283, 285 (in combination with https://github.com/ansible-community/ansible-build-data/pull/69)
16:14:57 <samccann> or maybe a github issue that links to them all and says what has to be don?
16:15:17 <felixfontein> acozine: to be fair, it was lying around a long time because I didn't got around to debug it :)
16:15:41 <acozine> ah, squashing bugs!
16:15:52 <abadger1999> felixfontein: Thanks
16:16:20 <samccann> so what do Alicia and I need to review/merge/test to move things along?
16:16:44 <acozine> I'm happy to open a GitHub issue to track the work if there's still stuff to be merged/debugged/coded after today
16:16:53 <abadger1999> #action abadger1999 to review and (hopefully) merge  antsibull PRs 284, 283,  285, and then 282 today.
16:17:27 <acozine> thanks!
16:17:34 <acozine> anything else for today's open floor?
16:17:58 <felixfontein> samccann: acozine: with a new version of antsibull (potentially today?), getting https://github.com/ansible/ansible/pull/75059 (with == 0.7.0 and not >= 0.7.0) merged would be good, as well as getting https://github.com/ansible/ansible/pull/74956 merged (probably first, so it doesn't collect more potential conflicts)
16:17:58 * acozine waits a few beats
16:18:07 <felixfontein> abadger1999: thanks! :)
16:18:19 <samccann> #action with a new version of antsibull (potentially today?), getting https://github.com/ansible/ansible/pull/75059 (with == 0.7.0 and not >= 0.7.0) merged would be good, as well as getting https://github.com/ansible/ansible/pull/74956 merged (probably first, so it doesn't collect more potential conflicts)
16:19:02 <acozine> sounds great
16:19:44 <acozine> okay, at one hour twenty . . . I think we're done for today
16:19:48 <acozine> good progress!
16:20:01 <acozine> thanks abadger1999 briantist felixfontein lmodemal samccann tadeboro (in absentia)
16:20:05 <acozine> #endmeeting