18:00:22 <gundalow> #startmeeting Community Working Group
18:00:22 <zodbot> Meeting started Wed May 27 18:00:22 2020 UTC.
18:00:22 <zodbot> This meeting is logged and archived in a public location.
18:00:22 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:22 <zodbot> The meeting name has been set to 'community_working_group'
18:00:28 <gundalow> #chair felixfontein
18:00:28 <zodbot> Current chairs: felixfontein gundalow
18:00:38 <felixfontein> cyberpear gregdek
18:00:45 <cyberpear> o/
18:00:46 <gundalow> #info Agenda https://github.com/ansible/community/issues/539
18:00:53 <gundalow> cyberpear: hi there :)
18:01:09 * cyberpear can't believe it's already Wednesday!
18:01:11 * gregdek hullos
18:01:11 <felixfontein> welcome everyone to the first community working group meeting :)
18:01:20 <gregdek> I am sadly double booked, but I will lurk :)
18:01:36 * acozine waves
18:02:43 <gundalow> #chair cyberpear gregdek acozine
18:02:43 <zodbot> Current chairs: acozine cyberpear felixfontein gregdek gundalow
18:02:59 <felixfontein> I put two topics on the agenda, but in the end it's all about community.general and community.network versioning and releasing (and deprecation)
18:03:18 <gundalow> #info Thanks for joining the first of the new series of Community Meetings
18:03:57 <acozine> \o/
18:04:00 <gundalow> #topic Community.(general,networking) versioning, releasing and deprecation
18:04:08 * samccann waves
18:04:28 <gundalow> #chair samccann
18:04:28 <zodbot> Current chairs: acozine cyberpear felixfontein gregdek gundalow samccann
18:04:30 <felixfontein> because sooner or later we have to release 1.0.0, and maybe some more complete versions before, and so we have to know how to adjust all the existing deprecation version numbers ;)
18:04:30 <gundalow> hi samccann :)
18:04:39 <samccann> hello everyone!
18:05:08 <felixfontein> (and things like having a changelog)
18:05:17 <abadger1999> Hi
18:05:28 <gundalow> #info felixfontein's proposal for Versioning, deprecation and changelogs for community.general and community.network https://gist.github.com/felixfontein/2bad8517b70008ab9be90387ee4090c8
18:05:31 <gundalow> #chair abadger1999
18:05:31 <zodbot> Current chairs: abadger1999 acozine cyberpear felixfontein gregdek gundalow samccann
18:05:34 <gundalow> hi abadger1999 :)
18:06:36 <gregdek> To cut to the chase: is there anything in the proposal that people disagree with?
18:06:38 <felixfontein> after some discussions I tihnk the first question would be: how often do we actually want to release new features? and how hard do we want to try to adhere to semantic versioning?
18:06:47 <gundalow> andersson007_: I see you've added a lot of comments already, thank you
18:07:08 <cyberpear> I'd suggest major versions "as needed", unless there's a good reason for 6 months? -- or maybe "no more often than 6 months"
18:07:43 <gregdek> I suspect that "major" releases will largely be driven by changes to ansible-base that require major changes.
18:07:45 <felixfontein> cyberpear: the 6 months is mainly so that deprecation versions can be picked from the schedule (i.e. remove in 4 major versions after deprecation)
18:07:48 <gundalow> cyberpear: fair question.
18:07:58 <felixfontein> but that depends on whether we actually want to deprecate by version
18:08:08 <gundalow> felixfontein: Just to clarify, do you think this is specific to c.general and c.network which have a lot of commits?
18:08:22 <gregdek> And those kinds of big dependency changes to ansible-base shouldn't come more frequently than 6 months, I shouldn't think.
18:08:29 <cyberpear> or maybe "new major version to correspond with ansible-base releases, if required"
18:08:32 <gundalow> (I know it says that in the proposal title, just want to make sure everybody is on the same page)
18:08:37 <felixfontein> nitzmahone and jborean93 yesterday pointed out that deprecate by version has some disadvantages, mainly that if you have to do an unexpected major release, you speed up removal if you don't adjust all deprecation versions
18:09:12 <felixfontein> gundalow: some of the structure in there is probably only needed for large "incoherent" collections like c.g and c.n
18:09:43 <felixfontein> gundalow: smaller collections don't have a huge amount of independent parts which independently want to add/deprecate/remove features and make releases
18:09:48 <gregdek> I know abadger1999 strongly favors version deprecation -- it's my hope that we can sync release cycles strongly enough that the two are usually equivalent, a la Fedora's mostly 6 month cycle
18:09:58 <gundalow> `New features can be backported to the current stable-x release branch after x.0.0 and until x.5.0 has been released` I'm not sure about that, haven'tgot my head around the implications of that
18:10:05 <gregdek> But we should probably be updating c.g more often than that
18:10:16 <felixfontein> gundalow: essentially that means that new features can go into the current major version
18:10:20 <gundalow> felixfontein: is your aim with ^, so that people don't have to wait 6 months for new features?
18:10:34 <samccann> fwiw I think the ansible-maintained collections will use a timeline based deprecation cycle, not version
18:10:43 <gregdek> So maybe we say "major releases are by definition once every six months and that's when deprecations take place" and we're rolling minor releases with content changes more frequently...
18:10:49 <felixfontein> so while 2.2.0 is the current release, it gets new features. when 2.5.0 is released, the next release will be 3.0.0, so no new features for 2.x.y with x>5 anymore
18:10:52 <cyberpear> w/ semver, you can have new features in a Y release; you just can't break old stuff w/o bumping X
18:11:02 <gregdek> Right
18:11:06 <felixfontein> gundalow: yes. my idea was that new features once per month is probably a good schedule
18:11:12 <felixfontein> but that's something we maybe also have to discuss
18:11:14 <gregdek> And just because you bump X, it doesn't follow that you must break old stuff :)
18:11:24 <gregdek> It's just the only opportunity to do so
18:11:25 <felixfontein> gregdek: indeed!
18:11:26 <cyberpear> felixfontein: in that case, you'd switch to doing only Z releases after X.5.0
18:11:36 <abadger1999> This looks sane.... provided there's the manpower and leadership to do it.
18:11:45 <felixfontein> cyberpear: exactly. so x.5.1, x.5.2, ... x.5.1231 will be the next releases
18:11:48 <cyberpear> gregdek: if you're not breaking old stuff, please don't unnecessarily bump X
18:12:03 <abadger1999> 2 years of support and releases approximately every month.
18:12:26 <felixfontein> abadger1999: I would only do monthly releases of the current major version, and maybe the previous one (if there are bugfix backports)
18:12:29 <abadger1999> i think it will end up being 4 concurrent releases at a time?
18:12:35 <gundalow> felixfontein: To throw a random thought out. If we don't backport features, what about doing major releases two (or three) months, would that reduce the amount of branches we need to maintain, and dramatically drop the amount of backports needed?
18:12:51 <felixfontein> the two before should hopefully almost never get updates (only in case of major bugs or security bugs)
18:13:00 * gregdek goes to the other meeting he's in, sorry
18:13:05 <felixfontein> gundalow: that would
18:13:07 <gregdek> (sigh)
18:13:45 <felixfontein> gundalow: it has a big disadvantage though: since ACD sticks to one major version of the collection per release cycle, there will be no new features after 3 months since the collection has a new major version
18:14:15 <cyberpear> w/ semver, features go into Y releases; breaking changes go into X releases. fixes go into Z releases; so if we don't want to backport features, we'll only ever have X.0.Z releases
18:14:19 <felixfontein> so the release cycle of c.g/c.n should be roughly similar to the one of ACD, and that somewhat similar (or related to) the one of ansible-base
18:14:31 <acozine> am I correct to think that the proposed cadence would respect the "negative" aspects of semver (e.g. don't break stuff except when you bump X), but not the "positive" aspects (some major versions might not add anything huge)?
18:14:53 <felixfontein> gundalow: also, if we have major releases every few months, people will be not happy to upgrade, since new major version = you have to check everyplace the collection is used if something breaks
18:15:36 <cyberpear> if we're doing semver, let's do it consistently... if we never backport features, let's never have an X.1.0 release; only X.0.Z
18:15:46 <felixfontein> acozine: I think so
18:15:46 <gundalow> felixfontein: yup ,that's a fair point
18:15:52 <cyberpear> bumping Y implies adding features
18:16:00 <felixfontein> so IMO there should be regular major releases, but not too often
18:16:07 <cyberpear> I assume the ship has sailed on whether to use semver at all
18:16:21 <felixfontein> cyberpear: semver is kind of dictated by galaxy I think
18:16:28 <cyberpear> I'm not against it; just do it right if you do
18:16:45 <felixfontein> you can still do a Y version bump without new features. it's maybe strange, but possible I think :)
18:16:52 <cyberpear> and in a semver world, you can opt-out by having 0.Y.Z, and you're off the hook
18:16:58 <acozine> I like the idea of a time-based cadence
18:17:19 <felixfontein> one problem with semver is that backporting new features makes it possible to accidentally do breaking changes in minor versions. (but that's also possible with bugfixes.)
18:17:20 <acozine> so we can be even-handed in saying "if you want your feature in X.Y, it needs to be merged by this date"
18:17:47 <cyberpear> acozine: yes, that would be fine
18:17:59 <cyberpear> felixfontein: why would you want to bump Y w/o adding a feature? why not just bump Z?
18:18:10 <felixfontein> acozine: that's one reason why I like having an explicit list of dates, so everyone can plan accordingly. especially important for a large collection like community.general, where a lot of different independent groups work on independent modules
18:18:42 <felixfontein> cyberpear: mainly to keep the schedule :) so RM doesn't have to check every release "is there really a new feature in here?"
18:18:47 <acozine> with this approach the changelog/porting guide becomes more important, since folks might skip a few versions when upgrading
18:19:14 <gundalow> I personally like Ubuntu's YYMM style
18:19:20 <felixfontein> cyberpear: for small collections skipping versions is feasible, but for large ones either someone has a lot of spare time, or someone has to be paid :)
18:19:36 <acozine> gundalow: link?
18:19:38 <felixfontein> gundalow: me too.
18:19:38 <cyberpear> felixfontein: skipping?
18:20:17 <acozine> oh, I never connected Ubuntu 16 with the year 2016
18:20:19 <acozine> d'oh
18:20:23 <felixfontein> cyberpear: if we announce 3.5.0 will be release on say August 27th, but on August 27th we notice that we ahve no new features, so we should use 3.4.1 instead, it kind of breaks the schedule
18:20:47 <felixfontein> acozine: it took me some time to realize this as well :) but once you get used to it, it is *really* nice :)
18:21:04 <acozine> yeah, that is really nice
18:21:22 <cyberpear> so only announce 3.5.0 if there have been any new features?
18:21:43 <cyberpear> agreed YYMM versioning is useful, but it's not semver
18:21:49 <felixfontein> cyberpear: doesn't work well if you want to publish a date->version table a long time in advance :)
18:22:20 <acozine> cyberpear: it's definitely not semver, but it's a totally different option that might work well for collections
18:22:56 <cyberpear> acozine: I think it's worth discussing, especially if we don't really want to do semver anyway
18:23:04 <felixfontein> except that to make galaxy happy, you need to use 2004.0.0 instead of 2004 ;)
18:23:22 <felixfontein> I think semver is kind of baked into ACD
18:23:28 <cyberpear> oh, please no
18:23:37 <felixfontein> because without semver it is kind of impossible to synchronize such a large zoo of collections into a unified release
18:23:41 <cyberpear> yes, it technically works
18:24:15 <cyberpear> but probably need to bring in the galaxy folks if they've got semver hardcoded and we actually want to go non-semver
18:24:16 <felixfontein> I mean, how do you want to relesae a new ACD version which doesn't break backwards compatibility if you have to check every of the 50+ collections manually?
18:24:27 <gregdek> We need the semantics of semver to glue things together, but the strict meanings of x.y.z we're probably less bound to...
18:24:30 <acozine> can we have date-related release numbers on individual collections and semver on the overall ACD version?
18:24:33 <felixfontein> does someone actually wants to avoid semver?
18:24:38 <cyberpear> Yes, ACD itself as a collection of collections will probably need something like semver
18:24:39 <felixfontein> (I don't)
18:25:01 <gundalow> AFAIK collections today MUST be semver
18:25:06 <abadger1999> Hmm... things like publishing release data (3.0 will come out on Aug 27, 2021) is also something that hinges on my manpower question.
18:25:07 <gregdek> Yes, that's correct
18:25:22 <acozine> ah, okay
18:25:45 <felixfontein> abadger1999: in particular the 27th of december dates will be funny :)
18:26:28 <felixfontein> it might be better to have a somewhat more flexible schedule, and only fix more concrete dates some time before the release
18:28:40 <cyberpear> we don't announce dates for ansible itslef
18:28:48 <gundalow> "guide dates, subject to change"
18:29:00 <cyberpear> (or we do a poor job... freeze is nominally Saturday, IIRC)
18:29:41 <felixfontein> gundalow: or just specify a month for everything that's further than 2-3 months away
18:29:53 <gundalow> I'm happy for Ansible (ACD) to have dates that can change. This is a community project, with community resource.
18:29:57 <felixfontein> 3.0.0 will be released in august 2021
18:31:12 <gundalow> Ok, what do people think the next steps are?
18:31:28 <gundalow> or the specific questions that need answering?
18:31:49 <felixfontein> I think we should vote (maybe just tentatively, to get an idea what people want) on a few more specific things
18:31:56 <gregdek> +1
18:32:07 <gundalow> yup, sounds good
18:32:23 <gundalow> felixfontein: got any specific questions in mind?
18:32:26 <felixfontein> like 1) semver vs. other versioning? 2) how often new features, how often breaking changes (i.e. major releaes for semver)?
18:32:28 <andersson007_> gundalow: about comments, yep.  i'm taking part in an unplanned release at my day work now, so can't be actively involved here
18:32:48 <felixfontein> more questions depend a bit on the answers to these two :)
18:32:52 <gundalow> andersson007_: don't worry about it you've been doing lots of great stuff
18:33:13 <felixfontein> gundalow: andersson007_: indeed!
18:33:29 <andersson007_> gundalow: felixfontein: thanks:)
18:33:39 <gundalow> I think moving away from semver for collections is a wider discussion, and I'm concerned that it might not go anywhere
18:33:40 <felixfontein> so. does someone prefer something other than semver?
18:34:23 <felixfontein> gundalow: I agree, I mainly want to know if someone currently prefers to not use semver, or if everyone would be happy with semver
18:34:47 <gundalow> QUESTION: Anyone interested in non-semver for collections
18:35:14 <abadger1999> semver for collections will mean that constructing ACD/ansible gets harder.
18:35:32 <felixfontein> abadger1999: do you mean '*not* semver'?
18:35:41 <abadger1999> felixfontein: yes, sorry.
18:35:57 <felixfontein> ok :) I fully agree then
18:36:05 <cyberpear> semver for collections means that you bump the X or Y if an X or Y of an included collection was bumped
18:36:20 <abadger1999> If collections do not use semver, constructing ACD/ansible will require collection owners tell the ansible builder which versions to include for every major and minor release.
18:36:21 <cyberpear> *bump ACD if an included colleciton was bumped
18:36:25 <gregdek> I think that non-semver for collections is off the table.
18:36:39 <gregdek> And maybe we should agree that here, even if everyone doesn't love it.
18:36:40 <abadger1999> It's possible (Give me a version range and I can manually stuff it in the file).
18:36:50 <abadger1999> But it requires more human interaction.
18:37:08 <cyberpear> I'd only ask that if we're doing semver, we do it right.
18:37:32 <cyberpear> is ACD itself semver?
18:38:11 <gundalow> ok, so some terminology
18:38:31 <felixfontein> if ACD wants to use the same version numbers as ansible-base, it cannot be semver
18:38:39 <cyberpear> if semver for ACD itself, it seems reasonable that every release will have some deprecated items removed, hence a major version bump; otherwise, point releases could be Y releases if new features are allowed, or Z releases if features are not allowed
18:38:41 <gundalow> ansible-base = gh/ansible/ansible
18:38:55 <cyberpear> https://github.com/ansible/community/issues/539#issuecomment-634846106
18:38:59 <gundalow> ansible 2.10 will be `ansible-base` + subset of collections
18:39:36 <gundalow> so the `ansible` package will continue the non-semver Ansible versioning format
18:39:45 <gundalow> Maybe that will change in 3.0, unsure
18:39:49 <abadger1999> Errrr....
18:39:58 <gundalow> abadger1999: did I get that wrong?
18:39:59 <felixfontein> gundalow: that would be 3.0.0 then ;)
18:40:11 <gundalow> felixfontein: ah, yes
18:40:13 <abadger1999> ansible-base will definitely continue non-semver versioning for now.
18:40:20 <gundalow> abadger1999: +1
18:40:21 <felixfontein> will 2.10.1 only contain bugfixes, or also new features (compared to 2.10.0)?
18:40:26 <abadger1999> ACD/ansible we can control our own dstiny.
18:40:31 <cyberpear> I think switching to semver for ansible itself should be a much larger discussions
18:40:50 <abadger1999> The release schedules of ansible-base and ansible are going to get out of sync fairly rapidly, it looks like.
18:41:08 <felixfontein> I guess for the first ACD releases, sticking to the ansible version numbering system is helpful to avoid too much confusion of users
18:41:13 <abadger1999> So after 2.10, we probably are not bound to their versioning.
18:41:45 <cyberpear> I'd suggest to match ACD to ansible version, to avoid confusion
18:41:49 <abadger1999> Should ansible be semver?  I don't know... I just wanted to be clear that we are not going to match with ansible-.base for very long.
18:42:26 <felixfontein> I think nobody really wants to start changing versioning for 2.10. so maybe let's dicsuss this once 2.10 has been released :)
18:42:31 <felixfontein> (or 2.10.0)
18:43:09 <abadger1999> felixfontein: yeah.... all of your points are good.  For your question... I currently have it coded to allow new features into 2.10.1.  But it's an easy change to make it bugfixes only.
18:43:15 <gundalow> I wonder if we are ending up in stuff that's way to far in the future
18:43:28 <abadger1999> That's a question  for you all of "What do you want?"
18:43:50 <felixfontein> ok. so I think the following is consensus: use semver for collections, in particular community.general and community.network; use old versioning schema at least for 2.10, and discuss a new versioning schema for ACD later?
18:43:55 <cyberpear> I think ACD should allow new features in 2.10.X releases, but not breaking changes
18:43:58 <gregdek> Some clarity here: ACD *is* Ansible.
18:44:02 <gundalow> ^^^^^
18:44:05 <gregdek> ansible-base is a separate project.
18:44:10 <abadger1999> felixfontein: +1  I wholheartedly agree to all of that.
18:44:12 <gregdek> We are highly dependent on one another.
18:44:19 <felixfontein> gregdek: I use ACD to make it clear I really don't mean ansible-base :)
18:44:42 <gregdek> Fair, but never use ansible when you intend to say ansible-base.
18:45:00 <abadger1999> cyberpear: Cool.
18:45:02 <felixfontein> gregdek: I hope I avoided that so far
18:45:07 <gundalow> felixfontein: I'm a solid +1 to what you said
18:45:26 <gundalow> QUESTION: Anyone against `use semver for collections, in particular community.general and community.network; use old versioning schema at least for 2.10, and discuss a new versioning schema for ACD later?`
18:45:46 <felixfontein> (if you're against it, write a quick 'no' before writing a longer explanation :) )
18:45:47 <andersson007_> LGTM
18:45:50 <gregdek> Was more for cyberbear and his comment "I'd suggest to match ACD to ansible version, to avoid confusion" to be clear
18:46:34 <cyberpear> yes, ACD version to ansible-base version
18:46:35 <gundalow> cyberpear: the first release of ansible (the package formally known as ACD) will be `2.10`, which will depend on `ansible-base@2.10
18:46:43 <gundalow> `
18:47:12 <felixfontein> so next questions from my side would be 2) how often new features (minor release) and breaking changes (major releases), 3) date vs. version based deprecation?
18:47:41 <gundalow> To step back a bit, what do we think users want/care about?
18:48:15 <gundalow> At least as fast as ansible <2.10 releases
18:48:19 <gundalow> ie, 6 months
18:48:21 <andersson007_> felixfontein: what you suggested in your gist proposal sounds good to me. we discussed
18:48:32 <felixfontein> it looks to me that a) users want new features more often, b) users want stability (i.e. avoid breaking changes)
18:48:43 <gundalow> or is their a strong need for people to get new features more frequently
18:49:03 * gundalow agrees with a & b
18:49:12 <felixfontein> especially people who contributed new features do ask when they will get released
18:49:15 <cyberpear> I think new features should come faster, perhaps monthly; breaking changes should only happen when ansible-base bumps its "major" version; e.g., 2.11 from 2.10
18:49:28 <samccann> I feel like developers have wanted to get features out faster than traditional ansible (6 months)
18:49:31 <abadger1999> felixfontein:  clarification question: for ansible/acd or for community.*?
18:49:43 <gundalow> samccann: yup, I'd agree
18:49:44 <felixfontein> cyberpear: the ansible-base cycle might slow down, possibly even to yearly "major" releases
18:49:57 <cyberpear> then you actually get a story for how end users tangibly benefit from collections
18:50:27 <cyberpear> seems fine w/ me; I guess we could revisit if it become a problem
18:50:48 <felixfontein> abadger1999: I guess mainly for collections; but they also wanted to have that for ansible in the past, so probably also for ACD - I guess the question is how many users will use ACD, and how many users will use ansible-base and just install the collections they care about
18:51:21 <cyberpear> ACD will become like EPEL, shunned by InfoSec departments
18:51:23 <gundalow> I know it's good to think about all the future implications, so we don't paint ourselfs into a corner. Though part of me feels we need to get 2.10 out there and get some real feedback
18:51:30 <cyberpear> so folks will choose the collections they actually need
18:51:35 <samccann> felixfontein: I thought someone somewhere said they expect most users to use ansible (aka acd) but I don't have anything to back that up
18:52:35 <felixfontein> samccann: I heard different things from different people; I guess it is really hard to find out until 2.10 is out and we can see what people do
18:52:39 <cyberpear> once ansible-base is a thing, I think lots of folks will try to depend on only that, to avoid dependency bloat; but probably end users will use ACD for convenience for quite some time
18:52:45 <felixfontein> gundalow: I agree
18:53:55 <felixfontein> does anyone think that new features every 6 months is enough?
18:54:25 <samccann> for a collection or for ansible ?
18:54:37 <felixfontein> I guess features every 6,  3, 2 or 1 months are good choices (good old divisors of 6 ;) )
18:54:44 <cyberpear> it's "enough" in that it matches the status quo, but doesn't give users a "benefit" of collections
18:54:49 <gundalow> cyberpear: +1
18:54:51 <felixfontein> samccann: both
18:54:56 <felixfontein> (kind of)
18:55:04 <abadger1999> cyberpear: +1
18:55:11 <samccann> collections imo need to move faster than 6 months for new features
18:55:15 <felixfontein> I'd prefer new features more often. 6 months really is a long time.
18:55:18 <acozine> would quarterly releases take the per-release pressure off?
18:55:38 <acozine> (quarterly == every 3 months)
18:55:41 <gundalow> If the versions don't contain dates, then can we start slow then ramp up release cadence
18:56:05 <felixfontein> acozine: if releasing is sufficiently automated, I assume we could even release more frequently. but then, I don't have much experience with releasing such big beasts
18:56:05 <samccann> yeah thinking individual collection owners will make their own decisions on cadence
18:56:29 <gundalow> I'm personally not as concerned about dedicated collections
18:56:51 <acozine> felixfontein: that makes sense, I just don't want to make promises we can't keep
18:56:53 <gundalow> as they, as you say, can do their own thing, and have a good understanding of most of the changes
18:57:45 <samccann> so here's a scenario I've heard - community.network as a 'breeding ground' for new ideas (aka modules). As it gains acceptance, works out the kinks, etc... that module could be 'graduated' to a more specific collection (even a supported one at some point). A slow cadence for community.network of every 6 months makes that graduation problematic/slow
18:57:47 <gundalow> "c.general and c.network will initially have major releases quarterly. This may change in the future
18:58:00 <gundalow> "
18:58:17 <felixfontein> gundalow: I really would prefer major relases less frequently
18:58:26 <andersson007_> me either
18:58:47 <felixfontein> a major release means that you have to look at all uses of that collections (which could be really a lot for large collections such as c.g and c.n)
18:58:55 <gundalow> felixfontein andersson007_: you feel going from 6 months to 3 months for major releases is too frequent?
18:59:17 <felixfontein> gundalow: I think it is
18:59:22 <andersson007_> yep, looks too frequent
18:59:25 <felixfontein> gundalow: why do you want major releases that often?
18:59:32 <samccann> losing the plot here - does a new module qualify as a major release or a minor release for a collection?
18:59:35 <gundalow> I'm just throwing stuff out there
18:59:40 <cyberpear> how about every ACD release is a feature release.  Included collections can choose their own policy, but we won't take breaking changes -- make breaking changes only coincident w/ ansible-base releases
18:59:44 <felixfontein> samccann: new module = new feature = can appear in minor version
18:59:58 <samccann> ok thanks felixfontien
19:00:03 <bcoca> switch acd to rolling releases .. then the numbering is simplified
19:00:22 <gundalow> samccann: so I believe the change is that semver is (partly) about knowing if a upgrade could break you
19:00:38 <gundalow> adding new functionality (new module) doesn't break anyone
19:00:57 <samccann> ok so major release here means breaking change within the collection
19:01:00 <cyberpear> major releases are only ones w/ breaking changes, such as deprecated feature removal
19:01:05 <gundalow> Though adding new module, refactoring module_utils and changing some default options could break people
19:01:26 * acozine has to go pick up her cat from the vet
19:01:33 <felixfontein> gundalow: every change can potentially break :)
19:01:36 <samccann> heh
19:01:49 <samccann> we have a changelog fragment type for that now!
19:01:53 <bcoca> normally 'new feature' is considered a bump cause of new 'possible inestablity' .. but new plugins should be discrete enough to avoid that
19:01:54 <samccann> (just an aside)
19:02:14 <felixfontein> samccann: true :)
19:02:54 <felixfontein> POLL: every how many months do you like to have major releases (with breaking changes) for collections? just write the number
19:03:07 <cyberpear> 8
19:03:18 <cyberpear> (only if coincident w/ ansible-base release)
19:03:39 <felixfontein> I mean for collections, not for ACD
19:03:40 <andersson007_> felixfontein: definitely no less than every 6 months
19:03:48 <andersson007_> for collections
19:03:48 <samccann> given gundalow's comment on minor changes potentially being breaking fixes, 6
19:03:58 <samccann> (for those large collections)
19:03:59 <cyberpear> included collections can make their own cycles, but ACD will only take breaking changes at a stated frequency
19:04:05 <andersson007_> 6m - 1 year
19:04:11 <gregdek> Can someone put this meeting on the calendar for next time?
19:04:11 <gundalow> 6m
19:04:13 <felixfontein> 6
19:04:47 * samccann ponders if there is some deepseated psychological comfort factor about the number 6 now
19:04:55 <felixfontein> :D
19:04:56 <andersson007_> ok, 6 is ok
19:05:07 <felixfontein> so nobody wants less than 6, it seems
19:05:25 <felixfontein> (or nobody bothered to mention it if they do)
19:05:48 <samccann> no, my earlier noise about faster than 6 was my misunderstanding about where a new module would fit in (minor version I learned)
19:06:21 <cyberpear> hence my initial "no more frequently than 6 months for breaking changes"
19:06:48 <gundalow> #action Setup this meeting https://github.com/ansible/community/blob/master/WORKING-GROUPS.md#process-for-ansible-staff
19:06:57 <felixfontein> ok. so 6 it seems to be? (for collections at least)
19:07:38 <felixfontein> POLL: how often do you like to have new features?  just write the number as in "every n months"
19:07:41 <gundalow> (agreed 6 month major release for community.general and community.network. This maybe revisited in the future)
19:07:50 <gundalow> is ^ a fair summary, any more detail I need to add
19:08:02 <felixfontein> gundalow: I think it is a fair summary
19:08:06 <samccann> gundalow: +1
19:08:12 <andersson007_> +1
19:08:19 <felixfontein> I prefer new features every 1-2 months
19:08:28 <gundalow> #agreed 6 month major release for community.general and community.network. Other collections can release at their own cadence. This maybe revisited in the future.
19:08:30 <gundalow> Thanks
19:08:40 <abadger1999> 1
19:08:47 <gundalow> ------------------
19:08:49 <gundalow> POLL: how often do you like to have new features?  just write the number as in "every n months"
19:08:50 <samccann> every month for new featurs
19:08:56 <felixfontein> 1 or 2
19:09:03 <andersson007_> 1-2
19:09:08 * samccann she sez not doing any of the work involved
19:09:10 <andersson007_> we could start from 2
19:09:21 <samccann> yeah that's a good idea
19:09:30 <cyberpear> 1
19:09:37 <samccann> start at 2 months, bring it in if needed and if the community has bandwidth to make that happen
19:09:43 <cyberpear> (not more frequently than monthly; otherwise, only as-needed)
19:09:51 <andersson007_> samccann: +1
19:09:52 <gundalow> 2+
19:10:17 <gundalow> cyberpear: would you be OK with 2 months? You appear to be the only person saying `1`
19:10:18 <andersson007_> we could start from 2, then will see
19:10:26 <gundalow> Just want to make sure we aren't missing something
19:10:28 <cyberpear> sure
19:10:33 <felixfontein> abadger1999: are you also ok with 2?
19:10:43 <felixfontein> abadger1999: I assume your '1' was for this as well
19:10:53 <abadger1999> I say 1 as well, but 2 is fine
19:11:26 <abadger1999> Just don't guarantee the release schedule out too far and we can change it as we learn more :-)
19:11:27 <cyberpear> I say "not more frequently than 1 month" but only do feature releases if there are features that need releasing
19:11:56 <felixfontein> abadger1999: I think the schedule is mostly important for major releases, and doesn't have to be up to a day ;)
19:12:35 <felixfontein> so... maybe last question for today... do you prefer deprecation by date, or deprecation by version?
19:13:14 <cyberpear> (for ACD, I think it's fine to assume every 2.10.X release might be a feature release)
19:13:23 <felixfontein> if we have major releases every 6 months with a relatively fix schedule, i.e. the exact date might vary a bit, but it will always be in the defined month, both are relatively equivalent
19:13:58 <abadger1999> By version.
19:14:00 <andersson007_> felixfontein: deprecation by version
19:14:09 <gundalow> Proposing: (#agreed New features for community.general and community.network will be released ~2 months. We will not guarantee how many major releases we do at this cadence yet. We need to get some feedback from users, contributors and maintainers to see how much work it actually is )
19:14:23 <abadger1999> By date isn't very good for end users
19:14:23 <gundalow> Feedback on ^^^, please keep me honest here
19:14:29 <felixfontein> gundalow: do you mean
19:14:34 <felixfontein> "minor" or "major"?
19:14:36 <felixfontein> (sorry for newline)
19:14:40 <cyberpear> for collections where major versions are only bumped along with ansible-base version, I think by version definitely
19:14:50 <samccann> i can say the ansible-maintained collections have decided to deprecate by date, not version
19:15:02 <samccann> whether that matters for community collections... ? dunno
19:15:24 <samccann> (by ansible-maintained I mean the internal developer team at Ansible/RH and the collections they own)
19:15:32 <cyberpear> samccann: I think that's fine as long as they match the major versions to those dates
19:15:54 <jborean93> the trouble with by version is you can't guarantee that you will stick to a cadence that the deprecation period mandates
19:15:58 <felixfontein> cyberpear: deprecation by date would be "removed in the next major release after 20xx-yy-zz" (for collections)
19:16:07 <bcoca> the 'dates' is also a automation hub issue
19:16:18 <cyberpear> ^^ yes; as long as that's what they adhere to, it's probably fine
19:16:25 <jborean93> what happens when you need to bump the major version outside of the proposed 6 month time frame
19:16:51 <gundalow> felixfontein: are we still taking specifically about community.general and community.network, therefore Automation Hub (where *S*upported content goes) is out of scope?
19:16:52 <bcoca> but it does not work the same, they select a 'specific version' and that is supported for the range, deprecations/versioning is parallel to that
19:16:53 <jborean93> now you either have features that are removed before the full 2 years, or the dep date needs to be updated for stuff that was going to be removed in that version
19:17:03 <felixfontein> jborean93: I was wondering a bit in which situations we actually have to do that
19:17:23 <felixfontein> gundalow: IMO yes
19:17:36 <cyberpear> also wondering why might need to bump major out of cycle
19:17:45 <jborean93> It's more about keeping your options open
19:18:09 <bcoca> cyberpear: ansible-base decides on a 3.0 release 2 months after you released acd
19:18:09 <jborean93> or if you want to adjust the cadence at some point in the future
19:18:15 <cyberpear> maybe for a "breaking security fix", you just violate semver guarantees
19:18:24 <jborean93> or if there's a feature in ansible-base that you need for the collection out of cycle
19:18:35 <abadger1999> By date is an end user nightmare at the moment, though.
19:18:41 <jborean93> I disagree
19:18:49 <abadger1999> Tooling can address some of that but not all
19:18:51 <jborean93> it states a date in which this feature cannot guarantee to be there
19:18:53 <bcoca> i also think 'by date' is not something people will handle well
19:18:57 <cyberpear> agreed; if I install a particular version of ACD, I don't want it to self-destruct by date
19:19:02 <cyberpear> (I know that's not implemnted)
19:19:09 <jborean93> but it won't self-destruct
19:19:18 <cyberpear> but I don't want the tooling to tell me "this is doprecated" just because a date passed
19:19:23 <jborean93> it will still require a new release for something to pick up the breaking change
19:19:28 <bcoca> jborean93: but by setting a date, that is impresison most will get
19:19:30 <cyberpear> but yesterday it didn't tell me that, but I didn't make any system changes
19:19:37 <abadger1999> But the date doesn't help you install and update things at the moment
19:19:39 <jborean93> bcoca: that's why the wording is important
19:20:08 <abadger1999> You need both the date and the versions that go along with those dates and then you can feed the versions to the tools
19:20:11 <bcoca> jborean93: wording or not, getting a deprecation w/o having 'done anything' is also something most users will find 'undesirable'
19:20:11 <jborean93> cyberpear: the dep won't appear based on the date, the dep appears if you use a deprecated feature and that tells you when you can't rely on it being there in the future
19:20:14 <felixfontein> cyberpear: it would always tell you "this feature will be removed in a release after 2020-05-xx", no matter whether that's a date in the past or future
19:20:35 <jborean93> bcoca: they will have done something, they use a deprecated feature just like it happens today with by version
19:20:46 <jborean93> exactly
19:20:52 <felixfontein> abadger1999: you also need to know to which collection the date is refering ;)
19:21:13 <jborean93> hence why the wording is important
19:21:49 <jborean93> I'm not saying dep by version isn't right, just giving you the reasons why most of the S*upported collections are using by date
19:22:04 <jborean93> it looks like runtime.yml supports both scenarios anyway
19:22:25 <cyberpear> I'll tell you on the RHEL 8 side, the deprecation by date is very confusing/annoying
19:22:44 <felixfontein> I personally find version numbers easier to handle than dates. for dates, I have to figure out whether the major release of a version was relesaed before or after this date. for a version, I just compare versions
19:23:22 <bcoca> jborean93: if this is going by AH rules .. it really should not affect 'releases not specifically flagged as supported'
19:23:30 <bcoca> you can handle deprecations independantly
19:23:38 <jborean93> bcoca; no idea what you mean by that
19:23:43 <cyberpear> saying version X.Y is EOL on "this date" is much clearer
19:23:59 <jborean93> cyberpear: versions have a support period
19:24:05 <cyberpear> sorry, AH?
19:24:06 <jborean93> that is independent from deprecating features
19:24:09 <bcoca> the date issue started becasue of how the AH wording on support was 'confusing' .. it does not mean a 'module will be supported till certain date'
19:24:10 <jborean93> automation hub
19:24:15 <felixfontein> community doesn't sell support, so we are more free :)
19:24:30 <jborean93> so on AH, there is a 24 month maintainance release
19:24:33 <bcoca> but that a 'release'  is supported till certain date and for THAT release (minor increments) you cannot deprecate anything
19:24:44 <jborean93> that will be supported for 24 since release and will have no features or breaking changes
19:24:59 <jborean93> once released people know exactly when support will end because that's based on a time period
19:25:10 <jborean93> but this is not strictly related to deprecation
19:25:15 <bcoca> so you release 1.23 .. 1.45 .. 2.2 if 1.23 is 'supported any 1.23.x is supported for that period and cannot have deprecations/removals
19:25:25 <jborean93> bcoca: you can still have the warnings in there to tell people, hey stop using this
19:25:28 <bcoca> after that period a new release is chosen, bu t1.45 can deprecate/remove all you want
19:25:36 <jborean93> you can't remove but you can still deprecate
19:25:38 <bcoca> jborean93: those people will be in 1.23.x
19:25:48 <bcoca> not in 1.45
19:25:51 <jborean93> why not
19:25:55 <bcoca> since 1.45 is not covered as supported
19:26:13 <jborean93> I don't get why you can't add the deprecation message to that
19:26:14 <bcoca> only ONE release is supported
19:26:15 <felixfontein> people can also stick to community.general 1.x.y for as long as they want - they eventually won't get new features and bugfixes and security fixes, but they also get no features removed
19:26:22 <bcoca> jborean93: you can .. but it makes little to no sense
19:26:29 <jborean93> I don't get what you mean
19:26:42 <bcoca> only 1.23.x needs 'per date' deprecation in this scenario
19:26:56 <jborean93> whatever is the current maintained releases will need it
19:27:00 <bcoca> and its not per plugin, the whole release is unsupported
19:27:12 <bcoca> jborean93: no, that is the point, 'current' doesnt matter, 'supported' does
19:27:21 <bcoca> for the AH case
19:27:23 <jborean93> sure a collection author can deprecate whenever they want and not support something for 2 years
19:27:26 <bcoca> and the period
19:27:32 <jborean93> but that's really annoying for people on the rollign release
19:27:38 <bcoca> yep
19:27:45 <bcoca> i pointed that out
19:27:53 <felixfontein> I get the feeling that deprecations with versions are still more clear (especially if there is a table "which major verisons of collection A are still supported, i.e. get new minor/patch releases")
19:27:53 <jborean93> you can say the same thing for dep by version
19:27:57 <bcoca> but anyone adding to AH is signing up for those rules
19:28:08 <jborean93> felixfontein: but that's different from deprecation
19:28:10 <bcoca> jborean93: not really, since there it is clear what 'next is'
19:28:38 <bcoca> with the supported/period, you dont know what the 'next supported' is
19:28:42 <jborean93> regardless of the dep by route that is chosen you can easily know what versions are supported and for how long
19:28:43 <bcoca> since it is chosen much later
19:29:06 <jborean93> next supported may not be known until release
19:29:11 <abadger1999> felixfontein: Yeah, I think for anything not trying to figure out how their developers are going to support a thing, by version is the only sane way to go.
19:29:16 <jborean93> as I said, who knows if an unexpected major version will come out
19:29:25 <felixfontein> if you have a deprecation warning that feature B in collection A you're using will be removed in version 4.0.0, you can use any version of A before 4.0.0 and still have the feature. and as long as one of these versions still has (sort of) support, you can happily use it and get fixes
19:29:31 <jborean93> and as I said, support is different from deprecation
19:29:32 <bcoca> jborean93: would not matter, 1.23.x will still be supported
19:29:34 <bcoca> yes
19:29:45 <jborean93> which is why I have no idea why we are talking about this
19:29:58 <bcoca> but the whole 'date' conversation started from taht and i think many got a misconception on how it works (ceratinly i did, till it was explained in detail)
19:30:14 <felixfontein> jborean93: we need to write the current incorrect deprecation version numbers to something new. but for that we need to know to WHAT.
19:30:44 <felixfontein> (current deprecation version numbers are ansible-base version numbers from the pre-ansible-base era)
19:30:47 <jborean93> and that's the reason why dep by version is potentially problematic
19:31:36 <jborean93> dep by date, 1. you are enforcing a minimum 2 year period for deprecations, 2. you aren't tied into removing it against a certain version number (which can break point 1)
19:31:51 <cyberpear> dep-by-version will only ever be a major version in semver world. if you have to do an unexpected major version bump, either remove it sooner (time-wise) than you planned, or update extend the dep cycle to the next release
19:32:02 <jborean93> a 24 month S*upported release may go beyond that 24 month period (i.e deprecated before the initial release) but due to semver it won'y be removed
19:32:17 <abadger1999> cyberpear: +1
19:32:20 <jborean93> cyberpear: that's the problem we can't remove it earlier time wise
19:32:28 <jborean93> that goes against our promise of a 2 year deprecation window
19:32:36 <gundalow> Yup, `we need to write the current incorrect deprecation version numbers to something new. but for that we need to know to WHAT` is my main question at the moment
19:32:37 <felixfontein> ok. does anyone who is not in the *S*upported world want deprecation by date? :)
19:32:44 <bcoca> again, the promise is not on the 'current release'
19:32:52 <cyberpear> so only announce single major version dep cycles?
19:32:57 <cyberpear> then extend as necessary?
19:33:00 <felixfontein> jborean93: for community, I think we have some discretion to break promises :)
19:33:05 <jborean93> that'
19:33:17 <jborean93> that's fair enough, just giving you the reasons why dep by versoin is chosen by others
19:33:20 <jborean93> both are valid use cases
19:33:28 <jborean93> bcoca: says who
19:33:32 <jborean93> that's not what I've heard
19:33:42 * gundalow notes we are at the 90 minute mark
19:33:46 <felixfontein> indeed
19:33:50 <felixfontein> can we have a quick poll?
19:33:53 <bcoca> i discussed in depth with partner team, since they were the ones writing the obligations
19:33:54 <felixfontein> before we finish?
19:33:55 <gundalow> felixfontein: go for it
19:34:02 <gundalow> ---------------------------
19:34:03 <gundalow> ---------------------------
19:34:04 <gundalow> ---------------------------
19:34:18 <felixfontein> POLL: just write in one line (without much text): deprecate per version, or deprecate per date **for collections**?
19:34:18 <jborean93> bcoca: because we can always trust what they say and it doesn't change every 2nd day
19:34:19 <bcoca> jborean93:  sivel and i asked for clarification a while back, since it was very confusing
19:34:38 <gundalow> #chair jborean93 bcoca
19:34:38 <zodbot> Current chairs: abadger1999 acozine bcoca cyberpear felixfontein gregdek gundalow jborean93 samccann
19:34:42 <bcoca> jborean93: well, this was the partner contract (to get into AH) ... i hope that doesn't change every day
19:34:43 <felixfontein> (for ocmmunity collections, I mean)
19:34:49 <andersson007_> per version
19:34:51 <cyberpear> version
19:34:52 <felixfontein> (community.general and community.network to be more precise)
19:34:56 <gundalow> Please vote on just write in one line (without much text): deprecate per version, or deprecate per date **for *COMMUNITY** collections**?
19:35:08 <gundalow> specifically community.general and community.network
19:35:14 <felixfontein> deprecate per version
19:35:26 <gundalow> deprecate per version
19:35:46 <cyberpear> deprecate per version
19:35:50 <bcoca> well, the 'per colleciton' matters less than 'what is the requirement to be in ACD';
19:36:02 <bcoca> if 'no requirement' .. then it becomes per collection
19:36:56 <abadger1999> deprecate per version
19:37:23 <samccann> deprecate by version
19:37:40 * gundalow wonders if a decision was reached
19:37:47 <jborean93> should I do a count :)
19:37:49 <samccann> (keeping in mind neither a developer nor user so just going by what I would want to know if an app on my iphone was gonna remove something I used)
19:38:37 <felixfontein> nobody wrote 'date' yet after the poll started
19:38:38 <cyberpear> 5 votes for version; 9 attending, 0 opposed so far
19:39:02 <gundalow> #agreed derecation per version for c.g and c.n (5 votes for version; 9 attending, 0 opposed)
19:39:06 <gundalow> cyberpear: thanks for counting
19:39:12 <felixfontein> thanks indeed!
19:39:13 <bcoca> ^ but my question stands, is there a 'version system' requirement for ACD (and deprecation one)?
19:39:49 <felixfontein> bcoca: ACD will assume that collections use semver, and will have no breaking changes in 2.10.x releases; the next "major" release will probably just use the latest major versions of collections
19:40:08 <bcoca> so no requirements
19:40:11 <felixfontein> i.e. no guarantee that breaking chnages will be announced 24 months ahead for ACD
19:40:24 <samccann> ooch
19:40:38 <felixfontein> I hope most collections will do it
19:41:05 <cyberpear> then there's the question of whether we community want to support ACD 2.10 after ACD 2.11 is out
19:41:06 <samccann> is there any magic in porting guides/changelogs that would let  an ansible user know that what they depend on will be gone by x version or y date for ansible-xxx in the future?
19:41:09 <felixfontein> but I also bet that there will be at least one who won't - nothing concrete on my mind, just experience and knowing that there are 50+ collections in ACD :)
19:41:11 <bcoca> i would make that clear in acd docs, that 'deprecations are up2 the collection maintaners and that acd does not enforce anything' .. currently site reflects ansible2,9 policies
19:41:37 <bcoca> which go on 4 version deprecation cycle
19:41:46 <cyberpear> I'd say ACD shouldn't bump major collection versions w/in a single 2.10 or 2.11 release of ACD (assuming versioning number matches ansible proper)
19:41:46 <felixfontein> samccann: the changelog / porting guide would mention breaking changes. assuming people read it *before* installing the next major version :)
19:41:55 <samccann> LOL yeah there is that
19:41:57 <cyberpear> ^ "criteria for ACD inclusion" is a separate question, probably has to wait next time? -- (are we weekly for now?)
19:42:04 <gregdek> We don't know.
19:42:13 <bcoca> cyberpear: but 'major' doesnt mean anything unless you enforce a versioning standard
19:42:26 <gregdek> We haven't announced the meeting on the calendar, and the only folks here are the folks felixfontein tagged in the issue :)
19:42:32 <abadger1999> samccann: felixfontein It could be a good idea to have a deprecations changelog entry
19:42:37 <cyberpear> sure, it's up for discussion.
19:42:42 <felixfontein> bcoca: we use "major" (in quotes) for 2.10.0, 2.11.0, 2.12.0
19:42:48 <cyberpear> yeah, we should do an ansible-devel list announcement for the next meeting
19:42:52 <felixfontein> abadger1999: there already is :)
19:42:57 <gundalow> cyberpear: for 2.10 I'm not expecting to be any new collections added
19:43:02 <bcoca> felix that is following a standard, 'date' or 'rolling' release collections wont have those
19:43:09 <abadger1999> Cool, so samccann is the deprecation entry what you want?
19:43:09 <felixfontein> abadger1999: `deprecated_features` category, and `removed_features` category
19:43:24 <samccann> abadger1999 yeah
19:43:45 <samccann> so today, a user has to scroll the porting guide before updating to know something is gone (or will go in the future)
19:43:56 <gundalow> #info You can see the list of Collections which make up Ansible 2.10 in https://github.com/ansible-community/ansible-build-data/blob/master/2.10/acd.in
19:44:01 <felixfontein> of course we have to hope that collection authors actually write changelogs, and (when they do) that they don't forget to mention deprecations / removals
19:44:06 <samccann> an ansible 2.10 ,  they will do the same thing, but it will be autogenerated porting guide from those fragments
19:44:07 <abadger1999> samccann, acozine: what bcoca said is somthing we'll have to address too.... ansible-base has one deprecation policy and ansible has a different one.
19:44:30 <jborean93> and each collection cna then have their own
19:44:47 <samccann> abadger1999: yeah, we're getting more and more of those differences. We will likely need to split the docs to cover it
19:44:51 <abadger1999> <nod>  yeah... the ansible deprecation policy will be: Look at the individual collections.
19:44:52 <bcoca> jborean93: depends, collections going to AH have a set of rules they need to follow, ACD can impose their own
19:45:06 <bcoca> or chose not to
19:45:15 <jborean93> then what happens if ACD's policies mismatch with the ones on AH
19:45:22 <bcoca> fun!
19:45:23 <felixfontein> bcoca: if we want to have all modules contained in 2.9, we're more dependent on collections than able to impose rules
19:45:25 <samccann> #action samccann to start a tracking docs issue on what ansible-base has for deprecation etc vs what community collections may have vs ansible-maintained collections etc
19:45:28 <bcoca> jborean93: they already do
19:45:39 <felixfontein> (if we don't want to fork collections and maintain them by ourselves)
19:45:41 <bcoca> but mismatch is not as much of anissue as 'incompatible mismatch'
19:46:10 <jborean93> which is why I said each collection can have their own
19:46:12 <felixfontein> jborean93: I would assume that usually AH's policies are a more strict superset of the ACD policies
19:46:33 <bcoca> felixfontein: one would hope we can maintain that state
19:46:36 <jborean93> well they are going a different dep route, i.e. by date not version
19:46:40 <bcoca> otherwise it becomes very hard
19:46:44 <felixfontein> we will try to make the best result with the conditions we have to work with :)
19:47:06 <bcoca> jborean93: check with partner team, i think you are using the same def i did before they clarified
19:47:10 <felixfontein> jborean93: as long as they stick to semver, it's kind of ok
19:47:23 <felixfontein> (if we don't mandate something else in our policy - which I guess we won't)
19:47:57 <cyberpear> if the dates line up, ACD might choose a *S*upported collection version to include for a particular release, if convenient
19:48:07 <gundalow> cyberpear: nop
19:48:12 <gundalow> hum
19:48:15 <felixfontein> I guess the most basic requirements for collections in ACD is a) stick to semver, b) have a changelog / porting guide with AT MINIMUM breaking changes
19:48:30 <cyberpear> ^ maybe also deprecations
19:48:35 <cyberpear> (we're going on 2 hours now... do we want to meet twice weekly until things settle a bit?)
19:48:46 <gundalow> cyberpear:  acd will be made up of https://github.com/ansible-community/ansible-build-data/blob/master/2.10/acd.in
19:48:59 <gundalow> you can see there are some `ansible.` packages in there which are *S*upported
19:49:08 <cyberpear> yep, understood
19:49:18 <felixfontein> cyberpear: for the first couple of weeks twice per week could be good, after that I hope weekly will be enough (or even biweekly, let's see)
19:49:44 <gundalow> #topic next meeting
19:49:47 <felixfontein> ok. so let's end the meeting for today!
19:49:49 <felixfontein> heh :)
19:49:55 <cyberpear> but say ACME, INC decides to release a version of acme.acme on AH; if it were also included in ACD, we could also keep that particular version if we wanted
19:50:13 <cyberpear> (nevermind inclusion criteria questions)
19:50:15 <gundalow> #info We will meet again next Wednesday
19:50:40 <felixfontein> which is after the freeze, so hopefully everyone has more time ;)
19:50:48 <cyberpear> someone want to announce on -devel list?
19:50:57 <cyberpear> (maybe also -project if appropriate)
19:51:29 <cyberpear> (any blockers in the way of freeze?)
19:51:44 <gundalow> 1. Create yml which will create the ics file
19:51:44 <gundalow> 2. Announce and link to ics
19:51:58 <gundalow> I believe ansible-base 2.10 beta1 is still on for Monday
19:52:10 <gundalow> Thanks everybody
19:52:12 <gundalow> #endmeeting