18:02:32 <gundalow> #startmeeting Ansible Community Meeting
18:02:32 <zodbot> Meeting started Wed Nov  4 18:02:32 2020 UTC.
18:02:32 <zodbot> This meeting is logged and archived in a public location.
18:02:32 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:02:32 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:02:40 <jtanner> the intent with including tests ouput was for galaxy to present the coverage repors in the UI ... but that idea died on the vine
18:02:41 <dmsimard> o/
18:02:48 <felixfontein> I wonder if I ever get used that the meeting starts at 19:00 :D
18:02:49 <gundalow> #chair abadger1999 felixfontein tadeboro dericcrago dmsimard
18:02:49 <zodbot> Current chairs: abadger1999 dericcrago dmsimard felixfontein gundalow tadeboro
18:02:51 <andersson007_> hi
18:02:55 <felixfontein> #chair andersson007_
18:02:55 <zodbot> Current chairs: abadger1999 andersson007_ dericcrago dmsimard felixfontein gundalow tadeboro
18:03:05 <felixfontein> welcome to the community meeting!
18:03:10 <cybette> o/
18:03:19 <felixfontein> #topic agenda: https://github.com/ansible/community/issues/539#issuecomment-720085949
18:03:23 <felixfontein> #chair cybette
18:03:23 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein gundalow tadeboro
18:03:35 * dericcrago waves
18:03:35 * samccann waves
18:03:38 <abadger1999> Ola
18:03:43 <felixfontein> #chair sagredo
18:03:43 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein gundalow sagredo tadeboro
18:04:03 <felixfontein> #chair jtanner
18:04:03 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner sagredo tadeboro
18:04:06 <felixfontein> jtanner: thanks for the info!
18:04:09 * alongchamps waves
18:04:24 <dmsimard> Missing from agenda link: discussion about re-scheduling community meeting
18:04:42 <aminvakil> hi
18:04:50 <felixfontein> dmsimard: true :)
18:04:57 <felixfontein> #chair aminvakil alongchamps
18:04:57 <zodbot> Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner sagredo tadeboro
18:05:15 <felixfontein> gundalow said he's away for the first 5 minutes, so we should discuss it once he's back
18:05:17 <cybette> #chair samccann
18:05:17 <zodbot> Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner sagredo samccann tadeboro
18:05:39 <felixfontein> oh, I accidentally chaired sagredo instead of samccann. sorry for that!
18:05:46 <felixfontein> #unchair sagredo
18:05:46 <zodbot> Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner samccann tadeboro
18:05:58 <felixfontein> sagredo: you are of course free to take part in this meeting if you want :) just give a shout
18:06:12 <felixfontein> #topic announcements
18:06:20 <cybette> something about a rule of having less unique first 3 letters in nicks :)
18:06:22 <felixfontein> #info Ansible 2.10.2 has been released
18:06:26 <rockaut> heja there... first community meeting for me. how does this work
18:06:31 <felixfontein> #chair rockaut
18:06:31 <zodbot> Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner rockaut samccann tadeboro
18:07:01 <felixfontein> #info The Bullhorn 13 has been sent today https://mailchi.mp/redhat/the-bullhorn-13
18:07:27 <cybette> rockaut: check what's the current topic, and join in the discussion if you have any comments/questions
18:07:29 <felixfontein> I guess that's the main news, at least from my side
18:07:39 <abadger1999> rockaut: Basically just discuss along with the rest of us.  If you have something specific to talk about which isn't on the agenda, bring it up at open floor.
18:07:58 <rockaut> (y)  great
18:08:04 <cybette> rockaut: also good to take a look at the agenda before the meeting (if you have a chance) https://github.com/ansible/community/issues/539
18:08:11 <felixfontein> maybe let's discuss the first topic, and then switch to the meeting time (hopefully g. is around by then)
18:08:15 <abadger1999> One day we might have some more formality around voting but we haven't gotten big enough to need that yet.
18:08:30 <felixfontein> indeed :)
18:08:37 <felixfontein> #topic Should we merge small number of modules/plugins from companies?
18:08:55 <felixfontein> #info https://github.com/ansible/community/issues/539#issuecomment-714454605
18:09:07 <felixfontein> #info we started discussing it last week: https://meetbot.fedoraproject.org/ansible-community/2020-10-28/ansible_community_meeting.2020-10-28-18.02.html
18:09:29 <felixfontein> #info for larger set of new modules/plugins, we ask submitter to create their own collection
18:09:41 <felixfontein> the question is, what do we do if there are only 1-2 modules right now, but there might be a lot more later?
18:10:09 <felixfontein> if we accept them now, they maybe should be moved later, and moving is always annoying :)
18:10:17 <alongchamps> how big if a jump is it to go from one module to a whole collection, in terms of effort?
18:10:33 <alongchamps> s/if/of
18:10:40 <tadeboro> CI/CD setup is probably the biggest issue.
18:11:00 <alongchamps> collections keep it modular, and I like going down the right path the first time, personally
18:11:10 <felixfontein> yes. though setting up tests for your modules isn't that much easier, especially when it is about cloud modules or things like that
18:11:16 <dmsimard> tadeboro: is that something we can help with?
18:11:32 <jtanner> if they start in community.general, you need to go through deprecations and teach your users about the new FQN they have moved in once you move to a new separate collection
18:11:35 <felixfontein> dmsimard: to some regard, yes. depends on how much resources you have for it ;)
18:11:40 <tadeboro> But I think this is almost a solved problem because collection template contains almost everything needed to get an initial thing up and running IIRC.
18:12:02 <rockaut> out of a user perspective I would say to start even small one in an own collection. It's anoying if you have to look at versioning for this too.
18:12:05 <felixfontein> jtanner: yes, and the c.g maintainers have some hassle for moving, and redirecting later support requests
18:12:06 <abadger1999> It would be a whole new thing to learn (you don't need to know about collections at all to write a module for community.general) and you'd have to devote effort to release engineering stuff.
18:12:08 <samccann> agree with jtanner - it's a bigger user problem when they move out of c.g.
18:12:51 <felixfontein> a concrete instance of such a request is https://github.com/ansible-collections/community.general/pull/772, where one inventory plugin for a cloud provider (yandex cloud) is added
18:12:52 <github-linkbot> https://github.com/ansible-collections/community.general/pull/772, | closed, created 2020-08-13T14:47:00Z by st8f: Yandex.Cloud inventory plugin [affects_2.10,community_review,feature,has_issue,inventory,needs_triage,new_contributor,new_plugin,plugins]
18:13:01 <samccann> A somewhat related question - do we allow anything new into c.g etc?
18:13:15 <felixfontein> by someone working for yandex, that is. if it would be a community contribution, I wouldn't mind accepting it
18:13:21 <felixfontein> samccann: we do
18:13:28 <rockaut> but what if then the module doesn't end up in any collection because the one doing it isn't interrested in maintainer role?
18:13:53 <felixfontein> rockaut: that's the other side of the story :)
18:14:46 <tadeboro> rockaut: Is it fair to place that burden on c.g maintainers? I would say that maintainers have the final say here.
18:14:48 <samccann> what about the idea of c.g/c.n being 'tech preview' so to speak. As in no implied support even from community, user beware it's a testing ground for new ideas etc?
18:15:16 <samccann> or if not there, then community.newstuff :-)
18:15:20 <felixfontein> samccann: problem is that it already has several other uses, like 'dumping ground' and also 'home of well-supported and much used modules'
18:15:24 <dmsimard> before accepting a new module/plugin in c.g, we should make sure that a collection would not be a better fit to avoid incurring the cost of a move in the near future
18:15:33 <jtanner> how can you quantify c.g's "testing" nature vs any other collection?
18:15:34 <gundalow> I've thought about that, though I think you end up with all the bad sides of trying to store metadata (support) in the repo structure, ie ansible-modules-core vs ansible-modules-extra
18:15:59 <gundalow> dmsimard: +1
18:16:25 <rockaut> I don't like the idea of a separate collection for all the things
18:16:37 <felixfontein> jtanner: parts of c.g are well-tested, some have unsupported tests, many parts are not tested at all
18:16:48 <abadger1999> I like the idea of community.{newstuff|incubator|etc}.
18:17:01 <jtanner> felixfontein: how does an end user know parts are what?
18:17:06 <felixfontein> it's essentially a smaller version of ansible/ansible before the purge :)
18:17:08 <andersson007_> there's no point to wait while yandex creates a lot of stuff for a separate collection:) Better to have something rather than nothing
18:17:15 <felixfontein> jtanner: they don't.
18:17:36 <felixfontein> andersson007_: they can release a collection with one plugin right now, there's no need to have a collection with many things in it
18:17:37 <jtanner> hence the idea to segment bits out into separate collections
18:17:39 <tadeboro> rockaut: After I learned today that ansible weighs 40 MB, I vote to keep each module in its own collection ;)
18:17:39 <dericcrago> is there an equivalent of community.beta already?
18:17:40 <dmsimard> rockaut: neither extremes are desirable outcomes but I think it is logical to regroup things that fit together into a collection
18:17:43 <abadger1999> It feels like this is a valid (developer) use case but adding the use case to community.general has too many negative repercussions for user expectations.
18:17:54 <gundalow> dericcrago: nothing like that yet
18:18:14 <felixfontein> dericcrago: a problem with community.beta is: what happens if things outgrow beta? do we have to move them (and annoy users)?
18:18:16 <rockaut> absolutely on regrouping but just things that belong together
18:18:39 <gundalow> I don't want to blanket band any company from contributing net-new modules to c.general, though that's where I'm leaning
18:18:45 <rockaut> a user might not want orphaned modules just because nobody likes them.
18:18:45 <abadger1999> felixfontein: Yes, we do.  But to me it's about expectation setting.
18:18:50 <felixfontein> moving content sucks bigtime for 2.9 users. it's only a bit annoying for 2.10 users.
18:18:54 <abadger1999> users should expect that to happen eventually.
18:19:10 <felixfontein> abadger1999: for new content we require tests, so it's getting better :)
18:19:23 <abadger1999> (in a community.beta.... but they don't for community.general)
18:19:47 <gundalow> What would be the pros of `community.beta` over `community.general`?
18:20:02 <dericcrago> "beta" does imply, "this may not always work" to me, and if it outgrow's beta then it probably needs it's own collection as there is active maintenance / improvements happening?
18:20:02 <rockaut> Question: what if we would find a bunch of people which would agree to MAINTAIN orphaned collections ... that would solve things then?
18:20:23 <dmsimard> c.g is included in the ansible package, right ? would an hypothetical beta collection be ?
18:20:24 <rockaut> Maybe with an metadata tag like orphaned
18:20:24 <samccann> `community.beta` by the name, suggests users be cautions. This is new stuff, will eventually move etc
18:20:48 <samccann> s/cautions/cautious/
18:20:54 <gundalow> rockaut: finding (and supporting) mainainers is always a good thing. In particular it helps the PRs and issues been resolved
18:21:09 <gundalow> c.g is included in `ansible`
18:21:12 <aminvakil> samccann: i don't think many users will use modules in community.beta then
18:21:33 <tadeboro> We are "teaching" our customers to select their collections just like they select libraries for their development projects: see how well maintained the thing is, is it certified, etc. So having things in separate collections makes this easier. But this is maybe less relevant for the Ansible community.
18:21:46 <samccann> aminvakil - true, but then any new module would suffer from 'does anyone want/need this besides the creator?"
18:21:48 <rockaut> I dont think many users will use community.beta as a whole if it is 100MB then again :D
18:22:00 <samccann> and if the creator is willing to maintain, they create a collection for their stuffs.
18:22:08 <felixfontein> rockaut: if it's "our" collection we'll make sure it won't grow that much ;)
18:22:21 <gundalow> What do programing languages do for this? I'm not aware of a PyPI `beta` package for example
18:22:24 <abadger1999> dmsimard: I think yes.  But it would need documentation about the expectations.
18:22:46 <gundalow> Is there a Python Package equilevant of community.general?
18:23:07 <tadeboro> gundalow: Not that I would know of.
18:23:19 <abadger1999> You mean on pypi?  No, not at the moment.  It's possible to do that (the technology would support that) but core discourages that idea.
18:23:36 <abadger1999> and also, it would conflict with the ansible package.
18:24:06 <rockaut> well... another question: are there actually that many such small things incoming so it worth doing that much thoughts? dont you think that most people may just throw them at galaxy as themselfes?
18:24:30 <dmsimard> gundalow: pypi recognizes semver and pre-releases (say, 2.10.0rc1) and they can be installed with "pip install --pre"
18:24:34 <abadger1999> there are cases where they could work together and also ways in which we could make them play nicer together but no one seems to want to champion that yet.
18:24:53 <tadeboro> I think gundalow was thinking more about the nature of the package: does PyPI contains package that is just a bundle of other packages with beta quality stuff.
18:25:19 <rockaut> i dont think pypi does have such
18:25:21 <gundalow> tadeboro: thanks, that was a better way of explaining it
18:25:28 <rockaut> thats what versions are for imo
18:25:30 <abadger1999> yes-ish
18:25:56 <dmsimard> so like a metapackage ? an "empty" package that just depends on other packages ?
18:26:13 <abadger1999> most of the ones I've seen are along the lines of "I have had 20 years in software and built up a collection of unrelated code that I use in every new work project I undertake.  Here it is"
18:26:50 <gundalow> I'm happy to accept that one of the reasons companies might not want to setup their own collection is through lack of understanding what they need to do. Improving docs is on the list
18:27:18 <tadeboro> But those are still "maintained" by someone in a separate and are not pushed to some giant beta package that holds just about anything.
18:27:31 <felixfontein> I wonder if companies would be willing to set up their own collection if they get help for setting it up, and then they have to take care themselves. or whether they except help all the time
18:27:59 <jtanner> both
18:28:25 <webknjaz> @dmsimard: strictly speaking, that's not semver but PEP440-compliant versions
18:28:37 <dmsimard> ++
18:29:21 <rockaut> just had a look at https://github.com/ansible-collections what if there is a new tag which marks such collections?
18:29:48 <tadeboro> No matter what, we always end up with "who will maintain this from now on" question.
18:30:18 <felixfontein> tadeboro: indeed.
18:30:27 <jtanner> you could counter with "why was it accepted in the first place"
18:30:27 <rockaut> tadeboro thats true but from an user perspective it might be "acceptable"
18:30:43 <rockaut> also it might attract newcommers to have a look at it
18:31:07 <webknjaz> @gundalow: here's an example of a beta release on PyPI -- https://pypi.org/project/pip/20.3b1/
18:31:33 <aminvakil> felixfontein: after setting the collection up, what issues will be created "maintaining collection wise" not "maintaining modules", so that companies will need help about that?
18:31:57 <tadeboro> But newcommers can also have a look at the code in the separate repo. All they need to be able to do id find it. And this is what I currently see as a bigger issue right now.
18:32:00 <gundalow> Stepping back a bit, Collections are a first class citizen. In Galaxy you can search for stuff by company, product or tags (cloud, monitoring, database)
18:32:00 <gundalow> If community.general ends up growing it's going to have 45,000 modules in and no one can find anything
18:32:24 <gundalow> tadeboro: could you please clarify what issue you are referring to?
18:32:41 <tadeboro> gundalow: Serching ansible galaxy is not the nicest experience if you are "browsing" for new stuff.
18:32:45 <rockaut> gundalow +1 for that
18:33:01 <gundalow> let's assume that Galaxy searching will improve
18:33:38 <felixfontein> aminvakil: I guess they need someone who watches ansible news (bullhorn; https://github.com/ansible-collections/overview/issues/45; ...) and makes sure that their collection still works and tests are working
18:34:20 <felixfontein> if you don't want to invest personell for that, your collection's quality will decline over time
18:34:44 <felixfontein> it's not a huge investment, but sometimes a lot more than what companies want to invest
18:35:23 <rockaut> again ... if those abandoned modules end up in c.g or so they might even break more there. so splitting them out is better imo. This way they end up aboned but nobody cares
18:35:41 <aminvakil> yep, it won't be that huge, but as tadeboro said, it ends up with "who will maintain this from now on" question after a while:)
18:36:02 <jtanner> the historical answer is "nobody"
18:36:44 <rockaut> and the future one is it too? the ansible team then marks them as stale/abandoned and users know
18:36:51 <felixfontein> if something is unmaintained in c.g, it will receive minimalist maintenance, like if tests start breaking, they get disabled.
18:37:03 <gundalow> Strawman 1:
18:37:04 <gundalow> 1. Companies shouldn't but 2+ modules into c.g. (or where we can see the number of modules growing).
18:37:04 <gundalow> 2. We will improve documentation on maintaining/releasing (and https://github.com/ansible-collections/collection_template) to make it easier for people
18:37:04 <gundalow> 3. We may look at improving `ansible-galaxy collection init` to pull in some of https://github.com/ansible-collections/collection_template
18:37:04 <gundalow> 4. If Companies ask for help we will provide guidance. We will NOT do the work for them
18:37:06 <felixfontein> (except if they are trivial to fix, or if someone is bored, etc.)
18:37:50 <felixfontein> sounds reasonable.
18:37:54 <rockaut> and it would be a small thing to add a "works with ansible <= 2.12.3" for core maintainers to don't include them somewhere.
18:38:08 <alongchamps> so individual modules can get in to c.g. but if it becomes 2 or more, then break them out? seems workable for me
18:38:15 <gundalow> 5. Repo should be in their own GitHub org (not gh/ansible-collection)
18:38:16 <felixfontein> does 1. include 1 module/plugin where it can be expected there will be more soon? like a first plugin/module for a cloud service?
18:38:25 <gundalow> felixfontein: yup. I think so
18:38:39 <tadeboro> Me wearing my maintainer hat, I would try to keep as much stuff out of c.g as possible. In my experience, collecting things together is PITA, but splitting then is even worse.
18:39:01 <alongchamps> any opportunity to simplify the transition process from one module in c.g. to a collection?
18:39:17 <felixfontein> tadeboro: for me the line is community contributions vs. companies 'donating' modules/plugins for their own stuff
18:39:46 <andersson007_> 4 and 5 sound good:)
18:39:46 <felixfontein> tadeboro: telling community contributors "create your own collection" is very harsh, and should be reserved for extremely specialized stuff that probably will never be used by anyone else
18:39:51 <dmsimard> gundalow: strawman proposal makes sense to me, I would add that we should validate when including a first module that a second one (or more) isn't already planned
18:40:12 <tadeboro> felixfontein: I was talking about company-sponsored stuff.
18:40:14 <abadger1999> I'm not sure I like the line between community and company maintainers.....
18:40:38 <abadger1999> Or at least.... most of the arugments about company modules also apply to community modules.
18:40:40 <felixfontein> tadeboro: ok. I fully agree w.r.t. that.
18:40:46 <rockaut> how many companies would even consider to dont do their own collection if they are realy wanting it?
18:41:03 <abadger1999> I think geerlingguy had once proposed that c.g shouldn't accept any new content.
18:41:08 <dmsimard> abadger1999: I think it's more about "I'm a storage vendor and have 15 modules"
18:41:16 <gundalow> advantages of strawman 1
18:41:16 <gundalow> a. Contributor Avoids c.g being even more of a dumping group
18:41:16 <gundalow> b. User: Avoids FQCN changing over time
18:41:16 <gundalow> c. Maintainer: Avoids `runtime.yml` and deprecation hell
18:41:16 <gundalow> d. User: Better searching in Galaxy (search for `monitoring`, find all of those modules
18:41:16 <gundalow> e. Contributor: All the general advantages of having a dedicated collection (ie I'm only interested in these PRs, not all 90 in c.g)
18:41:18 <dmsimard> vs an individual contributor
18:41:44 <gundalow> I need to drop off for 10 minutes
18:41:50 <abadger1999> I'm almost for geerlinguy's idea as long as there's some support for people who just have one module and want to get it included into ansible.
18:41:51 <tadeboro> abadger1999: Well, I maintain a collection for a vendor, and most of the bugs I get are not related to collection at all. Users just happen to find a bug while using ansible. Not sure if this is something a c.g maintainer should deal with.
18:42:33 <abadger1999> (thinking outside of the box, that could even be something like a github action that automates the releasse-to-galaxy workflow)
18:42:35 <rockaut> abadger1999 what you mean with included in ansible?
18:42:37 <samccann> I'm also for severely restricting what goes into c.g/c.n
18:42:52 <abadger1999> rockaut: in the ansible tarball.
18:43:06 <dericcrago> I like the idea of `c.beta` instead of `c.g` because it doesn't group `c.g` and any movement out of `c.beta` shouldn't be *that* much of a surprise to anyone
18:43:13 <felixfontein> tadeboro: such issues go on the stack of open issues that nobody ever looks at, if there are no active maintainers for the module in question ;)
18:43:15 <rockaut> actually I thought that has an ending date as such
18:43:17 <dericcrago> s/group/grow/
18:43:26 <abadger1999> dmsimard: That is true.... but is the storage vendor the important difference there or the "here are 15 modules related to this one product" ?
18:44:15 <abadger1999> I would say if five community members showed up with a total of 15 modules for a single product, they should also be asked to make a new collection, right?
18:44:20 <rockaut> any  grouping from c.g to c.whatever is breaking things for users. even worse they might end to then transition to c.other again
18:44:53 <felixfontein> abadger1999: I think so. that usually doesn't happen so quick though, for the first months there are only 1-2 modules, then a third one pops up, then a couple of months later maybe a fourth, etc.
18:45:23 <abadger1999> tadeboro: <nod> yeah, that's definitely a good point.
18:45:27 <felixfontein> rockaut: if they use ansible-base 2.10, it's not that much of a problem :) it's mainly a huge PITA for 2.9 users
18:45:36 <dmsimard> It's easier to tell a vendor that they need a collection for their 15 modules than to turn an individual contributor away for his one module
18:46:15 <jtanner> would it be the worst thing in the world to not accept every module submitted?
18:46:31 <abadger1999> dmsimard: yeah, it is easier.... but the experience for users and other c.g maintainers is still the same if we let them in, right?
18:46:31 <rockaut> Maybe being the evil then: who cares if they walk away?
18:46:43 <rockaut> or doing their own stuff
18:46:51 <felixfontein> jtanner: we're already not accepting every module/plugin :) people have to survive andersson007_ and my reviews for example ;)
18:46:58 <samccann> heh
18:47:09 <rockaut> If it's worth including 10 other people will pop up sooner or later
18:47:09 <andersson007_> severe reviews felixfontein :)
18:47:19 <felixfontein> andersson007_: yep, very nit-picky :)
18:47:26 * nitzmahone pictures some kind of secret fraternity ritual
18:47:28 <dmsimard> jtanner: I don't think but the exercise is to formalize and put requirements or expectations on writing
18:47:30 <felixfontein> (w.r.t. some formalities)
18:48:02 <abadger1999> i think there's a certain level of acceptance that is needed.  but the questions in my mind revolve around accepting things that are "good" without putting an undue maintenance burden on people who don't care about that niche.
18:49:11 <abadger1999> which returns me to... maybe c.g isn't the place for these modules but simply throwing people at galaxy and github and saying, "create your own collection" is probably not sufficient either.
18:49:28 <dmsimard> not just a maintenance burden but a packaging one too (re: size)
18:49:39 <jtanner> i don't see why the later is insufficient
18:49:57 <jtanner> galaxy should be the focal point, not our sprawling repos
18:50:12 <tadeboro> Replace "throwing" with "showing how" and I think things are OK.
18:50:24 <felixfontein> it's a lot more work to create a collection and releasing it, than just creating one plugin/module in an existing collection
18:50:43 <andersson007_> +1
18:50:47 <felixfontein> it will keep probably a lot of good submissions from happening
18:50:51 <jtanner> true, if the work you've deferred to the rest of the community doesn't count as effort
18:50:58 <felixfontein> (way more bad ones too :) )
18:50:58 <samccann> felixfontein - would that difficulty be minimized some by having a good collection template to start from?
18:51:00 <jtanner> someone has to take care of getting the bit out the door
18:51:07 <abadger1999> People arrive in open source to scratch their own itches.  If you make it hard for people to share the results of their itch-scratching to other people then those people will only scratch their own itches without sharing.
18:51:16 <felixfontein> samccann: only partially. it's still a lot more work, and it's harder to get help for it
18:51:44 <jtanner> people have been creating and sharing roles on galaxy for years ... i can't see how it's so burdensome to suggest the same for collections
18:51:50 <samccann> opensource rashes  :-)
18:52:09 <abadger1999> So, to grow open source, you want to be welcoming and help people go from "I sovled my own problem ." to "I was easily able to let other people use the solution to my problem as well"
18:52:10 <rockaut> people starting with opensource will first doing their own thing anyways. Just then they will try to do more in communities
18:52:11 <geerlingguy> abadger1999: I see your point, but I still don't like the idea of c.g being some sort of dumping ground, *especially* if it's a case of "but this vendor just wanted one module to make its way into the pip install ansible version, pretty please"
18:52:27 <abadger1999> geerlingguy: yes.  I'm in agreement with you.
18:52:30 <geerlingguy> If we are going to make this whole collection experiment work at all, we can't have any "blessed collection" that gets special treatment
18:52:38 <geerlingguy> ++
18:52:52 <abadger1999> geerlingguy: that's why I'm suggesting (1) the strawman shouldn't be limited to companies.
18:52:54 <felixfontein> also if people create their own collection, the risk of them getting abandoned is probably pretty high. and it's much harder to fork collections properly (and convince users to use that fork).
18:52:55 <dmsimard> jtanner: what did we say to PRs that we weren't interested in ansible/ansible before ? was there a formal criteria for inclusion ?
18:53:23 <jtanner> dmsimard: the PRs sat and rot until the BU or the community team mangaed to find someone to hit the green button
18:53:32 <felixfontein> BU=?
18:53:37 <jtanner> business unit
18:53:40 <felixfontein> ah
18:54:08 <rockaut> Thats what I meant with "a bunch of people willing to"
18:54:30 <jtanner> the core team completely divorced themselves of new module PRs because it was just too much expectation
18:54:37 <rockaut> I don't think we cant find 5 people in the community willing to handle such collections
18:54:39 <abadger1999> (2 & 3) We should consider whether we want to allow any additions to community.general at all.  As part of this, what we can do to make it easier for people to create and publish their work as something other than community.general (either community.beta [still has many of the problems of community.general... just sets user expectations] or something like a incubator.* namespace where we can automate workflow for them)
18:55:56 <rockaut> hmm... what about a whole gh.com/ansible-incubator then?
18:57:00 <samccann> +1 to adbadger1999 idea
18:57:02 <felixfontein> about not accepting anything new for c.g: I think there are several levels: 1) not accepting anything new, 3) not accepting new module/plugin groups, 2) not accepting new modules/plugins for new products/services, 4) accepting as now
18:57:03 <jtanner> you have to immediately build out the rules for which the thing has graduated from "incubating" to "good for use"
18:57:06 <abadger1999> rockaut: yeah, that could be part of the second idea.
18:57:06 <rockaut> this way those repos are clearly separated and differentiated from regular ansible-collection repos
18:57:07 <samccann> heh  abadger1999 even
18:57:38 <aminvakil> when will a module in community.beta be a candidate to be dropped of ansible tarball then? or move out to its own collection or move to c.g?
18:58:10 <abadger1999> felixfontein: <nod>  Maybe we want to take a poll on each of those three starting with 4?  That we narrow down our range of options?
18:58:12 <samccann> that is an interesting point aminvakil - my nickel would be community.beta etc are NOT in the Ansible tarball at all
18:58:37 <samccann> as incentive to put it into its own maintained collection
18:58:56 <dericcrago> I agree with samccann
18:59:01 <jtanner> or when is a module ready for total deprecation+deletion?
18:59:04 <abadger1999> samccann: Eh..... If it's still built for pypi, I'd be okay with that.
18:59:15 <felixfontein> I wouldn't include c.beta in ansible as well
18:59:25 <andersson007_> nobody will know about new stuff there
18:59:31 <andersson007_> felixfontein: ^
18:59:33 <aminvakil> well why should a module be put in community.beta then? i mean what's the point?
18:59:46 <aminvakil> users will use ansible galaxy to include them
18:59:56 <andersson007_> c.beta will be like a black hole
18:59:58 <felixfontein> andersson007_: true, but if we include it, the content should stick to certain standards
19:00:19 <tadeboro> You can put it somewhere without having to worry about releasing and setting up CI/CD.
19:00:27 <jtanner> who sets the standard for "this is actually useful to somebody" ?
19:00:28 <dmsimard> ^ what tadeboro said
19:00:32 <andersson007_> felixfontein: yep, in c.g. we review all stuff
19:00:41 <aminvakil> jtanner: +1
19:00:55 <andersson007_> +1
19:01:00 <abadger1999> samccann: but the idea is that someone has a single module.  They want to give it back to the community to improve ansible. they don't have the time to learn about building collections, uploading to galaxy, etc.  Right now, distribution on pypi is the only thing that links their contribution into the thing that they wnat to contribute to.
19:01:04 <dericcrago> aminvakil - it's like an intermediary step between I wanna share this module / plugin and I want to maintain a collection
19:01:24 <abadger1999> (Yeah, I agree with aminvakil saying "what's the point" then)
19:01:53 <dmsimard> fwiw I don't know if "beta" would be the right word
19:02:11 <abadger1999> felixfontein: +1 to that.... the nomenclature it bothered me too.
19:02:23 <jtanner> if a contribution only has to pass code smell and code quality reviews, without actually being useful to more than 1 person ... c.g. is a "dumping ground"
19:02:33 <samccann> abadger1999 yeah I'm still debating that issue w/ jtanner's earlier thoughts - do we have to continue to include very module in Ansible (the package)? or Can we leave more and more to what users can find in Galaxy. I don't really know the 'future' of the project in that regard. Do we hope/expect Ansible the package to double in size in 2-3 years?
19:02:34 <andersson007_> i'd suggest not making new contributors lifes more difficult
19:03:00 <felixfontein> jtanner: we only merge things which look like they would be used by multiple persons :)
19:03:10 <nitzmahone> `community.toiletwater`
19:03:16 <jtanner> who makes that determination though?
19:03:17 <andersson007_> so imo no c.beta needed
19:03:25 <abadger1999> samccann: I do not hope, but I do expect..... that's part of gregdek's vision of what the ansible package is.
19:03:33 <abadger1999> nitzmahone: I think sivel has the trademark on that ;-)
19:03:40 <jtanner> that was the pivotal core problem .. who knows enough about all the proprietary domains to say if this new module has any use?
19:03:40 <samccann> I think prior to collections, we had to accept most modules as it was the only way to be a part of Ansible. But now with collections, people can put their stuff on Galaxy, and then Ansible the package could decide - hey that's a very useful/popular collection, maybe we add it to the Ansible package
19:04:26 <abadger1999> andersson007_: +1
19:04:26 <nitzmahone> I always assumed that would be the way
19:04:36 <abadger1999> (1 to do not make new contributors lives harder)
19:04:53 <nitzmahone> I know "we're just going to ship everything on galaxy" has come up before, but yikes for so many reasons
19:05:12 <jtanner> the "sense of belonging" by ending up in the ansible distribution was the ideal that splitting modules out of core was meant to get rid of
19:05:31 <nitzmahone> (well, one of many reasons)
19:05:46 <abadger1999> I don't think that's an impression shared by everyone jtanner.
19:06:54 <jtanner> then i would counter by asking those people opposed to the idea if we should have also shipped roles with the distribution also
19:06:56 <aminvakil> i have not thought this through, but can't there be a time limit (e.g. 6 months) for a module to be in community.beta? after that it should either go to its own collection or if it's used by multiple persons as felixfontein says be merged into one of existing collections.
19:07:03 <abadger1999> Sense of belonging is important.  things that I saw were "where is the maintenance burden being carried"
19:07:55 <felixfontein> aminvakil: how do we know whether it's used by multiple persons? just because someone told their 10 friends "please create a GH account and write in this issue that you use this module" doesn't mean it's actually used :) also 6 months is a rather short timeline
19:08:14 <jtanner> there are ways to feel like part of the ansible community besides getting a poorly written module with no chance that anyone wants to use it into ansible
19:10:10 <andersson007_> jtanner: +1 and +1 for "sense of belonging"
19:10:17 <abadger1999> felixfontein: we're at 10 after the hour.
19:10:23 <samccann> felixfontein - maybe there's something in galaxy (when it has module docs support) to track how often the new module page gets hits.  Not perfect, but an indication of some amount of reference to it.
19:10:29 <felixfontein> abadger1999: yep, I noticed too
19:10:32 <abadger1999> Do we want to have a poll on your 1-4?
19:10:40 <abadger1999> Or move to discussing meeting times?
19:11:13 <aminvakil> felixfontein: right, i meant if current maintainers of collections feel that it's useful and can be merged to the current collections, move it it to the collection.
19:11:34 <felixfontein> hmm, good question. I'm not sure whether it's already the right moment to start voting on putting quite restrictive measures on c.g
19:12:39 <felixfontein> meta-vote: who wants to vote on restrictions on c.g today? +1 for vote on restrictions, -1 for not today
19:12:43 <dmsimard> is it an emergency ? otherwise we can write down the proposals and take more time to discuss/decide at next meeting
19:12:49 <rockaut> +1
19:12:51 <andersson007_> -1
19:12:52 <felixfontein> #chair
19:12:52 <zodbot> Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner rockaut samccann tadeboro
19:12:55 <felixfontein> -1
19:13:01 <aminvakil> -1
19:13:04 <dmsimard> -1
19:13:04 <abadger1999> +1 to a poll.... I'd like to know the terrain.
19:13:10 <felixfontein> dmsimard: I don't think it's an emergency, that's why I would not vote today
19:13:15 <cybette> -1
19:13:18 <dericcrago> -1
19:13:18 <alongchamps> -1, seems like more discussion needs to happen
19:13:23 <felixfontein> abadger1999: poll = just asking for opinions, but not deciding?
19:13:28 <abadger1999> Like, is banning everything new from c.g on the table?  Is c.g being open to anyone who can pass review on the table?
19:13:31 <abadger1999> Yeah.
19:13:51 <felixfontein> I think that we can do.
19:14:06 <samccann> +1 to what abadger1999 is suggesting - let's get a pulse (nonbinding vote :-)
19:14:19 <felixfontein> POLL (won't end up in a decision!): if you'd have to vote now, would you: +1 allow more contributions to c.g (new plugins/modules), -1 diallow that?
19:14:30 <andersson007_> +1
19:14:30 <dericcrago> -1
19:14:34 <felixfontein> +1
19:14:34 <samccann> -1
19:14:41 <tadeboro> -1
19:14:46 <aminvakil> +1
19:14:59 <jtanner> -1
19:15:01 <cybette> -1
19:15:22 <alongchamps> +1
19:15:28 <felixfontein> right now, we could rephrase: are you paid by ansible? +1 for no, -1 for yes ;)
19:15:30 <geerlingguy> -1
19:15:45 <samccann> AAAAHAHAH omgosh felixfontein was wondering the same thing ;-)
19:15:45 <rockaut> -1
19:16:00 <abadger1999> -1 to c.g; but +1 to something else that ends up associated with the ansible name (ansible package on pypi or ansible-extra-content or etc)
19:16:03 <abadger1999> Heh :-)
19:16:05 <dmsimard> I'm leaning towards -1 but I'm not in favor of a blanket ban
19:16:20 <jtanner> contrary to popular believe, the module count does not correlate to popularity or profit
19:16:25 <jtanner> belief*
19:16:29 <abadger1999> To me, with my community hat on, that would be a big warning sign that any form of strict -1 is a bad idea :-)
19:16:36 <felixfontein> please remember this is not about limiting new content to less things, like only allowing new modules for groups that already live in c.g, this is about denying ALL NEW plugins/modules
19:17:06 <dmsimard> felixfontein: right, I'm -1 on "hard no to everything" but I'm also not +1 on "let's accept everything"
19:17:10 <andersson007_> felixfontein: it seems that we're going to get bored w/o new stuff in c.g....:(
19:17:21 <samccann> heh
19:17:25 <felixfontein> andersson007_: I somehow doubt that, but it will definitely be less interesting ;)
19:17:39 <andersson007_> felixfontein: definitely
19:17:52 <tadeboro> I am for -2: move everything from c.g into smaller collections ;)
19:18:09 <felixfontein> hmm. maybe we have to re-phrase the poll? with three options, one for absolutely no new content, one for much less new content, and one for continue like now
19:18:18 <geerlingguy> I think -1 on anything at all new in c.g, BIG +1 on "making a process for adding other collections to the Ansible "community distribution thingie that's not called ACD"
19:18:27 <abadger1999> felixfontein: yeah, and pick all that you are okay with
19:18:35 <aminvakil> felixfontein: could you please define much less new content?
19:18:48 <geerlingguy> otherwise I'm a big +1 for just undoing all the collections stuff and putting everything back into ansible core, or doing the ansible-modules-extra split again, because that's what c.g will be (IMHO)
19:19:17 <dmsimard> geerlingguy: you want to go back to git submodules ? :)
19:19:24 <jtanner> because "much less" can't be quantified or really measured, it'll end up being who knows which elbows to rub
19:19:30 <felixfontein> aminvakil: hard to say, there's isn't that much new content right now. one could for example say "no new modules/plugins for areas not yet covered", like a new github module is ok, but a new module for random_new_source_control_system is not
19:19:38 <geerlingguy> No, I'm saying if we're going to go to collections, then what's the point of having one super special blessed collection that gets more love and attention
19:20:00 <geerlingguy> why would I consider building a module and putting it in my own collection at all if I know the fast/easy path to getting it into Ansible is to try to squish it into c.g
19:20:20 <felixfontein> geerlingguy: right now it's neither fast nor easy ;)
19:20:25 <geerlingguy> jtanner's point, exactly
19:20:31 <jtanner> and that you can abandon it afterwards and left someone else deal with it
19:20:40 <geerlingguy> the people who get their modules in will be partners, or people who know felixfontein, gundalow, abadger1999, me, etc.
19:20:44 <felixfontein> (in general. sometimes people come up with well-polished stuff)
19:21:15 <andersson007_> (yep)
19:21:20 <felixfontein> hmm. I think we need a lot more discussion :)
19:21:25 <geerlingguy> and we will end up right back where we were last year, 3,000 open PRs that have modules that are half-polished but the few community maintainers will not be able to devote time to shepherding them
19:21:30 <andersson007_> felixfontein: and more options
19:21:40 <geerlingguy> whether that takes a few months or a few years is debatable
19:21:56 <jtanner> knowing who can or being able to get a module into the distribution is political capital. it can be abused, will be abused and has been abused
19:21:58 <felixfontein> so let's stop it for today. maybe create some concrete proposals of restrictions and paste them in https://github.com/ansible/community/issues/539, so we can discuss them next time?
19:21:59 <geerlingguy> But my key is: if we end up going that route, I know a lot of people who will see this as "ansible-modules-extra" split 2.0 and walk
19:23:13 <felixfontein> #topic possibly change community meeting time
19:23:14 <felixfontein> #chair
19:23:14 <zodbot> Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner rockaut samccann tadeboro
19:23:32 <felixfontein> I think for gundalow and me it would be helpful if the meeting is one hour later
19:23:43 <felixfontein> no idea how that affects everyone else. some already stated they are not affected.
19:23:54 <geerlingguy> I'm okay with later, as current time is always in middle of lunch
19:23:54 <dmsimard> felixfontein: right now it's at 18:00 UTC, isn't that actually more on the later side on things ? would earlier work too ?
19:23:56 <felixfontein> now that we have so many people around, what are your opinions? or some completely different time?
19:24:00 <rockaut> As it's my first: idc
19:24:05 <samccann> fine with later
19:24:28 <cybette> I'm ok with later
19:25:06 <tadeboro> 19:00 UTC works for me too.
19:25:07 <felixfontein> dmsimard: earlier isn't that great for me, it will just shift the problem to summer ;)
19:25:08 <abadger1999> This is in the middle of my day so I have broad flexibility.
19:25:20 <felixfontein> andersson007_: I think for you it could be worse
19:25:30 <dmsimard> yeah it gets late in emea/apac
19:25:31 <felixfontein> (I think you're one timezone further?)
19:25:39 <andersson007_> felixfontein: yep:)
19:25:58 <felixfontein> andersson007_: yep for timezone, or yep for worse? :)
19:26:13 <andersson007_> felixfontein: for both:)
19:26:26 <felixfontein> andersson007_: would earlier work better for you?
19:26:37 <felixfontein> like two hours earlier?
19:26:42 <andersson007_> felixfontein: no;)
19:26:47 <felixfontein> (one hour earlier means the same problems we currently have in winter time will happen in summer time)
19:26:53 <felixfontein> andersson007_: ok :D
19:27:36 <felixfontein> so is one hour later worse for anyone than the current time?
19:27:44 <felixfontein> please speak up now :)
19:27:50 <felixfontein> #chair
19:27:50 <zodbot> Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner rockaut samccann tadeboro
19:28:00 <felixfontein> (gwmngilfen isn't on the list)
19:28:02 <dmsimard> 1 hour later wfm
19:28:20 <abadger1999> We can also change when DST rolls around every time.
19:28:20 <felixfontein> aminvakil?
19:28:20 <andersson007_> 1 hour later is better than earlier for me
19:28:34 <aminvakil> 1 hour later is better for me too
19:28:43 <abadger1999> 1 hour either direction wfm.
19:29:01 <felixfontein> ok. should we try one hour later? and maybe reconsider for the next time change?
19:29:06 <rockaut> ok for me
19:29:07 <gundalow> back
19:29:16 <felixfontein> gundalow: we're talking about meeting times now :)
19:29:25 <gundalow> sorry, I mean I'm back
19:29:33 <rockaut> :D
19:29:36 <felixfontein> current proposal is one hour later, and look again when time is changed next time
19:29:41 <gundalow> +1
19:29:53 <felixfontein> so far nobody said it's worse for them
19:30:15 <felixfontein> I guess if nobody speaks up in the next few minutes, we'll meet at 19:00 UTC from next week on.
19:30:35 <dericcrago> one hour later would be the same time as the molecule wg (I think) - just an fyi (if I'm right) :)
19:30:57 <felixfontein> is the molecule wg meeting right now?
19:31:03 <felixfontein> (because it's 1.5 hours later :) )
19:31:11 <gundalow> dericcrago: ah, I think that's dead, remind me tomorrow and I'll show you how to remove it
19:31:14 <felixfontein> the public project meeting on Tuesday is also at 19:00 UTC
19:31:26 <gundalow> yup, Molecule meeting hasn't happened in 2020
19:31:44 <felixfontein> ok, then let's steal their time ;)
19:31:58 <felixfontein> #agreed community meeting will start at **19:00 UTC** from next week on
19:32:00 <gundalow> (May 2019 was the last molecule meeting)
19:32:09 <felixfontein> #topic open floor
19:32:14 <felixfontein> does anyone have something for the open floor?
19:32:18 <dericcrago> thanks, sorry for any confusion :)
19:32:24 <felixfontein> (not to be confused with the open trapdoor in the floor)
19:32:32 <gundalow> dericcrago: nah, you are right to mention it
19:32:38 <nitzmahone> Just an FYI on plugin_utils
19:32:52 <nitzmahone> We'll discuss internally within the next week
19:32:58 <felixfontein> oh right, I could have mentioned the proposal in announcements
19:33:14 <felixfontein> nitzmahone: sounds good!
19:33:27 <felixfontein> for anyone who wants to know what's this about: https://github.com/ansible/proposals/issues/186
19:33:35 <felixfontein> #info https://github.com/ansible/proposals/issues/186 will be discussed by core team internally next week
19:33:36 <nitzmahone> IMO the ability to move beyond module minimum Python version sanity tips it to "we should do some form of that" for me.
19:34:04 <nitzmahone> (will be more important in 2.11+ as those drift apart more severely)
19:34:24 <nitzmahone> That's all from me
19:34:31 <felixfontein> does anyone else have something?
19:35:33 <gundalow> dericcrago: you want to say hello
19:35:44 <felixfontein> hello dericcrago :)
19:35:53 <nitzmahone> ah yeah, woot!
19:35:55 <dericcrago> Hi everyone! :)
19:36:09 <felixfontein> it's good to have you around!
19:36:23 <dericcrago> I'm excited to be here
19:36:33 <gundalow> Happy to announce that dericcrago has joined my team (along side abadger1999)
19:36:49 <daniel-wtd> Welcome :)
19:36:55 <dmsimard> I can say hello next week :P
19:37:27 <rockaut> nice
19:38:01 <gundalow> dmsimard: :)
19:38:14 <gundalow> #chair
19:38:14 <zodbot> Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner rockaut samccann tadeboro
19:38:20 <gundalow> Anyone got any thing else?
19:38:41 <webknjaz> nightlies?
19:39:28 <gundalow> webknjaz: ah, yes
19:40:12 <gundalow> #topic Nightly builds of `ansible`
19:40:14 <gundalow> #info https://github.com/ansible-community/antsibull/pull/195
19:40:14 <github-linkbot> https://github.com/ansible-community/antsibull/pull/195 | open, created 2020-09-30T18:02:11Z by webknjaz: Add a workflow building nightlies
19:40:16 <gundalow> abadger1999: felixfontein
19:40:18 <felixfontein> I think we found out last time (or inbetween meetings?) that some people would appreciate nightlies
19:40:40 <gundalow> yup, can't remember who, though yes
19:41:09 <abadger1999> Someone with a CI problem (testing against ansible-base devel)
19:41:15 <abadger1999> zbr maybe?
19:41:26 <gundalow> Is the remaining question: `The major question I have is where should the nightly artifacts live`
19:41:26 <webknjaz> Yeah, people keep saying that they'd like it, others want a formal decision + a clear decision on where to host them
19:41:39 <samccann> is this `ansible-base` nightlies?
19:42:01 <abadger1999> I think nightlies are okay.  Where do they need to live?  And does the core team need to sign off on it?  (Since it could potentially include both ansible and ansible-base)
19:42:16 <abadger1999> samccann: definitely ansible-base.  I think ansible as well.
19:42:19 <webknjaz> @abadger1999: not only zbr, me too. I originally wanted them for the lint CI
19:42:22 <abadger1999> Err reverse those.
19:42:33 <abadger1999> definitely ansible and I think ansible-base as well.
19:42:54 <nitzmahone> Not sure what you mean by "include ansible-base"?
19:43:03 <webknjaz> @samccann: it's both acd+base in my PR
19:43:28 <nitzmahone> I assume a nightly would be no different than the current thing that just has a ref to whatever core artifact version is being targeted
19:43:52 <felixfontein> was it tadeboro who was also interested in nightlies?
19:44:01 <felixfontein> or geerlingguy?
19:44:08 <samccann> what  would be an an ansible nightly that's different than the current release?
19:44:10 <webknjaz> @nitzmahone: https://webknjaz.github.io/ansinight/
19:44:17 <abadger1999> They probably all are :-)
19:44:40 <felixfontein> samccann: it includes the ansible-base devel version, and the latest collection releases
19:44:43 <felixfontein> so it's more fresh
19:44:44 <dmsimard> webknjaz: so how would I install from there with pip ?
19:44:58 <abadger1999> samccann: It would look a lot like the current release but be built once a day.  so ansible-base from the head of the devel branch and ansible using whatever the latest collections on galaxy were.
19:45:08 <felixfontein> samccann: right now you cannot install ansible with ansible-base from devel
19:45:21 <abadger1999> I think the ansible nightly would be a preview of what the next major ansible package would contain
19:45:31 <webknjaz> @samccann: nightlies are the same as releases except they are updated every day and contain fresh Git devel
19:45:34 <abadger1999> (ie, it would look like 2.11.0, not like 2.10.3)
19:45:42 <tadeboro> I am interested, but now that most of the stuff I care about can work with ansible-base, this is less urgent.
19:46:02 <felixfontein> ansible-lint can't, unfortunately
19:46:49 <samccann> Ok so the Ansible part of that - it would get the latest patch release from Galaxy per collection? or the latest collection even if it's a major change? (2.x vs 1.x in Ansible 2.10?)
19:46:50 <nitzmahone> It seems like an ACD nightly should test against the released `ansible-base` artifact it's currently slated to ship with
19:47:12 <felixfontein> samccann: I think latest collection, even if it is a new major release
19:47:42 <abadger1999> dmsimard: something like `pip install --upgrade  --extra-index-url https://webknjaz.github.io/antsibull/ ansible`   (I didn't look up the cli arg so it's probably a little off)
19:47:44 <felixfontein> but apparently different people have different ideas :)
19:47:48 <webknjaz> Here's what's generated for that PR as it is now: https://webknjaz.github.io/antsibull/
19:49:01 <abadger1999> samccann: I think that it makes the most sense to get the latest collection even if it's a major change but I'm not a consumer of this so maybe webknjaz, tadeboro, zbr, geerlingguy, etc would be better to have the final word on that.
19:49:13 <samccann> felixfontein: my worry - if the nightly has say 2.x for a collection, but the next Ansible release is still 1.x (I lost track of what would be in Ansible 2.11 and if it would allow breaking changes etc)
19:49:41 <abadger1999> samccann: yeah, 2.11 allows breaking changes.
19:49:41 <samccann> what I don't want is that a nightly has the absolute most recent collections, but for some reason the next Ansible release isn't allowed to go that far into the future.
19:49:58 <samccann> ah ok... so there's no way my fears could come  true then ;-)
19:50:11 <nitzmahone> If you limit all the deps to publicly released stuff *other* than ACD itself, it also makes the install much simpler, since you can just directly point at the artifact and let everything else come from prod PyPI
19:50:23 <geerlingguy> Yeah as long as that wouldn't happen nightlies could be helpful in some situations.
19:50:26 <abadger1999> webknjaz: ^ Okay, so one thing that falls out of samccann's requirement would be that during the pre-release freeze period, nightlies would have to be built differently.
19:50:40 <geerlingguy> But I wasn't the one who requested them :)
19:50:59 <rockaut> sorry i'm out for today - long day here. gn8
19:51:22 <abadger1999> webknjaz: since we'd start encoding compatibility guarantees at that point but 2.11 wouldn't have been released yet.
19:51:23 <felixfontein> samccann: ansible's devel branch also has things that the next ansible-base 2.10.x release won't have
19:51:34 <abadger1999> rockaut: Good night!  And no need to apologize :-)
19:51:53 <felixfontein> samccann: the problem is that everyone has different expectations from what exactly nightlies are :)
19:51:58 <felixfontein> good night rockaut!
19:52:09 <rockaut> ;-)  Austrian friendliness
19:52:41 <cybette> good night rockaut
19:53:02 <webknjaz> @abadger1999: so acd may need to become more permissive later but right now it's probably not a blocker
19:53:10 <abadger1999> So the one use case I know of, does require targetting ansible-base devel.
19:53:41 <webknjaz> What do you mean?
19:53:46 <abadger1999> Coupled with felixfontein's point, that would mean targetting latest collections might also be okay.
19:53:57 <webknjaz> Ah
19:54:31 <felixfontein> for me the main use-case would be to be able to install ansible-base devel next to something which would make ansible-lint's requirements happy
19:54:47 <webknjaz> FWIW in my mind "nightly" always means bleeding edge, sometimes broken, the latest no matter what
19:54:47 <felixfontein> if I install the released ansible, it will uninstall ansible-base devel and install ansible-base 2.10.x instead
19:54:49 <abadger1999> webknjaz: someone (I think zbr, in CI) wanted to be able to run ansible-base from devel + the ansible package.  A nightly which requires the last stable release of ansible-base  would not allow that.
19:55:26 <abadger1999> Okay cool, so felixfontein has the same use case needs.
19:55:38 <abadger1999> and it sounds like webknjaz, you have the same desire also.
19:55:46 <webknjaz> Yep
19:56:19 <webknjaz> So where do we publish the index?
19:57:03 <abadger1999> samccann: So it seems like the need that people have right now, is counter to having the nightly be strictly "the next major version". around the time ansible-2.11.0alpha1 comes out, the nightly will track something more bleeding edge.
19:57:34 <samccann> ah gotcha
19:57:45 <abadger1999> samccann: is that okay?
19:57:47 <samccann> I think so long as we make that clear
19:57:53 <abadger1999> Cool.
19:58:10 <samccann> like 'this is not a pre-alpha - this is cutting edge... expect  to bleed' :-)
19:58:38 <felixfontein> would be nice if it could even contain the latest git version of collections :)
19:58:39 <abadger1999> gundalow?  nitzmahone?  Ideas about where to host this?  You can see what would be generated from webknjaz's link.  ( https://webknjaz.github.io/antsibull/  )
19:59:01 <felixfontein> that would make it easier for users to test merged changes before a release, with the collection having to do prereleases
19:59:16 <felixfontein> (I'm thinking of c.g where a lot of things happen)
19:59:20 <gundalow> abadger1999: any reason not to use https://releases.ansible.com/?
19:59:22 <abadger1999> felixfontein: hehe :-)  That's going to be more work and higher chance of problems :-)  antsibull-build can't deal with that yet.
19:59:39 <nitzmahone> Yeah, I'd suggest "anywhere but" :I
19:59:42 <felixfontein> abadger1999: I know, it's more like a future enhancement ;)
20:00:06 <gundalow> Do we need to keep the old versions around, or could we just keep the last (say) 14?
20:00:11 <webknjaz> @gundalow: I'd prefer GitHub Pages for it to be easy to deploy, unless we can point this domain there
20:00:15 <abadger1999> gundalow: I don't think we'd have permissions to push there from a github action.  I don't know that using that would match up with thaumos's push to make releases.a.c a source for supported content only.
20:00:27 <felixfontein> webknjaz: are there traffic limits for GH pages?
20:00:33 <gundalow> ah, didn't know https://releases.ansible.com was going to be for supported stuff
20:00:53 <nitzmahone> Does this really make sense to publish as an artifact vs just "here's a script/container/whatever" that can grab whatever set of stuff you want? Seems like there's a lot of disagreement on what people want from it, so rather than trying to publish all the permutations as nightlies...
20:01:01 <gundalow> Published GitHub Pages sites may be no larger than 1 GB.
20:01:01 <gundalow> GitHub Pages sites have a soft bandwidth limit of 100GB per month.
20:01:02 <gundalow> GitHub Pages sites have a soft limit of 10 builds per hour.
20:01:41 <webknjaz> @gundalow I think it keeps the last version only now but we could arrange something to facilitate more versions (although, it's probably useless)
20:02:08 <gundalow> I'm OK with latest only, I hadn't looked at the PR
20:02:34 <felixfontein> nitzmahone: for me, having an empty dummy `ansible` package which just tells pip that `ansible` is installed would already be enough, it doesn't have to actually install anything :)
20:02:37 <samccann> do people tend to use older nightlies in other projects?
20:02:45 <webknjaz> @felixfontein: I don't think there's traffic limits but maybe there's a general repo size limit
20:02:56 <gundalow> How about GitHub pages for a single build. If we hit traffic limits we can look at moving it elsewhere
20:03:23 <gundalow> #info GitHub pages usage limits https://docs.github.com/en/free-pro-team@latest/github/working-with-github-pages/about-github-pages#usage-limits
20:03:41 <felixfontein> I think just having the current nightly there (and no older one) would be fine as well
20:04:02 <felixfontein> at most a couple of latest ones
20:04:19 <felixfontein> so that people can switch between them to check when exactly something started breaking
20:04:22 <webknjaz> @samccann: no, that's not the point of nightlies as I see it
20:05:23 <gundalow> PROPOSAL: Nightly build (only one copy) stored on GitHub pages
20:05:56 <webknjaz> Sounds like folks are okay with the PR as it is, except it needs to migrate to a different repo or aquire some other domain?
20:06:15 * nitzmahone would suggest avoiding a custom domain
20:06:34 <webknjaz> @gundalow: yep, that's my original intent
20:07:00 <abadger1999> gundalow: I'd be both surprised and a little worried if we did hit the traffic limit on nightlies :-)
20:07:01 <gundalow> webknjaz: cool
20:07:20 <abadger1999> How many people are using this?  Should we be pushing them to use something else instead?
20:07:23 <abadger1999> ;-)
20:07:23 <webknjaz> @abadger1999: agreed
20:07:23 <gundalow> abadger1999: hehe, maybe
20:07:52 <gundalow> So should this be in a standalone repo under gh/ansible-community?
20:08:51 <felixfontein> ok, we're more than one hour over.
20:08:55 <felixfontein> we should really stop :)
20:08:56 <abadger1999> gundalow: that would be fine with me... I just don't know what it should be.  (Toshio: "naming things are hard.  Ask gundalow to decide!" ;-)
20:09:14 <webknjaz> Since almost nobody is using it, it's not time to care about limits + I don't really care about the URL either, it's just easier to have a self-contained/self-updating thing with just GH pages+actions
20:09:34 <gundalow> gh/ansible-collections/nightly-releases
20:10:01 <dmsimard> does github have limitations if that thing ends up taking a lot of traffic ?
20:10:04 <gundalow> Unless anyone has a better suggestion
20:10:12 <gundalow> dmsimard: they will email me
20:10:13 <dmsimard> (CI downloads things a lot)
20:10:36 <felixfontein> as long as they don't shut down the whole of gh/ansible-collections because of it, I'm fine with putting it under there
20:10:39 <gundalow> If that's a problem, future gundalow will deal with it
20:10:53 <dmsimard> gundalow: might I suggest ansible-community/nightly-builds rather than releases ?
20:10:56 <gundalow> nop they will email saying "erm, maybe you want a real CDN"
20:11:02 <gundalow> dmsimard: good suggestion
20:11:07 <gundalow> 5
20:11:08 <gundalow> 4
20:11:09 <gundalow> 3
20:11:17 <webknjaz> So the repo naming scheme is ansible-community.github.io/nightly-releases, sounds good to me
20:11:18 <felixfontein> +1 for nightly-builds
20:11:31 <gundalow> I'll set that repo up now and give webknjaz admin
20:12:02 <abadger1999> Excellent.  Thanks :-)
20:12:04 <felixfontein> ok. thanks everyone for this extra-long meeting!
20:12:09 <felixfontein> #endmeeting