20:00:06 <jborean93> #startmeeting Windows Working Group
20:00:06 <zodbot> Meeting started Tue Jun 27 20:00:06 2017 UTC.  The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:06 <zodbot> The meeting name has been set to 'windows_working_group'
20:00:14 <dag> o/
20:00:18 <nitzmahone> yo
20:00:20 <jborean93> #chair dag
20:00:20 <zodbot> Current chairs: dag jborean93
20:00:25 <jborean93> #chair nitzmahone
20:00:25 <zodbot> Current chairs: dag jborean93 nitzmahone
20:00:25 <jhawkesworth_> hey
20:00:32 <jborean93> #chair jhawkesworth_
20:00:32 <zodbot> Current chairs: dag jborean93 jhawkesworth_ nitzmahone
20:00:49 <nitzmahone> Long time no see ;)
20:00:49 <jborean93> please bare with me if I screw something up, new to zodbot so we'll see how it goes
20:01:58 <dag> :-)
20:02:02 <jborean93> #topic ansible.cfg winrm https://github.com/ansible/community/issues/153#issuecomment-303340639
20:02:14 <jborean93> I saw this floating around dag and was unsure if we discussed it
20:02:25 <nitzmahone> I think you weren't in the meeting where we did
20:02:27 <dag> jborean93: this is going to have to wait for bcoca's config rewrite
20:02:37 <dag> we should make a not, will do
20:02:39 <dag> note
20:02:47 <jborean93> no worries
20:02:50 <jborean93> #topic doco split https://github.com/ansible/community/issues/153#issuecomment-305778649
20:02:57 * gundalow waves
20:03:00 <jborean93> did you guys discuss this more at London
20:03:04 <jborean93> #chair gundalow
20:03:04 <zodbot> Current chairs: dag gundalow jborean93 jhawkesworth_ nitzmahone
20:03:14 <dag> ah, the note is in the comment
20:03:17 <nitzmahone> We didn't get to details, other than, "it's a thing we should do"
20:03:27 * jborean93 should learn to read
20:03:43 <dag> next !
20:03:55 <nitzmahone> Probably a good time to actually do that is during the core freeze before 2.4.0
20:03:57 <jhawkesworth_> iirc feeling was we'd need to wait for bcoca's changes first. so after2.4
20:04:35 <jborean93> jhawkesworth_ was that for the documentation or dag's ansible.cfg?
20:04:48 <jhawkesworth_> ansible.cfg I think
20:04:51 <jborean93> ok
20:05:22 <jborean93> ok sounds like the change freeze is  good time to look at this
20:05:36 <jborean93> we can use the wiki to build up a basic structure and go from there?
20:06:13 <nitzmahone> Something like that- or just check in stubs. Want to make sure we don't actually replace the other stuff until we reach some stability/parity, or they flip 2.3 to the default docs
20:06:34 <nitzmahone> (otherwise someone will publish the stubs and we won't have any docs :) )
20:06:56 <dag> let's discuss first in the Wiki, and then do the changes in a WIP PR
20:07:01 <nitzmahone> Basically just "don't replace intro_windows content until everything's workable"
20:07:09 <dag> so everyone can verify and we can still shuffle it around
20:07:13 <nitzmahone> +1
20:07:22 <jborean93> +2
20:07:35 <gundalow> Remember to look Scott into discussion regarding docs, he's a good resource
20:07:36 <nitzmahone> I don't think we actually want to write it in the wiki, but we can agree on structure and fill in stuff in PRs
20:07:37 <dag> I will move my stuff in, then we discuss in the next meeting ?
20:07:46 <dag> gundalow: Scott ?
20:07:52 <nitzmahone> dharmabumstead
20:07:55 <dag> aha !
20:07:58 <jborean93> #action wait until 2.4 freeze before starting on documentation work
20:07:58 <nitzmahone> our docs guy
20:08:12 <gundalow> Scott = dharmabumstead = Technical Author at Ansible
20:08:14 <dag> jborean93: you can put my name on it
20:08:23 <dag> I will add it to the planning on my name
20:08:25 <jborean93> can I do that retroactively?
20:08:32 <jborean93> or just add another action?
20:08:43 <nitzmahone> just do another- there's #undo I think
20:08:47 <dag> no clue :)
20:08:51 <nitzmahone> but I don't remember how it works
20:09:07 <jborean93> #action dag to start on documentation foundation after 2.4 freeze
20:09:15 <jborean93> double action it is
20:09:26 <jborean93> cool, anything else on that topic?
20:09:42 <dag> #action jborean to read up on how the bot works by 7/4 :P
20:10:16 <jborean93> #topic winrm connection issues https://github.com/ansible/community/issues/153#issuecomment-307416504
20:10:22 <jborean93> how did you go with your POC
20:10:34 <jborean93> I know you said you found differences between WMF 5 and older versions
20:10:35 <dag> I'll ask around informally when doing the new structure to get it as good as can be for the first draft
20:11:08 <dag> jborean93: I can reproduce it, and my fix causes a HTTP 500 on WMF 4, but works fine on WMF 5
20:11:44 <dag> I tried retrying on HTTP 500, but that gave me errors on the returned XML IIRC on WMF 4
20:12:32 <dag> I was hoping to get some feedback from others on this, my changes are not very good for making public (it's in winrm)
20:12:37 * nitzmahone is getting ready for a pywinrm update- will definitely include the error message in 500's fix
20:12:43 <jborean93> do you have a branch on github with your changes or is it just local for now?
20:12:57 <dag> but making the retry-count and retry-sleep configurable means changing functions calls etc.
20:13:04 <dag> jborean93: it's local
20:13:28 <dag> nitzmahone: good to know, because for the lab I'd prefer not to have to move to WMF 5 for this one
20:13:53 <dag> the vmware-issue I cannot reproduce on demand, it happens from time to time, but I am pretty sure the cause is identical
20:14:45 <jborean93> ok so it sounds like we are going to wait until nitzmahone has time to work on pywinrm for this one here?
20:15:16 <dag> fine by me, I'll make the changes available asap
20:15:36 <dag> another problem is that "Connection refused" is not exposed by WinRM IIRC
20:15:37 <nitzmahone> yeah, if dag wants to either make a pywinrm PR or share a repo w/fix that's mostly working, I can try to include in 0.3.0 or whatever we're calling this one
20:15:47 <dag> sorry, by requests
20:15:48 <nitzmahone> We can fix that
20:15:48 <jborean93> #action dag to push with pywinrm changes for broken connections
20:15:57 <nitzmahone> Oh, requests will be harder
20:16:01 <dag> so we don't know exactly that it is a Connection refused
20:16:13 <nitzmahone> Yeah, it's the "retried lots of times, gave up" error, right?
20:16:20 <dag> but at least it is a connection related error
20:16:45 <dag> I don't think it retries, it just returns a generic string, not the original error information
20:16:49 <dag> which is stupid :-(
20:17:17 <dag> next topic :)
20:17:26 <jborean93> #topic iis modules, webbinding and website]
20:17:27 <nitzmahone> stupidity abounds in pywinrm
20:17:46 <nitzmahone> (and sometimes requests)
20:17:49 <jborean93> I written a comment about it yet
20:17:54 <jborean93> I haven't*
20:18:08 <jborean93> but basically we have a module to create an IIS site and another to configure bindings
20:18:32 <jborean93> iis_website can set the bindings but only on creation and the changes I'm making to iis_webbindings can configure them
20:18:43 <nitzmahone> noice
20:18:55 <jborean93> The trouble is that I feel this might belong into one module instead of 2 but it would complicate it a bit
20:19:23 <nitzmahone> I'd be more inclined to deprecate the stuff in website, IIRC the UI is ... obtuse
20:19:33 <dag> jborean93: normally one module manages on "object", modules trying to do more than one thing are always a pain (unclear what was changed, etc...)
20:20:01 <nitzmahone> Since bindings are a multiple-object thing under a site, having their own module is OK IMO
20:20:07 <jborean93> The problem I have is if you create a site and want to set some bindings you would 2 task calls
20:20:27 <jborean93> 1 to create the site (iis_website), 2 to create the binding (iis_webbinding) and 3 to start the site (iis_website)
20:20:47 <jborean93> + you may end up with multiple bindings if you don't delete the originals
20:20:52 <nitzmahone> Yeah, where that gets ugly is when you need to define N bindings- the code gets nasty in a hurry. Some of the new module API stuff makes it a little better, but  it's still kinda nasty.
20:21:26 <nitzmahone> What are you using as the binding key- proto + port?
20:21:45 * nitzmahone hasn't scripted IIS binding setup in a long time, doesn't remember what the natural key is
20:22:01 <jborean93> it depends on what type of binding and IIS version unfortunately
20:22:21 <nitzmahone> right, that's the proto part (http,https,net.tcp, etc)
20:22:29 <jborean93> currently the module get's a list of bindings based on the parameters and modified them accordingly
20:22:39 <jborean93> well tries to
20:22:53 * jborean93 sees lots of issues with the current module
20:23:10 <dag> are the DSC modules any better ?
20:23:25 <jborean93> I haven't looked at them but DSC only works with WMF 5.1
20:23:28 <nitzmahone> yeah, I've been tempted to take a flamethrower to that before, but didn't have the bandwidth to adopt another module :)
20:23:39 <dag> right
20:23:41 <jhawkesworth_> trond was saying that he's only using DSC stuff for IIS now
20:24:02 <jborean93> #chair trondhindenes
20:24:02 <zodbot> Current chairs: dag gundalow jborean93 jhawkesworth_ nitzmahone trondhindenes
20:24:47 <dag> hey trond !
20:25:48 <trondhindenes> hey guys!
20:25:53 <jborean93> I'm happy to keep the status quo for the bindings module but I see limitations with it
20:25:54 <jborean93> hey
20:26:21 <nitzmahone> I'm sure the DSC modules are stronger- IIRC Microsoft wrote them
20:26:43 <trondhindenes> are we talking IIS stuff?
20:26:47 <jborean93> yep
20:26:59 <jborean93> around win_iis_website and win_iis_webbindings and how they fit together
20:27:22 <trondhindenes> we switched to dsc-based modules couple of weeks ago. The IIS dsc stuff is fairly solid.
20:27:45 <jborean93> I suppose we can just fix the issues as they are and recommend people to use the DSC stuff instead for those who can
20:28:15 <jborean93> that way we still cater for the older servers (using the modules in a convoluted way) and DSC wherever we can
20:28:45 <trondhindenes> its complex stuff - mostly since the apis to manipulate IIS sux. So might be better to invest time elsewhere, and let M$ write stuff for managing IIS themselves (DSC modules that is)
20:28:58 <nitzmahone> I think that may be a long-term solution to a lot of things, especially if we can minimize the friction of bootstrapping the DSC stuff
20:29:22 <jborean93> I've got the changes to the bindings done I just came across this issue and didn't know how to proceed
20:29:33 <trondhindenes> I'd really like to get going on a general "Ansible and DSC" page for documentation as @dag suggested, but have no idea where I should put it
20:29:37 <jborean93> it should tie people over there is just some ugly warts there
20:29:58 <dag> trondhindenes: we are going to restructure the documentation, so it doesn't matter for now ;-)
20:30:03 <jborean93> trondhindenes: we were waiting for 2.4 change freeze to start looking at the doc rewrite
20:30:12 <dag> trondhindenes: I would simply add another main title in the current document, and start adding the content
20:30:20 <trondhindenes> I'll just write it in Sharepoint for now :-)
20:30:23 <nitzmahone> @trondhindenes generating the content is the hardest part, so if you want to get started with it kinda "standalone" we can figure out how to integrate it later
20:30:24 <dag> trondhindenes: having the content now is more important then where it is at
20:30:31 <jhawkesworth_> :-)
20:30:32 <nitzmahone> mental jinx dag
20:30:33 * jborean93 shudders at hearing the S word
20:30:48 <jborean93> cool next topic
20:30:52 <nitzmahone> Oh, you didn't know a complete suite of Sharepoint modules was on the 2.4 list ? ;)
20:30:53 <jborean93> #topic open floor
20:31:09 <jborean93> nitzmahone you can deal with that :)
20:31:54 <trondhindenes> I'd like to look at win_environment actually. But I don't completely understand jon's code. Specifically, the fact that an envvar isnt available until the "next" process keeps biting us in the behind
20:31:56 <dag> trondhindenes: ok if I add this as an action item for you on the planning ? you can add the PR if you have one
20:32:00 <nitzmahone> Do we want to keep using the issue as our agenda?
20:32:09 <trondhindenes> Jon, what are those [$level] brackets doing? Do you remember?
20:32:27 <trondhindenes> oh sorry, this is "the" meeting and I'm rambling on.
20:32:27 <jhawkesworth_> not now, let me have a look
20:32:54 <jborean93> #action jborean93 to keep the iis modules separate, encourage use of win_dsc instead
20:33:01 <dag> nitzmahone: I do like the issue for the fact that if we reference anything, it get's cross-reference too
20:33:19 <dag> nitzmahone: the Wiki unfortunately cannot do that, and that's a major feat.
20:33:24 <nitzmahone> Yeah, I was hoping the wiki would have something similar, but alas...
20:33:36 <trondhindenes> so i guess:
20:33:51 <trondhindenes> #action trond starts on "general" dsc documentation/recommendations
20:34:04 <nitzmahone> +1
20:34:11 <jborean93> +100
20:34:11 <dag> nitzmahone: we have some feature-requests for GitHub, jhawkesworth_ already asked for automatic issue/PR substitution like comments
20:34:28 <dag> trondhindenes: finally !! :p
20:34:42 * jhawkesworth_ needs to follow that up with github support.
20:34:43 <nitzmahone> IIRC the GH wiki stuff has been very stagnant for a long time
20:34:51 <dag> trondhindenes: You already had quote some examples ready, so it's going to be easy IMO
20:35:21 * jborean93 wishes I still had access to Confluence
20:35:42 <dag> nitzmahone: if it's Open Source, I don't mind looking at it, the main problem for the wiki is that they support about 10 markup languages, and they probably want to keep feature-parity
20:36:16 <nitzmahone> Yeah...
20:36:22 <nitzmahone> Oh:
20:36:28 <dag> BTW before the meeting I did this: https://github.com/badges/shields/pull/1020
20:36:31 <nitzmahone> #info 2.3.2 RC1 released today I believe
20:36:45 <jborean93> yep I saw that annoucement
20:36:48 <dag> would look nice for the wiki/info page (and maybe motivates us to bring it down p:)
20:36:52 <jborean93> and I saw your pipelining stuff make it in
20:37:11 <dag> great !
20:37:22 <nitzmahone> Yeah- it didn't CP cleanly into 2.3, so I had to flog it to find the bad merge
20:37:33 <nitzmahone> but should be good to go
20:38:11 <jborean93> sounds good, will have to test it out in devel and see how it works
20:38:30 <nitzmahone> There are a few other things I might try to sneak in if we do an RC2, but TBD (label:windows milestone:2.3.0)
20:38:50 <nitzmahone> I woulda had 'em in but for AnsibleFest/Iceland stuff
20:39:05 <jborean93> are there any pressing bugs we want to try and bring into 2.3 if there is another RC?
20:39:37 <nitzmahone> That dude in #ansible today that was complaining about the win_copy thing with missing lines is worrisome- I couldn't repro
20:39:55 <nitzmahone> The fact that the missing lines specifically has "password=" in both of them makes me wonder
20:40:11 <jborean93> I'll have a look at that today, I saw a bug with win_find was raised as well I was going to look at
20:40:37 <jborean93> #action jborean93 look at win_copy and win_find issue for potentially 2.3 RC
20:40:44 <nitzmahone> win_find might be a good case for "change some tests to units" too- the test coverage is great but it's hella slow
20:40:58 <nitzmahone> (once we get our PS unit testing stuff in place)
20:41:11 <jborean93> yea it is a bit of a complex one, so many edge cases
20:41:13 <nitzmahone> Or "on box integration"- I've had some ideas about that too
20:41:35 <jhawkesworth_> square1 was saying something about a win_copy leaving out one file at Fest.  He worked around by zipping first in the end.
20:41:35 <nitzmahone> (basically send over a bunch of inputs and bulk-run the module code on the client, batch up results and send back)
20:41:57 <nitzmahone> That's my plan for making recursive win_copy anyway (+ a multi-stat module)
20:42:05 <nitzmahone> making it fast
20:42:10 <nitzmahone> well, fast-er
20:42:13 <jborean93> haha
20:42:21 <jhawkesworth_> anything to speed it up.
20:42:26 <jborean93> at my previous place we ran a local action to zip it and then copy that single file
20:42:46 <jborean93> would be good for that to be the default as recursive is abysmally slow
20:42:54 <nitzmahone> Yeah, I basically want to wrap that up into the module for idempotent exec
20:43:21 <nitzmahone> (stat the whole thing on the client, figure out what we need, then archive/copy/expand and return results)
20:43:34 <nitzmahone> s/client/target
20:43:48 <nitzmahone> This one stat per file thing is horrendous
20:44:04 <square1> hey :)
20:44:07 <jborean93> #action nitzmahone to look at win_copy and improve the speed for multiple files
20:44:10 <bcoca> but needed for accurate change notitifciation
20:44:10 <square1> yeah, win_copy is the devil :P
20:44:10 <jborean93> hey
20:45:00 <nitzmahone> bcoca: right, but we don't need to do it per file *from the controller*- we've needed a remote multi-stat
20:45:12 <square1> hi everyone
20:45:30 <nitzmahone> kinda like the file: paths={{ listoffiles }} thing
20:45:40 <nitzmahone> we were talking about this morning
20:45:44 <jhawkesworth_> I got the impressiong slicing up files and xferring via encoded soap messages means the transfer was always going to be slow
20:46:12 <nitzmahone> Yeah, that part can't really be improved much without an out of band file xfer, but the slow recursive dircopy is our fault
20:46:17 <square1> I'd be happy to test any win_copy bug fixes to see if it solves my issue of it randomly missing a few files :)
20:46:38 <dag> SSH for Windows, godammit !
20:46:40 <nitzmahone> square1: I'd love a repro on that one if you can get it
20:46:53 <trondhindenes> what if win_copy copies the file to sharepoint, and then the target node could download from there? That way we wouldn't have to go thru winrm
20:47:02 <bcoca> nitzmahone: stat trees, for recursive at least
20:47:07 <nitzmahone> slash kickban trondhindenes ;)
20:47:12 <trondhindenes> :-)
20:47:13 <bcoca> nitzmahone: bsds have 'tree' for that, but not linux equiv
20:47:21 <jhawkesworth_> win_get_url is backchannel for win_copy :-)
20:47:29 <bcoca> stat/win_stat are probably easy to modify to take 'list'
20:47:33 <square1> he should be banned for even typing the SP word!
20:47:46 <jborean93> can't you see he is being ignore :P
20:48:30 <nitzmahone> OK, anything else for today?
20:48:32 <square1> nitzmahone: i'd have to see if it happens on random files, i was trying to copy 30 files over - and after 4 hours figured it was only copying 27 files :P
20:48:52 <jborean93> trondhindenes had something on win_environment?
20:49:02 <trondhindenes> yeah, I think I have a fix
20:49:17 <trondhindenes> if we actually change, I'll inject the same change into in-proc via [Environment]::SetEnvironmentVariable("lalatest", "hoho")
20:49:17 <jhawkesworth_> did anyone else try the threading_not_forking branch yet?
20:49:20 <square1> (it was a windows service and it wouldn't start because some files where missing - even though ansible said copy was fine)
20:49:33 <trondhindenes> that seems to make the var immediately available
20:49:42 <nitzmahone> jhawkesworth: yeah, I was playing with getting it running under Windows natively :)
20:50:17 <trondhindenes> so it's working? That is so kool!
20:50:27 <nitzmahone> trondhindenes: I wonder if that sends the Window message to processes to refresh- that's the only way to get that to work (and only for processes that register for that message IIRC)
20:50:52 <trondhindenes> i'll test if it works for child processes
20:50:59 <jborean93> there's a way to set it for the current process IIRC
20:51:12 <jhawkesworth_> I had some luck with it, but it seems to have trouble with the integrated kerberos stuff.
20:51:30 <trondhindenes> it probably _doesnt_ work for unrelated processes. Still, my grief is that ansible_env['lala'] won't be "active" until the next run, and my fix should alleviate that
20:52:02 <jborean93> nitzmahone: I thought we create a new shell on each task, or am I mistaken?
20:52:18 <nitzmahone> We do unless you're using with_X
20:52:38 <jborean93> ahh and the facts on the host are already gathered so ansible_env won't work?
20:52:56 <jborean93> well it won't have the new env variables
20:53:01 <dag> Can we look at some of the integration-test PRs ? plenty of those open
20:53:02 <jhawkesworth_> depending on the level, you may need to log out and log in to pick up new env
20:53:04 <nitzmahone> Right- but you can always just conditionally run setup after changing to force a refresh.
20:53:20 <jborean93> dag: planning on doing that today
20:53:40 <nitzmahone> I'll look at Jordan's, Jordan can look at yours
20:53:56 <trondhindenes> jboreaon93: even if you do a refresh (running setup) you're gonna get in trouble since its the same process.
20:53:59 <dag> doesn't that lead to corruption ? :p
20:54:01 <trondhindenes> I think
20:54:04 <nitzmahone> It's not though
20:54:13 <nitzmahone> Setup will run in a new process
20:54:23 <nitzmahone> Each new task gets its own shell
20:54:27 <jborean93> each task creates a new shell in WinRM
20:54:33 <jborean93> ^^ what nitz said
20:54:48 <nitzmahone> Only with_items (etc) reuses the shell
20:55:06 <dag> hmm, that can't be very efficient ?
20:55:32 <jhawkesworth_> the above sounds like it would be good to put in windows docs somewhere
20:55:46 <nitzmahone> There are a lot of reasons for it- I've played with persistent connections that reuse the shell (and/or the underlying HTTP connection) and it only saves about 10-15% on noop tasks
20:55:58 <dag> #action jhawkesworth_ is going to improve the docs :-)
20:56:01 <jborean93> #action someone to add shell details to docs
20:56:05 <jborean93> dag beat me to it
20:56:18 <dag> does it take actions from me ?
20:56:26 <nitzmahone> Now that we;re starting to get persistent connection stuff supported in the controller, it's something we can play with, but my prototyping shows that it's a lot of potential issues for not a huge gain
20:56:39 <nitzmahone> yeah, anyone who's been # chair'ed
20:56:45 <trondhindenes> btw, are you guys using the ansible-autocomplete extension for vscode? It's really nice
20:56:45 <dag> ah
20:56:47 <gundalow> dag: Bot should take #commands from anyone that is chaired
20:57:07 <jhawkesworth_> happy to take a stab at documenting shell stuff
20:57:08 <jborean93> IIRC there are only 2 messages send to build a shell and get it ready with WSMV
20:57:16 <nitzmahone> I haven't tried it yet- I've had more sinister thoughts playing with an actual language service for VS code
20:57:17 <gundalow> Anyone in the channel can #startmeeting
20:57:27 <jborean93> cool we are nearing a close
20:57:29 <nitzmahone> Is that true? I thought only ops
20:57:29 <dag> so any feedback on the new Wiki/community stuff ?
20:57:39 <gundalow> Bot doesn't have anything to do with IRC Ops
20:57:56 <dag> I tried to stay true to the original content
20:58:08 <jborean93> dag: so far it is fine
20:58:10 <gundalow> I was going to ask how it's working out for you, but it's not even been a week
20:58:13 <dag> but the "ideas list" could be dumbed down
20:58:16 <nitzmahone> My only fear is that the more ephemeral bits will drift a lot from our agenda tickets
20:58:36 <dag> what ephemeral bits ?
20:58:41 <nitzmahone> (would be better if we actually used the wiki for agenda, but the lack of linkage is annoying)
20:58:46 <dag> (have to look up what that means)
20:59:00 <nitzmahone> The references to individual bugs and stuff
20:59:16 <jborean93> you could use individual pages but that is a big pain
20:59:43 <dag> so to me the wiki is mostly to collaborate and give newcomers a sense of what's going on
20:59:44 <nitzmahone> Would be ideal if we just used the wiki for all coordination activities, but the appeal of automated cross-linkage in issues is hawt
21:00:42 <dag> but there is overlap with the agenda (and the meeting notes), the planning is just the summary of all things WWG
21:01:03 <dag> and the progress page could be gone once we have ticked everything off
21:01:18 <jborean93> I don't like how the current agenda works, get's harder and harder as time goes off to see what is outstanding as we need to scroll down the page
21:01:39 <dag> jborean: I agree, we could move stuff over, but that's a drag if a lot is oustanding
21:01:45 <nitzmahone> Yeah, the other WGs usually recreate monthly, but then we have to bring things forward. The wiki would be better in most ways IMO
21:02:18 <jborean93> well we have run out of time
21:02:28 <dag> with the wiki, we'd be removing stuff a lot, and so it's harder for people to see what's been done
21:02:29 <nitzmahone> We'd either have to allow global edits or have some other way for non-members to add things
21:02:55 <jborean93> I've got my orientation next week and nitzmahone is going to be playing with fireworks so I think the meeting will be off next week
21:03:16 <nitzmahone> unless someone else wants to run it
21:03:19 <dag> maybe we could do a sprint ?
21:03:37 <bcoca> i prefer a light jog
21:03:43 <jhawkesworth_> :-)
21:03:49 <dag> but then we'll need jhawkesworth_ and trondhindenes around I guess
21:04:04 <jhawkesworth_> I like idea of trying to tackle a few bugs or something.
21:04:12 <jhawkesworth_> I should be able to be around next week
21:04:15 <trondhindenes> me too
21:04:25 <jborean93> sounds good
21:04:32 <dag> ok, let's make some noise and contact some of the reporters
21:04:43 <dag> but first set the scope
21:04:46 <jborean93> #action dag, jhawkesworth_ and trondhindenes will squash some bugs next week instead of the meeting
21:04:49 * nitzmahone doesn't run unless chased
21:04:55 <nitzmahone> ;)
21:05:02 <dag> hehe
21:05:10 <jborean93> Sharepoint is behind you, better run now
21:05:15 <trondhindenes> oh lord
21:05:27 <trondhindenes> well, better behind than in front I guess.
21:05:29 <nitzmahone> ... and with that, we'll call it a week... Thanks all!
21:05:33 <jborean93> thanks
21:05:35 <trondhindenes> same!
21:05:35 <nitzmahone> hehe
21:05:42 <jborean93> #endmeeting