14:11:02 <denials> #startmeeting 2012-05-23 - Developer Meeting
14:11:02 <pinesol_green> Meeting started Wed May 23 14:11:02 2012 US/Eastern.  The chair is denials. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:11:02 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:11:14 <bshum> denials++
14:11:22 <denials> #link http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2012-05-23 is the agenda
14:12:00 <denials> any further agenda items?
14:12:23 <denials> #topic Documentation in the code repository
14:12:51 <bshum> +1 to docs
14:13:18 <denials> #info Dan Scott has been discussing the idea with Robert Soulliere and Yamil Suarez since the EG Conference, working out some of the workflows, etc
14:13:28 <tsbere> From the git access control POV it should be possible. Mildly complicated, but possible. I have notes. ;)
14:14:15 <denials> tsbere++
14:15:04 <denials> rsoulliere mentioned that he was provisioning a new server for the doc builds, and that this would fit into his reconfiguration process
14:15:12 <berick> +1
14:15:15 <denials> Any objections?
14:15:19 <jeff> +1 I think it's a good idea. Thanks to Dan, Robert, and Yamil!
14:15:47 <phasefx> +1 (no objections)
14:15:51 <eeevil> +1
14:15:54 <eby> +1 already depend on README as up to date doc
14:16:00 * denials notes that this could make it easier to commit docs as part of a new feature branch - that's apparently how the PostgreSQL folks do it these days
14:16:21 <eeevil> denials: indeed, they require it!
14:16:28 * eeevil shivers
14:16:38 <denials> tyrants!
14:16:54 <denials> okay, last call for objections or questions...
14:16:56 <hopkinsju> +1
14:17:28 <denials> and tsbere, you'll be okay with taking on the action item for setting up the git bits?
14:17:49 <tsbere> I am willing to do so, yes.
14:18:29 <denials> Oh, I should note that this would only be for the Asciidoc docs - certainly for master / 2.3, but we could consider backporting the merge to 2.2 (post 2.2.0)
14:19:14 <eeevil> -1
14:19:36 <eeevil> forward progress only!
14:19:43 <eeevil> no looking back!
14:19:46 <denials> eeevi: in fact, for sanity's sake, I think we would want to get them into rel_2_2... the problem is that if we don't, then that complicates the workflow considerably
14:20:39 <denials> given that the primary focus of DIG will be 2.2 docs for the next few months; I guess they could keep ploughing away at a rel_2_2 branchified version
14:20:49 <eeevil> fair enough
14:21:17 <denials> otherwise it's one repo for 2.2, and a different one for 2.3, and cross-repo backporting, and we're trying to keep things simple :)
14:21:57 <eeevil> yeah, I can see that, I withdraw my decrement
14:22:29 <denials> okay. we can just do that master merge for now, see how that shakes out, and look at a rel_2_2 backport in a few weeks (after 2.2.0 GA) :)
14:23:02 <denials> #agreed We will merge the docs into the master branch of the Evergreen code repository
14:23:32 <denials> #action tsbere to figure out how to restrict commits to a subdirectory (docs/) of a given branch for given committers
14:23:36 <denials> tsbere++
14:23:48 <denials> unified_code_and_docs++
14:23:48 <jeff> tsbere++
14:23:57 * tsbere grabs his notes and opens the config
14:23:59 <phasefx> hey, if svn can do it... :)
14:24:05 <eby> doc_pull_requests++
14:24:13 <jeff> docs++
14:24:14 <jeff> dig++
14:24:24 <denials> #topic Release notes entries
14:25:16 <denials> Could someone take a TODO of documenting what we're doing with release notes entries for feature branches - maybe in the HACKING file, or in the wiki, or some canonical place
14:26:00 <berick> i can
14:26:22 <jeff> the HACKING file seems like a good place. is there anything that needs discussion right now, or is the plan pretty much set?
14:26:48 <berick> i'm not 100% clear on the questions raised on the meeting agenda.  rather, that was not my assumption of how it might work
14:26:57 <jeff> nor mine.
14:27:06 <berick> i thought the contents of _NEXT would be compiled at release cutting time
14:27:30 <denials> sorry, have to step out at some point
14:27:54 * berick would like to avoid more per-feature merge steps if possible
14:27:56 <jeff> same. as i understood it, the contents would be concatenated into a single document to become the release notes for that release, and the component files in _NEXT removed.
14:28:10 <jeff> (at release time)
14:28:47 <denials> back: which is why I'm asking for someone to codify it
14:28:58 <berick> denials++ touche
14:29:27 <berick> does anyone have any preferences / objections to either approach?
14:29:38 <jeff> How would release notes differ from docs, and are we also thinking about encouraging feature branches to include "docs" in addition to "release notes"?
14:29:52 <denials> release notes are part of the docs, linked into the build
14:29:57 <eeevil> berick: as RM for EG.next, I think you can "dictate" what you want for "your" release... IMO, anyway
14:30:05 <denials> (well, will be once the merge happens)
14:30:12 <eeevil> jes sayin
14:30:34 <denials> so the advantage of merging the bit into the release document is that you see it in the doc builds as they get committed
14:30:50 <tsbere> Disadvantage is merge conflicts
14:30:54 <denials> alternately, we could link to each individual bit from the docs
14:31:01 <berick> eeevil: heh, "everyone write my release notes for me!!" ;)
14:32:30 <denials> I guess merges of the feature branch bits into the consolidated release doc could happen at different intervals
14:33:04 <eeevil> tsbere: same problem exists for 002.schema.blah, and it's minor in practice
14:33:07 <denials> wouldn't have to be just at release time, if DIG wanted to refresh them at various points in the release cycle
14:33:15 <eeevil> and 950
14:34:54 <eeevil> denials: perhaps automatically by buildbot ;)
14:34:57 <denials> proposal: let's take it one step at a time: codify "adding a release notes entry into the release_notes_next dir" to begin with
14:35:09 <berick> denials: i could see that.  whenver dig wants to update the current version of the notes, do the concat-and-clear dance
14:35:10 <jeff> So, ditch the "directory" idea and have RELEASE_NOTES_NEXT be an asciidoc file that you append to with your new feature release notes?
14:35:12 <denials> and then look at possible enhancements once that piece is rolling
14:35:28 <berick> jeff: i think we want to stick with the directory to avoid conflicts
14:35:46 <denials> berick: right-o
14:35:50 <eeevil> are conflicts an actual concern?
14:35:51 <jeff> +1 to denials proposal to codify and enhance later
14:36:09 <denials> eeevil: sure, with categorization via index entry :)
14:36:11 <eeevil> git will just shift things up/down, no?
14:36:34 <tsbere> eeevil: I have seen git do weird things with lines that are equal but should be doubled.
14:36:36 * denials gets confused by some things that git results in conflicts, like CSS files
14:36:42 <berick> eeevil: not quite.  i often get conflicts in 950 seed data, etc
14:37:12 <tsbere> I fear that things like the header syntax in a release notes file could confuse git if two headers have the same line length from two different branches
14:37:17 <denials> (aside: would be nice to split the upgrade number out of 002 into its own file to avoid screwing up the rest of that critical file :)
14:37:51 <denials> okay, I'm going to call for a vote on the "start small, codify release notes bits in a directory to begin with" in a second
14:38:02 <denials> first, do we have any volunteers for said codification?
14:38:08 * berick raises hand
14:38:12 <berick> where to, HACKING?
14:38:13 <denials> berick++
14:38:17 <eeevil> whatever is least error-y in practice is fine with me (I like the dir approach for other reasons than conflict avoidence)
14:38:32 <denials> berick: HACKING sounds good to me
14:38:36 <berick> k
14:38:53 <tsbere> Quick question: Should docwriters be able to write to the README file?
14:39:10 <denials> tsbere: the way I've worked the branch in question, they will be able to
14:39:11 <eby> a few links to background here for those interested http://stackoverflow.com/questions/4920885/what-constitutes-a-merge-conflict-in-git
14:39:51 * denials would rather err on the side of permission in the spirit of collaboration
14:40:45 <denials> so: back to +1/-1 on codifying "adding a release notes entry into the release_notes_next dir" to begin with, with possible refinements down the road?
14:40:56 <tsbere> +1
14:41:32 <phasefx> +1
14:41:32 <jeff> +1
14:41:36 <hopkinsju> +1
14:41:39 <berick> +1
14:41:52 <eby> +1
14:42:26 <denials> #agreed berick will codify "adding a release notes entry into the release_notes_next dir"
14:42:30 <denials> Thanks berick!
14:42:38 * berick notes this is already codified in the wiki contributing document.  i'll just copy it into HACKING :)
14:42:52 <denials> oh cool :)
14:43:00 <denials> #topic Github pull requests
14:43:07 <hopkinsju> http://cdn.memegenerator.net/instances/400x/20848813.jpg
14:43:11 <jeff> berick++
14:43:32 <berick> hopkinsju++
14:44:13 <denials> This is perhaps minor, we've only had a handful of pull requests to date from github, but it will probably continue. and we don't want to turn away enthusiastic devs!
14:44:44 <denials> The "get steamrollered" approach would be to just do it all in github :)
14:45:22 <denials> OTOH, some clarifications in the HACKING file might make it easier to guide folks a bit.
14:45:34 <denials> I could take a stab at that
14:46:05 <denials> (and maybe at some point HACKING replaces the "contributing code" chunk of the wiki contributing doc...)
14:46:10 <jeff> I agree with the sentiments in the agenda (though I haven't read the Linus rant). No reason not to accept pull requests from github, and always a good idea to have clear and easy-to-find information on what is expected/appreciated from people making contributions.
14:47:40 <denials> We probably don't need a vote on this yet. I'll prep a branch with a modified HACKING file, designed to merge conflict with berick's efforts, and post to the -dev list
14:47:55 <denials> (unless someone else wants to!)
14:48:44 <denials> #action denials to post a branch with a modified HACKING file to the -dev list
14:49:01 <denials> #topic bug 925776 - grey bibs in the staff client
14:49:02 <pinesol_green> Launchpad bug 925776 in Evergreen "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 2, heat: 12) [Undecided,New] https://launchpad.net/bugs/925776
14:49:02 <berick> denials++
14:49:57 <bshum> Personally I think it's time for a new ticket (wishlist) to discuss options, etc. since we've diverged pretty far from the original reported issue.  But that's just me being nitpicky :)
14:50:48 * denials notes that the original report was for rel_2_0 which is no longer supported, right?
14:50:57 <bshum> 2.2 hasn't been released yet.
14:51:14 <bshum> So theoretically, it's still supported?
14:51:16 <denials> bshum: I thought there was weasel wordage around RC
14:51:24 <bshum> Oh that could be.
14:51:24 <eeevil> bshum: meh ... if the problem, as reported, gets addressed then having a sidebar to discuss things that are related (and touched by the same area of the code) is fine
14:51:39 <eeevil> denials: well, there was mention of the problem in 2.1 as well, I believe
14:52:42 <denials> eeevil: right, beth mentioned that, although there was also some correction in rel_2_1 to how bibs are scoped which might be an issue to
14:52:45 <denials> too
14:53:28 <denials> Maybe the resolution is "keep on discussing the ticket"?
14:53:39 <denials> s/the/in the/ ?
14:53:57 <phasefx> that was my whole goal with putting it on the agenda, was to get discussion
14:54:14 <denials> phasefx++ # we foiled you by discussing it in the ticket!
14:54:20 <phasefx> :)
14:54:21 <eeevil> the located uri behavior did get some refinement in 2.1, but that was OPAC targeted ... the SC probably still acts in 2.0 way
14:55:04 <bshum> I think the idea of having a way to eliminate gray bibs from the staff client is great for most staff.  But I know that catalogers aren't supposed to do that in our consortium to prevent them requesting bibs that already exist.
14:55:13 * phasefx forgot about the hidden-in-ancestor-orgs property of targeted URI's
14:55:20 <bshum> So having it applied user by user would be... "nice"
14:55:33 <eeevil> I think, though, that the general "gray records" and "uris show everywhere" problem might be nearly ameliorated by denials' suggestion
14:55:42 * denials proposes "please continue discussion in ticket, it's been kick-started nicely" (and there's lots of release-oriented stuff to talk about on the agenda)
14:56:00 <phasefx> now that the z39.50 client supports native-evergreen results, we may not need to show anything extra in the embedded opac at all
14:56:00 <jeff> sounds good. next?
14:56:02 <eeevil> heh
14:56:04 <eeevil> +1
14:56:09 <phasefx> +1
14:56:09 <bshum> +1
14:56:42 <denials> #agreed those passionate about grey bibs in the staff client will continue discussion in bug 925776
14:56:43 <pinesol_green> Launchpad bug 925776 in Evergreen "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 2, heat: 12) [Undecided,New] https://launchpad.net/bugs/925776
14:57:00 <denials> (a bit preemptive maybe with only 3 +1s, but I have to go soon)
14:57:16 <denials> #topic GSoC project updates
14:57:33 <denials> Hey! Do we have any GSoC students in the channel?
14:57:55 * eeevil guesses no
14:58:03 <denials> :(
14:58:08 <senator> pranjal710 tab completes for me
14:58:08 <eeevil> I have a request from my student, though!
14:58:23 <denials> Can I ask the mentors to link to reports or provide quick summaries?
14:58:27 <denials> Oh, sure!
14:59:30 <eeevil> if anyone has examples of nasty search queries culled from their logs (real is better, contrived is ok), and EXPLAIN ANAYLZE output for them for bonus points, it would be very helpful
14:59:56 <eeevil> the more complex the search (bools, nesting, SVF, facets, etc) the better
15:00:43 <denials> eeevil: cool, maybe you and / or your student could provide suggestions on how to set up your environment to log such things - statement length, log for query time, etc?
15:01:04 <eeevil> and, he's starting with {search|naco}_normalize(), fwiw.  it looks like ICU4C will become a dep, but that's available everywhere, AFAIK
15:01:23 <eeevil> denials: I can, and will, soon on -dev
15:01:31 <denials> (I'm guessing this would be oriented towards sites that have full dev/test replicas of their prod databases)
15:01:42 <denials> sounds awesome :)
15:01:51 <eeevil> though, I know some of you folken have done this in the past ... so this is a pre-list request
15:02:13 <senator> pranjal is working on client code in C that runs against opensrf on his own test system, to better understand what opensrf is all about.  he's also venturing out onto the mailing lists and starting to learn from some of those who have already done a little PHP work. and he's learning about the osrf gateway since that's a big difference in how one reaches opensrf services between C clients and PHP
15:02:19 <senator> clients
15:02:22 <senator> so there's our update
15:02:41 <eeevil> denials: or just on production. obv, without the ANAYLZE part ;)
15:02:59 <denials> eeevil: also, fts-whateveritwas.pl is pretty awesome
15:03:29 <eeevil> senator++
15:03:32 <eeevil> berick++
15:03:40 <eeevil> for improving my ugly crap ;)
15:03:44 <denials> eeevil: right, but unless postgresql is set up, it won't log lengthy stmts or the full text of the lengthy stmt et al
15:04:12 <denials> dbwells isn't here, so no android report
15:04:31 <denials> tsbere: any news on jlewis and the great dojo uplift?
15:04:31 <eeevil> denials: right. I'll be asking on the list. but I'm making an in-person-ish plea here, since, well, we're all here ;)
15:04:37 <denials> eeevil++
15:05:04 <tsbere> denials: I am lacking in information, poking him is on my todo list today.
15:05:14 <denials> (LD_PRELOAD those perl libs for performance wins!) :)
15:05:30 <berick> see also query_parser.pl, which is fts-whateveritwas.pl + dynamic stuff (/me didn't know fts-whateveritwas.pl was goign to get merged, so I cribbed it).
15:05:40 <tsbere> (was on my todo list yesterday, but I gave it a bad date in the 3012 range and didn't notice until today)
15:05:52 <denials> tsbere: okay, cool; a link to jlewis' blog would be good
15:05:53 <senator> gmoc
15:06:18 <tsbere> I believe he is using http://evergreengsoc.blogspot.com/ - And has no updates since the 6th
15:09:47 <denials> (sorry, I need to go) - okay -- keep in close contact with your students, get them to come to these meetings (and community meetings and whatnot), and get them involved on the lists, posting updates, etc!
15:09:59 <denials> good to see pranjal710 posting questions!
15:10:46 <denials> Release discussions?
15:10:54 <eeevil> I'll try to be better about getting things ont the list
15:10:59 <senator> re 2.2.0,
15:11:09 <denials> #topic Evergreen 2.2.0
15:11:26 * denials needs someone else to chair, sorry folks - have to run
15:11:29 <senator> i'm pretty swamped this week, but since i don't want to personally impede the release, please everyone identify the showstoppers for 2.2.0 and if possible, test and patch
15:12:07 <senator> i'll get more busy here in-channel in the new couple working days, or early next week at the latest
15:12:44 <ldwhalen> I have just installed 2.2, and I've been out of the loop for a while.  Is there any functionality that needs testing in particular?
15:12:47 <senator> if i could ask for help with just one thing though it'd be making sure everything that needs an "importance" in launchpad gets it
15:14:04 <senator> ldwhalen: great question, and i would say circ and holds, followed by tpac personally, but feel free to test according to your site's priorities. all bug reports are helpful
15:14:25 <senator> acq and serials have bugs for sure, and some folks are documenting those more formally now. you could help with that. just ideas.
15:14:36 <ldwhalen> ok.  Well, I've just z39.50 about 30 items.   I'll play around with them.
15:14:36 <bshum> denials: Toss me the chair Dan
15:14:50 <eeevil> scanning the 2.2-targetted bugs, the only one that looks like anything for 2.2.0 (to me) is 972754
15:15:17 <senator> there's more than that
15:15:42 <eeevil> ahh... the 2.2.0 milestone shows more, yes
15:15:42 <senator> also, please target bugs everyone!
15:15:47 <eeevil> like bookbag id
15:15:56 <senator> i've been bad at that myself
15:16:08 <senator> bshum: can you wrest the chair away?
15:16:17 * senator doesn't know how it worksk
15:16:27 <bshum> senator: Unfortunately not, I think denials has to issue #chair bshum or whatever
15:17:05 * eeevil hacks laurentian via denials' phone...
15:17:32 <jeff> a supybot admin should be able to @addchair
15:17:43 <bshum> Oh, hmm
15:17:57 <eeevil> @addchair bshum
15:17:58 <pinesol_green> eeevil: Error: You don't have the admin capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
15:18:03 <gmcharlt> csharp: ^^
15:18:19 <bshum> @addchair bshum
15:18:19 <pinesol_green> bshum: (addchair <channel> <network> <nick>) -- Add a nick as a chair to the meeting.
15:18:32 <bshum> Sigh
15:18:38 <gmcharlt> @addchair bshum
15:18:38 <pinesol_green> gmcharlt: Error: You don't have the admin capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
15:18:46 <gmcharlt> curses!  foiled again!
15:18:48 <gmcharlt> ;)
15:18:50 <bshum> You have to identify yourself to the bot first :)
15:19:03 <gmcharlt> bshum: I am, I just don't have the admin bit
15:19:27 <bshum> @addchair #evergreen irc.freenode.net bshum
15:19:27 <pinesol_green> bshum: Meeting on channel #evergreen, network irc.freenode.net not found
15:19:31 <bshum> Really
15:19:45 <swills_> why is the bot screaming .."must sterilize!"?
15:19:45 <phasefx> just use offline mode
15:20:24 <eeevil> phasefx++
15:21:15 <jeff> bshum: @listmeetings -- but i suspect the network is just "freenode"
15:21:32 <bshum> There we go
15:21:37 <bshum> jeff++
15:21:40 <jeff> bshum: or, shorten to @addchair nickname
15:21:41 <bshum> I have it now
15:21:43 <bshum> #chair
15:21:43 <pinesol_green> Current chairs: bshum denials
15:21:44 <jeff> good deal.
15:22:04 * jeff takes down the PLEASE STAND BY WE ARE EXPERIENCING TECHINCAL DIFFICULTIES slate
15:22:06 <eby> technology+-
15:22:30 <bshum> So we were talking about 2.2?
15:23:14 <bshum> Sounds like we should set an action item for the bug wranglers to target / mark bugs for 2.2.0
15:24:28 * senator also encourages Dyrcona to recruit help to that end if needed
15:24:34 <berick> and see the Importance is set
15:24:42 <senator> for my part no further updates re 2.2.0
15:24:54 <bshum> #action Dyrcona (and others) to help target and mark importance for bugs against 2.2.0 milestone.
15:26:08 <bshum> Alrighty.
15:26:18 <bshum> Looks like we skipped a bunch of stuff and headed to 2.2
15:26:29 <bshum> berick had an agenda item about the proposed 2.3 timeline
15:26:37 <bshum> #topic Proposed 2.3 Release Schedule
15:26:44 <bshum> #link http://libmail.georgialibraries.org/pipermail/open-ils-dev/2012-May/008263.html
15:27:52 <berick> i think a simple #meh will suffice.  (it's early).  as long as there are no obvious problems with the proposal
15:28:43 <eeevil> very well ... I'll see your #meh and raise you an #hrm
15:28:57 <gmcharlt> I think the overall timeframe is OK, but I do have a question of whether there's anything in particular, particularly  any major architecture bits, targetted for the alpha
15:29:04 <gmcharlt> as opposed to the feature freeze for beta
15:29:42 * tsbere would like to aim new xulrunner at before 2.3 alpha
15:30:07 <eeevil> I think the alpha could start later and be shorter ... but maybe that doesn't really matter since we'll be doing it all again in jan/feb
15:30:18 <berick> i'd like to make serious play at getting the kid's pac code in by alpha.  i can dream.
15:30:52 <berick> point taken, though, we could push A1 back a week or two
15:31:18 <berick> though, that will be a pretty short alpha period
15:31:27 <berick> (we're running on limited time all around)
15:31:49 <jeff> GSOC timeline suggests that the new Dojo work would not be complete in time for alpha or beta.
15:32:13 <jeff> Joseph's proposed timeline is slightly more aggressive, but still suggests "not in time for 2.3".
15:32:54 <berick> jeff: what's his timeline?
15:34:14 <jeff> oh, sorry. wrapping up July 29 with an approx two week buffer for the unexpected ending Aug 13: http://evergreengsoc.blogspot.com/2012/04/2012-gsoc.html
15:34:50 <jeff> GSOC 2012 suggested "pencils down, start polishing up your work" date isn't until Aug 13.
15:35:39 <berick> ah
15:35:41 <eeevil> IOW, if it's good enough for alpha by his expected finish date...
15:36:25 <eeevil> one of the things that it was hoped time-based releases would help with is last minute mad dashes ... I think it might not as much as we'd like ;)
15:36:40 <eeevil> but, (as a wise man once said) meh ... we shall see
15:37:32 <berick> yeah, i think there will still be mad dashes, we'll just have a better sense of when the mad dashes are required to be done
15:37:48 <gmcharlt> eeevil: oh, it won't stop the mad dashes -- it just presents a brick wall for them to run into before too much haste tempts us to delay ;)
15:38:04 <berick> so, stick w/ the proposal, and if the GSOC code is ready on time, it gets in, otherwise no?  (IOW, don't change the release date to accommodate GSOC)
15:38:41 <gmcharlt> berick: +1 # might be worth tweaking next year if we get into GSoC again, but then again, we'll have more time to plan
15:38:41 <eeevil> it's a fair question to ask, so perhaps "to the list!" ?
15:40:33 <bshum> Alright
15:40:46 <berick> list++
15:41:14 <bshum> Alright.
15:41:16 <berick> i'll send something to the list
15:41:41 <berick> to the effect of whether GSOC schedule should affect our release schedule
15:42:07 <bshum> #action berick to reply to 2.3 vs. GSOC schedule
15:43:00 <bshum> So the last agenda items relate to the releases
15:43:05 <bshum> #topic Releases
15:43:21 <bshum> #info See agenda for details regarding OpenSRF releases.
15:43:46 <bshum> Anything else we need to discuss regarding releases right now?
15:44:31 <berick> bshum: i'm going to open an LP ticket to address denials's concern re:2.1.0
15:45:53 <bshum> Cool deal.
15:47:05 <bshum> Alrighty then
15:47:12 <bshum> #topic Open Time
15:47:56 * berick cues jeopardy music
15:48:35 <bshum> Just a random thought that denials had while we were at Ottawa, he thought it might be fun to plan a developer in-person meeting sometime between now and EG 2013
15:48:37 <eeevil> I'll look at CORS some time ... soon-ish
15:49:07 <gmcharlt> bshum: +1
15:49:20 <berick> indeed, and not only fun, but highly valuable
15:49:42 <tsbere> But *where*? We are a tad spread out ;)
15:49:57 <bshum> I figure it might be similar to how Conifer hosted tpac dev day, etc.  So we should pick the brains of various folks to see what we can think of.
15:50:00 <eeevil> bshum: Atlanta might be generally equidistant ;)
15:50:39 <eeevil> (bonus: relatively cheap hotels, and free meeting space)
15:50:43 <bshum> I guess I can take an action item to start a discussion on the general list.
15:50:43 <eeevil> just putting that out there
15:50:57 <tsbere> If it is a dev meeting wouldn't the dev list make more sense?
15:51:09 <bshum> Oh, right :)
15:51:11 <eeevil> or both
15:51:55 <bshum> #action bshum to post something to lists about denials suggestion to have an in-person dev meeting before the next EG conference.
15:52:27 <bshum> Alrighty, if there's nothing else to discuss for now, I think we can adjourn this meeting.
15:53:09 <denials> +1
15:53:20 <bshum> Cool, thanks for coming everyone.
15:53:21 <eeevil> bshum++
15:53:23 <eeevil> denials++
15:53:24 <bshum> And welcome back denials
15:53:31 <bshum> kmlussier++ # meeting poll wizard
15:53:42 <bshum> #endmeeting