18:00:24 #startmeeting Ansible Community Working Group 18:00:24 Meeting started Wed Jun 3 18:00:24 2020 UTC. 18:00:24 This meeting is logged and archived in a public location. 18:00:24 The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:24 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:24 The meeting name has been set to 'ansible_community_working_group' 18:00:34 #chair abadger1999 felixfontein cyberpear andersson007_ 18:00:34 Current chairs: abadger1999 andersson007_ cyberpear felixfontein gundalow 18:00:50 hey :) 18:00:52 hey, again 18:00:57 2nd time lucky 18:01:14 indeed :) 18:01:28 so 18:01:47 shall we continue to talk about versioning/releasing/all the fun for community.general and community.network? 18:02:16 let's! 18:02:27 someone want to #topic? 18:02:35 last week we decided a) we use semver, b) major releases (with breaking changes) every 6 months, c) minor releases (with new features) every 2 months, d) deprecation by version 18:02:50 #topic ersioning/releasing/all the fun for community.general and community.network 18:02:55 #undo 18:02:55 Removing item from minutes: 18:02:55 My proposal for ACD versions and support would be: support a version of ACD corresponding to each currently-supported version of ansible, allow new features (X.Y.0) no more often than an ansible 2.10.Z release, and allow bugfixes and security (Y.Y.Z) on an as-needed basis. 18:03:03 #topic Versioning/releasing/all the fun for community.general and community.network 18:03:20 #info https://github.com/ansible/community/issues/539#issuecomment-638239306 18:03:25 remind me please about patch releases, weekly? 18:03:26 but narrowing it to only stuff felixfontein didn't say: maintain a branch of ADC for each supported branch of ansible 18:03:30 *of ansible-base 18:03:45 I adjusted my proposal https://gist.github.com/felixfontein/2bad8517b70008ab9be90387ee4090c8 to what we discussed last week, and added some questions for discussion here: https://github.com/ansible/community/issues/539#issuecomment-638239306 18:04:03 andersson007_: I don't think we talked about patch releases yet 18:04:03 cyberpear: i believe this is only about the collections 18:04:12 felixfontein: ok 18:04:38 yes, I'd say we discuss collections first so we can release them again (so abadger1999's docs generator gets something a lot less buggy) 18:04:41 * samccann strolls in late 18:04:50 #chair samccann 18:04:50 Current chairs: abadger1999 andersson007_ cyberpear felixfontein gundalow samccann 18:04:52 hey :) 18:04:54 okay... collections can do whatever they want, but I'd proposed a major version of a collection can correspond to a "major" version of ansible, such as 2.10 18:05:09 how are RC's handled in semver? 18:05:12 cyberpear: I think that is what was planned so far (i.e. what abadger1999 implemented) 18:06:14 I'd guess we'd stick to non-RCs if the collection maintainers are not actively asking for it (and if they do, no idea :) ) 18:06:52 ok. so about the big collections. the hardest part there is to figure out how to actually do releasing/versioning 18:07:06 there are two approaches: a) develop and release from master, b) develop on master, release from release branches 18:07:26 a) makes it easier (less backports), but breaking change PRs can only be merged for a new major release 18:07:48 b) is similar to what ansible/ansible does, and means that everything that should go into a new release (minor or patch) needs to be backported 18:07:51 which includes new features 18:08:04 probably release from branches since we're semver and that's a sane way to maintain those guarantees 18:08:46 yes, especially because the collections in question are large, have a lot of different maintainer groups with different activity levels (from zero to full :) ), so coordinating a clean master would be hell 18:09:04 maybe a first 18:09:24 POLL: is anyone still trying to make up their mind on this question, i.e. release branches vs. release from master? 18:10:00 I don't have strong views, happy to follow the suggestions from y'all 18:10:07 ditto 18:10:38 afte talking about this with abadger1999 some weeks ago, I'm preferring release branches 18:10:50 abadger1999 also wrote before the meeting that he also prefers them 18:11:10 andersson007_: I think you also do? 18:11:18 in it's the similar approach as in ansible base, it sounds ok 18:11:33 in/if 18:11:45 cyberpear: what do you think? 18:12:07 yes, branches, please 18:12:17 (how do they say for weddings? speak up now, or shut up forever? ;) ) 18:12:29 haha, yup 18:12:44 I also don't like the cherry-pick workflow, nor squash-merges, but I'm not going to win that argument here 18:13:14 I hate having to pull up GitHub to see the actual commit history of a gigantic squashed PR 18:13:44 but I digress 18:13:59 :) I think that's a debate similar to tabs vs. spaces 18:14:15 next topic if none opposed to branches? 18:14:23 maybe a formal vote first? 18:14:29 yep 18:14:31 or is that already clear enough? 18:14:33 k 18:14:48 VOTE: +1 = releases from release branches, -1 = releases from master 18:14:50 +1 18:14:53 +1 18:14:54 +1 18:14:58 someone want to do an #agreed foo (votes) 18:15:19 should we count abadger1999's +1? 18:15:29 since he stated this before the meeting (outside the log zone)? 18:15:40 +1 18:16:06 can you copy/paste his agreement here and make that vote count? 18:16:09 #agreed community collections will release from branches (+1: 5, 0: 0, -1: 0) 18:16:21 woot 18:16:23 thanks 18:16:28 #chairs 18:16:30 #chair 18:16:30 Current chairs: abadger1999 andersson007_ cyberpear felixfontein gundalow samccann 18:16:36 even if abadger is against, we will win:) 18:16:42 heh 18:16:44 (just checking I've got everybody) 18:16:54 19:33 <@abadger1999> release from master or from release branch.... I think we need both a development and a release branch. 18:16:57 19:33 <@abadger1999> But with our maintainers, which is going to be more active? 18:17:00 19:42 <@abadger1999> I think that releasing from a release branch makes more sense but it could just be that I've grown so accustomed to how ansible does it that it seems right. 18:17:40 he's definitely not against it 18:17:46 ok 18:18:09 so a related question: how should features and bugfixes be backported from master to the release branch? 18:18:24 a) maintainers create backports, RM judges and maybe merges 18:18:36 b) maintainers create backports, can merge via bot (similar to shipit) 18:18:51 c) bot creates and merges backport (if possible without conflicts) if maintainer request it 18:19:00 d) ...? 18:19:15 (assuming that feature / bugfix backports are still accepted for that release branch, that is) 18:19:46 * abadger1999 in dentist waiting area. 18:19:57 good luck :) 18:20:24 In like automation for this. If s maintainer gets it wrong, just teach and observe if they've learned better next time 18:20:54 so b)/c) (depending on how automated it got) I assume 18:21:04 the main disadvantage of a) is that someone has to be that RM 18:21:07 So both b and c (not mutually exclusive). 18:21:08 Yep 18:21:31 b) would always be the fallback for c) if there are conflicts / the bot cannot backport for whatever reason 18:21:33 merge via bot is good, plus manual backports?, or auto-backport, manual approve, auto merge? 18:21:43 Quick google comes up with https://github.com/marketplace/actions/backport-bot which will create a backport if a label is added 18:21:43 If there are a lot of community members who want to spice backport, then a can work 18:22:39 maybe a quick question: is someone preferring a), or thinking that a) is important? 18:22:45 (looking a bit at andersson007_ :) ) 18:23:13 I'm not sure who would be RMs for c.g and c.n 18:23:16 we discussed it:) 18:23:25 felixfontein: ^ 18:23:38 if it's safe enough (b,c), ok 18:23:48 andersson007_: that's why I'm looking at you ;) 18:23:59 I don't know what you consider 'safe enough' 18:24:00 heh 18:24:03 so if I created a PR, I would then put a `backport` requested label on it and then magic happens after that? 18:24:14 (for b and c) 18:24:33 felixfontein: if abadger1999 considers, that's enough 18:25:10 samccann: something like that. in the best case (we did enough automation), the bot would automatically create a backport PR, and if that's `shipit`'ed, it will get merged by the bot 18:25:32 18:25:55 samccann: if the bot cannot create a backport, it should report back. and if we don't hvae a bot which can backport, someone has to create the backport PR manually, and the bot can merge it (with sufficient `shipit`'s) 18:26:18 ok cool, thanks 18:26:35 ok. so it looks like nobody is insisting on manual merging by a RM 18:26:39 such pr's can be backported automaticaly, no? 18:26:43 prs 18:27:04 ok ok, i see now 18:28:15 ok. so proposal: backports are merged by bot, and if someone implements it the bot also creates backport PRs. 18:28:21 should we vote on this? 18:28:50 +1 18:28:57 let's do the formal stuff 18:29:09 VOTE: backports are merged by bot, and if someone implements it the bot also creates backport PRs. Is that ok? (+1=yes, -1=no) 18:29:12 +1 18:29:16 +1 18:29:17 +1 18:29:22 +1 to bot 18:30:06 from the talk before the meeting, it looks like abadger1999 also likes this solution. at least he definitely isn't against it :) 18:30:43 #agreed backports are merged by bot, and if someone implements it the bot also creates backport PRs (5 x yes, 0 x no, 0 x abstain) 18:30:54 ok :) 18:31:26 next questions... how long will features and bugfixes be backported, and how long is the deprecation cycle? maybe let's start with the first two questions 18:31:41 abadger1999 summed this up as "How many release streams does community.general want at any one time." 18:32:00 my suggestion is to backport features only to the current active major release 18:32:20 i.e. x.1.0 and x.2.0 get new features, and then that's it for major release x 18:32:32 (since we release minor versions every 2 months, major versions every 6 months) 18:32:52 sounds good, any other options? 18:33:16 does anyone want to backport features to older releases? 18:33:26 definitely not me 18:33:54 as a maintainer I sometimes would like to do it, but when thinking about the effort that is required for that for a large collection such as c.g.... no thanks ;) 18:34:11 how would this compare to say 2.9 vs 2.8? As in do we have a history of needing something backported from 2.9 to 2.8 that wasn't just a bugfix? 18:34:27 in ansible/ansible features were never backported 18:34:39 i.e. features had to wait for the next release (recently ~6 months, sometimes more, sometimes less) 18:34:50 yeah that's what I thought but wanted to be sure 18:35:22 #info there are bots such as https://github.com/marketplace/actions/backport-bot which would raise backport PRs 18:35:31 I want features... 18:35:56 ansibullbot could set the label on request, and that bot could do the backporting 18:36:02 yup 18:36:06 cyberpear: but for how old versions? 18:36:33 all of them, but only when requested 18:37:05 i.e., if someone does the effort 18:37:23 but then someone also has to do the release management 18:37:44 we have major releases every 2 months, maybe we'll release them more frequently, e.g. every month, later. IMO, who wants to have features right after merge can use ansible from master branch 18:37:47 sure, but we're also doing bugs 18:38:03 we're *always* also doing bugs 18:38:05 minor releases every 2 months 18:38:06 we also backport bugs :) 18:38:23 features are usually more complex things 18:38:37 that's also one reason why I wouldn't backport features to older major versions, to reduce the danger of accidentally introducing a bug 18:38:37 probability to backport bugs will increase 18:38:38 major implies compatibility break 18:39:08 we don't have money to pay a dedicated RM which tries to make sure this isn't happening 18:39:11 I wonder if we can start small, then revisit when we know how frequently people upgrade/find pain 18:39:29 gundalow: that's a good idea 18:39:29 adding a new module doesn't generally add any bugs in existing components 18:39:54 cyberpear: true. but only accepting new modules/plugins in older releases and not other new features would also be strange 18:40:02 let's backport less stuff for the beginning 18:40:17 then we can analyze what happend after a while 18:40:27 cyberpear: would that be ok for you? 18:40:35 sure, start small, but don't make it the policy 18:41:18 it *is* a policy if we do it. but of course policies can be changed. 18:41:31 yep 18:42:36 VOTE: accept feature backports only for the current major version (for now. can be extended later.) 18:42:40 I think between now and the end of the year we will learn a lot. We can take that knowledge and experience 18:42:41 +1 18:42:46 +1 18:42:47 maybe features for current and previous, bugs only for older? 18:42:47 +1 18:42:52 I think between now and the end of the year we will learn a lot. We can take that knowledge and experience, and change things in the future 18:43:02 gundalow +1 18:43:09 cyberpear: I'd prefer not to promise that too early, before we know how much work it actually is 18:43:33 if it turns out to be almost no work, we can still change this later. but restricting this once we allowed it is hard. 18:43:57 also until the end of the year we only have one major release (1.x.y), so it doesn't really matter until 2.0.0 is out :) 18:44:04 changing any decision is hard, I guess 18:44:19 not necessarily 18:44:20 i suggest giving minimal promises as a general approach for a while 18:44:27 -0 is my vote 18:44:36 if it breaks something, it is hard. but extending that isn't breaking something (it's just adding more work) 18:45:03 do we use IEEE floats, or ints for votes? 18:45:14 lol 18:45:15 (or rational numbers?) 18:45:37 +1 18:45:52 4/1/0 is my count 18:46:05 +3i 18:46:11 #agreed accept feature backports only for the current major version (4/1/0); with option to adjust this later - discussion maybe at end of 2020 18:46:29 * felixfontein throws an exponential function at bcoca 18:46:35 stay in your circle :P 18:46:56 * bcoca lobs back an integral with a logarithim 18:47:28 ok 18:47:59 to which versions do we want to backport bugfixes? only current major? or also the previous one? or even older? 18:48:14 (also this is only really relevant once we release 2.0.0 and have more than one major release) 18:48:26 every version that ever existed ... 18:48:27 all maintained versions 18:48:46 have we defined what's maintained? 18:48:50 nope 18:48:59 cyberpear: in your mind, what's maintained? 18:49:01 also .. diff levels of maintenance are possible 18:49:03 so alternative question: how many versions do we want to maintain at once? 18:49:22 the ones suggesting the highest value offer themselves as responsible for maintaining :P 18:49:24 security only, major, all fixes ... 18:49:36 one per major ansible release 18:50:18 bcoca: indeed. I suggested prev major version for regular bugfixes, and 1-2 more major versions for security fixes (or otherwise really major bugfixes) 18:50:37 cyberpear: do you mean ACD with ansible, or ansible-base? 18:50:39 mostly how asnible 2.x has been handled ... 18:50:57 bcoca: yep 18:51:35 except that since we allow feature backports, we should allow regular bugfix backports a bit longer (so that bugs in backported new features can be fixed) 18:52:24 allowing feature backports basically mandates bugfix backports (specially for ones introduced by new features backported) 18:52:35 base 18:52:38 also .. doesnt feature backport violate semantic versioning? 18:52:54 bcoca: no, not if these are put into minor releases 18:53:02 (new features must not appear in patch releases) 18:54:18 +1 ansible-base approach 18:54:32 maybe this is also something we should revisit by the end of the year, when we know how things are going (and when there's still only one major release: 1.x.y) 18:54:48 andersson007_: what do you mean with ansible-base approach? 18:55:26 security, major, all bugs 18:55:52 and for how long should each of these categories be backported? 18:55:54 N all, n-1 major, n-2 security (N == current) 18:56:26 bcoca: but then regular bugfixes can only be backported as long as new features can also be backported 18:56:59 ^ explaining the policy, not saying it should be applied 18:57:29 how about: n-1 all, n-2 security and Major (with capital M), possible longer on a case-by-case discussion in this meeting? 18:57:39 ok: all, all, major, security:) 18:58:46 andersson007_: what do you mean? 18:59:22 ok so just to see if I understand this - I can add a new module to N and N-1. I can bugfix the same way... and finally, security fixes go all the way down to N-2? 18:59:24 you said we need allow regular bugfix backports a bit longer 18:59:52 samccann: you can add a new module or new feature only to N 19:00:16 but bugfixes/major fixes/security fixes potentially longer 19:00:59 ok. maybe we should continue this discussion next week (or later this year, as it only becomes important 6 months after 1.0.0) 19:01:16 but maybe we can decide something else before we close today :) 19:02:04 namely fix a rough versioning timeline, and a way to transform pre-ansible-2.9 deprecation version numbers to collection deprecation version numbers 19:02:23 #proposed allow all bugfixes to 2 most recent major versions, only critical and high-priority bugs for N-2 release 19:02:24 that would allow us to actually adjust the versions, and maybe do a first "proper" release soon (0.2.0?) 19:02:34 #proposed allow all bugfixes to 2 most recent major versions, only critical and high-priority bugs for N-2 release, re-evaluate and end of 2020 19:02:45 cyberpear: sounds good to me 19:03:10 is #proposed a meetbot command? 19:03:17 I don't think so 19:03:19 votes: +1 == agreed to #proposed -1== disagree 19:03:25 +1 19:03:29 +1 19:03:31 cyberpear: +1 19:03:58 +1 19:04:04 gundalow: ^ 19:04:34 +1 19:04:39 #help 19:04:43 ok 19:04:47 #halp 19:04:58 those commands send a help request to #fedora-commops 19:05:02 #agreed allow all bugfixes to 2 most recent major versions, only critical and high-priority bugs for N-2 release, re-evaluate and end of 2020 (+5, 0, -0) 19:05:09 Hum, no proposed, only info, action, agreed 19:05:55 hmm, one hour is already over. should we continue next week, or try to get more done now? 19:06:20 is there anything important to discuss before 2.10 freeze? 19:06:32 maybe a quick poll: what do you think about having a first proper release 0.2.0 soon, with correct version_added and deprecation versions and changelog? 19:07:08 why not 0.1.0? 19:07:09 cyberpear: I *think* nothing that affects community. at least not that I know of. 19:07:16 because we already released 0.1.0 19:07:24 ah, ok 19:07:26 :) 19:07:32 that was the initial release 19:07:47 ok, so, would be strange to release 0.3.0 19:07:51 which is old and somewhat broken (f.ex. the dependencies are missing) 19:07:54 it'd be convenient to use 0.X.Y releases as release-candidates for Y.Z.0 releases, but whatever. technically 0.Y.Z dosen't follow symver rules 19:08:04 i.e., you're allowed to do whatever you want 19:08:11 would love to have 0.2.0 that works with the docs pipeline but I don't know if that's achievable 19:08:29 (and with changelogs... cuz why not ask for the sky!) 19:08:37 samccann: I think it is. the main thing missing is that we adjust version_added and deprecation version numbers :) 19:08:51 \o/ 19:09:01 samccann: I also want changelogs, so that we have at least one properly released collection with changelogs! 19:09:09 yes!! 19:09:32 ok. so let's try to fix everything we need for that next week? 19:09:41 is anyone opposed to that? 19:10:11 gundalow: anything from your side, or the non-public RH side against this? 19:10:56 I'm working on updating overview/README.rst to reflect where we are. 19:11:42 And been poking ansible/ansible's bot so it correctly identied which collections issues and PRs should be closed and pointed to. 19:12:20 sounds cool! 19:12:35 Next is to work out the minimal amount of docs Contributors need on what collections and how to develop against them 19:12:54 This is so we can start closing and redirecting PRs 19:13:21 do you think we should wait with a first proper release of community.general (and/or community.network) until this is done? 19:14:16 I think things should be in a stable state before mass closing/migrating 19:14:47 by stable do you mean 1.0.0 or 0.2.0 or something in between? 19:15:11 not in a state of flux 19:15:33 I think a "proper" 0.2.0 (when versioning is decided) would already be pretty stable 19:15:35 not a specific version or release, just think that the processes and big changes have calmed down 19:15:36 compared to the current state 19:16:12 (it's probably best to release this after the freeze of ansible-base though, to avoid "surprises") 19:16:24 Wait before issues and PRs in ansible/ansible get closed? Yes, I think we have more to do like Zuul is failing c.g 19:18:37 so no release soon? 19:19:47 I think we can release the collections soon. 19:19:48 Is that all for today? 19:20:03 Nothing else from me 19:20:08 I guess it is 19:20:19 anyone else has a topic? 19:20:26 Maybe need an issues that tracks what needs to be done before c.g can be released 19:20:37 +1 19:21:09 +1 19:21:30 I can create one (and you can update it :) ). where should I create it? 19:21:36 in c.g's repo itself? 19:22:32 I think that should be great, thanks. 19:24:19 Cool 19:24:30 Anyone got any final comments? 19:25:43 #action felixfontein to create issue in community.general to define what needs doing before we can release community.general. Gundalow to update 19:25:50 Thanks everybody 19:25:55 #endmeeting