15:00:09 <bshum> #startmeeting 2012-02-27 - Developer Meeting
15:00:09 <pinesol_green> Meeting started Mon Feb 27 15:00:09 2012 US/Eastern.  The chair is bshum. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:09 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:50 <bshum> I can run us through the agenda, and pass reigns around when we get to specific sections.
15:01:08 <moodaepo> #info Agenda: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2012-02-27&#agenda
15:01:26 <moodaepo> bshum++
15:01:50 <bshum> #topic Who's here?  (sound off with #info if you are!)
15:02:03 <bshum> #info bshum is Ben Shum, Bibliomation
15:02:13 <mrpeters-isl> #info mrpeters-isl is Michael Peters, Evergreen Indiana
15:02:14 <phasefx_> #info phasefx is Jason Etheridge, Equinox
15:02:17 <tsbere> #info tsbere is Thomas Berezansky, MVLC
15:02:19 <kmlussier> #info kmlussier is Kathy Lusser, MassLNC
15:02:24 <tspnidler> #info Tim Spindler, C/W MARS
15:02:29 <berick> #info berick, Bill Erickson, Equinox
15:02:34 <dbwells> #info dbwells is Dan Wells, Calvin College
15:02:46 <csharp> #info csharp is Chris Sharp, GPLS
15:02:46 <moodaepo> #info moodaepo is Anoop Atre, PALS
15:02:57 <senator> #info senator is Lebbeous Fogle-Weekley, Equinox
15:03:02 <eeevil> #info eeevil = Mike Rylander, Equinox
15:03:07 <kivilaht1o> #info kivilaht1o is Olli-Antti Kivilahti, Library of Joensuu
15:03:11 <denials> #info dbs = Dan Scott, Laurentian University
15:03:41 <bshum> Wow, full house today.  Okay, we'll move on to past action items momentarily.
15:03:53 <bshum> Figured I'd try seeing what the full list of attendees would look like as a topic entry.
15:04:01 <bshum> Thanks for the experiment.  And welcome to the meeting.
15:04:05 <Dyrcona> #info Dyrcona is Jason Stephenson, MVLC
15:04:37 <bshum> #topic Review past action items
15:04:46 <bshum> #info dbs to update the release process doc with a mention of the version_upgrade directory
15:05:14 <bshum> I can see that got some new information added.
15:05:34 <bshum> dbs: Anything new we need for this?  Some #help to include in the notes?
15:05:48 <dbs> As noted, the real work is to define who does what and how, as a repeatable process
15:06:29 * dbs has basically waved his hands thus far; we have some precedents from the past such as issuing NOTICEs at the end of upgrade scripts for further manual efforts that may be needed
15:06:55 <jamesrf> #info jamesrf is James Fournie, BC Libraries Cooperative
15:07:14 <bshum> Also recalled some manual steps being included in upgrade steps we put together on wiki's / DIG docs
15:07:36 <dbs> yep, the db schema upgrade is just one small part of the overall upgrade process
15:08:57 <bshum> #help Need to find volunteers / assigned developers to manage and establish the parts of the upgrade process for the release checklist.
15:09:27 <bshum> We can talk about that now in more details or we can push it to the mailing list?
15:10:20 <dbs> If someone has some bright ideas about making the release process more functional & aligned to reality, that would be cool
15:10:41 * dbs notes that the release checklist currently has many missing 2.1 team members and no 2.2 team listed yet
15:10:52 <tsbere> Stop making numbered releases and have everyone run out of git? :P *ducks*
15:11:10 <moodaepo> tsbere++ # banging his same old drum
15:12:02 <bshum> #info Need to find missing team members for 2.1 release team and 2.2 release team.
15:12:22 <moodaepo> +1 to move it to mailing list
15:12:35 <bshum> Okay, action I guess to start a thread on seeking volunteers / firming up how all that will work.
15:12:51 * moodaepo will volunteer to send the request out/start discussion
15:13:15 <bshum> #action moodaepo to start mailing list discussion for to seek volunteers for release team
15:13:19 <bshum> *ack
15:13:24 <bshum> Silly enter key :(
15:14:11 <bshum> I think dbs' notes on the agenda are a great starting point for the discussion, fwiw.
15:14:13 <bshum> dbs++
15:14:20 <berick> agreed dbs++
15:14:27 <moodaepo> dbs++
15:14:54 <bshum> #info Other two agenda items are done, so... moving on.
15:15:11 <bshum> Anything else before our next topic?
15:15:54 <bshum> #topic Google Summer of Code 2012
15:16:05 <bshum> #link http://evergreen-ils.org/dokuwiki/doku.php?id=dev:summer_of_coding_ideas
15:16:29 <mrpeters-isl> I put a new VM up there about a week and a half ago
15:16:39 <mrpeters-isl> and some instructions on how to upgrade it
15:16:51 <dbs> mrpeters-isl++
15:17:06 <mrpeters-isl> tsbere had a sweet script to automate the update, but i havent had a chance to test it
15:17:17 <dbs> might be good for someone(s) to give it a shot to ensure it works in different virtualization envs
15:17:22 <mrpeters-isl> yes, please!
15:17:30 <bshum> mrpeters-isl: Speaking of the new VM, I asked some questions about including an associated README file (like dbs did last year), but haven't read too many details there.
15:17:38 <bshum> mrpeters-isl++
15:17:39 <mrpeters-isl> was built in vbox, from the old "trunk" vm
15:17:45 <moodaepo> mrpeters-isl++
15:17:53 <mrpeters-isl> it has notes in the vm about user accounts, passwords, etc.
15:18:02 <bshum> Ah, cool.
15:18:27 <tsbere> Looking over the list there, I can remove at least two things we should remove. I will do so momentarily: Customizable toolbars and remote XUL in the staff client.
15:18:36 <bshum> #info mrpeters-isl has a new VM based on master with instructions on how to upgrade it.
15:18:48 <bshum> #help Find volunteers to test the VM in different virtual environments.
15:19:09 <berick> in regard to the android app, I'll offer my services updating the opensrf / evergreen java libs
15:19:18 <mrpeters-isl> description -- http://desmond.imageshack.us/Himg26/scaled.php?server=26&filename=descriptiono.png&res=medium
15:19:36 <dbs> tsbere++ # for coding those up & removing them from the "wanted" list :)
15:19:55 * tsbere only gets full credit for one of them
15:19:58 <dbs> berick: what sort of time frame?
15:20:25 <berick> dbs: i basically did it this weekend, just needs a little review and LP ticket, so next week at the latest
15:20:29 <bshum> dbs: From your email to the list, sounded like we need folks to go check for / set "bitesize" bugs for applicants to test with?
15:20:30 <dbs> berick++
15:20:52 <dbs> bshum: would be helpful if we want to use that as a suggested means of testing applicant seriousness
15:22:00 <tsbere> Quick, someone find or introduce piles of typos we can have people fix! :P
15:22:28 <eeevil> tsbere: I try to, but then you guys get mad when I merge without a signoff
15:22:29 <tsbere> On a more serious note, an alternative would be to have them submit results of running through a test or two on an existing patch, possibly doing a sign-off included.
15:22:30 * eeevil ducks
15:22:59 <dbs> tsbere: yup, and that would be helpful. or creating an additional unit test.
15:23:49 <dbs> that reminds dbs, GSoC has had students working on unit testing...
15:24:04 <berick> now that we have sample bibs and (pending) sample users, extending the test data set might be a good project
15:24:24 <berick> creating circs and more complicated relationships, etc.
15:24:40 <dbs> and auto-testing the crap out of it
15:24:52 <berick> yeah
15:25:26 * tsbere has plans for a (limited) "stress tester" he needs to get on that would do circs, holds, and transits
15:26:06 * phasefx_ has some stored procedures for creating some of these test objects on the fly
15:26:12 <kivilaht1o> I made a stress tester as a part of my comparison of Evergreen and Koha
15:26:22 <dbs> and there's constrictor :)
15:26:25 <eeevil> constrictor? with known bibs, items and users, it's ...
15:26:25 <kivilaht1o> It uses the old javascriptless OPAC search
15:26:26 <eeevil> yeah
15:27:11 <kivilaht1o> its made with Python multi-mechanize
15:27:23 * moodaepo Has tried using jMeter to do stress testing but a while back
15:28:08 <kivilaht1o> it creates statistics on the fly, and I extended it to return search result html-pags so I can debug deviations from normal search response times
15:28:32 <kivilaht1o> I can share, if any help
15:28:37 * dbs is somewhat interested in stress testing, but as noted there seems to be a lot of coverage in that area. testing that the results match expectations, otoh...
15:28:40 <moodaepo> kivilaht1o++
15:29:23 <bshum> So we're agreed to support a GSOC application this year then?  And have folks poke at wiki pages, add ideas, etc.
15:29:33 <moodaepo> bshum: +1
15:30:36 <dbs> Do we have any other willing / able mentors?
15:30:37 <eeevil> dbs: which is what constrictor does with it's scripts ... just it can also lead a botnet to pound at the same time
15:31:35 <phasefx_> just for the logs, one more in the stress testing arena: collab/phasefx/performance_testing @ working/Evergreen.git
15:31:37 <eeevil> dbs: expect at least one more from Equinox... in the next day or two
15:31:51 <eeevil> (re mentors)
15:31:59 <moodaepo> eeevil++
15:32:10 <senator> yeah me
15:32:14 <senator> i'll mentor
15:32:39 <moodaepo> senator++
15:32:41 <bshum> senator++
15:33:07 <dbs> eeevil: as far as I recall, constrictor doesn't report those results in a standard fashion that fits into an overall testing harness. e.g. it's good for humans to test manually, not so good for automated tests of the "make test" kind
15:33:26 <dbs> perhaps a reasonable job for a hypothetical GSoC student to tackle though
15:33:29 <dbs> senator++
15:33:42 <dbwells> I am also interested in mentoring, if needed
15:33:51 <moodaepo> dbwells++
15:34:06 * moodaepo mentors coming out of the woodwork today!
15:34:10 <dbs> dbwells: awesome! GSoC suggestions for 1st year orgs are to have a 2:1 ratio of mentors to students
15:34:32 <eeevil> dbs: it dumps all that to a sqlite db, actually. so gluing that should be simple
15:34:49 <dbs> eeevil: I'm sure it would be simple. I'm saying that it doesn't do that today.
15:35:01 <bshum> Yay mentors!  dbwells++
15:35:06 <eeevil> the scripts themselves can be as complicated (testing values) or not (did we get anything without an error) as one wants
15:35:48 <bshum> #info Any GSOC mentor volunteers, please contact dbs for further details.
15:36:00 <dbs> eeevil: great, please hook it up to python's unittest or something and then we can integrate it into the buildbot
15:36:16 <bshum> Anything else before we move on to the next topic?
15:36:41 <dbs> bshum: gmcharlt had offered to act as org admin for GSoC, actually, so maybe dbs/gmcharlt? we co-admin'ed last year
15:36:42 * eeevil puts down the drum
15:36:53 * dbs pings testing.evergreen-ils.org
15:36:54 <bshum> Ooops, thanks dbs.
15:37:19 <bshum> #info Correction:  Contact dbs/gmcharlt for more details if willing to be a GSoC mentor.
15:37:47 <dbs> bshum: one further thing: how many slots should we apply for? Might make sense to apply for 1 less than the number of willing/available mentors?
15:38:18 <dbs> and then we can have mentors paired up with students who have the best technical fit, perhaps
15:38:39 * dbs setting up a secret plan to escape having to do any actual work
15:38:59 * moodaepo wonder if we need this in the minutes > #help Request dev list to update wiki pages, add project ideas & submit bite size bugs to launchpad for GSoC.
15:39:23 <moodaepo> dbs++ # for already doing quite a bit of the 'work'
15:40:24 <moodaepo> #help Request dev list to update wiki pages, add project ideas & submit bite size bugs to launchpad for GSoC.
15:40:25 <bshum> Since #help isn't chair only, anybody can use that to include information for the logs.
15:41:33 <bshum> dbs: Re: slots, sounds logical to me, I only wish I could help more myself.  But you or gmcharlt can let us know what we (other devs/non-devs) can do to help out.
15:41:58 <bshum> So if we get 4 willing mentors, aim for 3 slots?
15:42:01 <dbs> bshum: it takes a community to raise a dev!
15:44:06 <bshum> Okay, next topic then.
15:44:25 <bshum> #topic Evergreen 2.2 alpha2 / beta1 / RC ?
15:45:19 * moodaepo notes..now this is the topic which we have all been waiting for right kmlussier?
15:45:45 <tspnidler> i would like to give a + for dbs original suggestion about time release ala linux
15:46:15 * tspnidler hears kmlussier on the phone
15:46:31 <Dyrcona> depending on what makes it in, the next release should probably be 3.0. ;)
15:46:46 <moodaepo> Dyrcona++
15:46:51 * eeevil thought dbs/tsbere/bshum/csharp were going to cut (or planning to, or discussing) ... something ... a month ago
15:46:55 <Dyrcona> Actually, tsbere++
15:47:23 <tsbere> I have gotten very confused as to what the process is supposed to be at this point for upgrade scripts.
15:47:27 <eeevil> s/bshum/mrpeters-isl/ ?
15:47:37 <Dyrcona> some weeks ago we said we'd do an alpha2 release and it never happened.
15:47:39 <tsbere> Without knowing what I am supposed to do with that chunk, I can't cut a tarball. :(
15:48:08 <dbs> http://evergreen-ils.org/meetings/evergreen/2011/evergreen.2011-12-20-12.01.txt
15:48:29 <eeevil> tsbere: "what's the last number in the previous tarball"; cat that+1 that+2 ... > upgrade.sql
15:49:01 <tsbere> eeevil: Last time I did that it didn't work without lots of testing and tweaking after the fact.
15:49:21 * tsbere even otherwise automated that process before finding out about the issue later
15:49:44 <bshum> eeevil: I vaguely recall that I was supposed to try a 2.0 cut at some point, but still haven't gotten around to it.
15:50:02 <bshum> Now i'm caught up trying to test 2.1-2.2 and beyond
15:50:42 * tsbere continues to tweak his make release script, for the record, and if he knows how to do something to the point of automation he will add it there
15:50:58 <eeevil> tsbere: there's the seeds of a db update script already, under build/tools/
15:53:49 <bshum> tsbere: While I figure out what's "missing" from the 2.1-2.2 upgrade script I'll pass along notes on that to IRC / dev list.
15:54:02 <mrpeters-isl> i dont remember anything about that?
15:54:09 <mrpeters-isl> but i could be forgetting
15:54:11 <eeevil> mrpeters-isl: yeah, ignore me
15:54:28 <mrpeters-isl> ok, no problem.  ill do what i can though, if there is something.
15:55:29 <eeevil> mrpeters-isl: signing off branches at http://goo.gl/3EAzQ is something everyone with git skillz and an ssh pubkey can do :)
15:55:39 <eeevil> well, and a test server
15:55:48 <bshum> Maybe we should schedule some pullrequest action to occur this week and generally aim for an alpha2 end of this week or early next?
15:55:56 <mrpeters-isl> yep, ill update master again this week if need be
15:56:49 <mrpeters-isl> i think we can probably do an alpha server too once its cut
15:57:27 * kmlussier is finally off the phone and will give a +1 to any suggestion that will get alpha out end of this week or next.
15:57:31 <moodaepo> mrpeters-isl++
15:57:40 <berick> i'd be game for a pullrequest session.  to be clear, in this context, we're talking about pullrequests for bugs, right, not features?
15:58:19 <tsbere> berick: I would be willing to say "just things targeted at 2.2 in general" but including non-targeted bugs is good too. Some feature branches have been gathering dust for months.
15:58:46 <dbs> alpha is still fair game for features
15:59:13 <dbs> at least according to http://evergreen-ils.org/dokuwiki/doku.php?id=versioning
15:59:15 <berick> right, i'm not saying no features, just if we want to cut a2 "as fast as possible", i'm guessing LP blockers are what we're focusing on
16:00:54 <tsbere> dbs threw out a launchpad link at one point that shows 2.2 targeted things. There are 20 things still on it.
16:02:04 <berick> many of those are features that would be nice to get into 2.2, though, right?  or am I misundersting "targeted" in this context?
16:02:26 <tsbere> Some are features, some are bugs. Some could be considered both at the same time.
16:02:48 * dbs doesn't know if we have anything actually classed as "blocker"
16:03:19 <dbs> 0 critical, 11 high-importance overall
16:03:30 * berick is not anti-feature, just pro-release
16:03:46 <dbs> 10/11 high-importance bugs are "fix committed"
16:03:48 * tsbere is pro git installs, but will work on getting releases out anyway ;)
16:04:20 <berick> dbs: got a link to the 11th? :)
16:04:33 <tsbere> https://bugs.launchpad.net/evergreen/+bug/924367
16:04:33 <pinesol_green> Launchpad bug 924367 in Evergreen "Holds cannot be suspended" (affected: 1, heat: 6) [High,In progress]
16:05:22 <berick> i can grab that one
16:05:32 <berick> if we kill that, can we cut a2? :)
16:05:57 <bshum> +1 to berick's proposal for a2
16:06:04 * tsbere would prefer to do a run of features branches and bug fixes from the overall list, then cut a2 later this week
16:06:06 <kmlussier> +1
16:06:19 <tsbere> Gives me time, if I am doing the tarball, to double-check my make release script
16:06:20 <dbs> or we could just cut a2 right now
16:06:39 <moodaepo> dbs++
16:06:44 <bshum> Sounds like tsbere is volunteered for the action item for a2 cutting.
16:06:44 <dbs> and avoid the RUSH RUSH RUSH TO GET STUFF IN
16:06:47 <berick> @coin
16:06:47 <pinesol_green> berick: tails
16:07:01 * moodaepo called tails!
16:07:50 <berick> tsbere: we could do beta real soon, leaving room for feature merges
16:07:54 <tsbere> Well, if we want to cut a2 *now* and worry about stuff before beta/a3 instead I can just upload my latest test run of my make release script, I think.
16:07:56 <dbs> seems bizarre to hold off cutting a release to address a bug that has been open for 10 months and has no branch
16:08:07 <berick> dbs++
16:08:11 <berick> perspective
16:08:30 <dbs> tsbere++
16:08:36 * tsbere wonders what bug dbs is talking about now
16:08:50 <dbs> https://bugs.launchpad.net/evergreen/+bug/758982
16:08:50 <pinesol_green> Launchpad bug 758982 in Evergreen "2.0, 1.6, Transactions not closing for LOST items once xact has been re-opened for modified billings. " (affected: 6, heat: 26) [High,Confirmed]
16:09:05 <tsbere> ahh. ok.
16:09:39 <bshum> So, tsbere to cut Evergreen 2.2 alpha2 this week, pending his tests for make release script, etc.
16:09:50 * dbs started at https://bugs.launchpad.net/evergreen/, clicked "High importance bugs", and that was the only one not "Fix committed". guess it wasn't the same as yours :)
16:10:37 <bshum> Then we issue a call for final features to be merged on the lists, along with bug ticket & branches?
16:10:38 <tsbere> dbs: Second one from the bottom there - In Progress, not Fix Committed.
16:10:56 <tsbere> launchpad-- # Re-using colors
16:10:59 <dbs> tsbere: ah, damned colour is the same
16:11:06 <dbs> yeah, launchpad--
16:11:14 <dbs> also dbs-- # lack of reading / laziness
16:11:46 <bshum> #action tsbere to cut Evergreen 2.2 alpha2 this week, pending his tests for make release script, etc.
16:12:12 <tsbere> On a related note, anyone have issues with getting the updated upgrade script pushed for https://bugs.launchpad.net/evergreen/+bug/798255 ?
16:12:12 <pinesol_green> Launchpad bug 798255 in Evergreen master "archiving stat cats with aged circulation" (affected: 2, heat: 14) [Medium,In progress]
16:12:45 <bshum> #info Final features will need to be merged in before 2.2 alpha3 / beta1.
16:13:10 <moodaepo> bshum++
16:13:38 <dbs> bshum: if we have an alpha3, not true
16:13:55 <bshum> dbs: Right... :)
16:14:13 <bshum> #info Correction:  dbs notes that alpha3 is not feature-freeze, only beta and beyond
16:14:29 <dbs> So... I guess we'll make the call about alpha3 / beta1 after a round of testing alpha2?
16:14:44 <bshum> +1
16:14:47 <tsbere> +1
16:15:00 <kmlussier> I notice there are no pullrequest meetings on the Evergreen calendar anymore. Does one need to be scheduled to help with the merging of final features?
16:15:05 <mrpeters-isl> #info master.evergreen.lib.in.us updated with master as of 2/27
16:15:23 <mrpeters-isl> #info Indiana will put up a server with alpha2 when available
16:15:49 <bshum> #agree Generally agreed that decision on alpha3 / beta1 will come after a round of testing alpha2 release.
16:16:13 <dbs> How long is a round? 1 week? 2 weeks?
16:16:34 <mrpeters-isl> #info master.evergreen.lib.in.us staff clients always at: http://master.evergreen.lib.in.us/updates/manualupdate.html
16:16:53 <bshum> kmlussier: By my recollection, pullrequest meetings are generally not on the calendars, they were just called whenever there was a move to have them.  (though generally held on every other week we didn't have a dev meeting)
16:17:12 <bshum> kmlussier: Officially setting meetings of that type would be a new move.
16:17:22 <kmlussier> bshum: ah, okay. Thanks for the explanation.
16:17:54 <bshum> dbs: Depending on volunteers, I would think 1 week, you could get some decent testing done.  But 2 weeks would be slightly more leeway on that.
16:19:21 <bshum> I think 1 week is good to get a sense of whether alpha2 is moving the right direction.  Testing the next release after that (be it alpha3 or beta1) more strenuously might be better.
16:19:26 <tspnidler> bshum: might be able to dedicate some staff here to testing if we had server (presumably from indiana) to do testing
16:20:04 * bshum yanks out calendar
16:21:00 <dbs> bshum++
16:21:08 <bshum> Soft dates:  Feb 29 (alpha2), March 7 (finish testing, decide on alpha3 or beta1), March 21 (finish more testing, beta2 or RC1)?
16:21:29 <bshum> That's a 1 week, 2 week spread
16:21:49 <bshum> And might fall into alpha3 and alpha4 if things still aren't lining up well.
16:22:50 <bshum> And largely depends on what sort of community support we see with testing / devs integrating branches, etc.
16:23:48 <bshum> (that's just my own made-up dates and scheduling, not anything "real" per say)
16:24:42 <bshum> (also notes that's we're almost 25 minutes overtime, so let's agree to see how alpha2 goes and talk again next week)
16:24:45 <berick> timeline looks sane to me
16:25:08 <berick> +1 to a2, then talk
16:25:14 <kmlussier> bshum++
16:25:55 <bshum> #info Round 1 will last approximately 1 week, but let's see how alpha2 testing goes first, then re-evaluate release schedule.
16:25:56 <bshum> Okay.
16:26:11 <bshum> Last topic was something from tsbere about xulrunner/firefox 4+
16:26:24 <bshum> #topic Applying Xulrunner/Firefox 4+
16:26:45 <tsbere> We may have covered it informally earlier, but I can only test so much to ensure it is working.
16:27:13 <tsbere> #info Firefox/XULRunner 4+ bug at https://bugs.launchpad.net/evergreen/+bug/942134 - Needs testing. Lots of it.
16:27:13 <pinesol_green> Launchpad bug 942134 in Evergreen "Improve Firefox/XULRunner Support" (affected: 1, heat: 6) [Medium,New]
16:27:19 <bshum> tsbere++
16:27:31 <dbs> tsbere++
16:27:34 <bshum> #help Please help to test the new xulrunner branch.
16:28:08 <kmlussier> tsbere++
16:28:09 <jamesrf> can we munge that into alpha2 since we're already testing?  or is that crazytalk
16:28:22 <dbs> jamesrf: no
16:28:30 <Dyrcona> jamsrf: if we did, we'd have to call it 3.0
16:29:19 <dbs> jamesrf: we test in branches before merging to master, otherwise master goes back to being (potentially) horribly unstable and unusable by MVLC :)
16:29:32 <tsbere> and others ;)
16:30:07 <dbs> that said, nothing to stop tsbere/others from cutting an alpha2+xulrunner-awesomeness release & vm & test server to help with possible mergery for alpha3/beta1
16:30:16 <jamesrf> what's the fun of running master if there's no risk then? :)
16:30:38 <tsbere> jamesrf: Plenty of risk, with eeevil merging things without signoff and such. :P
16:31:04 * tsbere sees it as getting *really* good testing in of master on a fairly regular basis
16:31:05 <Dyrcona> and someone breaking holds. :)
16:31:07 <kivilaht1o> eeevil++
16:31:12 <kivilaht1o> :)
16:31:25 <bshum> Heh okay then.
16:31:29 <bshum> Last topic
16:31:35 <bshum> #topic Next Developer Meeting
16:31:54 <bshum> The doodle poll (when it was working) seemed to indicate this was a good day/time
16:31:57 <dbs> Dyrcona: fwiw, I think 2.1 qualified for 3.0 naming already for "major infrastructure changes" due to PostgreSQL 9.0 requirement, no?
16:32:08 * tsbere agrees
16:32:19 <tsbere> (on the 3.0 naming)
16:32:19 <Dyrcona> dbs: it did, and 2.2 qualifies as 4.0 by the same rules.
16:32:20 <dbs> bshum: the doodle poll promised an end at 16:00 EST!
16:32:31 <dbs> Dyrcona: so, who cares about naming then? :)
16:32:32 <bshum> dbs: I'm still honing my poor whip cracking skills.
16:32:37 * bshum misses gmcharlt
16:32:54 <dbs> bshum++ # you're doing a good job, there's a pent-up demand for discussing deep dark things
16:33:05 <Dyrcona> bshum++
16:33:12 <jamesrf> so if march 7 is an end of testing soft date, should the dev meeting line up more with that or would there be release meetings?
16:33:48 <gmcharlt> bshum++
16:33:48 <bshum> jamesrf: That was me picking middle of the week.  But if devs (and other interested parties) feel that Mondays are better times, we can move things around a bit.
16:33:50 <tsbere> Weekly dev/pull/whatever meetings until 2.2 is out, perhaps, doodle for each one the week before?
16:34:03 <bshum> tsbere: +1 to that I think
16:34:15 <bshum> Also, kmlussier++ for helping us setup the Doodle poll
16:34:22 * tsbere doesn't want to stick with just mondays, if only due to things like monday holidays ;)
16:34:46 <kmlussier> bshum: I can do it again if people want to use Doodle again.
16:34:48 <bshum> If we start one for this week, we can see what'd be a good time to meet next week for talking about alpha2 results.
16:35:00 <kmlussier> It's one contribution I can make since I can't code. :-)
16:35:45 <bshum> #action kmlussier to help setup another Doodle poll to find a good time/date for the next developer meeting week starting on March 5
16:36:16 <bshum> We can also discuss something more concrete for more regular meetings on the lists.
16:36:31 <moodaepo> kmlussier++
16:36:47 <bshum> Okay, is there anything else we should discuss today?
16:37:50 <bshum> Alright, thank you everyone for participating in the discussions today.  Back to our regularly scheduled programming then.
16:38:08 <kmlussier> bshum++
16:38:26 <kivilaht1o> bshum++
16:38:29 <kivilaht1o> me off to bed
16:38:39 <yboston> bshum++
16:38:44 <bshum> kivilaht1o: Oh, yes, thanks for staying up!
16:38:56 <dbs> bshum++
16:39:02 <bshum> #endmeeting