18:04:39 <felixfontein> #startmeeting Community Working Group
18:04:39 <zodbot> Meeting started Wed Jun 10 18:04:39 2020 UTC.
18:04:39 <zodbot> This meeting is logged and archived in a public location.
18:04:39 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:04:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:04:39 <zodbot> The meeting name has been set to 'community_working_group'
18:04:54 <felixfontein> welcome all to the weekly community working group meeting :)
18:05:45 <felixfontein> #topic versioning and releasing community.general and community.network
18:05:54 <felixfontein> I hope we finally manage to finish this today :)
18:06:16 <andersson007_> lets see:)
18:06:25 <abadger1999> Oooh, zodbots back :-)
18:06:55 <samccann> woot!
18:07:02 <felixfontein> the last week we decided that the collections should be released from release branches, we talked about backporting (bot), feature backports only for current active major version, bugfixes for the current and previous, and serious bugfixes and security fixes even one more
18:07:09 <felixfontein> (more details: https://github.com/ansible/community/issues/539#issuecomment-640034934)
18:07:21 <felixfontein> I've tried to compile a list of questions still open: https://github.com/ansible/community/issues/539#issuecomment-640040115
18:07:37 <samccann> mind if I follow along with some infos for the meeting minutes?
18:07:40 <felixfontein> yep, with zodbot meetings are much more fun ;)
18:07:40 <abadger1999> (Oh, looks like its only back in certain channels... I guess we can rearrange meetings if we need to, though.)
18:08:06 <felixfontein> indeed, it's missing in #ansible-docs
18:08:16 <felixfontein> samccann: sure, thanks!
18:08:46 <abadger1999> (I know why that probably is... I'll update #ansible-docs about that after the meeting)
18:08:49 <samccann> #info collections should be released from release branches see https://github.com/ansible/community/issues/539#issuecomment-640034934 for details
18:09:04 <samccann> #info open questions https://github.com/ansible/community/issues/539#issuecomment-640040115
18:09:21 <felixfontein> does anyone know if gundalow will be here today?
18:10:15 <samccann> I thought he was out most if not all of this week (dunno if out was out and having fun or out and stuck in meetings all week or something)
18:10:27 <felixfontein> ok
18:10:34 <felixfontein> I guess he'll say something when he's around :)
18:10:50 <felixfontein> so, should we start with the deprecation cycle?
18:11:04 <felixfontein> #topic deprecation cycle for community.general/community.network
18:11:05 <abadger1999> felixfontein: Could you #chair some people?
18:11:08 <felixfontein> oh
18:11:22 <abadger1999> (then samccann's info will work ;-)
18:11:25 <felixfontein> #chair bdodd samccann andersson007_ abadger1999 cyberpear
18:11:25 <zodbot> Current chairs: abadger1999 andersson007_ bdodd cyberpear felixfontein samccann
18:11:42 <abadger1999> Thanks :-)
18:11:44 <felixfontein> sorry, never started a meeting before I think :)
18:11:53 <abadger1999> #info collections should be released from release branches see https://github.com/ansible/community/issues/539#issuecomment-640034934 for details
18:11:57 <felixfontein> I was hoping someone else does it, but apparently no... ;)
18:11:59 <abadger1999> #info open questions https://github.com/ansible/community/issues/539#issuecomment-640040115
18:12:04 <felixfontein> thanks!
18:12:09 <andersson007_> how long does it take to deprecate something in ansible-base? ~2 years?
18:12:11 <samccann> :-)
18:12:30 <felixfontein> andersson007_: right now, 4 versions, which right now is ~2 years. but that might change.
18:12:33 <abadger1999> andersson007_: yeah, ansible-base has been steadily creeping up.
18:12:41 <andersson007_> thanks
18:12:43 <felixfontein> also, as far as I understood the deprecation cycle was shorter a longer time ago
18:13:12 <abadger1999> When we originally decided on 4 versions, we were aiming for 1 year and 3 releases was just under one year.
18:13:30 <abadger1999> felixfontein: now you're making me feel like a greybeard ;-)
18:13:41 <andersson007_> felixfontein: in your proposal you suggest establishing 6 month cycle, right?
18:14:00 <felixfontein> I heard there were thoughts of increasing the ansible-base major release cycle to once per year, though no idea if that's still thought about
18:14:08 <felixfontein> abadger1999: sorry ;)
18:14:11 <samccann> #info original ansible/ansible deprecation was 4 versions, which was about a year or so
18:14:14 <felixfontein> andersson007_: no, two years
18:14:27 <andersson007_> ok, sorry
18:14:33 <felixfontein> though I was assuming that the 2 years ansible recently had was normal ;)
18:14:42 <samccann> #info that has stretched to close to 2 years now, since the releases have slowed down.
18:15:27 <felixfontein> since we deprecate by version, it should be measured in major releases. we currently plan to release a new major version every 6 months, so we can choose between ~6 months, ~12 months, ~18 months or ~24 months (assuming that nobody wants an even longer cycle)
18:15:59 <andersson007_> 2 year cycle is more than enough
18:16:00 <andersson007_> imo
18:16:12 <felixfontein> I think 6 months is too short, but 12 or 18 months sound good to me
18:16:26 <felixfontein> 24 might be a bit long, after all we don't sell commercial support ;)
18:16:32 <andersson007_> agreed
18:16:34 <andersson007_> about 24
18:16:40 <cyberpear> I'd tend toward the longer end, but I'd also make breaking major versions less frequently
18:17:12 <felixfontein> so, what kind of concrete numbers do you all like? :)
18:17:17 <andersson007_> 12
18:17:22 <samccann> 12 or 18
18:17:25 <cyberpear> so I'd consider 2 major versions fine as long as we don't make major releases except when necessary
18:17:36 <andersson007_> samccann: 12 or 18?:)
18:17:49 <felixfontein> cyberpear: major releases will be every 6 months, so 2 major versions will be ~12 months
18:18:03 <abadger1999> Will it be easier to adjust up or down later?
18:18:04 <cyberpear> I'd say 18 mo
18:18:08 <samccann> ok if I had to pick just one - 18 mo
18:18:12 <abadger1999> adjusting up inconveniences contributors.
18:18:19 <felixfontein> though. more like 8-12 months, since you could add a deprecation in 1.2.0, which is released 2 months before 2.0.0
18:18:22 <abadger1999> adjusting down inconveniences users.
18:19:00 <samccann> my nickel would be to favor users over contributors
18:19:10 <felixfontein> 3 major versions would be 14 to 18 months
18:19:27 <abadger1999> Okay, then I would suggest we start low and then get higher if we have contributors willing to do that.
18:19:39 <felixfontein> which happens to be the same amount of time we currently allow major bugfix/security fix backports
18:19:46 <abadger1999> ^ Regarding samccann's vote to favor users.
18:20:22 <felixfontein> we can also ask for at least 2 major versions, and allow 3 or even 4 if maintainers want that
18:20:38 <samccann> start low as in 12 mo? how does that help users? Seems a user would not want something removed every 12 months?
18:20:44 <abadger1999> It makes users less happy right away but it proves that we have the manpower to maintain for longer before making the expectation better.
18:20:50 <abadger1999> 6 months even...
18:21:03 <felixfontein> 6 months seems very short to me
18:21:18 <felixfontein> that way you can essentially remove something for the next major version
18:21:27 <abadger1999> What i worry about is say we started at two years.... but quickly found that we can't sustain that... no one in interested in maintaining their obsolete code that long.
18:21:34 <abadger1999> So then we decrease it to one year.
18:21:36 <samccann> ah gotcha
18:21:51 <abadger1999> End users then get their expectations crushed.
18:22:49 <cyberpear> so if it comes to that, make it an adjustment for only code not yet deprecated?
18:22:52 <abadger1999> If we do the opposite, start at one year... and we find we are able and willing to go longer because we have enough people willing to maintain a longer deprecation cycle, then users will be happier that they suddenly have 6 months or one year longer to port their playbooks.
18:23:08 <samccann> valid point
18:23:21 <abadger1999> cyberpear: yep I'd make that a given.... but it's still about managing expectations...
18:23:47 <felixfontein> cyberpear: deprecations can always be extended I guess, nobody minds if stuff stays longer (or even forever, if it turned out it shouldn't have been deprecated - remember group names? ;) )
18:23:56 <gundalow> Hi, here now
18:24:00 <felixfontein> hi gundalow! :)
18:24:03 <felixfontein> #chair gundalow
18:24:03 <zodbot> Current chairs: abadger1999 andersson007_ bdodd cyberpear felixfontein gundalow samccann
18:24:03 <andersson007_> hi
18:24:09 <abadger1999> I expect that I'm using this product and I'm getting two years to port things... suddenly the product announces that in the future I'll only have one year.  I probably feel like I'm having something taken away from me.
18:24:20 <samccann> true
18:24:55 <samccann> on the flip side - I'm an ansible 2.8 user and used to nearly a 2yr deprecation cycle, but when I go to 2.10 it's now a year
18:25:06 <gundalow> felixfontein: thanks for starting the meeting
18:25:30 <felixfontein> samccann: true
18:25:54 <felixfontein> but then we already have new features and bugfixes longer than ansible had before
18:25:57 <samccann> my next nickel though - is abadger had the most valid point - what can the community maintain on its own. And if we have doubts, go with the lower number (like 12 months)
18:26:35 <abadger1999> samccann: heh.... note that this policy would only be for collections we control.... so, for isntance, I think that community.kubernetes is already planning on 2.10 including backwards incompatibilities that weren't even announced
18:27:12 <felixfontein> hmm, I hope they add a breaking_changes section to their changelog...
18:27:24 <gundalow> Whatever is decided I think we should be clear that we reserve the right to change it based on user & contributor feedback (though maybe we can't shorten the 2.10 (lowercase) support cycle?
18:27:40 <abadger1999> That sounds important... I'll open a ticket in their github and cc you, felix.
18:27:52 <felixfontein> abadger1999: thanks!
18:28:55 <felixfontein> should we have a poll? about a number of major versions we want the deprecation cycle to last *at least* (for collections we control, i.e. community.network and community.general)?
18:30:22 <felixfontein> ok, if nobody doesn't want it, let's have one :)
18:30:30 <samccann> :-)
18:30:38 <felixfontein> POLL: write the number of major versions you want the deprecation cycle to last *at least*
18:30:42 <gundalow> #info whatever is decided, we need clear docs on how to write changelog/fragments wrt `breaking_changes`
18:30:50 <samccann> 2
18:30:55 <gundalow> 2
18:30:56 <felixfontein> 2
18:30:57 <andersson007_> 2
18:31:04 <cyberpear> 2
18:31:55 <felixfontein> abadger1999: any preference?
18:32:05 <abadger1999> 2
18:32:16 <felixfontein> ok, great!
18:32:26 <felixfontein> I guess nobody minds if maintainers want to have a longer one?
18:32:37 <abadger1999> Absolutely fine :-)
18:33:01 <felixfontein> #agreed the deprecation cycle should be at least two major versions. maintainers can decide to choose a longer one, but not a shorter one.
18:33:07 <felixfontein> great :)
18:33:10 <gundalow> Woot
18:33:34 <felixfontein> ok, an adjacent question: how should current deprecation versions (which are ansible versions) be mapped to collection versions?
18:34:25 <felixfontein> if we assume ~6 months per ansible release (currently), we could map 2.11 -> 2.0.0, 2.12 -> 3.0.0, 2.13 -> 4.0.0 and 2.14 -> 5.0.0 (that would be ~july 2022)
18:35:09 <felixfontein> of course we could also shorten that, and f.ex. say 2.11, 2.12 -> 2.0.0, and 2.13, 2.14 -> 3.0.0 (that would be ~july 2021, i.e. one year)
18:35:17 <cyberpear> I'd say, "the major release coming around the time that the corresponding version of ansible is released"
18:35:37 <felixfontein> cyberpear: we have to convert the versions now, so we can't wait until we find out when these versions are actually released
18:35:40 <samccann> problem is, ansible-base may have longer release cycles.
18:36:17 <samccann> so if we were to keep with the idea of 'don't cut current deprecation cycles short', then I think the first list makes sense
18:37:15 <felixfontein> I'm fine with that, though it's a bit funny that existing deprecations will last a lot longer than things that will be deprecated in the near future
18:37:53 <abadger1999> felixfontein: I think your mapping is sensible.... I think we could get away with going shorter because most people will realize that it's a large change in who is maintaining the content so the maintenance cycle can be different.  But there will probably be a little pushback, possibly from vocal people, if we do so.
18:39:14 <felixfontein> since deprecations can be prolonged, if we choose the shorter cycles, maintainers (or people who want to become maintainers) can still extend them afterwards. though they might get surprised in the first place
18:39:18 <abadger1999> (To be clear on my stance... I would be fine with shorter.)
18:40:17 <felixfontein> also, for deprecated features to be actually removed, someone has to actually remove them. I guess we will add deprecation errors to the ignore.txt file, and create an issue - and if nobody maintains the module/plugin, the deprecation warning will just stay there, as well as the feature, until someone invests time to remove it
18:40:39 <cyberpear> just leave a comment about the original ansible-base deprecation version for maintainers' reference
18:41:02 <felixfontein> that's fine with me
18:41:33 <felixfontein> POLL: does anyone wants the longer mapping, or a completely different mapping?
18:41:50 <felixfontein> I'm happy with the short mapping
18:43:50 <felixfontein> (anyone else already has an opinion?)
18:44:26 <samccann> i'm happy w/ it
18:44:35 <abadger1999> I'm fine with the short mapping.
18:45:06 <andersson007_> short
18:45:20 <gundalow> Short
18:46:09 <felixfontein> cyberpear?
18:46:32 <cyberpear> I won't get in the way of short
18:46:54 <felixfontein> ok
18:47:12 <felixfontein> so let's use the short mapping, and add comments with the original Ansible version
18:47:43 <felixfontein> #agreed mapping for old deprecation version numbers (from ansible): 2.11, 2.12 -> 2.0.0, and 2.13, 2.14 -> 3.0.0. old version should be kept as a comment
18:48:35 <felixfontein> should we look at the changelog questions next? then maybe we have everything together we need for a next release
18:48:56 <felixfontein> #topic changelogs
18:49:00 <felixfontein> my proposal would be:
18:49:33 <felixfontein> 1. have one changelog per major version (similarly as ansible/ansible right now)
18:49:51 <felixfontein> 2. delete fragments from repo after a new version is released
18:50:26 <cyberpear> sounds good to me
18:50:36 <felixfontein> having one changelog means that the changelog for 2.x.x says that it continues the 1.0.0 changelog, similar to what ansible/ansible is doing right now.
18:50:39 <andersson007_> 1. maybe per minor x.X.x version (collections)?
18:51:03 <samccann> so there would be a 1.x change log, and it would contain a runnning list (1.0.0, 1.1.x 1.2.x etc etc)?
18:51:08 <felixfontein> if we have multiple major versions released between two ACD major releases, the ACD changelog would combine the changelogs correctly
18:51:21 <felixfontein> samccann: yes
18:51:32 <felixfontein> andersson007_: that would be quite excessive IMO :)
18:51:46 <andersson007_> felixfontein: ok
18:51:56 <felixfontein> for smaller collections it is probably ok to have one continuous changelog
18:52:09 <felixfontein> though I guess for community.general that file would grow pretty big over time
18:52:27 <gundalow> I like the idea of making it easier for smaller collections.
18:52:37 <felixfontein> so trimming it for every major release would keep the size manageable
18:53:03 <gundalow> I'm OK with c.general and c.network having (needing) more process
18:53:12 <felixfontein> gundalow: this is mainly about community.general and community.network, smaller collections can IMO do whatever they want...
18:53:19 <samccann> I'm happy w/ one per major so long as it works for ansible (acd). So if ansible pulls in say the 1.2.1 version of a collection, the ansible changelog would only have those details?  Do we foresee a scenario where ansible pulls in 1.2.1 but a 1.2.2 or a 1.3.x already exists for that collection?
18:53:47 <felixfontein> samccann: the ACD changelog will contain all changelog entries between the last collection version included in ACD and the current one
18:53:50 <gundalow> felixfontein: nod
18:54:23 <felixfontein> even if there are five major community.general releases between two ACD releases, all entries from these changelogs will show up in the ACD changelog
18:54:31 <felixfontein> (though I hope that won't happen, since that's 2.5 years)
18:54:36 <samccann> yeah my point is what happens if ACD is not pulling the most recent version of a collection? Does the changelog generation still work, or would it pull in changelog fragments from a version that is more recent than what ACD has?
18:55:06 <felixfontein> samccann: the changelog is taken from the released collection on galaxy, so it will not contain anything newer
18:55:18 <samccann> so between the time ACD does a 'freeze' and does its release, a collection owner has updated their collection in galaxy
18:55:43 <felixfontein> samccann: if the old version is not contained in that changelog, the changelog code will look at the changelog's ancestor, download that collection version, and continue with its changelog, until it found the previous release included in ACD
18:56:03 <felixfontein> samccann: it will use the collection version that is included in ACD
18:56:16 <samccann> ok kewl
18:57:10 <felixfontein> is anyone opposed to the idea of not keeping fragments once they are included in changelog.yaml?
18:57:56 <samccann> nope
18:58:15 <andersson007_> no
18:58:26 <felixfontein> (ansible/ansible currently keeps them, and they are the source of truth, and they want to keep it that way.)
18:58:49 <felixfontein> since old collection releases are immutable, I think it also makes sense to not change old changelog entries
18:58:51 <abadger1999> felixfontein: so this would be a difference with ansible/ansible's workflow?
18:59:02 <felixfontein> if they are in changelog.yaml and not available as fragment files, that's easier to ensure :)
18:59:17 <abadger1999> (i'm not opposed, jsut clarifying)
18:59:33 <felixfontein> abadger1999: yes. but it shouldn't affect anyone - except people who want to modify old changelog fragments in an easy way
19:00:48 <abadger1999> Cool.
19:01:01 <felixfontein> hmm, should we vote?
19:01:33 <andersson007_> let's vote then:)
19:01:37 <felixfontein> POLL: is it ok for everyone if a) we have one changelog per major verion, and b) fragments are removed after a version is released (contents are in changelog.yaml)
19:01:45 <abadger1999> +1
19:01:46 <felixfontein> +1
19:01:52 <samccann> +1
19:01:52 <andersson007_> +1
19:02:23 <felixfontein> gundalow: cyberpear:
19:03:14 <cyberpear> no opinion
19:03:22 <felixfontein> that's fair :(
19:03:23 <felixfontein> :)
19:03:26 <felixfontein> sorry, typo :D
19:03:39 <cyberpear> sounds to do me. +1
19:05:09 <felixfontein> #agreed a) we have one changelog per major verion, and b) fragments are removed after a version is released (contents are in changelog.yaml)
19:05:12 <felixfontein> thanks!
19:05:47 <gundalow> (too late) yup
19:05:47 <felixfontein> maybe one last thing for today: what do you think of making a first proper release of community.general very soon, like next week (or the week after that)? version 0.2.0?
19:06:04 <felixfontein> (before having a 1.0.0 later, maybe next month?)
19:06:36 <abadger1999> version numbers are free, I'm all for more releases right now.
19:06:37 <felixfontein> or more precisely, how about: a) release 0.2.0 in two weeks, and b) release 1.0.0 by end of July?
19:06:59 <felixfontein> I think we should wait until ansible-base is really frozen, so there won't be more changes to deprecation etc ;)
19:07:02 <abadger1999> Maybe in the future we'll have release criteria nad testing periods and such, but I don't think we're anywhere close to that level of organization yet.
19:07:17 <abadger1999> <nod>
19:07:23 <abadger1999> +1
19:07:27 <felixfontein> I guess for 1.0.0 we can have a freeze, some testing period, ...
19:07:47 <felixfontein> I think in the proposal I defined it as two weeks, or so
19:08:04 <andersson007_> felixfontein: dates sound ok to me
19:08:15 <felixfontein> I'd really like to have a proper 0.2.0 release soon, so that abadger1999 has something better for the ACD docs pipeline, and I have something better for the ACD changelog pipeline ;)
19:08:27 <samccann> +1 to that :-)
19:08:43 <felixfontein> I guess we can also try end of next week, assuming that ansible-base 2.10 beta 1 is out by then
19:08:59 <felixfontein> if we want to be really quick
19:09:49 <felixfontein> does anyone prefer a release next week over one in ~2 weeks?
19:09:55 <cyberpear> 1.0.0-rc1 is a valid semver pre-release
19:10:10 <felixfontein> cyberpear: true, but I think it's a bit early for that yet
19:10:59 <cyberpear> agreed
19:11:09 <cyberpear> 0.2.0 sounds gid
19:11:10 <felixfontein> abadger1999: what's your opinion? since you depend most on a new release
19:11:12 <cyberpear> good
19:11:24 <andersson007_> no longer than 2 weeks is ok
19:11:31 <andersson007_> next week is also ok
19:11:58 <abadger1999> Same as andersson007_  from me.
19:12:03 <felixfontein> we can also say end of next week if ansible-base 2.10 beta is out by wednesday, and later if not
19:12:45 <felixfontein> I think having 1-2 days after the beta is out is a good thing, just to be sure that everything is working as expected
19:12:49 <samccann> need to run for another meeting.. later taters!
19:12:59 <felixfontein> samccann: see you later, and thanks a lot!
19:13:24 <felixfontein> ok. is everyone fine with "a couple of days after ansible-base 2.10 beta is out"?
19:14:01 <andersson007_> yep
19:14:05 <felixfontein> also: I guess for this one, we release directly from master and not from a branch?
19:14:16 <felixfontein> (i.e. no backporting until 1.0.0 is out)
19:14:26 <abadger1999> +1
19:14:54 <felixfontein> cyberpear: gundalow: objections, or other ideas?
19:16:02 <gundalow> No objections
19:17:33 <felixfontein> cool!
19:17:55 <felixfontein> cyberpear: I assume it's ok for you then
19:18:32 <felixfontein> #agreed version 0.2.0 to be released next, a couple of days after ansible-base 2.10 beta is released. with changelog and correct version_added and deprecation versions. version after that will be 1.0.0.
19:18:38 <felixfontein> #agreed will be released directly from master, i.e. no release branch, and no backporting until 1.0.0 is out
19:18:57 <felixfontein> ok. should we stop for today?
19:19:20 <felixfontein> the remaining questions from my list (https://github.com/ansible/community/issues/539#issuecomment-640040115) can also wait :)
19:19:58 <abadger1999> Up to other people... I can be here or go back to coding ;-)
19:20:05 <felixfontein> I think now we have everything so that we can do a next release, and announce a rough schedule and information about releasing in the repo
19:20:59 * cyberpear steps away
19:21:03 <felixfontein> I'll create PRs (resp update for version_added) for these aspects and CC you all in there
19:21:15 <felixfontein> good, I think in that case we'll better stop for today
19:21:25 <felixfontein> #endmeeting