15:00:59 <gmcharlt> #startmeeting
15:00:59 <pinesol_green> Meeting started Tue Feb 12 15:00:59 2013 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:59 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:02 <bshum> gmcharlt++ #bravery
15:01:14 <gmcharlt> #info Agenda is at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2013-02-12
15:01:18 <gmcharlt> #topic Introductions
15:01:25 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox Software
15:01:44 <jeff> #info jeff is Jeff Godin, Traverse Area District Library (TADL)
15:01:45 <bshum> #info bshum = Ben Shum, Bibliomation
15:01:49 <tsbere> #info tsbere = Thomas Berezansky, MVLC
15:01:51 <csharp> #info csharp = Chris Sharp, GPLS (at Code4Lib, so not fully engaged)
15:02:10 <senator> #info senator = Lebbeous Fogle-Weekley, Equinox Software
15:02:12 <berick> #info berick Bill Erickson, Equinox
15:02:13 <dbwells> #info dbwells = Dan Wells, Calvin College
15:03:25 <remingtron> #info remingtron = Remington Steed, Calvin College
15:03:39 <gmcharlt> ok, moving on -- folks can continue to introduce themselves
15:03:47 <gmcharlt> #topic Action items from Last Meeting
15:03:57 <gmcharlt> #topic Dojo 1.6 test server
15:04:07 <gmcharlt> edoceo: any update on that? ^^
15:04:26 <StephenGWills> #info Steve Wills Balsam Consortium
15:04:52 <eeevil> #info eeevil = Mike Rylander / Equinox Software (not driving this week)
15:05:07 <gmcharlt> eeevil: the commuters of Atlanta thank you!
15:05:15 <bshum> Well, fwiw, I did install the dojo 1.6 test branch on one of our servers along with dojo 1.6.1 and it didn't work at all.  None of the widgets populated and most of the pages didn't render at all.
15:05:34 <bshum> The dojo 1.8 branch is even further out of sync and had a ton of conflicts so I didn't really know what to do there.
15:05:43 <Dyrcona> #info Dyrcona = Jason Stephenson, Merrimack Valley Library Consortium
15:06:00 <bshum> *conflicts with master.
15:06:03 <eeevil> bshum: is this the GSoC's branch, or someone elses?
15:06:05 <ktomita> #info ktomita = Kyle Tomita Catalyst IT Services
15:06:33 <bshum> eeevil: I was using the 1.6 branch that tsbere put together from joelewis work and the 1.8 branch that came out of gsoc work too.
15:06:45 <bshum> Both of those are in the working repos...
15:07:09 <smyers_> #info smyers_ = Scott Myers Catalyst IT Services
15:07:10 <tsbere> My branch for 1.6 was bascially the 1.8 work without the 1.7+ commits at the end.
15:07:15 <bshum> #link http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/dojo_1.6_maybe
15:07:16 <eeevil> bshum: IIRC, joe never went past 1.7 in any meaningful way ...
15:07:45 <bshum> Then yeah, in either case, the 1.6 branch was pretty broken for my attempts.
15:07:47 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
15:08:14 <eeevil> bshum: are there other 1.6 branches that you're aware of?
15:08:14 <gmcharlt> ok, does anybody have any tuits to poke at Joe's branches, or should we consider ourselves back at the starting point?
15:08:33 <acoomes> #info acoomes is Andrew Coomes, Catalyst IT Services
15:08:55 <paxed> #info paxed = Pasi Kallinen, Regional Library of Joensuu
15:09:02 <bshum> eeevil: I'll check the repos and see what I can find.  I'm not sure all of them ended up linked anywhere on some pages.
15:09:33 * tsbere redirected his tuits to finding a way to remove dojo, rather than use new versions
15:09:35 <eeevil> tsbere: do you know of raw joelewis branches, or others than yours?
15:09:41 <bshum> tsbere is right, I was thinking of http://git.evergreen-ils.org/?p=evergreen/joelewis.git;a=shortlog;h=refs/heads/dojo_1.8
15:09:53 <bshum> Which is joelewis' repo
15:09:54 <tsbere> eeevil: ^^^ What bshum just linked to
15:10:13 <eeevil> tsbere: yes, after I asked :)
15:10:29 <soozle_> soozle_ = Suzannah Lipscomb, Equinox
15:11:43 <eeevil> gmcharlt: looks like the only person with experience on the existing code says no ...
15:11:54 <eeevil> (other than joe lewis, of course)
15:12:08 <gmcharlt> eeevil: sadlly, I agree with you
15:12:13 <jeff> I'm interested in doing what I can to assist with dojo modernization, but feel that I lack the guaranteed tuits to commit to any action item. Happy to assist, can't commit to taking the lead.
15:12:59 <gmcharlt> OK, I'm going to put tuit-searching as a general action item, in case it gets traction later
15:13:06 <bshum> +1
15:13:26 <eeevil> +1
15:13:56 <gmcharlt> #action See if anybody has cycles to spare on (or funding to apply to) Dojo modernizatio
15:14:23 <gmcharlt> OK, I think that make's the next action item (kmlussier to help coordinate end-user testing) moot for now
15:14:27 <gmcharlt> kmlussier: do you agreee?
15:15:12 <kmlussier> Yes
15:15:22 <gmcharlt> ok; moving on
15:15:25 <gmcharlt> #topic eeevil to continue to prod folks about jspac removal blockers
15:15:58 <gmcharlt> and to expand the topic a bit beyond just the pokage ... how are folks feeling nowadays about removing jspac from 2.4?
15:16:16 <eeevil> I did not do any prodding ... which we can blame for no movement on said
15:16:29 <paxed> i'm all for removing jspac from 2.4
15:16:33 <bshum> I haven't changed my feelings, which is to kill JSPAC with fire.  But I suspect everyone knew that.
15:16:37 * csharp thinks it's abandonware at this point
15:17:14 * Dyrcona doesn't use it any longer, so whatever everyone else decides works for me. :)
15:17:25 <gmcharlt> I agree; I think the only question at this point is whether we continue the formal deprecation for one more release or pull the trigger
15:18:02 <csharp> I've not heard from anyone in the channel or on the lists who is trying to keep it alive for end users
15:18:09 <tsbere> I don't see any reason to keep it around any longer myself
15:19:06 <eeevil> concerns raised by mrpeters-isl_ re files from jspac in use elsewhere (my only real concern is css, but JS is possible too) gives me pause, re kill with fire
15:19:28 <bshum> Yeah, css is still being used in parts of the staff client interfaces.
15:20:00 <bshum> But JS and XML should be safely removable (or hardly missed?)
15:20:10 <berick> i'm not 100% sure of that
15:20:31 <tsbere> Some of the "common" js is used in the staff client. I don't think any of the skin javascript is used elsewhere.
15:20:36 <csharp> sounds like it may need to exist for another release then, right?
15:20:36 <eeevil> so, I think the middle way -- remove all references to it from apache configs, force staff client to tpac, redirect rules in apache config for bookmarks ... but leave the files there -- is safest
15:20:41 <gmcharlt> eeevil: applying the fire selectively then, would do it though -- i.e., I think this the mechanics could be dealt with during test of a hypothetical patch removing jspac
15:20:46 <csharp> eeevil: +1
15:21:06 <bshum> Fair enough.  (probably didn't realize those connections enough)
15:21:12 <berick> heh, just remove index.xml
15:21:19 <berick> done and done
15:21:23 <eeevil> berick: we can certainly do that much ;)
15:21:37 <gmcharlt> heh
15:21:46 <eeevil> or move it
15:21:50 <Dyrcona> Perhaps someone should start a branch and remove various bits?
15:22:05 <gmcharlt> #vote Remove JSPac from 2.4 (in whole or part)? Yes, No
15:22:13 <gmcharlt> er, rather
15:22:19 <gmcharlt> #startvote Remove JSPac from 2.4 (in whole or part)? Yes, No
15:22:37 <gmcharlt> #vote Yes
15:22:48 <paxed> #vote yes
15:22:54 <tsbere> #vote Yes
15:22:55 <senator> #vote Yes
15:23:01 <csharp> #vote Yes
15:23:01 <bshum> #vote Yes
15:23:02 <StephenGWills> #vote yes
15:23:07 <ktomita> #vote yes
15:23:09 <eeevil> #vote yes (assuming "remove" can be described as I did above ;) )
15:23:26 <gmcharlt> eeevil: yep, I intentionally left wiggle room on exactly how we do it
15:23:33 <kmlussier> #vote yes
15:23:40 <Dyrcona> #vote yes
15:24:04 <gmcharlt> (I'm hoping that we do enough work this cycle to remove it all, but I agree that we may run out of time and have to do the middle way)
15:24:11 <gmcharlt> $showvote
15:24:12 <eeevil> bshum: you have a crazy, killing look in your eye. do you want to put together something resembling that?
15:24:52 <gmcharlt> (hmm, OK, doesn't look like the meetbot vote plugin is present (or at least, working how I expect it to), but no matter
15:25:11 <jeff> #vote yes
15:25:13 <jeff> #showvote
15:25:18 * jeff shrugs
15:25:25 <bshum> eeevil: I think tsbere already has front-facing code for getting JSPAC out of TPAC's way.  So I would suggest starting with some of that.
15:25:37 <tsbere> gmcharlt: You had a $ instead of a # on the showvote
15:25:49 <gmcharlt> #showvote
15:25:49 <bshum> And if there are JS ramifications, I probably should look into what I may have broken in our servers too...
15:25:50 <Dyrcona> @showvote
15:25:51 <pinesol_green> Dyrcona: Leave me alone, I'm busy right now.
15:25:55 <Dyrcona> heh.
15:25:58 * gmcharlt shrugs
15:26:16 <eeevil> bshum: indeed. I'm asking for someone to lead the charge toward an omnibus jspac-excising branch
15:26:18 <jeff> i don't think that the vote was very close. :-)
15:26:23 <gmcharlt> bshum: that still sounds like you're willing to spearhead it :)
15:26:36 <bshum> Sure I'll take the action item for that.
15:26:41 <gmcharlt> ok
15:27:00 <gmcharlt> #agreed JSPac will be (at least in effect) removed from Evergreen in release 2.4
15:27:12 <tsbere> I am willing to help with that as well (beyond my existing branches that were previously mentioned)
15:27:25 <gmcharlt> #action bshum will take charge of wrangling patches to remove JSPac
15:27:50 <eeevil> tsbere: thanks
15:27:51 <gmcharlt> tsbere: thanks
15:27:53 <gmcharlt> moving on
15:27:56 <gmcharlt> #topic denials to add a mention in the docs about PHP & Android efforts
15:28:12 <gmcharlt> anybody else have anything to say about that, since denials isn't here?
15:28:31 <gmcharlt> ok, sounds like not
15:28:32 * Dyrcona just volunteered to look at Pranjal's PHP code for OpenSRF.
15:28:42 <gmcharlt> Dyrcona++
15:29:00 <senator> which is here if anyone missed it: https://bugs.launchpad.net/opensrf/+bug/1109301
15:29:00 <pinesol_green> Launchpad bug 1109301 in OpenSRF "New submission for a client library in php for openSRF" (affected: 1, heat: 6) [Undecided,New] - Assigned to Jason Stephenson (jstephenson)
15:29:10 <senator> Dyrcona++
15:29:26 <gmcharlt> I'm going to bypass the "testing to be performed by various parties with older xulrunner versions" AI for now, as I thiink it better discussed in the memory leak discussion later in the agenda
15:29:59 <gmcharlt> as for the next AI, well, the future of the staff client meeting has happened, so not sure there's much to say about that at the moment
15:30:14 <gmcharlt> and finally
15:30:31 <gmcharlt> #item denials did issue a call for Evergreen 2.3 users to submit detailed workstation profiles
15:30:39 <gmcharlt> so I think we can move on to
15:30:44 <gmcharlt> #topic GSoC 2013
15:30:58 <gmcharlt> #info Google Summer of Code 2013 has been announced
15:31:31 <gmcharlt> so one big question ... do we want to apply this year?
15:31:44 <eeevil> no (IMNSHO)
15:32:21 <gmcharlt> eeevil: sure -- can you expand on why?
15:32:27 <eeevil> heh
15:33:30 <gmcharlt> if not, I'm happy to jump in -- IMO, if we do apply (and get accepted), I think we should not have as many as four students
15:33:43 <eeevil> well, there were great efforts on all parts (some more than others (most more than me)), but in the end I can't identify anything that I would argue for as "success" as defined by GSOC
15:33:56 <gmcharlt> it's my impression that the mentors last year did not have enough time to, well, mentor
15:34:23 <gmcharlt> and if we do this again, I'd like to see at least a 2-1 mentor-to-mentee ratio
15:34:38 <gmcharlt> and a lot more developing in the open
15:34:50 <dbwells> I feel like my student and I were productive and wouldn't mind doing it again.
15:35:09 <dbwells> It would be nice to have a co-mentor, though.
15:35:17 <senator> i feel pranjal's work was of value, but i don't forsee having as much time this summer
15:35:24 <senator> with a co-mentor i would try again
15:36:16 <senator> it seems to take a lot to get the typical student to work in the open. and more still to get anybody else to engage that student in conversation if s/he does venture, however timidly, into the open
15:37:36 <tsbere> I find myself wondering if we have too many things students have to learn about the system itself before they can get anywhere
15:37:44 <bshum> I wasn't a mentor, so I can't say anything about the past.  But to me those kinds of issues are faced by new developers entering the project too.
15:37:44 <gmcharlt> senator: indeed it does
15:37:58 <bshum> *any new developers
15:38:19 <jeff> to give a sense of timeline, there are 34 days from now to when mentoring organizations can begin submitting applications, and 45 days until the due date.
15:38:21 <senator> we might think about projects that directly target our appallingly unclear designs
15:38:27 <senator> take a bite out of the learning curve
15:39:11 <eeevil> and we might consider mentoring an existing community member that wants a subsidy to do more over the summer...
15:39:29 <gmcharlt> senator: agreed -- doing that would mean a lot more prep-work in coming up with potential projects, of course
15:39:40 <StephenGWills> Maybe a good student project is building a runway for new developers?
15:39:52 <eeevil> IIRC, there's nothing in the GSOC rules that says a mentee needs to be a complete outsider, is there?
15:40:03 <jeff> eeevil: do we have any existing community members that meet the program eligibility requirements?
15:40:13 <senator> indeed. and gsoc doesn't want documentation projects unfortunately. i'm not sure whether we can actually frame making sense of the way things work as coding
15:40:21 <eeevil> jeff: I do not know
15:40:22 <jeff> eeevil: no, the faq addresses that -- they can continue existing work as long as they are otherwise eligible for the program.
15:40:28 <gmcharlt> StephenGWills: in theory -- but it would take an exceptional student to overcome the chicken-meets-egg problem, though joelewis came very close
15:41:12 <gmcharlt> jeff: which boils the question down to -- how many current community members who can code are still in schooL?
15:41:58 <eeevil> dbs is taking french classes, IIRC ;)
15:42:03 <Dyrcona> StephenGWills: I have considered writing such a roadmap.
15:42:10 <StephenGWills> is Gsoc limited to heads down coders?  what about IT admin student?
15:42:17 * eeevil ducks
15:42:20 * Dyrcona is taking a free on-line course in March, does that count? ;)
15:42:30 <gmcharlt> at the moment, I'm leaning more towards skipping GSoC this year, but using the GSoC idea as impetus for doing something this summer to lower the barrier of entry to new developers
15:43:25 <senator> DIG has really improved end user and admin documentation in the past couple years,
15:43:29 <eeevil> I'm happy to continue discussing ways to make GSOC more likely to succeed for us, but my vote is currently still "no"
15:43:38 <remingtron> If we skip GSoC this year, how does that affect our chances of being selected in the future?
15:43:43 * StephenGWills take an hour and read the rules.. against my MBA/IT electives ;)
15:43:48 <senator> and maybe we could muster at least a small effort to do some development oriented documentation or tutorials
15:44:02 <jeff> I wonder about future consideration also. If there's objection or we change our minds, it seems like there might be one more dev meeting between now and the deadline.
15:44:04 <gmcharlt> remingtron: it really doesn't, IMO
15:44:29 <gmcharlt> jeff: yes, we don't have to make a decision set in stone today
15:44:39 <Dyrcona> GSOC organizers seem to like us from what I gather.
15:45:15 <gmcharlt> Dyrcona: agreed
15:45:35 <gmcharlt> I think this topic definitely qualifies at this point as one to take to the mailing list for serious discussion
15:45:53 <gmcharlt> so, moving on...
15:46:07 <gmcharlt> #topic testing and test servers, particular testing.evergreen-ils.org
15:46:33 <gmcharlt> thoughts on resurrecting it?
15:47:08 <StephenGWills> testing vs demo server?
15:47:28 <Dyrcona> Well, what's the goal with testing? Will it be just master or will it include other branches?
15:47:58 <gmcharlt> StephenGWills: AIUI, it's not meant as a demo server, but a platform for automated building and testing
15:47:58 <eeevil> as mentioned before, the VM died a horrible death.  If anyone wants to apply the tuits to re-do it, ESI will happily put a new (redundant) VM up for that purpose.
15:48:10 <jeff> automated testing seems to be a useful thing, especially with multiple environments. what led up to testing.evergreen-ils.org being unavailable? time required to maintain?
15:48:17 <eeevil> right ... buildbot master
15:48:18 <jeff> ah. thanks for the info, eeevil.
15:49:04 <jeff> i'm interested in helping resurrect it.
15:49:20 <Dyrcona> Yeah, so am I.
15:49:45 <gmcharlt> jeff++
15:49:49 <eeevil> cool.  I will make it re-appear in the next few days.
15:49:54 <gmcharlt> Dyrcona++
15:49:55 <jeff> we should approach denials, if he hasn't already voiced interest/dis-interest already
15:50:12 <gmcharlt> #action ESI will recreate the testing.evergreen-ils.org VM
15:50:26 <eeevil> it'll be a squeeze server. I'll just need some pub keys
15:50:32 <gmcharlt> #action jeff and Dyrcona will speak with denials about rebuidling the buildbot
15:51:05 <gmcharlt> #topic OpenSRF release
15:51:14 <gmcharlt> #info There are a few branches of interest to be merged here for the next release. We should identify those and decide whether it's another patch release or something slightly more.
15:51:47 <eeevil> who's manning DNS for evergreen-ils.org these days? (I'm outta the loop ...)
15:51:59 <jeff> eeevil: launchpad has a suitable pubkey for me. ttps://launchpad.net/~jgodin
15:52:20 <gmcharlt> eeevil: we are, actually :)
15:52:26 <jeff> eeevil: galen coordinated a recent dns change for that zone
15:52:30 <eeevil> gmcharlt: good!
15:52:41 <eeevil> :)
15:53:09 <jeff> er, https://launchpad.net/~jgodin for that launchpad link with an ssh pubkey
15:53:39 <gmcharlt> re OpenSRF, my impression is that we have enough branches in the pipeline to think about doing a 2.2 release
15:54:17 <Dyrcona> gmcharlt: +1 re OpenSRF
15:54:34 <gmcharlt> my main question is whether we should wait for websockets support to gel a bit first
15:55:34 <gmcharlt> berick: the-legions-who-have-been-testing-bericks-branch: thoughts on ^^
15:56:35 <berick> gmcharlt: i would wait on the websockets
15:56:42 <berick> until further testing
15:56:55 <gmcharlt> berick: ok, thanks
15:56:59 <berick> and, really, some concensus on whether we want to use it
15:58:17 <gmcharlt> still, even without websockets, sounds like we have engouh in the pipeline, so I volunteer to do some branch-wrangling with the soft goal of doing a release in the next 3-4 works
15:58:31 <berick> gmcharlt++
15:59:07 <jeff> gmcharlt++
15:59:16 <jeff> berick++ # websockets
15:59:30 <gmcharlt> #action gmcharlt to do some branch management with an eye towards an OpenSRF 2.2 release in the next few weeks
15:59:45 <gmcharlt> #topic Next 2.2 and 2.3 point release scheduled for February 20.
15:59:57 <gmcharlt> #item Have the memory-leak branches been tested sufficiently to get them merged?
16:01:15 <gmcharlt> IMO, we're getting there ... but I think it needs some more testing
16:02:09 <gmcharlt> so I think I'll just leave it at that: please test the proposed patches for https://bugs.launchpad.net/evergreen/+bug/1086458
16:02:09 <pinesol_green> Launchpad bug 1086458 in Evergreen 2.3 "Staff client memory leaks in 2.3 and later" (affected: 4, heat: 34) [High,Triaged]
16:02:18 <gmcharlt> #topic Plans for 2.4
16:02:22 <gmcharlt> eeevil: ^^ ?
16:03:13 <eeevil> I was originally planning an alpha for this week
16:03:23 <eeevil> then the first beta at the end of Feb
16:04:22 <eeevil> however, there are so many pullrequests and so few merges (several, if not many, pullrequests are speed/stability improvements), that I'm probably going to push things back a week
16:04:22 <Dyrcona> eeevil: You plan to merge all the 2.4.0-alpha branches?
16:04:39 <Dyrcona> eeevil++ # mind reader.
16:04:41 <eeevil> Dyrcona: not by my lonesome, no
16:05:07 <eeevil> I certainly hope other committers want to get things committed (he said snarkily)
16:05:09 * bshum has slowly been merging things, one tiny branch at a time
16:05:37 * Dyrcona has a pile of things on his list that he should really take a look at.
16:06:01 <eeevil> anyway ... I have held the (apparently minority?) perception that April, not March, was our target
16:06:17 <bshum> Oops, so much for March.
16:06:38 <eeevil> (I was surprised by Sept, instead of Oct, for 2.3, but that doesn't really matter now, in the present)
16:06:48 <Dyrcona> I thought we decided on March & September because they would be better for academics?
16:06:48 <dbwells> eeevil: I was also thinking April, just based on history, until I realized that didn't add up.
16:07:36 <eeevil> I could be swayed ($$$ ;) )to push 2.4 out in March, but based on the outstanding pile of fixes (and features) that I know, quite for a fact, many folks want in 2.4, it would be a big mistake
16:08:26 <Dyrcona> eevil: No objections here. I'm a fan of "it's done when it's done, and not before."
16:08:47 <eeevil> plus, with the run-up to egconf, and the fact that (likely) a majority of developers and admins at aggressive EG sites will be there, it's not like a lot of movement will occur between whenever-we-release and the conference
16:11:21 <eeevil> so ... the plan looks like: alpha at the end of Feb, Beta on March 13, coincident with 2.3.5(?)
16:12:32 <eeevil> if sufficient testing occurs between then and March 26, I'll cut then for release after final testing
16:12:54 <gmcharlt> eeevil: I don't think it makes a huge difference wither it's March or not-late-April ... but I think it's something to keep in mind for the next release to finalize whether we're targeting April/Oct or March/Sept
16:13:10 <eeevil> however, I'm going to pin my hopes on April 3
16:13:38 <berick> fwiw, 2.3.5 will not be until march 20
16:13:46 <eeevil> gmcharlt: agreed. I think that should be an at-conference chat
16:13:57 <gmcharlt> so to summarize
16:14:02 <eeevil> berick: my apologies ... ok, beta will be a week before 2.3.5
16:14:13 <gmcharlt> #item 2.4 alpha at end of February
16:14:47 <gmcharlt> rather,
16:14:52 <gmcharlt> #info 2.4 alpha at end of February
16:15:02 <gmcharlt> #info 2.4 beta around March 13th
16:15:07 <gmcharlt> #info 2.3.5 on March 20th
16:15:19 <gmcharlt> #info 2.4.0 most likely on April 3
16:15:31 <gmcharlt> eeevil: berick: accurate? ^^
16:15:39 <eeevil> gmcharlt: indeed, thanks
16:16:01 <gmcharlt> so, final topic
16:16:08 <gmcharlt> #topic Plans for 2.5
16:16:27 <gmcharlt> decisions to make include picking RM for 2.5
16:16:50 <gmcharlt> I propose that we plan on deciding this at the time of the conference
16:16:56 <berick> solution to all of our problems: get a GSOC student to be the 2.5 RM
16:17:10 <bshum> I think raising the question about March/September vs. April/October seems pretty important and maybe we should post that to the mailing list for further reflection.
16:17:17 <gmcharlt> berick: I think Google frowns on actually killing the students ;)
16:17:21 <berick> heh
16:17:44 <eeevil> gmcharlt: only if they're producing working code
16:18:35 <dbwells> gmcharlt: +1 to deciding at the conference
16:18:38 <gmcharlt> now *that's* a motivator for participating in F/OSS projects!   "you get to live" ;)
16:19:21 <gmcharlt> so
16:19:40 <gmcharlt> #agreed 2.5 roles to be decided at time of the EG conference
16:19:48 <eeevil> +1
16:20:00 <gmcharlt> bshum: yes, I think that's a fair question to put to the mailing list
16:21:03 <gmcharlt> so, I think we've exhausted this meeting (if not the participants)
16:21:23 <gmcharlt> so I'm going to end it in
16:21:24 <gmcharlt> 3
16:21:27 <gmcharlt> 2
16:21:33 <gmcharlt> 1
16:21:36 <bshum> gmcharlt++ # brave meeting wrangler
16:21:40 <gmcharlt> #endmeeting