18:03:03 <felixfontein> #startmeeting Ansible Community Meeting
18:03:03 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/645
18:03:03 <felixfontein> acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping!
18:03:03 <zodbot> Meeting started Wed Jun 22 18:03:03 2022 UTC.
18:03:03 <zodbot> This meeting is logged and archived in a public location.
18:03:03 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:03:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:03:03 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:03:08 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics
18:03:09 <andersson007_> o/
18:03:11 <felixfontein> #topic Updates
18:03:13 <felixfontein> almost missd the time while I started eating :D
18:03:15 <felixfontein> #chair andersson007_
18:03:15 <zodbot> Current chairs: andersson007_ felixfontein
18:03:21 <briantist> o/
18:03:22 <andersson007_> heh
18:03:40 <samccann> o/
18:03:46 <felixfontein> I just made it home (on bike) with food before the thunderstorm hit and it started raining like crazy
18:03:52 <felixfontein> #chair briantist samccann
18:03:52 <zodbot> Current chairs: andersson007_ briantist felixfontein samccann
18:04:05 <samccann> now that's motivation to peddle faster!
18:04:21 <andersson007_> i envy you in terms of weather
18:04:44 <felixfontein> samccann: haha it is, I'm glad I have a little motor that helps ;)
18:04:46 <mariolenz[m]> o/
18:04:49 <felixfontein> #chair mariolenz[m]
18:04:49 <zodbot> Current chairs: andersson007_ briantist felixfontein mariolenz[m] samccann
18:04:59 <andersson007_> a downpour would help
18:05:22 <felixfontein> andersson007_: since yesterday evening it got better, though it's only now that it seems to really cool down properly. at least I hope so :)
18:05:40 <andersson007_> that's cool:)
18:06:00 <felixfontein> literally ;)
18:06:05 <andersson007_> yep:)
18:06:32 <cybette> o/ sorry for my tardiness!
18:06:52 <felixfontein> #chair cybette
18:06:52 <zodbot> Current chairs: andersson007_ briantist cybette felixfontein mariolenz[m] samccann
18:06:58 <felixfontein> #info Ansible 6.0.0 has been released!
18:07:27 <cybette> 🎉 🎉
18:07:38 <andersson007_> 🎉
18:07:59 <andersson007_> thanks for your folks hard work!
18:08:05 <felixfontein> unfortunately, there's a problem with community.general and community.network and ansible-core 2.13 (and before): ansible-doc -l does not find the modules anymore since the symlinks are gone
18:08:08 <andersson007_> and the new unility
18:08:12 <felixfontein> (it doesn't use the routing info in meta/runtime.yml)
18:08:55 <cybette> #info ansible-core 2.13.1 and ansible-core 2.12.7 have been released
18:10:46 <felixfontein> samccann: I wonder whether we should start building the docsite already when the first RC comes out (or even before), just without making 'latest' point to it, so we can look at it in advance
18:11:08 <felixfontein> though I guess this unique situation won't happen again, so it would have mostly made sense for 6.0.0 and not for later releases :)
18:11:44 <samccann> felixfontein: yep I plan on adding that to the release checklist!
18:12:46 <samccann> added it - https://github.com/ansible/ansible/issues/77575
18:13:03 <samccann> (basically I copy that issue for each release so I added staging the docs)
18:14:02 <samccann> but I think it's worthwhile to have a staging time so people besides me can look and poke around on test to see if they uncover problems
18:14:19 <felixfontein> unrelated to this, we have two new interesting discussion topics (my opinion :) ) currently open:
18:14:29 <felixfontein> 1. https://github.com/ansible-community/community-topics/issues/112 Add SPDX-License-Identifier, and use LICENSES/ directory layout in collections and ansible-core?
18:14:32 <samccann> There's a few missing modules from new collections as well (likely malformed docs in the collection) that we could catch if we had a formal stage/verify step
18:14:37 <felixfontein> 2. https://github.com/ansible-community/community-topics/issues/113 Changelog: New collection versions against last GA or against latest version?
18:14:46 <felixfontein> is there interest in discussing one or two of these here?
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:02 <felixfontein> samccann: indeed. though that could have already been caught on devel
18:15:18 <gotmax[m]> I'm here if you want to discuss #1 :)
18:15:21 <samccann> I'm useless on licensing, but happy to think Deep Thoughts about the changelong
18:16:14 <felixfontein> #chair gotmax[m]
18:16:14 <zodbot> Current chairs: andersson007_ briantist cybette felixfontein gotmax[m] mariolenz[m] samccann
18:16:14 <gotmax[m]> For #2, I think it would make most sense to compare against the latest version, but I admittedly haven't read the issue closely
18:16:47 <felixfontein> for #2 one question would be "what is the 'latest' version?"
18:17:19 <felixfontein> which is a bit trickier than you might think :)
18:17:34 <samccann> Yes, looking at you Ansible 5.10
18:18:06 <felixfontein> but that wasn't released when 6.0.0a1 got released
18:18:12 <felixfontein> and that's where the 6.0.0 changelog starts
18:19:00 <samccann> ok so today, the 6.0.0 changelogs reflect changes since Ansible 5.x (where X is whatever version was around when 6.0.0.a1 was created?)
18:19:01 <felixfontein> besides that 5.10.0 is supposed to be released these days, but so far only 5.9.0 is out in the 5.x.y series
18:19:05 <samccann> cuz that's even more confusing.
18:19:12 <felixfontein> samccann: no, it reflects changes since 5.0.0
18:19:16 <mariolenz[m]> 5.10 isn't released yet, so I would say the latest release is 5.9.
18:19:35 <samccann> ok so today, changelogs are major release to major release (5.0.0 to 6.0.0)
18:19:38 <mariolenz[m]> 5.9.0
18:19:56 <felixfontein> mariolenz[m]: but 5.9.0 wasn't out when 6.0.0a1 got released :)
18:19:56 <samccann> And the question is - should it be to the most current release (aka 5.9.0), yes?
18:20:17 <felixfontein> that would require changing the way the changelog works for all prereleases
18:20:45 <felixfontein> and then there's the porting guide
18:20:52 <felixfontein> it would also start with 5.9.0 then
18:21:12 <felixfontein> which means that if you want to upgrade from 4.x to 6.0.0, you need to read not only the 5.0.0 and 6.0.0 porting guides, but also all inbetween
18:21:15 <samccann> ok so porting guide for 6.0.0 shows all entries since 5.0.0?
18:21:29 <felixfontein> the porting guide is basically a subset of the changelog
18:22:18 <felixfontein> one could obviously do porting guide and changelog differently, but that might also be confusing
18:23:57 <samccann> so today, the worst effect is we give readers too much info, right?
18:24:18 <samccann> like if they were updating dot releases for 5.x they'd already have seen some of these items.
18:24:41 <andersson007_> it especially feels like an overkill for users that update the package regularly
18:24:48 <felixfontein> it would be interesting to know why the changelog is at it is now, because the system we have now has been in place for quite a long time (also long before the collection split)
18:25:01 <andersson007_> samccann: was a bit faster
18:25:47 <samccann> Well we also have to consider - do we know how many people update regularly per dot release vs how many are going from 4 to 5 to 6 only on the major release for example?
18:26:03 <mariolenz[m]> felixfontein: That's correct. But for a user, it might be more important to see what changed from the last 5.x version that has been released to 6.0.0. Anyway, it was just an idea. If this would introduce too many problems and make things complicated, we can close this if that's OK for you.
18:27:21 <felixfontein> samccann: that's a very good question. Debian users usually jump multiple major versions at once, for example, if they don't install Ansible manually
18:27:54 <samccann> yeah I'm asking some docs folks what they do as well.
18:28:03 <samccann> for other products.
18:28:33 <mariolenz[m]> <felixfontein> "mariolenz: but 5.9.0 wasn't..." <- I think for the normal users, it's pretty unimportant when 6.0.0a1 was released. For them, it's important when 6.0.0 was released.
18:28:34 <felixfontein> mariolenz[m]: I'm not saying we shouldn't do it because it's harder to implement. I'm only trying to figure out how to do it properly (because it seems everyone ignores the prerelease problem), and I'm wondering why the old system is actually in place - I'm sure there have been arguments for it back then that might be useful to know
18:28:37 <bcoca> its mostly due to the packaging, debian is conservative on their selection, by the time the roll out new distro, we have jumped several versions
18:29:19 <felixfontein> mariolenz[m]: I don't mind changing that, but then someone has to come up with a way to adjust the current changelog creation process. because that change doesn't come for free.
18:29:28 <samccann> but does debian for example, have their own changelogs etc or do they just point to ours?
18:29:47 <samccann> aka what other packages might be depending on the way we do porting guide/changelogs now?
18:30:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:07 <felixfontein> samccann: I think they have changelogs in general, but I never looked at them (except in a few very special cases), I usually look at the upstream changelogs if I need to look somewhere
18:31:08 <mariolenz[m]> This doesn't sound like we will solve this today. An idea: Should I put this on Bullhorn? Maybe we get some input what other people think.
18:31:09 <bcoca> samccann: mostly they use upstream, but depends on the packager
18:31:36 <bcoca> they can have additional entries for package issues
18:32:05 <felixfontein> since the Ansible changelog is pretty extensive, I'm not sure whether they would use it
18:32:08 <bcoca> but they aslo have separate 'package versioning'/numbering
18:32:42 <gotmax[m]> At least for our changelogs In Fedora, we only include something like `Update to version x.x.x. Closes bug#xxxx`.
18:33:15 <bcoca> every distro has their own rules
18:33:20 <bcoca> most of them make sense
18:33:31 <felixfontein> gotmax[m]: I think that's a very good idea, otherwise you're basically paraphrasing potentially a lot of things (and have to adjust them to your changelog's style)
18:33:50 <bcoca> apt-changelog is a thing ...
18:34:05 <gotmax[m]> Exactly. It's actually explicitly forbidden to do that, but it is allowed to link to upstream's changelog.
18:35:17 <gotmax[m]> It looks like Debian does changelogs similarly to the way that Fedora does: https://salsa.debian.org/debian/ansible/-/blob/master/debian/changelog
18:35:47 <gotmax[m]> In that it's focused on packaging changes, not upstream changes
18:36:34 <bcoca> + cve
18:37:23 <samccann> ok attempting to think out loud a bit on this
18:37:41 <bcoca> they also seem to reference bugs open against debian
18:37:51 <samccann> So 6.0.0 - if we changed it to reflect 'the changes since the last 5.x release)  - it would show changes since 5.9.x
18:38:18 <samccann> but 6.1.x - would show what? changes since 6.0.0? or since 5.10.x?
18:38:45 <mariolenz[m]> changes since 6.0.0 i should say
18:38:55 <gotmax[m]> Yes, we also mention CVEs
18:38:57 <samccann> aka because the prior release doesn't stop until AFTER the new release, it makes it less obvious what the user is reading
18:40:13 <samccann> also, do we expect the user to update to 5.9 before going to 6.0?
18:41:02 <gotmax[m]> I don't think so?
18:41:08 <felixfontein> I would also say no
18:41:38 <samccann> then the user could be 5.anything going to 6.0.  In which case, the current approach makes sense to me
18:42:10 <felixfontein> also, one aspect that we ignored so far, is the ansible-core changelog that's included in the Ansible changelog
18:42:13 <samccann> of course I don't actually use them, so your mileage may vary :-)
18:42:56 <felixfontein> so if the 6.0 changelog extends the 5.9 changelog, the ansible-core part of it would go from 2.12.6 to 2.13.0
18:43:31 <felixfontein> but for ansible-core we only have a 2.12.0 -> 2.13.0 changelog, and a 2.12.0 -> 2.12.1 -> 2.12.2 -> ... -> 2.12.6 changelog
18:43:42 <felixfontein> so what do we show for ansible-core for the 2.12.6 -> 2.13.0 jump?
18:44:26 <felixfontein> if we pick the 2.12.0 -> 2.13.0 changelog, it will repeat a lot of entries that already ended up in the 5.1, 5.2, 5.3, ..., 5.9 changelogs
18:44:36 <gotmax[m]> I guess. How complicated would that be to handle?
18:44:49 <felixfontein> depends how you want to handle it :)
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:05 <felixfontein> if you don't mind the same entry showing up multiple times, it's easy to handle (i.e. do nothing)
18:45:45 <felixfontein> this can BTW already happen today if a collection has a non-linear changelog for a major release
18:45:54 <gotmax[m]> Yeah, I meant handling picking out only the jump
18:45:54 <felixfontein> (I hope none does)
18:46:38 <gotmax[m]> Shouldn't that not happen if they are using antsibull-changelog?
18:47:58 <felixfontein> it depends on how they use it
18:48:02 <felixfontein> it's a flexible tool
18:48:25 <felixfontein> if they use it in a sane way, it shouldn't happen
18:48:58 <felixfontein> the community.general and community.network changelogs use a similar mechanism as the Ansible and ansible-core changelog btw
18:49:48 <felixfontein> so these should probably also change how they work. though also there it won't work, because the cut-off date for new collection major releases is several weeks before the new major Ansible version release day
18:50:23 <samccann> felixfontein: so for Ansible 6.0.0 changelog, what part(s) of the core changelog are included? Just the ones from 2.12.(latest) to 2.13.0?
18:51:46 <felixfontein> like Ansible 5.9.0 got released with community.general 4.8.2, and Ansible 6.0.0 with community.general 5.0.2, while community.general 5.0.0 was released at the same time as community.general 4.8.1
18:52:05 <felixfontein> samccann: same as for every other component: all changes from 2.12.0 to 2.13.0
18:52:50 <felixfontein> also Ansible 6.0.0 can have older collection versions included than Ansible 5.9.0
18:53:18 <samccann> wow this is confusing lol!!
18:53:39 <gotmax[m]> felixfontein: That would happen if ansible 6.0.0 doesn't contain a major version bump
18:53:45 <gotmax[m]> ?
18:53:55 <felixfontein> 6.0.0 has community.dns 2.1.1, while 5.9.0 has community.dns 2.2.0
18:54:28 <felixfontein> gotmax[m]: yes, it can happen in that case, when a collection hsa a new minor release after feature freeze
18:55:11 <felixfontein> (see community.dns)
18:55:22 <gotmax[m]> It's starting to sound to me like it might be better to leave good enough alone
18:55:40 <gotmax[m]> Also, it probably makes sense to try and align with the way core does changelogs
18:55:54 <felixfontein> gotmax[m]: we already do that ;)
18:56:08 <gotmax[m]> I mean to continue doing that
18:56:47 <felixfontein> one way to go around the above problem is to stretch the time between the previous and the 'latest' 5.x.0 release, so that the feature freeze cycle of 6.0.0 falls into that delay
18:56:48 <gotmax[m]> felixfontein: Yeah, that makes sense. That happens sometimes in Fedora during our feature freezes as well :)
18:56:55 <mariolenz[m]> felixfontein: Just to clarify this: this should only happen for bugfix releases, shouldn't it? Ansible 6 shouldn't have a collection in version 1.2.3 while Ansible 5 has collection version 2.0.0. But it might happen that 6 includes 1.2.3 while 5.9 is already on 1.2.4, right?
18:57:15 <felixfontein> mariolenz[m]: it also works for minor releases, see the community.dns example above
18:58:13 <gotmax[m]> Re: schedules, I think we should try and align our GA ansible-core, but that's a separate discussion...
18:58:41 <mariolenz[m]> you're right, could also happen for minor releases.
18:58:49 <felixfontein> gotmax[m]: I'm not sure whether it should be aligned, to give us a bit of time to get rid of problems if something unexpected shows up, but I would prefer if they would be less far away from each other
18:59:37 <felixfontein> or three weeks would also be ok, since ansible-core has a four week release cycle
19:00:01 <gotmax[m]> Yeah, I guess. The month delay a little long and it prevented users (and distributions) from updating to a newer ansiblecore.
19:00:08 <gotmax[m]> s/ansiblecore/ansible-core/
19:00:21 <gotmax[m]> * Yeah, I guess. The month delay was a little long and it prevented users (and distributions) from updating to a newer ansible-core.
19:00:36 <felixfontein> maybe have ansible X.0.0 beta1 on the same day as ansible-core GA, have rc1 one week after that, a potential rc2 one week after rc1, and Ansible X.0.0 GA two weeks after rc1 and thus three weeks after B1, and one week before the first patch release of ansible-core
19:01:14 <gotmax[m]> So that's a week earlier than it was this time?
19:01:39 <cybette> ansible-core 2.13.0 release was also moved up one week this time
19:02:24 <felixfontein> gotmax[m]: I think multiple weeks, right now we had 5 weeks between B1 and GA. and ansible-core GA was one week too early, so it ended up being 6 weeks beween ansible-core GA and ansible GA
19:02:51 <felixfontein> ah wait. I misread
19:03:02 <felixfontein> ansible-core GA coincided with ansible A3
19:03:10 <felixfontein> so the six weeks were planned
19:04:07 <felixfontein> no, wait, the roadmap got modified because ansible-core GA got moved one week earlier, so we planned 5 weeks and got 6 weeks in the end
19:04:11 <felixfontein> (https://github.com/ansible/ansible/commit/235f2598b1b3f5dd3576e7d9fac0938013ae0612)
19:04:18 <felixfontein> sorry :)
19:04:38 <felixfontein> but yeah, I think halving that 6 weeks to 3 would be good, and probably quite sufficient
19:04:59 <felixfontein> anyway, time's up
19:05:05 <felixfontein> thanks everyone for the discussions!
19:05:06 <cybette> I think we planned 4 weeks and got 5 weeks, but down to 3 would be good
19:05:17 <gotmax[m]> I agree
19:05:31 <gotmax[m]> Thanks everyone
19:05:36 <cybette> thanks all!
19:05:46 <felixfontein> is anyone volunteering to write a schedule for 7.0.0? :)
19:05:50 <felixfontein> #endmeeting