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