18:00:22 <felixfontein> #startmeeting Ansible Community Meeting
18:00:22 <zodbot> Meeting started Wed Oct 21 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 felixfontein. 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 'ansible_community_meeting'
18:00:37 <gundalow> thanks felixfontein :)
18:01:10 <felixfontein> acozine: samccann: andersson007_: geerlingguy: aminvakil: ... everyone? :)
18:01:18 <cybette> o/
18:01:34 <felixfontein> #chair gundalow cybette
18:01:34 <zodbot> Current chairs: cybette felixfontein gundalow
18:01:47 * felixfontein is still busy eating, so don't expect fast responses :)
18:02:09 <geerlingguy> Can't make it today
18:02:59 <felixfontein> geerlingguy: no problem! :)
18:04:18 <felixfontein> #topic agenda https://github.com/ansible/community/issues/539
18:05:13 <felixfontein> I guess the main open topics are 1) new collections for 2.10.x / moving content, 2) new collections for 2.11, 3) nightlies, 4) BOTMETA, 5) sphinx extension
18:05:13 <gundalow> #info Proposals related to Collections have been moved to GitHub Discussions: https://github.com/ansible-collections/overview/discussions?discussions_q=category%3AProposals
18:05:24 <felixfontein> for 3) and 5) we should wait for Toshio
18:06:05 <gundalow> 1) I think we should do that 2) Yes though not sure about rules 3) If it works apply it 4) Need to agree aim (and if we care about docs) 5) probs wait as you said
18:06:27 <gundalow> The Bullhorn#12 has just been emailed out, which contains a summary of the open proposals
18:06:31 <felixfontein> I guess for 1) and 2) the question is more how should we continue discussing this. you created a discussion for it :)
18:06:50 <gundalow> #topic new collections for 2.10.x /
18:06:54 <gundalow> #undo
18:06:54 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fccd88a8190>
18:06:56 <gundalow> #topic new collections for 2.10.x
18:07:17 <gundalow> 1) Has there been enough discussion
18:07:17 <gundalow> 2) Is the plan clear
18:07:17 <gundalow> 3) Who needs to sign off
18:08:15 <gundalow> oh, I'm assuming we are only talking about moving content around from https://github.com/ansible-community/ansible-build-data/blob/main/2.10/ansible.in no net-new code
18:08:51 <felixfontein> well adding a new collection which contains code from a currently ansible-contained one might bring also new modulesplugins
18:08:55 <felixfontein> +/ :)
18:09:08 <svg> o/ cybette and others
18:09:14 <felixfontein> #chair svg
18:09:14 <zodbot> Current chairs: cybette felixfontein gundalow svg
18:09:33 <cybette> hi svg! :)
18:09:34 <felixfontein> gundalow: all three are good questions
18:09:44 <aminvakil1> hi everyone!
18:09:53 <svg> not used to these meetings, not sure how I can propose a topic?
18:09:54 <felixfontein> I'm not sure how much input, resp. from how many different people we actually had. I think from not that many yet.
18:09:58 <felixfontein> #chair aminvakil1
18:09:58 <zodbot> Current chairs: aminvakil1 cybette felixfontein gundalow svg
18:10:02 <felixfontein> hi amin!
18:10:03 <gundalow> felixfontein: I *think* that's the same as c.general could (does) have new modules
18:10:16 <aminvakil1> hi felix!
18:11:21 <gundalow> https://etherpad.opendev.org/p/ansible-contributor-summit-october-2020-morning Line 58
18:11:32 <felixfontein> I guess the final decision for 3) is up to Toshio, since he builds the thing :)
18:11:47 <felixfontein> but it's not nice to shift all decisions to the RM
18:11:52 <cybette> svg: you can propose it here https://github.com/ansible/community/issues/539 or use the "open floor" at the end to bring up a topic
18:12:43 <felixfontein> gundalow: that's kind of https://github.com/ansible-collections/overview/discussions/117#discussioncomment-106136
18:12:45 <svg> guess i'm to late for the issue, I'll wait for the open floor, makes more sense too
18:14:36 <felixfontein> I added the strawman proposal to https://github.com/ansible-collections/overview/discussions/117#discussioncomment-106136
18:15:18 <resmo> o/
18:15:19 <felixfontein> that proposal would be compatible to the versioning plan of c.g, and in case 2.10.x allows new collections, this could be done
18:15:22 <felixfontein> #chair resmo
18:15:22 <zodbot> Current chairs: aminvakil1 cybette felixfontein gundalow resmo svg
18:15:26 <felixfontein> hi resmo!
18:16:05 <gundalow> > move things out of c.g after the last 1.x.0 minor release (see release schedule: end of November 2021)
18:16:05 <gundalow> That's ambiguous to me. Does that mean `git rm` (and add runtime.yml redirects) after the last 1.x.0 release?
18:17:26 <felixfontein> gundalow: I think it means `git rm`, so they will be gone in c.g 2.0.0
18:17:39 <felixfontein> I should have been more precise last week, would be less thinking now :D
18:17:52 <gundalow> haha, I appreciate you taking notes
18:18:36 <gundalow> I'm +1 to that
18:18:50 <gundalow> It does put the requirement on users to know their is a new collection and to use that
18:19:23 <gundalow> Though I think it's the only clean way since otherwise ansible-base's runtime.yml may point to something you don't have installed
18:19:29 <felixfontein> I updated the proposal copy in https://github.com/ansible-collections/overview/discussions/117#discussioncomment-107974
18:19:37 <felixfontein> I hope it's more precise now :)
18:19:54 <felixfontein> yes
18:20:05 <gundalow> Yup, that's better
18:20:08 <felixfontein> and c.g 2.0.0 has a breaking change, which can be mitigated by installing the new collections next to it
18:20:28 <felixfontein> but that's ok since it's a new major release. it's unfortunate to not have a deprecation period, but since it's easy to mitigate, I think it's ok
18:20:35 <gundalow> resmo: svg aminvakil1 andersson007_ any thoughts on https://github.com/ansible-collections/overview/discussions/117#discussioncomment-107974
18:21:27 <felixfontein> sorry, I forgot to ping lmodemal at the beginning of the meeting
18:23:06 <lmodemal> Hello o/
18:23:23 <felixfontein> @chair lmodemal
18:23:41 <gundalow> #chair lmodemal
18:23:41 <zodbot> Current chairs: aminvakil1 cybette felixfontein gundalow lmodemal resmo svg
18:23:53 <felixfontein> no idea whether you're interested in this meeting, but since acozine and samccann are often here as well... :)
18:24:03 <gundalow> Are their any downsized to this proposal?
18:24:12 <felixfontein> typing, eating and thinking are not 100% compatible
18:24:16 <lmodemal> Thanks for including me :)
18:25:30 <aminvakil1> if i understand this correctly, the proposal is to copy the modules to community.postgres and update them there except bugfixes, anyone using postgres.somemodule will be redirected to community.general.postgres_somemodule, but they can use the community.postgres.somemodule, am I right?
18:26:00 <aminvakil1> and remove them from community.general in 2.0.0
18:26:14 <gundalow> anyone using `postgres_user` will end up using the (semi)unmaintained `community.general.postgres_user` module
18:26:17 <felixfontein> there's no redirect from community.postgres to community.general; the modules will mainly live in community.postgres, but be kept for compatiblity in community.general
18:26:17 * acozine is in a training session
18:26:24 <felixfontein> (until 2.0.0 is released, then they're gone)
18:26:41 <aminvakil1> yeah, this might make confusion.
18:26:55 <felixfontein> true. fortunately the timeframe is not that long (2 months)
18:27:13 <aminvakil1> november 2021?
18:27:15 <gundalow> hum, so potential thing is would people still raise PRs against community.general? Maybe not if we `git rm` from main, and the plugin is only in `stable-1` branch
18:27:27 <felixfontein> or 3 months, depending on when the collections are released and added to ansible 2.10.x
18:27:31 <felixfontein> aminvakil1: november 2020 :)
18:27:35 <samccann> sorry acozine and I are in training. I'll scroll back when it's done
18:27:41 <gundalow> felixfontein: `end of November 2021` (typo?)
18:27:56 <felixfontein> acozine: samccann: no problem :)
18:28:10 <felixfontein> did I write 2021?
18:28:15 <felixfontein> oh
18:28:16 <gundalow> etherpad and copypasted
18:28:17 <felixfontein> lol
18:28:18 <felixfontein> thanks :)
18:28:20 <aminvakil1> in github it has been written 2021
18:28:21 <gundalow> only just noticed
18:28:37 <felixfontein> aminvakil1: just changed it :)
18:30:07 <felixfontein> so for 2-3 months (more like 2, because the collections have to be set up first) c.g will get no new features, and maybe not every bugfix for these modules, but then ansible 2.11.0 is released which will contain c.g 2.0.0 which has redirects
18:30:29 <felixfontein> (the only suffering people will be the Ansible 2.9, they will have to adjust their FQCNs manually)
18:31:49 <felixfontein> (and they only have the problem when upgrading fom c.g 1.x.y to 2.0.0)
18:32:23 <gundalow> No going to impact that many people negatively in that time window
18:32:36 <felixfontein> I agree
18:32:44 <gundalow> For CI speed it would be good to migrate docker and postgres
18:32:55 <gundalow> migrating out postgres would also help Tower installer
18:33:08 <gundalow> Is there anything else that we know about, was there are k8s collection?
18:33:41 <felixfontein> I would also prefer to migrate everything that causes c.g to have collection dependencies
18:33:55 <gundalow> I see from #117 rockaut is in favor of migrating postgres as well
18:33:55 <felixfontein> i.e. kubevirt (I think someone already works on that?), and the handful of other modules/plugins
18:33:56 <gundalow> ah, yes
18:34:22 <felixfontein> https://github.com/ansible-collections/community.general/issues/354
18:35:02 <felixfontein> we could add a community.google collection (main problem are missing maintainers). that together with a kubevirt collection would remove all non-ansible dependencies
18:35:23 <felixfontein> for the ansible.* dependencies, we could vendor the few utility functions they include
18:36:02 <felixfontein> they only need some helper functions like validate_ip_address, validate_ip_v6_address, ismount
18:36:26 <gundalow> OK, lets do this
18:37:34 <felixfontein> we have to cut a bit on the maintainer requirements though
18:37:53 <gundalow> how do you mean? Making new collection/repos that no one will look at?
18:38:25 <felixfontein> yes, especially community.google might be kind of unmaintained
18:39:12 <felixfontein> we had this requirement somewhere "at least two maintainers"
18:39:17 <felixfontein> (for new collections?)
18:39:29 <gundalow> yup, in collection checklist
18:40:43 <tadeboro> I would say that this rule can be broken if the content is not new. Because the same people will still look after it no matter if it is part of the c.general or c.google (man, c.g is not unique ;)
18:40:48 <felixfontein> it shouldn't be a problem for community.postgres, might become a problem for community.docker, and probably is a problem for community.google
18:40:58 <gundalow> tadeboro: oh, that's a nice point
18:41:08 <felixfontein> tadeboro: true! I like that
18:41:32 <gundalow> technically we aren't making the situation worse (zero maintianers for X in c.g == zero maintainers in c.x
18:41:35 <gundalow> )
18:41:45 <felixfontein> as long as someone takes a bit care to make sure CI is still running, and allowing people who want to to contribute, I think it should be fine
18:42:05 <felixfontein> gundalow: true, except that there's a new separate CI ;)
18:42:41 <gundalow> luckly I should have some new people starting next month, so maybe I can take responsibility for that
18:42:54 <felixfontein> should we also move some stuff out of community.network? it currently depends on check_point.mgmt and fortinet.fortios
18:44:08 <gundalow> I guess so
18:44:23 <felixfontein> I'd also propose community.routeros (moved from community.network), since that part is actively maintained
18:45:23 <felixfontein> maybe we should create tracking issues for every move-out
18:45:35 <felixfontein> and maybe also ask whether others also want to move to their own collection
18:45:59 <gundalow> Do we want to encurage others at this stage?
18:46:05 <gundalow> given deadlines?
18:46:19 <felixfontein> good question
18:46:39 <felixfontein> the main deadline is "a few 2.10.x releases before 2.11.0" I guess
18:46:55 <felixfontein> and "a few weeks before c.g/c.n 2.0.0"
18:47:01 <felixfontein> i.e. beginning of January
18:47:51 <felixfontein> let's say the collections need to be done by end of december
18:48:02 <gundalow> +1
18:48:04 <felixfontein> then we have a bit of wiggle-time
18:48:22 <gundalow> Sounds like a plan
18:48:39 <felixfontein> for that we need a decision on the question "new collections in 2.10.x" though :)
18:48:44 <gundalow> If we can define the steps we can then farm this out to multiple people
18:49:19 <felixfontein> I'm happy to help with all of them
18:49:31 <gundalow> +1 to "We will allow content to migrate from an existing https://github.com/ansible-community/ansible-build-data/blob/main/2.10/ansible.in to a new one, as long as all dependencies are contained in https://github.com/ansible-community/ansible-build-data/blob/main/2.10/ansible.in"
18:49:35 <gundalow> Thanks felixfontein :)
18:49:50 <felixfontein> (of course I'm happy if I don't have to do all of them :) )
18:50:09 <gundalow> I can help with some
18:50:48 <felixfontein> btw, about CI for the new collections, should they use github actions, azure, or something else?
18:50:56 <gundalow> svg: did you have a topic?
18:51:06 <felixfontein> especially for postgres and docker having something like shippable would be better than github actions
18:51:14 <felixfontein> but that's not urgent. let's talk about svg's topic first!
18:51:27 <svg> not so much a topic, as some feedback
18:51:36 <gundalow> #topic Open Floor
18:51:42 <svg> I prepared a bt of text:
18:51:45 <gundalow> svg: The floor is yours
18:51:49 <svg> So I tried following discussions here tonight, but was overwhelmed by a;; those different collection namespaces that were mentioned. Came here after having a short discussion in a private group with some long time ansible users, and cybette asked us to give feedback here.
18:51:51 <svg> Basically, all those namespaces are confusing as hell. Now we understand this is al new, and lots of things are being tried, and need some time to sort out of course.
18:51:53 <svg> Now this made me wonder if there are specific rule, about how to know about 1/ official namesapces, 2/ community namespaces 3/ vendor specific namespace, and 4/ possible others. I know the theory a bit, and community.* is clear, but e.g - I think it was mention ed in the lates Bullhorn - "community.kubernetes collection is going to move to kubernetes.core" - again, confusing.
18:51:55 <svg> Not asking for the specific answer here, but I guess what I wanted to achieve, is stressing how confusing this is, even for Ansible experts - which perhaps don't work with collections on a daily basis yet, and propose this should get special attention in documentation and communication in general.
18:52:11 <svg> HTH :)
18:53:17 <gundalow> svg: Firstly I appreciate the feedback, especially on things we are doing that clearly confuse people
18:53:35 <svg> cybette, feel free to give some nuance, as you followed the discussion I refered to, I might miss a thing.
18:54:04 <tadeboro> svg: As far as I know, there is no guidelines about the namespaces at all (and some vendors had quite some troubles selecting the "right" one according to the partner engineering team).
18:54:08 <felixfontein> is tonight = today and here, or tonight = last week at the the community summit?
18:54:09 <cybette> svg: you've covered the main sentiments well
18:55:14 <cybette> I think tonight = today and here
18:55:27 <gundalow> `"community.kubernetes collection is going to move to kubernetes.core"` I think that's a good example of where we ever talk about changing namespaces we should assume zero background knowledge and therefore must give a one line summary, then link back to something more details that explains the what/why of naming
18:56:11 <tadeboro> svg: As far as the moving things around goes, I expect things to stabilize a bit once there are no more large collections such as community.general.
18:56:15 <felixfontein> I only heard about community.kubernetes -> kubernetes.core a couple of days ago (last week probably?) and have no idea on why it is done
18:56:18 <svg> gundalow, 👍
18:56:54 <felixfontein> I'm mainly concerned on shuffling around the community.* space :)
18:56:58 <svg> tadeboro,yes, that is too what I expect, and I expect that will become easier in the near future.
18:58:12 <tadeboro> But I can imagine the pain of an early adopter that moved to FQCNs just to be forced to do another grep over her stuff once every few weeks.
18:58:16 <svg> I recently read an issue I think, about some repo having older roles/modules, that were deprectated, and another namespace where the newest were to be found. Pretty sure that will be very confusing, if noticed at all, and I expect lots of people to pick the wrong one.
18:58:17 <cybette> a couple of events I'd like to mention:
18:58:42 <svg> not only early adopters of ansible, anyone who needs to start using some new bits
18:58:49 <cybette> (oops sorry matrix just burped out a bunch of messages, I thought people have stopped talking)
18:59:49 <felixfontein> svg: if you mean the procedure for moving stuff I mentioned (i.e. https://github.com/ansible-collections/overview/discussions/117#discussioncomment-107974), then early adopters will not miss much (and for only a short time) until they upgrade to ansible 2.11.0
19:00:25 <tadeboro> svg: Ugh, I forgot about the stuff that is only accessible via the FQCN.
19:00:41 <felixfontein> svg: it is mainly problematic for Ansible 2.9 users, which don't have the redirects
19:01:11 <felixfontein> tadeboro: that's no problem for 2.10+ users, since there will be redirects. it's a problem for 2.9 users though.
19:01:40 <felixfontein> but the only way to avoid this is not to move any content, until 2.9 is gone
19:01:50 <felixfontein> and then more people will have used the 'wrong' FQCNs
19:03:28 <gundalow> I may be missing something, though what's the 2.9 concern? 2.9 doesn't have runtime.yml, so if you are using collections you need to specify what you want to use
19:04:04 <felixfontein> gundalow: yes, and if 2.9 users start using c.g with the modules in there, they put the FQCNs like community.general.postgres_database in their playbooks/roles
19:04:14 <felixfontein> and once community.general 2.0.0 comes out, they suddenly stop working
19:04:34 <tadeboro> gundalow: On 2.9, if you need something new, you need to use FQCN for that stuff. And if the FQCN changes, you need to update your playbooks.
19:04:34 <felixfontein> since community.general.postgres_database is no more, and the redirect only works with ansible-base 2.10+
19:05:21 <gundalow> felixfontein: I though c.g 2.0 would have runtime.yml pointing to c.postgres.x
19:05:23 <felixfontein> that's why I wouldn't use 2.9 for collections :) but unfortunately 2.9 is pretty popular, and RH is not helping by skipping 2.10 :)
19:05:33 <felixfontein> gundalow: it has, but ansible 2.9 doesnt know about runtime.yml
19:05:46 <felixfontein> ansible-base 2.10+ knows about it, but not ansible 2.9 or earlier
19:07:00 <felixfontein> the problem is that if we tend 2.9 users, we screw 2.10+ usres, and if we tend 2.10+ users, we screw 2.9 users
19:07:10 <felixfontein> except if we don't move anything, then everyone's happy
19:07:15 <felixfontein> except us :)
19:09:16 <felixfontein> where us = the people who develop and maintain the collections
19:10:41 <gundalow> I wouldn't prioritise  2.9+collections over 2.10+
19:11:02 <tadeboro> felixfontein: collections that were created from ansible 2.9. The rest of us have less problems because we have a stable FQCN from the get go.
19:11:05 <felixfontein> me neither. we shouldn't just ignore them either, though.
19:11:42 <felixfontein> tadeboro: true :) even though also other collections might want to move stuff or rename themselves, and they'll then face the same problems
19:11:44 <tadeboro> Yeah, I just heard a few days ago Ansible 2.9 being called LTS, sooooo ;)
19:11:56 <felixfontein> exactly...
19:12:10 <felixfontein> and nitzmahone didn't like the idea of backporting routing to stable-2.9 :)
19:12:18 <felixfontein> that would also solve that problem for us
19:13:27 <felixfontein> anyway, the longer we wait with shuffling stuff around, the more it hurts for 2.9 users, since there will be more of them that are actively using FQCNs in a lot of places
19:14:04 <tadeboro> But I tend to agree with gundalow here: I think it is OK for community to prioritise ansible 2.10 over 2.9.
19:14:16 <gundalow> I vote we move the content out of c.g and c.n as we talked about today
19:14:26 <tadeboro> And yes, the sooner things can get their semi-permanent home, the better.
19:15:07 <felixfontein> should we vote on this somehow? or have a public poll (outside this small group)?
19:16:31 <tadeboro> I am not sure if public poll is the best way to go since most people do not have enough information to make an informed decision about this.
19:17:17 <felixfontein> yep, I agree
19:17:26 <gundalow> I'm OK to proceed
19:17:33 <tadeboro> I would say that current maintainers should decide on a compromise that makes their life bearable while not screwing up the users.
19:18:15 <tadeboro> And if I put myself in the end-users shoes, current compromise of leaving a few things broken on 2.9 is acceptable.
19:19:18 <felixfontein> especially if a simple `community.general.postgres_` -> `community.postgres.postgres_` transformation can be used to rewrite names
19:20:11 <tadeboro> If at all. As said before, if the moves are done sooner, most users will not even know about the move at all.
19:20:30 <aminvakil1> can this be implemented on ansible-lint, so that some users can do the fixes when redirection is still there?
19:20:37 <gundalow> I need to drop off now
19:20:42 <gundalow> Thanks everybody
19:20:52 <felixfontein> thanks gundalow!!!
19:20:55 <cybette> couple things to add
19:21:06 <cybette> #info Free webinar next week (Oct 28) "Introduction to Testing Ansible Collections" https://steampunk.si/webinars-training/intro-testing-ansible-collections/
19:21:10 <cybette> led by tadeboro :)
19:21:18 <cybette> #info Ansible Hacktoberfest 2020 (Oct 30) https://organize.mlh.io/participants/events/3936-ansible-hacktoberfest-2020-virtual
19:21:29 <cybette> bring your own beer and halloween costume if desired
19:21:34 <cybette> we didn't have a hack day after Contributor Summit last week, so this can be considered in lieu of the hackday
19:22:02 <cybette> the Hacktoberfest site requires you to create an account. if you prefer not to, just add your name to the etherpad here: https://etherpad.opendev.org/p/ansible-hacktoberfest-2020
19:22:07 <cybette> #info Ansible Hacktoberfest etherpad https://etherpad.opendev.org/p/ansible-hacktoberfest-2020
19:22:33 <felixfontein> aminvakil1: not sure, probably would need a big hack and it has to be done very fast, because once the move has been done and people upgraded the collections, it's too late
19:22:37 <felixfontein> hmmmmmmmmmmmmmmmmmm
19:22:37 <felixfontein> I just got an idea
19:23:10 <aminvakil1> felixfontein: yep
19:23:22 <felixfontein> how about adding redirects to meta/runtime.yml, but keeping the old modules around and marking them as deprecated? that will cause some sanity errors (because meta/runtime.yml and module disagrees), but it will continue to work for 2.9 users and they get a deprecation warning, while 2.10+ users get the redirects
19:24:17 <felixfontein> it will be a bit more tricky for the modules depending on another collection, since the dependency will be gone, but I think it's doable
19:24:28 <felixfontein> hmm, except that galaxy import will break since ansible-doc won't work when doc fragments are missing
19:24:31 <felixfontein> hrm
19:24:49 <tadeboro> felixfontein: This thing might need to live for quite a while though. So think twice before accepting that kind of maintenance burden ;)
19:25:12 <felixfontein> tadeboro: yep, I know
19:25:31 <felixfontein> tadeboro: considering the problems caused by doc fragments, it doesn't sound very good
19:25:45 <felixfontein> (if it's just adding some sanity/ignore-*.txt entries, it would be fine)
19:27:06 <felixfontein> hmm, I guess it's time to stop for today
19:27:18 <felixfontein> let's think about this and continue next week?
19:27:37 <tadeboro> +1 for next week.
19:27:42 <felixfontein> I'll try to write up some things in https://github.com/ansible-collections/overview/discussions/117#discussioncomment-107974
19:28:04 <felixfontein> ok, thanks everyone!
19:28:07 <felixfontein> #topic open floor
19:28:19 <felixfontein> if you have something else, write in the next two minutes :)
19:28:40 <cybette> oh I thought the previous topic was already open floor
19:29:16 <felixfontein> I think this week we forgot a lot of #topic and #info lines...
19:29:33 <cybette> not sure if it's element or matrix but I'm getting the messages in spurts and it's really confusing. sorry for my flood of messages earlier.
19:29:33 <tadeboro> Technically, it was. But the rules are there to be broken ;)
19:29:34 <felixfontein> but actually you're right
19:29:59 <felixfontein> cybette: no problem :)
19:30:47 <cybette> I #info-ed the stuff so it should be fine. just in the wrong order and interrupting people :P
19:31:32 <cybette> nothing else from me, thanks
19:32:02 <felixfontein> ok :)
19:32:04 <felixfontein> #endmeeting