18:07:14 <gundalow> #startmeeting Ansible Community Meeting
18:07:14 <zodbot> Meeting started Wed Jun 17 18:07:14 2020 UTC.
18:07:14 <zodbot> This meeting is logged and archived in a public location.
18:07:14 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:07:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:07:14 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:07:28 <felixfontein> andersson007_: cyberpear: acozine: samccann:
18:07:33 <cyberpear> o/
18:07:38 <andersson007_> hi
18:07:40 <gundalow> #chair felixfontein cyberpear acozine andersson007_
18:07:40 <zodbot> Current chairs: acozine andersson007_ cyberpear felixfontein gundalow
18:08:00 <andersson007_> abadger1999?
18:08:30 <felixfontein> #info agenda: https://github.com/ansible/community/issues/539
18:08:38 <gundalow> Just pinged him, hopefully abadger will appear shortly
18:08:51 <felixfontein> #info last community.general / community.network release questions: https://github.com/ansible/community/issues/539#issuecomment-642218822
18:09:09 <felixfontein> hi abadger1999! :)
18:09:13 <abadger1999> Hello :-)
18:09:17 <gundalow> #chair abadger1999
18:09:17 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein gundalow
18:09:26 <felixfontein> #topic version 1.0.0 of community.general and community.network: when will it happen?
18:09:30 <abadger1999> apologies, I didn't notice that irccloud dropped me from the channel last night
18:09:51 <felixfontein> abadger1999: you're also missing in #ansible-devel
18:09:59 <felixfontein> (and I forgot to check more channels...)
18:10:01 * abadger1999 rejoins there too
18:10:46 <felixfontein> ok. my original proposal was to have a 1.0.0 release of community.general / community.network at end of July
18:11:08 <felixfontein> so that we have a couple of weeks between that and ansible-base 2.10 final release, and ansible 2.10 release
18:11:39 <felixfontein> #info current ansible-base roadmap: https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_10.rst
18:12:03 <felixfontein> ansible-base currently plans RC1 for July 14, and final release for August 13
18:13:04 <gregdek> Did beta 1 go out or no?
18:13:04 <felixfontein> so what do you think? is end of july too early / too late / ...?
18:13:14 <felixfontein> gregdek: not yet, and freeze didn't happen either
18:13:51 <felixfontein> (though I heard they really want to freeze today, if shippable isn't making that too hard again)
18:13:56 <gundalow> #info ansible-base beta 1 should be today
18:14:15 <gundalow> yup, assuming Shippable is working
18:14:26 <gregdek> It's certainly a date to shoot for :)
18:14:39 <felixfontein> #chair gregdek
18:14:39 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein gregdek gundalow
18:15:05 <andersson007_> felixfontein: do we need to choose an exact release day today? or we can change that according to the situation with ansible base or anything else?
18:15:41 <gregdek> It's always good to have a target. Missing that target is ok, but it gives everyone a goal to shoot for and to communicate. My $0.02
18:16:05 <felixfontein> andersson007_: no, we don't have to, but it would be nice to have a more specific range - because by the 6 months per major release rule an d2 months per minor release rule, this also fixes approx times for all other releases :)
18:16:29 <gundalow> #chair rbergeron
18:16:29 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein gregdek gundalow rbergeron
18:16:38 <felixfontein> the exact day is not so important, but end of july is different than say mid of august, or beginning of july
18:17:10 <gundalow> Yup, I'd like us to have an aim as 1) Motivation 2) forces us to go "oh, erm, what about X". Though also I'm not going to lose any sleep if we slip the date
18:17:16 <felixfontein> or september (though I'd think we really should have 1.0.0 *before* ansible 2.10 is released ;) )
18:17:43 <felixfontein> I would definitely want to have 1.0.0 at minimum a few days after ansible-base RC1
18:19:22 <felixfontein> how about: let's aim for last week of July, and thus 2.0.0 for somewhen in January 2021, 3.0.0 somehwn in mid 2021, 4.0.0 in beginning of 2022, etc. (getting a bit less precise for every next version :) )
18:19:44 <gundalow> +1 to all that
18:20:20 <andersson007_> why not. +1
18:20:52 <gregdek> Less certain about future dates, of course -- maybe we can say them in principle, but we should be clear that things are still pretty uncertain right now
18:21:18 * abadger1999 imagines them fading off into grayscale
18:21:31 <abadger1999> the date works for me too.
18:21:53 <felixfontein> 100.0.0 will be released somewhen between 2050 and 2090 ;)
18:22:48 <mattclay> gundalow: Shippable is working again. The GitHub outage today may have been responsible. We're proceeding with the beta release and creation of the stable-2.10 branch.
18:22:49 <felixfontein> ok. does anyone wants to formally vote on this?
18:23:15 * samccann finally shows up
18:23:23 <felixfontein> #chair samccann
18:23:23 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein gregdek gundalow rbergeron samccann
18:25:12 <andersson007_> felixfontein: i want:)
18:25:44 <felixfontein> ok :)
18:26:23 <felixfontein> VOTE: is the following schedule ok: 1.0.0 to be released in last week of july (might slip if ansible-base RC1 hasn't been released by then), 2.0.0 for somewhen in January 2021, 3.0.0 somehwn in mid 2021, 4.0.0 in beginning of 2022, etc.
18:26:27 <felixfontein> +1
18:26:31 <andersson007_> +1
18:26:37 <samccann> +1
18:27:04 <cyberpear> +1 for "roughly"
18:27:05 <gundalow> mattclay: thanks for the update
18:27:20 <gundalow> rbergeron: ^
18:27:27 <gundalow> +1
18:27:30 <felixfontein> abadger1999:
18:28:16 <abadger1999> +1
18:28:49 <felixfontein> #agreed 1.0.0 to be released in last week of july (might slip if ansible-base RC1 hasn't been released by then), 2.0.0 for somewhen in January 2021, 3.0.0 somehwn in mid 2021, 4.0.0 in beginning of 2022, etc. (6 yes, 0 no)
18:28:53 <felixfontein> #chairs
18:28:54 <felixfontein> #chair
18:28:54 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein gregdek gundalow rbergeron samccann
18:29:14 <felixfontein> acozine: gregdek: if you want to say no, please do so quick :)
18:29:33 <gregdek> I don't say no. :)
18:29:43 <samccann> acozine went to grab some quick lunch
18:29:54 <felixfontein> samccann: true, sorry I forgot...
18:29:59 <felixfontein> ok :)
18:30:06 <gregdek> But it may be early to make a binding decision.
18:30:07 <felixfontein> so. next question: do we need a freeze period for 1.0.0?
18:30:12 <felixfontein> (and if yes, how long?)
18:30:24 <felixfontein> #topic should 1.0.0 have a freeze period, and if yes, how long?
18:31:03 <felixfontein> the longer I think about this, the less I'm sure there should be a freeze period with RCs and bugfix backports only during that period
18:31:11 <felixfontein> well, maybe for a couple of days, but not for full two weeks
18:31:21 <felixfontein> (my original suggestion was two weeks)
18:31:53 <samccann> hmm
18:31:58 <samccann> thinking out loud here -
18:32:18 <samccann> as a user, I'd want to exercise that RC for a bit, right? That's part of the reason for it.  a couple of days isn't much time
18:32:40 <felixfontein> the big question from my side: would actually anyone test this RC?
18:32:43 <samccann> from a developer perspective, being able to add new things right up to two days before sounds great
18:32:50 <samccann> heh yeah that was going to be my 2nd question
18:32:54 <felixfontein> :)
18:33:15 <samccann> with all the moving parts all moving separately now, that same user gonna be like 'huh?" on trying to track when to hop in and test something new.
18:33:22 <samccann> unless they are waiting for a fix of course
18:34:06 <samccann> Though even 'waiting for the fix' people might want more than a couple of days, depending on how closely they are watching everything.  Do we know what other upstream projects do other than ansible/ansible?
18:34:36 <gundalow> regarding testing, I'd thrown some random ideas of things/projects I'd like to test the new `ansible` package https://github.com/ansible-collections/overview/issues/55
18:34:38 <felixfontein> they could of course already install the latest default branch from git, and try that one
18:35:07 <andersson007_> i think there isn't a lot of volunteers to test RC.. i've never noticed bunches of bug reports after RC
18:35:09 <samccann> perhaps the flip question - how much testing do we get for alpha/betas in ansible/ansible in the past?
18:35:52 <samccann> s/testing/volunteers and bugs/ to mach what anderssonn007_ brought up
18:36:24 <felixfontein> I'm usually working with devel on my machine (if it's not broken), and use RCs during dayjob. but I'm not sure whether I'd bother to install RCs of individual collections as well
18:36:34 <felixfontein> (except on my machine, but there I'm using the default branch as mentioned)
18:37:01 <felixfontein> I think ansible as a full release definitely gets some testing
18:37:15 <felixfontein> but individual collections will probably not really get much testing, except from a few people really interested in them
18:37:27 <cyberpear> maybe if it's for folks via pip or RPMs on rawhide...
18:37:34 <felixfontein> and things like community.general / community.network are probably "too general" to have much RC testing
18:37:45 <gundalow> This is a bigger change, closer to a 3.0, so I'd really like to see a point where we publicaly say "We think we are good, please really test this", then we fix ansible-base and/or some collections
18:38:24 <felixfontein> gundalow: but that's more like a call for testing ansible (as in ACD), not individual collections
18:38:44 <gundalow> oh, yes
18:38:46 <gundalow> sorry
18:38:48 <felixfontein> so if our 1.0.0 ends up in ansible RC 1 (which includes some RC of ansible-base), that one would probably get tested
18:38:59 <cyberpear> same difference to most folks, though...
18:39:12 <felixfontein> if bugs are found, we can maybe squeeze a minor release in which ends up in ansible 2.10 final
18:39:26 <abadger1999> Yeah, I think right now we don't know quite what type of opensource scenario collections will fall into... are they like gimp as a part of gnome whre people would test an rc of gimp separately?  or are they like the flash plugin was to firefox?
18:39:30 <felixfontein> cyberpear: ansible RC 1 would be available via pip I think
18:40:03 <felixfontein> IMO more like the flash plugin...
18:40:38 <abadger1999> yeah, if that happens, people probably won't test hte rcs at all and many won't download the final until it ends up bundled as part of ansible.
18:41:25 <abadger1999> ansible rc1 will be available as part of pip.
18:41:46 <abadger1999> the ansible release will lag behind the ansible-base release but i'm not sure how much yet.
18:42:05 <cyberpear> maybe tag the collections as rc until ansible itself it's released? but at that point, just make a 1.0.1 if needed
18:42:08 <abadger1999> (I'm going to release ansible-2.10-alhpha1 to pip soon after ansible-base-beta1 is released)
18:42:43 <felixfontein> cyberpear: patch releases are problematic, as it doesn't work well with our current release branch plan where we allow feature backports
18:43:15 <felixfontein> we'd either need another branch (stable-1.0) and bugfix backports have to go both to stable-1 and stable-1.0, or we have to disallow feature backports for some time
18:43:55 <felixfontein> also (partially related), it seems that most ansible-controlled collections do their 1.0.0 release this or next week
18:44:22 <felixfontein> so we're already kind of "late" :)
18:44:25 <cyberpear> I guess my main point was that if issues are found, we just make a new release that fixes issues
18:44:43 <felixfontein> yes, but we can also do a minor release which includes features as well
18:45:00 <felixfontein> that would require no special branching
18:46:49 <abadger1999> that would be fine with me... assuming that users aren't going to test rc's I don't see any problems with having a quick 1.1.0, 1.2.0, etc if needed
18:47:30 <cyberpear> agreed
18:47:53 <felixfontein> would be fine for me too... we could add (because we said minor releases every two months) that before ansible releases, more minor releases could happen
18:48:11 <felixfontein> *ansible "major" releases
18:49:18 <felixfontein> so: should we do a freeze for c.g and c.n, or not?
18:49:36 <felixfontein> resp. does anyone wants to discuss this further, or should we vote?
18:50:53 <abadger1999> No further discussion needed for me.
18:51:12 <felixfontein> VOTE: should we have a) a freeze before 1.0.0, b) no freeze?
18:51:13 <felixfontein> b)
18:51:21 <andersson007_> b
18:51:44 <samccann> b
18:51:58 <abadger1999> b
18:52:57 <cyberpear> b
18:53:07 <felixfontein> #chair
18:53:07 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein gregdek gundalow rbergeron samccann
18:53:15 <felixfontein> (quick way to ping everyone ;) )
18:53:18 <gregdek> Heh
18:53:28 <acozine> b
18:53:31 <cyberpear> or just the few hours it takes to cut the release
18:53:32 <gregdek> I abstain, not knowing enough :)
18:54:04 <acozine> we can just pick a commit and designate that as the release point, right?
18:54:07 <felixfontein> cyberpear: that will happen anyway. there'll be a branch, and then 1-2 commits to the default branch to bump it to the next version, and then the release process will happen in the branch (I guess)
18:54:40 <acozine> s/release/branch/
18:54:42 <felixfontein> acozine: the changelog needs to be generated, and maybe some other maintenance things, so it will take slightly more than that
18:54:46 <gundalow> b
18:55:10 <felixfontein> I guess we'll find out when doing the 0.2.0 release what's exactly needed :)
18:56:04 <felixfontein> #agreed 1.0.0 is released with no freeze (7 yes, 1 abstain, 0 no)
18:56:12 <felixfontein> ok
18:56:17 <felixfontein> we almost filled one hour....
18:56:18 <acozine> heh, well, I still vote for b . . . if the whole thing blows up in our faces, we'll learn why we need to freeze next time
18:56:29 <felixfontein> acozine: true :)
18:56:56 <felixfontein> VOTE: should we do minor releases more frequently around ansible releases, if necessary? (i.e. deviate from the 2 months between minor release rules)
18:57:04 <felixfontein> (just a quick follow-up vote :) )
18:57:07 <abadger1999> +1
18:57:09 <felixfontein> +1
18:57:11 <abadger1999> Do what's needed.
18:57:58 <samccann> ditto ^^
18:58:20 <andersson007_> if necessary +1
18:58:26 <gundalow> I view all decisions as "based on our current understanding, we reserve the right to be educated along the way and change how things are done in the future"
18:58:48 <felixfontein> good :)
18:59:16 <acozine> +1
18:59:26 <felixfontein> #agreed if necessary, we deviate from the minor release cycle, especially when an ansible release is coming up, to get bugs fixed
18:59:31 <felixfontein> (and hopefully no new introduced ;) )
18:59:39 <gundalow> woot
18:59:43 <felixfontein> yay :)
19:00:10 <felixfontein> should we talk about the last topic: changelog fragments for *every* PR (there's the `trivial` category), or do you want to move it to next week?
19:00:39 <samccann> you could try a quick vote and see if there's agreement or not :-)
19:00:42 <felixfontein> short background: during one of the docs meetings we decided to have a `trivial` changelog fragment category, which is recorded in changelog.yaml, but NOT written to the generated .rst file
19:01:06 <felixfontein> POLL: discuss changelog fragment policy now (+1), or next week (-1)?
19:02:04 <felixfontein> +1
19:02:15 <samccann> heh was thinking POLL to see if everyone agreed on `trivial` :-)
19:02:21 <samccann> +1
19:02:24 <acozine> 0 from me - I'm happy to discuss but it's the middle of my day and I just had lunch . . . happy to push it off if folks need to move on to other activities
19:02:26 <gundalow> what's the aim
19:02:37 <felixfontein> the advantage of using the `trivial` category is that we can simply require that every PR has a changelog fragment (which can be automatically tested, so nobody has to manually write this everywhere)
19:02:58 <gundalow> ah, cool
19:03:01 <acozine> no more "please add a changelog fragment" comments
19:03:07 <felixfontein> right now it is often andersson007_ or me who writes "Could you please add a changelog fragment?" with a link to the changelog fragment docs
19:03:10 <gundalow> Yup, that's not the bets use of people stime
19:03:10 <samccann> also builds 'memory muscle' to think about a changelog every time you make a change
19:03:12 <andersson007_> what about doc prs?
19:03:31 <acozine> `trivial: corrects typo` seems like a reasonable changelog
19:03:43 <andersson007_> ok
19:03:46 <andersson007_> agreed
19:03:48 <felixfontein> it would be `trivial:` and next line `- correct typo` :)
19:03:53 <samccann> my personal nickel on doc prs is they should have a changelog if they are something major.  like "look to the collections now for all the module docs' kind of thing
19:04:03 <samccann> otherwise, `trivial`
19:04:35 <andersson007_> it's annoying to put "please add a fragment" to 99% of prs..
19:04:36 <samccann> oh `trivial` needs words added to it?  hmm.  Thought it could just be a near-empty fragment
19:04:41 <felixfontein> I guess the next discussion would be what qualifies as trivial and what not ;)
19:04:48 <acozine> could we set up something on GitHub that checks for a changelog entry and adds a template to any PR that doesn't already have one?
19:05:00 <felixfontein> samccann: no, it's a regular fragment, with lines of text in it
19:05:51 <gundalow> +1 to this, we can add some logic in ansible-test  to a) only require on certain repos b) not require if only changes are docs (or test/utils/)
19:06:15 <felixfontein> gundalow: detecting docs-only changes isn't that easy
19:06:25 <felixfontein> especially for plugins, where the argspec is part of the docs
19:06:34 <gundalow> oh, yes, I was thinking about docs directories
19:06:35 <acozine> I'd say if we're changelogging everything, we changelog the docs too
19:06:46 <cyberpear> presumably reviewers would say if it's not trivial
19:07:02 <felixfontein> cyberpear: that assumes that the reviewers know the categories ;)
19:07:05 <gundalow> So, is this something we think we need sooner or later?
19:07:21 <felixfontein> I'm fine with later, it's not that pressing an issue right now :)
19:07:53 <felixfontein> we'd need a) document that category in the ansible docs, b) start using it ourselves, c) add support to ansible-test and/or ansibullbot
19:08:01 <gundalow> ok, so summary: we think this is sensible, though not a priority for now
19:08:16 <felixfontein> <nod>
19:08:30 <gundalow> if it's not for (say) pre 1.0.0 I think we punt it for later
19:08:59 <felixfontein> we could try to start it with the 1.0.0 release, but let's talk about it again somewhen later
19:09:15 <felixfontein> ok
19:09:52 <felixfontein> #info consensus seems to be that every PR should eventually have a changelog fragment (with the `trivial` category if necessary), but right now it's not a priority
19:10:29 <felixfontein> #topic open floor
19:10:42 <felixfontein> we never had that before I think :)
19:11:16 <gundalow> Nothing else from me
19:11:21 <acozine> cool!
19:11:28 <felixfontein> my next step will be to write everything up we decided for releasing c.g and c.n as a gist, ask you all to look over it, and if it looks good to post it in the repos
19:11:28 <acozine> (having an open floor, I mean)
19:11:38 <acozine> awesome, thanks felixfontein
19:12:20 <felixfontein> I hope I won't encounter important things that we didn't discuss ;)
19:12:35 <nitzmahone> felixfontein: any chance you feel like rebasing that batch of ansible-test backports to 2.9?
19:12:53 <felixfontein> nitzmahone: you mean the WIP PR I have left?
19:13:09 <nitzmahone> yeah, unless you're not worried about it for 2.9.10
19:13:11 <felixfontein> nitzmahone: https://github.com/ansible/ansible/pull/69377
19:13:22 <nitzmahone> yeah, that one
19:13:36 <felixfontein> nitzmahone: I think they are already all merged, I created individual backports, the only one missing is https://github.com/ansible/ansible/pull/69409
19:14:03 <felixfontein> I needed the "complete" one to run community.crypto tests against it until all backports were merged to stable-2.9 :)
19:14:05 <nitzmahone> ah cool
19:14:14 <felixfontein> (and in the first place to see whether it fixed the problems)
19:14:26 <nitzmahone> so once 69409 is merged, 69377 can go away
19:14:33 <felixfontein> ah, wait, maybe a couple of them don't have backport PRs yet
19:15:21 <felixfontein> I'll have to check
19:15:31 <felixfontein> but Ithink 69409 is the most important missing (at least for me)
19:20:12 <felixfontein> #endmeeting